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 少给原始音频增加一个接收方
短指令可能采用以下形式：
跑一下测试
改这个文件的第二行
把刚才那个函数抽出来
短句、高频、连着说。
这类输入的暴露面容易被低估——因为它听起来「没什么敏感的」。
但工作场景中的语句往往带有项目信息：文件名、模块名、正在修改的内容、卡住的位置。
把 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，回复也可以在本机合成。
这套设计减少了一个云端语音服务接收原始音频的环节，但不能保证整句话不被任何云端服务看到。如果还希望转写文字不发送给云端模型，需要另外检查模型配置。
代码：语音实现目录
