端侧语音Agent落地指南：从语音记事本到Computer Use的技术细节

端侧语音 Agent 这个词，最近半年刷屏频率越来越高，从“语音记事本”“语音速记”这种最轻量的功能，到“Computer Use”这种让 AI 直接操作电脑的重交互，跨度大得让人眼花缭乱。很多人问我同一个问题：这些场景到底怎么落地的？端侧跑能不能扛得住？声音该怎么处理？模型选多大合适？我最近正好完整跟进了几个端侧语音 Agent 项目，从最早的语音笔记到后面接系统级操作，一路踩了不少坑，今天把这些场景重新拆开盘点一遍，从轻到重一条线讲清楚，顺便把背后真正影响落地的技术细节也都摊开说。这波内容适合正在做 Agent 的客户端、后端和 AI 应用层同学，也适合产品经理和技术决策者用来判断边界。

先说一个基本判断：端侧语音 Agent 不是简单把“语音识别+大模型”塞进手机，而是要在功耗、延迟、隐私、模型能力之间做一批具体而微的取舍。场景越轻，取舍越容易；场景一旦走到 Computer Use 这种需要视觉理解、鼠标键盘模拟、实时语音反馈的重交互，整个技术栈都要换一层思考方式。下面按场景从轻到重拆开讲。

1. 先从第一性原理看：端侧语音 Agent 到底解决了什么问题

1.1 云端方案解决不了的三个痛点

很多人一开始不理解为什么要做端侧。明明云端的 ASR（语音转文字）准确率高，大模型能力也更强，把录音丢上去不就行了？确实，单看效果，云端几乎全面胜出，但真正落到实际产品里，有三个问题让人不得不转向端侧。

第一个是隐私。语音天然携带大量个人信息：说话人的身份、健康状况、家庭关系、工作内容，甚至情绪状态。一段录音传到云端就意味着这些信息要离开用户设备，很多用户过不了心里这道坎。让我印象很深的是一次内部评审，产品经理说“用户其实不知道我们把语音传到云端了”，这话当场被安全同事拦住，后来我们也确实在合规审查中发现，语音数据的留存策略、第三方共享清单、跨境传输声明，每一项都能写上几十页。端侧处理直接从源头把这个问题简化了，音频不离开设备，个人数据只在本地闭环。

第二个是延迟。语音交互的体验阈值非常苛刻，人在说完一句话之后，通常只有 300 毫秒到 500 毫秒的耐心等待期。云端方案就算 ASR 再快，网络往返一次也要 100 毫秒以上，再叠加排队和推理时间，经常干到 1 秒以上。尤其是那些“打断式”交互，用户说到一半停下来改口、补充，端侧可以做到实时出字，云端方案会明显感觉到顿挫。

第三个是可用性。网络差、地铁里、车库中、飞机上，这些真实场景下云端服务就是不可用的，而语音交互恰好经常发生在手没空、眼没空的场景。离线可用听起来是很朴素的需求，但是对产品定位来说，是一个能让用户形成“随时掏出就能用”心智的分水岭。

1.2 端侧不等于全部本地，关键看分层

这里必须澄清一个误区。所谓端侧语音 Agent，常见的形态其实是分层的，不是所有能力都必须在端侧跑完。我经手的项目里，最稳妥的架构是“端侧做主链路、云端做增强”：唤醒词、回声消除、VAD、ASR、意图理解、轻量任务执行，这些必须在设备上实时完成；遇到复杂推理、知识问答、跨系统操作这种真正吃模型能力的任务，再通过用户授权走云端。这样既保住了隐私、延迟和可用性，又不至于让端侧设备背一个跑不动的大模型。

如果一刀切追求全本地，会出现什么情况？我曾经在一个中端手机上试过把 7B 模型塞进语音 Agent，结果首次加载要 20 秒，流式输出一个字要半秒，整个交互节奏完全不能看。后来又试过 1.5B 模型，响应快了，但复杂指令的理解能力明显下降，用户说“帮我把昨天拍的照片里那张有猫的找出来再发给老张”，它就犯了难，因为需要拆解多步操作。所以现实的做法不是“全端侧”或“全云端”二选一，而是识别任务的复杂度，把轻量决策留在端侧，把重量处理做成受控的云端查询。

1.3 语音链路是 Agent 的“输入层”，比文本 Agent 多出来的硬骨头

文本 Agent 的输入就是一段字符串，简单、干净、结构化。语音 Agent 不一样，在文本进入模型之前，先要过一整条音频链路：麦克风阵列采集、AEC（回声消除）、波束成形、噪声抑制、自动增益控制、VAD 切分、ASR 转写。每一步都可能引入错误，而且这些错误是叠加放大的，音频里一个小的误判，到了语义理解阶段可能被放大成完全不同的指令。

最典型的是断句问题。人说话没有逗号句号，停顿也不一定代表语义结束。我曾经用一句“帮我定明天早上八点的闹钟顺便把航班信息查一下”测试多款 ASR，结果有的把“八点的闹钟”理解成“八点钟”，有的把“航班”听成“航班信息页面”，导致 Agent 后续规划动作时出现偏差。文本 Agent 几乎没有这类输入噪声，但语音 Agent 必须把整条链路当成一个整体去调优，任何一环出问题，后面模型再强也白搭。

2. 场景一：语音记事本，最轻量的端侧语音 Agent 长什么样

2.1 为什么语音记事本是合格的“第一个 Agent 场景”

语音记事本是我见过最适合拿来做端侧语音 Agent 起步的场景，没有之一。它的任务边界足够清晰：用户说一段话，设备转成文字，再按时间和语义整理成结构化笔记。不需要跨应用操作，不需要复杂推理，也不依赖实时互联网信息，大部分逻辑都可以在本地闭环。

但“记事本”三个字其实把它的上限拉低了。真正有意思的是在里面叠加 Agent 能力之后，它可以做得比“录音转文字”聪明得多。比如用户说“周二下午三点和产品对一下新版隐私协议的范围，记得带上法务”，传统语音笔记只能记下一句话，而 Agent 可以拆出时间、地点、参与人、动作、待办事项，自动生成日历事件和提醒。这就是从“转录工具”到“语音 Agent”的关键跃迁：从被动记录变成主动理解。

2.2 端侧实现的关键链路：从音频到结构化输出的完整数据流

语音记事本的最小可用闭环长这样：

1. 麦克风采集 16kHz 单声道 PCM 音频，按每 30 毫秒一帧做 VAD 检测；
2. 判断语音活动结束之后，把这一整段音频送进端侧 ASR；
3. ASR 输出带标点的文本，时间戳按词对齐；
4. 把文本送到轻量级意图识别模块，做实体抽取；
5. 根据抽取结果生成结构化数据，写入本地存储；
6. 返回通知给用户，并支持语音或文字回看。

这里面每个环节都有选择。VAD 我推荐用 Silero VAM 这类轻量模型，CPU 推理单帧低于 1 毫秒，非常稳。端侧 ASR 的选择要看平台，安卓上常见的是 sherpa-onnx 配合 Zipformer 系列模型，iOS 上可以直接用系统 Speech 框架，也可以用自带的 SpeechAnalyzer，但系统框架的离线包较大，而且词表更新滞后，有时识别新兴词汇会翻车。实体抽取这一步，如果没有太重需求，基于规则的匹配加上少量正则就够了，因为记事本的实体基本就是时间、人名、地点、待办，这四类可以覆盖 80% 的场景。只有当你要处理大量非固定句式时，才值得上一个小型 bert 模型或直接用大模型的函数调用能力。

2.3 容易被忽视的体验细节：误触发、录音中断、转写冲突

语音记事本看起来简单，实际跑起来坑都在细节。第一坑是误触发。我把唤醒词做成了“记一下”，结果用户在正常对话里说“你先记一下，回头再弄”，设备就被唤醒了，录了一整段无效音频。这个问题的缓解办法是加双模型确认：先用一个极轻量的唤醒词模型粗筛，再用一个 30MB 左右的关键词模型二次确认，只有连续两次命中才真正启动录音。

第二坑是录音中断。用户说到一半突然停住思考，VAD 会判定语音结束，后半句话就丢了。常规做法是设置 1.5 到 2 秒的尾音等待时间，但这段等待时间又会拖慢整个交互的结束感，用户觉得“我说完了它还在转圈”。我的经验是做一个“静音但仍在录音”的双状态机制，VAD 判断语音结束之后不立即停止采集，而是保留一个 2 秒的缓冲窗口，如果检测到新语音就从窗口处续接，而不是重新开始。这个机制投入不大，但对实际体验提升非常明显。

第三坑是转写冲突。用户在语音笔记里提到的人名、地名、专业术语，和标准词表经常不一致，如果直接按 ASR 原始输出存，后面搜都搜不到。我会在 ASR 之后挂一个“热词修正表”，把用户常说的联系人、项目名、地点别名维护成本地词表，每次转写后做一次轻量替换。这个小功能让我实打实理解到，语音 Agent 的“智能”很多时候不是靠大模型，而是靠一批朴素但有效的工程细节。

3. 场景二：设备控制与车载环境，语音 Agent 开始“动手做事”

3.1 从“听懂”到“执行”：设备控制场景的 Agent 化改造

如果说语音记事本只是“听懂并记录”，那么设备控制场景就是语音 Agent 第一次开始动手做事。开灯、关窗帘、调空调温度、播放音乐、设置提醒，这些动作在传统方案里靠的是“命令词+固定槽位”，能但非常死板。用户只能说“打开客厅灯”，如果说“太亮了，把灯光调暗一点”，传统方案就蒙了，因为它没有维护亮度上下文，也不理解“太亮了”是一个反馈信号。

Agent 化改造之后，交互模型变成“多轮对话+环境状态跟踪+动作规划”。用户说“太亮了”，Agent 会结合当前灯光明亮度状态、用户偏好、室内时间等因素，推理出用户想调暗，然后调用设备控制接口，把亮度目标值调整到 60%，并回复“已帮你把亮度调暗了一些，还需要再低一点吗”。这个能力的关键不在大模型本身，而在于给模型提供准确的“环境状态快照”，也就是把当前所有可控设备的开关状态、亮度、温度、模式都编码成结构化的上下文，放进 prompt。

端侧为什么要做这个场景？因为设备控制对延迟极其敏感。灯亮一下的等待时间超过 1 秒，用户就会觉得“这还不如我自己去按开关”，所以控制回路必须本地闭环。云端方案没法保证 200 毫秒以内的响应，而端侧小模型加上规则的本地预测，完全可以把常用控制指令的响应压到 150 毫秒以内。

3.2 车载场景的特殊挑战：噪声、远场、多说话人

车载是设备控制里最折磨人的场景，没有之一。车舱内的噪声类型极其复杂，风噪、胎噪、空调声、音乐声、雨刷声、别的乘客说话，全部叠加在一起，而且用户可能坐在副驾或后排，离麦克风有半米到一米远。普通手机麦克风阵列在这里基本失效。

我在车载项目里踩过最狠的坑是“听音辨位”。用户坐在主驾说“打开车窗”，结果副驾的乘客也在说话，系统把副驾的话识别成了控制指令，主驾车窗没动，副驾车窗开了。这个问题的解法是波束成形加说话人追踪：麦克风阵列先定位声源方向，锁定主驾位置，再利用波束成形增强该方向的声音、抑制其他方向，最后用 VAD 加上声纹特征判断是不是当前用户发出的指令。这套组合下来，误唤醒率能降一个数量级，但调试成本非常高，因为车内声学环境每台车都不一样，不能靠一套固定参数吃遍所有车型。

另一个车载特有问题是打断和连续指令。用户一边开车一边说话，经常是“打开空调——不，先关窗——不对，是打开通风”，系统必须实时跟踪用户修改意图。端侧方案的优势在于可以在 VAD 阶段就捕捉到“不、先、不对”这类修正信号，及时清空之前的待执行动作，而云端方案一旦把整句话发出去了，等转写结果返回再纠正，用户早就失去耐心了。这里我体会到一句经验：语音 Agent 的智能不只在理解，更在交互节奏的感知。

3.3 多设备协同才是完整形态：语音 Agent 作为统一入口

设备控制如果只服务单设备，价值就被锁死了。真正让用户觉得“语音助手终于有用了”的瞬间，往往是跨设备联动。用户站在客厅说“我睡了”，Agent 可以按惯例执行一个“睡眠模式”脚本：客厅灯关闭、卧室灯调到夜灯模式、空调切换到睡眠曲线、窗帘自动拉上、门锁确认是否已反锁。这种场景里，语音 Agent 不再是一个控制某个灯的工具，而是一个统一的系统入口，背后接的是全屋设备的状态抽象层。

端侧在这个角色里兼任网关和决策者。设备状态聚合、场景意图识别、脚本执行，都可以在本地完成，只有遇到不在脚本里的异常情况（比如门锁没有反锁成功）才需要请求云端做复杂推理。把云端的使用频率控制在少量异常场景，既能保证日常体验的稳定，也能控制推理成本。这也是我对端侧语音 Agent 落地定位的一个核心观点：它不是替代大模型，而是用本地调度把大模型的调用次数压到最低。

4. 场景三：Computer Use，语音 Agent 离“替你用电脑”还有多远

4.1 Computer Use 是什么：AI 不再只“说”，而是开始“操作”

Computer Use 是最近热度暴涨的方向，核心含义是让 AI 通过视觉理解屏幕内容、规划操作步骤、模拟鼠标键盘动作，直接操作电脑完成复杂任务。和传统的“API 集成”不同，Computer Use 本质上是让模型像人一样“看屏幕—点鼠标—敲键盘—再观察反馈”地工作。OpenAI 的 ChatGPT 里已经能看到雏形，各种开源项目也在做类似的事情。

语音 Agent 和 Computer Use 结合之后，形态会变成这样：用户说“帮我把这个文件夹里所有 PDF 重命名成‘提案_日期’的格式，然后发到指定邮箱”，语音 Agent 负责理解用户的自然语言，生成一份操作目标，交给 Computer Use 引擎去执行，执行过程中如果需要确认，再用语音反馈给用户。这套链路一旦跑通，语音就从“助手”变成了“远程遥控器”，用户不再需要关心操作步骤。

4.2 端侧 Computer Use 的架构拆解：视觉感知、状态规划、操作执行

端侧 Computer Use 不是一个单模型，而是一套流水线，比语音链路复杂得多。我把它拆成四层：

• 屏幕感知层：通过截屏或录屏获取当前屏幕图像，用视觉模型做 OCR、元素识别、区域定位，输出结构化描述，比如“左上方是文件夹列表，第二行有‘报告.pdf’，右下角有‘发送’按钮”。
• 状态建模层：把当前屏幕结构、目标意图、历史操作整合成状态图，用来判断下一步动作。这一步最考验模型，它需要理解“当前页面状态”和“目标状态”之间的差距。
• 操作规划层：根据状态差距生成操作序列，比如“点击 报告.pdf 右键，选择重命名，输入新名称，按回车”。规划要足够细，但也不能太机械，否则一步出错后面全崩。
• 执行层：模拟鼠标键盘事件，执行操作，然后截屏验证结果，如果失败就触发重试或转向人工确认。

端侧做 Computer Use 的瓶颈在视觉模型。一个能稳定理解复杂界面的视觉模型，参数量通常在 3B 以上，而且需要较长的图像 token 输入。在手机上跑这种模型，延时和功耗都是大问题。我在一个平板上试过跑 3B 视觉模型，单次屏幕理解就要 3 秒，用户根本等不起。所以更现实的部署形态是：把“界面理解”放在云端强视觉模型上，把“操作执行”和“语音交互”放在端侧，形成混合架构。

4.3 语音 Agent + Computer Use 的实战链路：一个完整的语音操作示例

举个完整例子，用户对电脑说“把刚才收到的合同附件存到项目文件夹里，并且回一封确认邮件”。这条任务拆成语音 Agent 加 Computer Use 的链路是这样的：

1. 端侧 ASR 先把这句话转成文本，意图识别模块判断这是一个跨应用文件操作任务；
2. 语音 Agent 向 Computer Use 控制器下发一个“找邮件附件→保存到项目文件夹→写邮件→发送”的总体目标；
3. Computer Use 控制器截屏并把屏幕图像送到视觉模型，识别邮件客户端界面、附件位置、“下载”按钮，执行点击；
4. 下载完成后，进入文件管理器界面，视觉模型继续识别目标文件夹，执行移动；
5. 回到邮件客户端，生成一封包含简短正文的回复邮件，点击发送；
6. 每完成一步，Controller 都会截屏核对，并向语音 Agent 回报进度，如果需要用户确认（比如“附件有两个版本，选哪个”），就触发语音询问，等待用户回答后继续执行。

这套链路现在的成功率还做不到很高，尤其在处理不规则界面、弹窗、下拉菜单时容易出错。我实测过几个开源 Computer Use 项目，在固定网页流程上成功率能到 80%，一旦切到本地原生应用、拖拽操作、文件对话框这些非标准控件，成功率会暴跌到 50% 以下。所以语音 Agent 作为 Computer Use 的入口，必须设计“失败兜底”：执行三步没验证到预期结果，就立刻停下来问用户，而不是闷头继续点，否则风险会被放大。

4.4 安全边界：语音 Agent 操作电脑时，必须设计哪些护栏

Computer Use 给语音 Agent 带来一个全新的安全维度：一旦 Agent 能模拟键盘鼠标，它的权限已经等同于用户本人在操作电脑。用户说错一个字，或者模型规划错了动作，轻则删错文件，重则误发信息。所以落地之前必须设护栏，这是我做这方向最强烈的建议。

我至少会做四层护栏：第一层是操作前确认，涉及删除、发送、转账、修改系统设置等不可逆操作，执行前强制语音复述一次让用户确认；第二层是操作白名单，初期只允许 Agent 操作特定应用和特定文件夹，超出范围直接拒绝；第三层是操作审计，所有 Agent 执行的鼠标键盘事件和截屏都记录成本地日志，方便回溯；第四层是紧急停止，用户在任何时候说“停”“取消”“不对”都要能立刻打断自动化流程，这个信号必须在端侧用低延迟链路实时识别，不能等到云端周期结束才响应。

这层护栏同时也是产品信任的基础。没有护栏的 Computer Use 语音 Agent，用户是不敢把真实工作交给它的，因为一次错误操作的成本可能远超它节省的时间。

5. 端侧语音 Agent 的工程底座：模型怎么选、并发怎么扛、记忆怎么存

5.1 模型选型不是越大越好，要按“任务复杂度金字塔”分配

端侧语音 Agent 对模型的挑选，我的原则是“按需分配，能小则小”。可以把任务按照复杂度塞进三个层级：简单规则任务（比如开灯、设置定时）、中等理解任务（比如多轮对话、信息提取、意图识别）、复杂推理任务（比如跨应用规划、长文本分析）。简单任务用不到大模型，规则和分类模型就够了；中等任务用小参数 LLM（1B 到 3B 级别）；只有复杂推理才需要调用云端大模型。

我实测过一条经验：在手机处理器上用 1B 模型做意图识别，延迟可以控制在 40 毫秒内，功耗大概 0.5W 左右；3B 模型延迟会到 150 到 300 毫秒，功耗翻倍；7B 模型延迟直接破秒，而且发热明显。对语音 Agent 这种需要高频交互的任务来说，每一层延迟都会直接反馈到用户感知上，所以宁可把任务拆细、用小模型多跑几次，也不要一个 7B 模型把所有事都揽下来。

模型格式也有讲究。ONNX 和 MNN 是目前端侧比较稳的选择，前者通用性好，后者在部分安卓设备上有硬件加速优势；苹果生态则要看 Core ML 的支持情况。我建议在选型阶段就锁好量化方案，一般用 INT8 或 INT4，视觉模型可以考虑混合量化，把对精度敏感的层保留 FP16。模型压缩到 2GB 以下，端侧跑起来才比较从容。

5.2 端侧 Agent 的并发与资源管理：不能把手机变成暖手宝

很多做云端 Agent 的人第一次转端侧，最大的不适就是并发模型完全变了。云端可以随时扩容，端侧则只有一个 CPU/GPU/NPU，内存还非常紧张。语音 Agent 同时要做音频采集、ASR、推理、TTS 播放，一批操作可能同时争抢资源，处理不好就是卡顿+发热。

我给一个最小资源预算：ASR 模型常驻内存控制在 80MB 内，1B 语言模型常驻 500MB 内，视觉模型按需加载不常驻，TTS 用轻量拼接式引擎占据内存最小。关键技巧是把流水线做成“生产者-消费者”链，每个环节单独线程或队列，ASR 在音频线程跑，语言模型推理在推理线程跑，TTS 在播放线程跑。两个环节之间用队列解耦，不至于因为一方卡顿导致整条链路阻塞。

并发还有一个容易忽略的点：用户可能同时发起语音命令和触屏操作。比如用户正说着“帮我打开设置”，手指已经去点“设置”了。语音 Agent 必须能识别这种意图冲突，取消语音执行或把控制权交还给用户。我做这个功能的时候，用了一个简单的优先级规则：用户主动触屏操作永远优先于语音操作，语音 Agent 检测到触屏事件后自动暂停当前规划。这个规则很朴素，但确实解决了不少实际冲突。

5.3 记忆与上下文：让语音 Agent “记得上次说过什么”

端侧语音 Agent 想要真正好用，记忆是绕不开的。语音交互天然是碎片化的，用户不会像写 prompt 那样把背景交代清楚，所以 Agent 必须能从历史对话里提取有用信息并带进当前上下文。我在项目里把记忆分成三层：短期对话记忆，只存当前一轮多轮对话；中期偏好记忆，存用户常设的时间格式、称呼、常用命令；长期事实记忆，存用户的关键个人信息（生日、家庭角色、工作偏好等）。

端侧存储长期记忆要特别注意隐私。我的建议是在设备本地用加密数据库保存，任何一条记忆都允许用户查看和删除。不要轻易把记忆同步到云端，一旦云端保存了“用户每天早上 7 点提醒吃药”这类信息，一旦泄露风险很大。记忆的引用方式也要控制，不要把全部历史都塞进 prompt，而是按相关性检索出最近几条，否则 1B 级别的上下文窗口根本不够用，而且塞多了还会稀释模型对当前指令的注意力。

关于 Agent 记忆还有一个很实用的技巧：给每条记忆打上“时间衰减权重”。一周内的记忆权重最高，一个月内的次之，半年以上的只在直接相关时引用。语音 Agent 环境下用户常常今天问“周日提醒我交房租”，下周又提到同一个话题，时间衰减权重能帮模型判断“现在应该重新提醒，还是沿用上次的提醒”。

5.4 Agent 框架与编排方式：端侧适合用轻量框架还是要自己写

热词里经常看到“Agent 框架”“Agent 编排”，但对端侧场景来说，我的建议是别迷信重框架。业界常见的 LangChain、LangGraph、CrewAI 这类框架都是为云端 Python 环境设计的，依赖重、抽象多，直接搬到移动端基本跑不动。端侧 Agent 更合适的是自己维护一个极简的“状态机+工具调用表”，把每个场景的动作封装成一个个工具函数，由调度器根据意图识别结果去调用。

这里并不是说完全排斥框架，而是要看移植成本。如果团队已经有一套云端 Agent 框架，可以考虑把核心的“规划-工具调用-反馈”逻辑抽象成跨平台协议，端侧用轻量实现，云端保留重量级实现，两边遵循同一套工具定义和状态回传格式。这样既保持端侧可控，又不至于两套系统很难维护。但纯端侧项目，老老实实写状态机的性价比是最高的，调试起来也最直观。

6. 常见问题与排查实录：那些文档里不会告诉你的坑

6.1 音频质量问题的排查顺序

音频链路出问题，最忌讳一上来就调模型，因为很多时候根本不是模型的问题。我总结了一个排查顺序，从物理层到算法层一层层往上：

先看音频原始波形，可以用录音工具抓一段 PCM，在电脑上画波形。如果波形整体变形或幅度忽大忽小，那就是增益或硬件问题；如果波形正常但语音内容不清晰，再到算法层查降噪和回声消除。回声消除是最常翻车的点，很多端侧设备用了个简单的 AEC，远场效果极差，用户语音里混着一半扬声器的回声。一个有效的自查方法是：让设备播放一段固定铃声，同时录音，看回声音量是否被压制到 20dB 以下。如果压不下来，就要检查 AEC 参考信号是否真的接入了扬声器播放的原始音频流。

还有一个容易踩的坑是采样率不一致。ASR 模型有些要求 16kHz，有些要求 8kHz，如果前面音频采集是 48kHz 没有做重采样就送给 ASR，结果就是识别率大幅下降。这个问题的排查很简单，打印音频流的采样率、通道数、位深，和模型的输入规格对一遍就出来了，但很多第一次做的人会忽略。

6.2 端侧 Agent 推理延迟高的常见原因

延迟高不代表模型真的慢。我排查过的案例里，有六成以上延迟是工程问题而不是算力问题。最大的嫌疑是模型加载时机错误，很多实现把大模型常驻内存，哪怕不推理也占着资源，导致设备整体响应变慢。我建议把模型加载策略分成“常驻”和“懒加载”两类：对话模型这种高频使用的可以常驻，视觉模型和复杂任务模型则在使用前才加载。

第二个嫌疑是推理线程跑在了主线程上，导致 UI 卡顿且 CPU 降频。移动设备的 CPU 有一种特性，一旦负载持续过高，系统会自动降频来保护发热，降频之后推理反而更慢，形成一个恶性循环。解决方法是把推理丢到独立线程，并且限制推理时的 CPU 占用峰值，不要让设备整体升温。

第三个嫌疑是前后处理做了过多无用的数据拷贝。比如视觉模型输入前，你可能要做图像缩放、归一化、颜色空间转换，每一步都在内存里复制数据；在端侧，内存带宽往往比算力更紧张，所以尽量用“零拷贝”的方式，让数据直接映射到模型输入张量，避免中间结果反复搬运。

6.3 交互层面的问题：误唤醒、声音反馈延迟、权限申请被拒

音频交互最常见的是误唤醒。前面提到过双模型确认，但即便这样，在电视声、音乐声中还是会有漏网之鱼。我后来在工程上进一步细化了唤醒置信度的动态阈值：检测到高噪声环境时自动提高唤醒阈值，安静环境则适当降低，让唤醒率在不同信噪比下都能保持合理水平。

声音反馈延迟是另一个麻烦。很多 Agent 在收到指令后要等执行完才给语音回复，用户会觉得“没反应”。体验比较好的做法是分层反馈：先立即播放一个 100 毫秒内的“收到”提示音，再在任务完成后给一句完整的语音结果。这个细节很朴素，但对用户感知的“响应快不快”影响非常大。

权限申请也要单独说。语音 Agent 需要麦克风权限，但很多手机用户对麦克风权限天然警惕，生怕被录音。产品上要解决信任问题：在申请权限时明确说明音频仅在本地处理、不会上传；在设置里提供可视化“最近录音记录”和“一键清除”按钮。我做过一个小 A/B 测试，加了隐私说明之后，麦克风权限授权率从 61% 提升到了 84%，这个数据说明隐私透明度不仅合规，还是实打实的产品力。

6.4 Computer Use 执行失败时的兜底策略

Computer Use 场景下的失败更难排查，因为动作是连续的一串，考验的是状态验证。我建议在每一步动作完成后都做一次“屏幕差异对比”：截屏、计算当前画面与执行前的差异区域，如果差异不符合预期，就判定这一步失败，终止当前任务并询问用户。这个策略说起来简单，但想判断“差异是否符合预期”本身又是一个视觉理解问题，所以在实现上不要追求完美，用 OCR 提取关键文本变化就够用。

还有一个务实的建议：初期不要做“全自动完成整条任务”，先把任务拆分成交互式确认的多个子任务，每完成一个子任务就向用户汇报一次。表面上步骤变多了，但用户的信任感和最终任务成功率都更高。我自己试过几个场景，交互式确认版本的平均任务完成时间，只比全自动版慢了 30%，但任务失败率和用户焦虑感大幅下降，这个性价比非常划算。

6.5 快速问题定位表

为了方便排查，我把常见的现象、可能原因和优先排查方向整理成一张表，遇到问题照着走就行。

这个表格看起来零散，但每一个都是我实际踩过的坑，整理出来之后，新人接手项目时能少走很多弯路。

最后再分享一点真实体会

做了这么多端侧语音 Agent 的场景，我最大的感受是这个领域真正的门槛不在某一项单点技术，而在“全链路的耐心”。语音链路、模型取舍、状态管理、隐私防护、失败兜底，每一环单独拎出来都不算惊世骇俗，但要把它们组合成一套稳定好用、让用户愿意天天打开的产品，需要投入的打磨时间远超大多数团队的预期。我个人在项目里最值的一个投入，就是搭了一套完整的“端侧链路可观测”工具，把音频质量、ASR 置信度、模型响应时间、动作执行结果全部可视化出来。没有这套工具，排查问题基本靠猜，有了之后就变成按表找因。如果你也准备做端侧语音 Agent，我建议第一步不是选模型，而是先把这条链路的观测能力建起来。