Loop 的语音识别在运行后端的电脑上执行，不调用云端语音 API。
语音是需要安装资源、主动启用的可选能力。
代价是：ASR/VAD 模型下载约 167.3 MiB，解压后约 189.3 MiB，平台引擎和安装临时空间另算。
换来的是：识别和语音合成都由本机引擎处理。但识别后的文字仍会提交给配置的 Agent，手机音频也需要传到运行 Loop 的电脑。
下面拆解资源成本，并说明 Voice input 和 Voice call 为什么要采用两种提交方式。
上图：点击开始录音，停止并完成识别后，文字追加到可编辑草稿，再由用户手动发送；上面两条是排队中的后续消息。
1. 语音方案的选择标准
方案需要回答三个问题：音频在哪里处理？应用能否控制录音和提交时机？语音能否进入现有会话的权限、队列和历史流程？
云端语音 API。 能省去本地模型与运行时的维护，但需要上传音频，并受网络和服务计费影响。本文没有准确率或总成本对照测试，不对不同方案作优劣排名。
操作系统自带的听写。 可以把文字填入输入框，足以满足部分输入场景。但应用还需要管理录音、提交和朗读状态。
浏览器 Web Speech API。 可以减少接入代码，但是否调用远端服务取决于浏览器实现和配置。仅凭 API 名字不能判断它是否离线。
开源本地 ASR 模型。 可以离线，不依赖网络。但它不是一个「装上就能用」的东西——模型、运行时、音频处理都需要自行组装。
现成的桌面语音应用。 可以通过输入框等方式传入文字，但获得文字不等于接好了连续通话、暂停朗读、纠正方向和任务提交。
这里需要的是**「Loop 会话的一部分」**，复用现有权限、队列和历史流程。
本地模型允许应用控制推理位置，也要求应用负责资源分发和平台适配。
2. 本地推理能保证什么
原始音频处理和后续模型请求需要分别讨论。
2.1 少给原始音频增加一个接收方
短指令可能采用以下形式：
text跑一下测试
改这个文件的第二行
把刚才那个函数抽出来短句、高频、连着说。
这类输入的暴露面容易被低估——因为它听起来「没什么敏感的」。
但工作场景中的语句往往带有项目信息：文件名、模块名、正在修改的内容、卡住的位置。
把 ASR 放在本机，可以避免为了获得文字，再把原始音频发给一个云端语音服务。TTS 也在本机执行，不需要把回复文字交给云端语音合成服务。
2.2 文字提交和手机传输仍然存在
识别出的文字进入正常的会话提交流程。如果配置的是云端模型，模型服务就可能收到这段文字，与键盘输入一样。 本地语音不会改变这一点。
“本地”指的是运行 Loop 后端的电脑。从手机使用时，音频需要通过配对连接传到电脑。使用当前 tunnel 服务时，音频会经过中继，中继终止传输层 TLS。因此不能声称音频只留在手机，或中继无法接触音频。
实现边界是：Loop 的语音实现不调用云端 ASR/TTS。它不是“所有数据都不会出设备”。
3. 支撑它的资源管线
语音需要一组能一起工作的资源，下载一个模型文件并不代表语音已经可用。
3.1 模型之外还需要什么
| 环节 | 干什么 |
|---|---|
| VAD | 判断是否在说话、何时停止 |
| ASR | 把音频转成文本 |
| TTS | 把回复读出来 |
| 平台引擎 | 各平台底层的运行时 |
| 资源管理 | 版本、校验、安装、修复、卸载 |
每一项都要占空间，都要有代码。
3.2 资源如何到达本机
上图：按平台构建、版本化存储、用户触发安装后下载，再在本地校验和激活。能否安装还取决于兼容资源是否可用。
3.3 下载量和安装体积要分开算
| 组成 | 压缩包下载量 | 解压后体积 |
|---|---|---|
| ASR + VAD 模型 | 约 167.3 MiB | 约 189.3 MiB |
| 可选双语 TTS 模型 | 再加约 123.8 MiB | 再加约 168.0 MiB |
| 平台引擎 | 另算 | 另算 |
这些数字来自当前准备的固定模型资源，不是所有版本和平台的永久值。标题里的 167 MiB 只指 ASR/VAD 压缩包下载量，不是完整安装占用。 安装需要额外的压缩包和暂存空间；更新成功前还会保留原来的激活资源。
3.4 资源管理的六条约束
资源管理采用以下约束：
1. 用户主动安装
模型下载会消耗网络流量并占用磁盘空间，因此不放在启动流程中。
下载只在用户从设置中主动触发安装后开始；缺少兼容资源时显示不可用。
2. 资源必须版本化
每个公开的语音资源版本使用独立的语义版本号。同一公开版本不能替换内容，以便追溯当前启用的资源。
3. 要有完整性校验
模型文件有固定大小和 SHA-256 校验，引擎还需要通过版本探测。校验失败的资源不会被激活。完整性校验本身也不等于对整个供应链安全的证明。
4. 要能修复
修复按组件执行：重新校验文件，在兼容下载可用时，用经过校验的替代组件修复损坏目录。它不是只下载损坏的几个字节；本地导入的引擎也可能需要重新导入。
5. 卸载清理受管理资源
卸载会删除受管理的语音资源、未完成下载和损坏安装，保留其他 Loop 数据。
6. 不支持时明确显示不可用
平台或兼容资源不可用时，语音能力显示不可用，不自动降级到云端语音服务。这样可以保持音频处理边界一致。
4. Voice input 和 Voice call 为什么分开
两种模式复用同一条会话链，但采用不同的提交时机。
Voice input 是输入框的一种输入方式。 点击开始录音，停止后等待后端完成已排队音频和最后一句的识别，再把结果追加到草稿。用户可以修改文字，然后按 Send。丢弃录音会保留原有草稿和附件；识别结束失败时，不插入不完整结果。
Voice call 是持续监听的通话方式。 最终识别出的句子自动提交，普通请求进入现有任务队列。用户也可以让下一句用来纠正当前方向，在当前工具批次边界交给 Agent。键盘草稿和附件与通话保持分开。
朗读回复使用本机 TTS。用户开口或暂停朗读时，会清掉待播放的朗读内容，避免旧回复继续积压。中断朗读和挂断通话都不等于取消已提交的 Agent 任务，停止任务仍需使用任务取消操作。
识别结束、任务提交和播放中断需要分别管理，转写只是其中一个环节。
音频在有界处理缓冲区中流转，Loop 不把它保存成录音。提交的最终文字会按正常会话历史保存，并可能发送给配置的模型。 “不保存录音”不等于“没有留下任何信息”。
5. 当前限制
采用本地语音仍需考虑以下限制：
| 使用场景 | 建议 |
|---|---|
| 只需快速试用语音输入 | 仍要先安装兼容资源 |
| 所在平台不受支持 | 该能力不可用，且没有降级方案 |
| 对口音、噪声或术语有要求 | 需要用实际场景验证，本文不提供准确率排名 |
| 手机使用 | 需要安全上下文、麦克风权限、前台页面和到电脑的连接 |
6. 这笔账怎么判断
约 167.3 MiB 的模型下载量和一套资源管理流程，支持在 Loop 后端电脑上执行语音识别。再安装 TTS，回复也可以在本机合成。
这套设计减少了一个云端语音服务接收原始音频的环节，但不能保证整句话不被任何云端服务看到。如果还希望转写文字不发送给云端模型，需要另外检查模型配置。
代码：语音实现目录
Loop's speech recognition runs on the computer hosting its backend. The implementation does not call a cloud speech API.
Voice is optional: it requires installed resources and an explicit action to start listening.
The cost: about 167.3 MiB of ASR/VAD model downloads, or 189.3 MiB expanded, plus a platform engine and temporary installation space.
Recognition and synthesis run on the host. This does not mean a sentence never reaches a cloud service: the transcript goes to the configured Agent, and a phone sends audio to the Loop host.
This article explains that boundary, the resource pipeline, and why voice input and voice calls submit differently.
Above: click Voice input to record. After stopping and completing transcription, text is appended to an editable draft for manual submission. The two items above it are queued follow-ups.
1. Requirements for a voice integration
The criteria are where audio is processed, who controls capture and submission, and whether voice uses the existing session's permissions, queue, and history.
Cloud speech APIs. They remove the need to maintain a local model runtime, but introduce audio uploads, network requirements, and provider billing. This article includes no accuracy or total-cost benchmark and does not rank these options.
OS-level dictation. It can fill an input field and may be enough for that use case. Loop also needs control over capture, submission, and narration.
Browser Web Speech API. It can reduce integration work, but remote-service use depends on the browser implementation and configuration. The API name alone does not establish an offline guarantee.
Open-source local ASR models. Inference can run offline after resources are installed. The application still needs to integrate the model, runtime, and audio handling.
Desktop voice tools. They can pass text through an input field. That alone does not implement continuous calls, paused narration, steering, or task submission.
Voice needs to be part of the Loop session, using its existing permissions, queue, and history.
A local model gives the application control over inference location, along with responsibility for resource distribution and platform support.
2. What local inference actually changes
Raw-audio processing and subsequent model requests have separate boundaries.
2.1 One fewer recipient for raw audio
Short instructions might look like this:
textrun the tests
change line two in this file
extract that functionShort, frequent, back to back.
This kind of input is easy to underestimate, because it does not sound "sensitive."
But workplace utterances carry project information: file names, module names, what is being changed, where progress is blocked.
Local ASR avoids sending raw audio to an additional cloud speech service just to obtain text. Local TTS also avoids sending reply text to a cloud synthesis service.
2.2 Transcripts and phone transport still cross boundaries
Transcripts use the ordinary session submission flow. If the configured coding model is cloud hosted, that service may receive the text, just as it would receive typed input. Local speech does not change that.
Here, "local" means the computer running Loop's backend. On a phone, microphone audio travels to that computer through its paired connection. With the current tunnel service, audio passes through a relay that terminates transport TLS. Local inference does not mean audio stays on the phone or that the relay cannot access it.
The implementation does not call cloud ASR or TTS. It is not a guarantee that every piece of data stays on the input device.
3. The pipeline behind it
These resources need to work together. A downloaded model alone is not a usable voice feature.
3.1 More than a model file
| Stage | What it does |
|---|---|
| VAD | Detects whether speech is present and when it stops |
| ASR | Turns audio into text |
| TTS | Reads the reply back |
| Platform engine | The native runtime per platform |
| Resource management | Versioning, verification, install, repair, uninstall |
Each one costs disk space and code.
3.2 How resources reach the host
Above: build per platform, store versioned resources, then download, verify, and activate after the user requests installation. Installation also depends on compatible resources being available.
3.3 Download size is not installed size
| Component | Compressed download | Expanded size |
|---|---|---|
| ASR + VAD models | About 167.3 MiB | About 189.3 MiB |
| Optional bilingual TTS models | About 123.8 MiB more | About 168.0 MiB more |
| Platform engine | Additional | Additional |
These measurements describe the currently prepared pinned model assets, not permanent values for every version or platform. The 167 MiB in the title is the ASR/VAD archive download, not the complete installed footprint. Installation needs space for archives and staged files. Updates retain the previous activation until a replacement succeeds.
3.4 Six resource-management constraints
Resource management follows six constraints:
1. Explicit installation
Model downloads consume bandwidth and disk space, so they are not part of the startup path.
Downloads start only after the user requests installation in Settings. Missing compatible resources are reported as unavailable.
2. Resources must be versioned
Every public voice resource release uses an independent semantic version. Released content cannot be replaced under the same version, so the active resource set remains traceable.
3. Downloads must be verified
Model files have pinned sizes and SHA-256 checks. The engine also has to pass a native version probe. Resources that fail verification are not activated. Integrity checks alone are not proof of supply-chain security.
4. It has to be repairable
Repair operates at component granularity: recheck files and use verified replacement components when compatible downloads are available. It does not download only the few bytes that were damaged. A locally imported engine may need to be imported again.
5. Removal covers managed resources
Uninstall clears managed voice resources, partial downloads, and damaged installations while leaving unrelated Loop data intact.
6. Unsupported resources are reported as unavailable
When the platform or compatible resources are unavailable, voice reports that state without automatically falling back to cloud speech. This keeps the audio-processing boundary consistent.
4. Why voice input and voice calls submit differently
Both modes connect to the same session, but have different submission boundaries.
Voice input is a way to edit the composer. Click to record, then stop. The client waits for the backend to finish queued audio and the last phrase before appending text to the draft. The user can edit it and press Send. Discarding capture preserves the existing draft and attachments. A finalization failure reports an error rather than inserting incomplete text.
Voice call keeps listening. Final utterances submit automatically, and ordinary requests enter the existing task queue. The user can select the next utterance to correct direction; it reaches the Agent at the current tool batch boundary. The typed draft and attachments stay separate from the call.
Spoken replies use local TTS. Speaking over narration or pausing it clears the pending narration backlog. Interrupting playback or hanging up does not cancel an Agent task that was already submitted. Task cancellation remains a separate operation.
Transcription completion, submission, and playback interruption require separate state management. Turning audio into text solves only part of the interaction.
Audio flows through bounded processing buffers. Loop does not save it as a recording. Submitted final text is stored through normal conversation history and may be sent to the configured model. "No saved recording" does not mean "no information remains."
5. Current limitations
Local speech has several constraints that affect suitability.
| Scenario | Recommendation |
|---|---|
| Voice input is only needed for a quick trial | Compatible resources still need installing |
| The platform is unsupported | The capability is simply unavailable; there is no fallback |
| Particular accents, noise, or terminology matter | Test with those inputs; no accuracy ranking is provided |
| Phone use | Requires a secure context, microphone permission, a foreground page, and a host connection |
6. Is the trade worth it?
Speech recognition on the Loop host requires roughly 167.3 MiB of model downloads and a resource-management pipeline. Installing TTS adds locally synthesized replies.
This design removes an additional cloud speech service from the raw-audio path. It cannot guarantee that no cloud service ever sees the sentence. Keeping transcripts away from a cloud coding model requires separate consideration of model configuration.
Code: the voice implementation
The local voice runtime guide covers contracts and resource limits. The Web voice guide covers interactions and remote-audio boundaries.