端侧语音Agent实战指南：从语音记事本到Computer Use

1. 先说结论：端侧语音 Agent 已经过了"能不能用"的阶段

去年年底我折腾了一台淘汰下来的 Windows 笔记本，目标很朴素：把它变成一台"能听懂人话"的桌面助理。语音记事是第一个跑通的功能，后来慢慢加了日程提醒、待办管理，最后甚至让它在 Chrome 里帮我完成"把当前页面加入稍后读"这种带界面操作的任务。整个流程串起来之后，我最大的感受是：端侧语音 Agent 这个方向，已经不再停留在"演示很酷"的层面，而是到了"该认真盘点哪些场景值得做、哪些场景纯属自嗨"的阶段。

所谓端侧语音 Agent，拆开看就是三件事：语音入口留在本地设备（麦克风采集、唤醒、本地识别，或至少关键环节不出设备），决策用 Agent 的方式做（不是写死规则，而是让模型根据意图调用工具），最后把动作落回真实世界（写笔记、发消息、操作界面）。它和早年语音助手的本质区别在于：以前是"识别一句话、匹配一个固定动作"，现在是"识别一段语音、理解上下文、动态规划需要调用哪些工具、执行后还能看结果决定要不要继续"。

这篇文章想把端侧语音 Agent 的落地场景按难度分层讲清楚，从人人都能做的语音记事本，一路讲到偏前沿的 Computer Use（语音指挥模型操作电脑屏幕）。内容里涉及的技术点、选型、踩坑经验，都来自我自己真机调试的体会，也参考了社区里大量同行的实践。适合三类人看：想给个人项目加语音入口的开发者、正在评估端侧 AI 产品方案的产品经理、以及对"语音 + Agent 能做什么"好奇的爱好者。

先给结论：端侧语音 Agent 目前在四类场景上已经具备真实可用性——记录型（语音转文字笔记、会议纪要）、任务型（日程、提醒、待办）、设备控制型（智能家居、App 内操作）、类 Computer Use 的屏幕操作（语音驱动模型操作 GUI）。难度和工程成本呈指数级上升，但并不是越高级越值得做。下面我按场景爬坡的顺序，把每一级的技术细节和坑展开讲。

2. 语音记事本并不简单：一条语音从麦克风到笔记的完整链路

很多人觉得语音记事本是"最入门"的功能，能难到哪去？实际做一遍才发现，它几乎涵盖了端侧语音全部基础组件：唤醒、VAD、流式识别、结构化理解、反馈播报。这一层如果做扎实了，后面的高级场景都是在此基础上叠加而已。

2.1 唤醒与 VAD：低功耗常驻是第一个分水岭

语音记事类产品需要设备保持"随时可被叫醒"的待命状态，但又不能一直开着全量识别模型——功耗和算力都扛不住。所以第一个核心组件是唤醒词引擎。开源自选方案里，我实测过 openWakeWord 和 Picovoice 的 Porcupine，两者都能在树莓派、老笔记本这类低功耗设备上常驻运行。openWakeWord 的优势是社区训练好的唤醒词模型多，中文也有现成资源；Porcupine 的优势是跨平台封装简单，几行代码就能接入。

唤醒之后轮到 VAD（语音活动检测）上场。这里强烈建议用 Silero VAD，它按 30ms 粒度输出"有人说话/没人说话"的置信度，在 ONNX Runtime 下跑得非常快。VAD 的工程细节容易被低估：音频流进来之后，要拼帧判断连续语音段，遇到 400~600ms 的静音判断为"这句话说完了"，然后把该段音频送去识别。如果静音阈值设太短，用户停顿一下就会被切句；设太长，用户说完话要干等。我的经验是先全量录进环形缓冲，等 VAD 判定结束后再取出语音区间，最后用端点检测（EPD）把前后端的多余静音裁掉。

2.2 端侧 ASR 的选型：流式识别和一次性识别要分清

记事本场景要回答一个关键问题：用户是"按住说话，说完再识别"，还是"唤醒后自由说话，边说边识别"。前者简单，按住唤醒之后录音，松手一次性识别即可；后者体验更好，但需要流式识别（streaming ASR）。

一次性识别的本地方案，我用下来最顺手的是 sherpa-onnx，它把一系列模型都封装成统一 API，支持 Paraformer、FireRedASR、Fast-Conformer 等结构。中文场景 Paraformer 系列的准确率和速度平衡得很好，量化后在老 CPU 上也能实时跑。如果不在乎一点点延迟，faster-whisper 的小模型在安静的办公室环境下，字错率也够用。

流式识别则是另一套玩法：把语音切成小片（比如每 160ms 推一次），模型边听边吐"中间结果"，等句子结束后输出最终结果。Paraformer 的流式版本、WeNet 都干这活。工程上最麻烦的是"中间结果要不要展示/处理"——边听边出字幕时，后一个 partial 可能把前一个修正掉，如果代码按"partial 到达就触发逻辑"去处理，很容易产生误操作。放在记事本里还好，如果是"边说边执行"的任务型场景，这个问题会被放大，后面第 6 节会专门讲。

噪音是端侧 ASR 的隐形杀手。单一麦克风在安静房间没问题，在风扇旁、咖啡厅就明显掉点。预算允许的话，建议直接用麦克风阵列加波束成形，Apple 生态的 AVAudioEngine 自带一些降噪处理，Windows/Linux 上可以用 webrtc 的噪声抑制模块先做一层兜底，再把音频喂给 ASR。

2.3 从文本到结构化：规则还是小模型，取决于你想覆盖多少长尾

语音记事本如果只是"把话变成字"，价值有限。真正的价值在于把一段自然语言整理成结构化条目。比如用户说："明天上午十点和产品对齐需求"，一个合格的语音记事 Agent 应该产出：

{ "type": "todo", "title": "和产品对齐需求", "datetime": "2025-06-10 10:00", "source": "voice_memo" }

这里有两种路线。路线一是规则解析：正则匹配时间词、动词、名词，优点是确定性强、开销极低，缺点是"系统性覆盖不了人类的说话方式"，稍微换个说法就漏。路线二是上小模型：用 Qwen2.5-1.5B-Instruct 这类本地模型做意图识别和槽位抽取，通过 function calling 输出结构化 JSON。实测下来，1.5B 级别的模型在时间解析、任务抽取这类窄任务上已经相当能打，first token 延迟大概在 400~800ms，放到端侧算力富余的设备上完全可接受。

我的取舍建议：把"高频确定性指令"（比如"记一下""提醒我…"）走规则或轻量分类器，把"长尾复杂描述"（"帮我安排一下，下周三之前每天下午抽半小时做测试"）走小模型。两条路汇合到同一个 JSON Schema，下游逻辑完全一致。

2.4 反馈播报：TTS 的选型与"可打断"设计

语音 Agent 做完一件事，至少要"说一句"确认，否则用户心里没底。端侧 TTS 目前中文效果最好的是 CosyVoice 系列，但在普通 CPU 上延迟偏高；追求轻量可以用 Piper、VITS 结构或 sherpa-onnx-tts 的封装，用短句合成，首包延迟控制在 150ms 以内是比较容易做到的。

更重要的是"可打断"：TTS 正在播报时，用户在说话，系统要能停下播报、重新进入聆听。这要求 VAD 和 TTS 队列之间做抢占式协作——TTS 播放的同时 VAD 依然在监测人声，一旦置信度超阈值，立刻停止播放并转回识别。没有这层设计，交互会非常死板。

3. 场景爬坡路线：从"记录"到"执行"再到"操作电脑"

我习惯把端侧语音 Agent 的落地场景分成四个等级，每个等级的执行成本和容错要求完全不同。做产品决策前，先对照这张表，能省掉很多"辛辛苦苦做完发现没人用"的尴尬。

3.1 L1 记录型：为什么它是端侧语音的最佳切入点

记录型的共同点是"交互单向、结果可改"——用户说一句话，系统把它变成文字或结构化条目存下来，就算理解错了，改一下成本很低。这决定了它可以接受相对低的识别准确率，也天然适合把 ASR 放在端侧：笔记内容往往包含大量隐私，用户不希望它们被传上云端。

语音记事本之外，会议纪要也是一个被低估的场景。手机录音转文字不是新鲜事，但端侧 Agent 的价值在于它不只是转写，而是能自动做说话人分离、提取待办、识别"谁答应了什么事"。离线状态下把一场两小时的会议处理成结构化的行动项，这是传统录音转文字工具做不到的。工具链上加一个说话人分离模型（比如 pyannote 生态里的模型）后，体验会质变。

3.2 L2 任务型：引入工具调用，体验开始分水岭

任务型场景的特点是"理解之后必须动作"。用户说"明天上午提醒我带体检单"，系统要真正创建一条日历提醒。这个等级开始，语音 Agent 的核心从"识别"转向"规划与执行"：先判断意图属于哪个域（日历/通讯/待办），再抽取必要参数，再调用对应的本地工具 API。

我建议这一段直接用 LLM 的 function calling，而不要写意图分支树。原因很简单：用户的表达方式是无限多的，意图分支树维护到后面会变成灾难。小模型配合一个清晰的 JSON Schema，就能把"帮我取消明天下午的会议，改到周五三点"这种句子正确映射成 calendar.update 调用。社区的 agent 框架里，把"提示词 + 工具集 + 校验逻辑"打包成可插拔模块的 Agent Skill 思路也可以在这个等级引入——新增一种任务类型时，不碰主程序，只加一个 Skill，这对端侧项目的迭代效率提升是肉眼可见的。

3.3 L3 设备控制型：可靠性和权限是硬门槛

设备控制比任务型更进一步，动作作用到物理世界。智能家居算典型：语音说"把客厅亮度调到 30%"，需要经过唤醒 → 理解 → 设备映射 → 下发指令 → 确认回执一整套链路。这类场景对端侧的天然优势在于：家庭环境下网络不一定稳定，离线可用是刚需；而且设备控制往往是高频短指令，本地小模型的响应速度优于云端往返。

但这里有个容易栽的坑：设备控制指令的语义密度很高，"关闭客厅灯"和"打开客厅灯"只有一个字之差，识别错一个字后果天差地别。所以做设备控制时，我强烈建议加一步"指令回读确认"——执行前用 TTS 说一句"好的，关闭客厅灯"，给用户 300ms 的改口窗口。这一招技术成本极低，体验安全感提升极大。

3.4 L4 Computer Use：语音 Agent 的"手"开始出现

Computer Use 在我看来是端侧语音 Agent 的终极形态之一：语音负责表达意图，模型负责理解屏幕内容并执行操作。过去一年，Codex 这类编码工具、以及各家推出的 computer-use 能力，已经把这个方向推到普通开发者面前。但落到"语音指挥电脑"这个具体组合，依然有很多工程细节要解决，下一节专门拆解。

在这一级场景里，判断标准变得很重要：哪些操作适合让语音 Agent 直接操作 GUI，哪些应该只用语音唤起、然后用传统快捷键或 API 完成？我的经验是：凡是能用 API/命令行/快捷键完成的操作，优先用 API；只有当目标功能没有可编程接口、必须靠模拟人手点击才能完成时，才值得走 Computer Use 路线。为炫技而让 Agent 去点本来就有 API 的按钮，是纯技术债。

4. Computer Use 怎么做：语音指令与屏幕操作的分工链路

Computer Use 的本质，一句话：给模型一张（或多张）屏幕截图，模型输出下一步动作（点击坐标、输入文本、滚动、按键），系统执行动作后再截图，模型观察结果决定继续还是结束。语音 Agent 要做的，是在这个闭环前面加一个"耳朵"，让用户能用自然语言发起任务，并在执行完后获得语音反馈。

4.1 屏幕理解要交给 VLM，语音只负责"指挥"

架构上最容易犯的错误，是让同一个模型既处理语音理解又处理屏幕理解。这两个任务对模型能力的要求差异很大——语音命令理解需要强对话上下文，屏幕操作需要强空间定位。我的做法是明确分工：本地小 LLM 负责把语音转成"任务计划"（例如"打开浏览器，搜索端侧语音 Agent，把第一条结果的标题读给我听"），屏幕理解和动作定位交给视觉语言模型（VLM）。

VLM 的选择分两档。资源紧张时，用本地量化 VLM，比如 Qwen2-VL 的小参数版本或 MiniCPM-V，识别"浏览器地址栏大概在哪个位置"这类粗粒度定位没问题，但复杂页面下的精确点击会不太稳定。有条件时，把截图动作发给云端的强 VLM（GPT-4o 这类带视觉和多步推理能力的模型），准确性明显高一截。做产品时可以根据任务复杂度动态路由：敏感页面留在本地识别，普通网页走云端强模型。

4.2 落地要点：截图、grounding 与 UI 自动化

一条"语音 → 屏幕点击"的流水线，关键环节是这样的：

async def handle_voice_command(audio_stream): text = await asr.transcribe(audio_stream) # 端侧流式 ASR plan = await llm.plan(text) # 解析任务与目标 screenshot = screen.capture() # 截全屏 loc = await vlm.locate(screenshot, plan.target) # 定位目标元素坐标 await controller.click(loc.x, loc.y) # 模拟点击 await asyncio.sleep(0.8) # 等待界面响应 after = screen.capture() ok = await vlm.verify(after, plan.expected) # 检查是否成功 await tts.say("操作完成" if ok else "好像没点对，我换个方式重试")

这里最关键的工程决策是"如何定位操作目标"。纯靠 VLM 输出的像素坐标完全不靠谱——同样是"浏览器的关闭按钮"，窗口位置一变坐标就失效。正确做法是结合 UI 结构化信息做 grounding：

• Windows 上用 UI Automation（pywinauto、uiautomation 库）拿到按钮的名称、类型、位置矩形，让 VLM 输出"右上角的关闭按钮"这类语义描述，再由代码映射到具体坐标。
• macOS 上用 Accessibility API 做类似事情。
• Linux 桌面（尤其是 Wayland）自动化受限较多，X11 下用 pyautogui + AT-SPI 还能凑合。

VLM 输出语义目标，结构化 API 负责坐标定位，这套组合的稳定性比"VLM 直接出坐标"高一个量级。另外，现代应用普遍采用自绘 UI（游戏、Electron 应用的 canvas 部分），这时候拿不到可访问性树，只能退回像素级定位，这也是 Computer Use 的长期难点之一。

4.3 操作闭环中最容易被忽略的验证环节

Computer Use 和普通"脚本自动化"的最大区别在于：脚本是线性执行，Computer Use 必须"看结果调整"。所以 verify 环节不是可选项，而是必需品。每执行一步动作，截一张图，让 VLM（或轻量 OCR）判断"预期结果是否出现"。如果连续失败两次，不要死循环重试，直接放弃并语音告知用户，等人工接管。

我在真机调试时踩过的具体坑包括：DPI 缩放导致"截图像素坐标"和"实际点击坐标"不一致（Windows 下 125%、150% 缩放场景尤其明显）；多显示器环境下出现负坐标；窗口被遮挡导致点击落空；全屏应用截图时捕获到的是合成器画面而非真实画面。解决套路是先把全局坐标系统一换算，再在点击前做一次"目标是否在前台/可见"的前置检查。

5. 支撑端侧 Agent 的工程骨架：事件、函数调用与记忆

单点能力再强，没有一套可靠的运行时，语音 Agent 就只是一堆演示脚本。这一节聊聊真正把它"立起来"的工程骨架：事件驱动循环、函数调用协议、记忆存储，以及端云分工。

5.1 用状态机管理交互，而不是用 if-else

端侧语音 Agent 的运行时，本质上是一个状态机循环。我常用的状态划分是：

• idle：不接收语音，只等唤醒词
• listening：用户正在说话，流式 ASR 持续出 partial
• understanding：VAD 判定句子结束，LLM 在解析意图
• acting：工具调用执行中
• feedback：TTS 播报结果，同时监听用户是否打断

每个状态的进入和退出都对应明确事件，工具执行结果也通过事件回投给主循环。设备端组件多了之后，本地消息总线（MQTT 的本地 broker、NATS、甚至简单的 Redis Stream 都行）是必须的。社区里常见的个人助理项目——不管叫 Hermes Agent 还是 Pi Agent——底层基本都有这么一条事件总线，否则唤醒模块、ASR 服务、LLM Worker、工具执行器各自为政，出问题根本没法排查。

5.2 函数调用协议：本地 Agent 的"能力注册表"

Agent 要会调用工具，先得让模型知道设备上有哪些能力可用。我推荐把每个工具定义成一个 JSON Schema 描述，在上下文里一次性注入给模型。Schema 要写清楚参数类型、必填项、枚举值和约束。例如：

{ "name": "create_todo", "description": "创建一条待办事项", "parameters": { "type": "object", "properties": { "title": {"type": "string"}, "due_datetime": {"type": "string", "format": "date-time"} }, "required": ["title"] } }

工具数量一多，把所有 schema 塞进上下文会挤占本就紧张的小模型上下文窗口。这时候可以做两级路由：先用一个极小的意图分类模型判断大体方向（calendar / todo / email / screen_op），再只把对应的一组工具 schema 注入给 LLM。这条路我实测后，小模型的函数调用准确率和解析速度都有明显提升。

5.3 记忆：工作记忆与长期记忆分开管

端侧语音 Agent 没有记忆，就永远停留在"一次性指令助理"的层次。我把记忆拆成两层：

• 工作记忆：当前会话内的对话历史、待确认操作、临时上下文。只需保留最近几轮，避免上下文爆炸。
• 长期记忆：跨会话的用户偏好、习惯、历史记录摘要。落地做法是本地向量库——sqlite-vec、LanceDB、Chroma 都不错，几百条记忆条目用 sqlite-vec 就够了，不需要引重型数据库。

长期记忆有一个我认为很重要的原则：默认关闭，用户显式打开才启用。语音场景天然容易采集到大量敏感信息，如果默认就把所有对话存入向量库，用户隐私风险不可控。我自己的做法是记忆写入前弹一条本地通知，用户可以选择"这条别记"。"记忆"本身是个双刃剑，产品化之前先想清楚谁有权删、过期机制是什么。

5.4 端云分工：别把"端侧"搞成宗教

端侧语音 Agent 不等于 100% 离线。合理的架构是"按需端云分工"：语音链路（唤醒、VAD、ASR、TTS）留在本地，这是隐私和体验的底座；意图理解和工具规划优先走本地小模型，但遇到复杂任务或用户显式要求高质量回复时，可以升级到云端强模型。关键是用一条明确的策略去控制"哪些数据允许出设备"——比如识别出的文字先做一遍脱敏（电话号码、邮件地址打码），再决定是否上云。

这样既保住了语音交互的低延迟和断网可用性，又给复杂场景留了后路。那些声称"全端侧就是好"的观点，容易把自己逼进小模型能力不足的死胡同；而"全云端"则丢失了端侧语音 Agent 最重要的隐私和时延价值。

6. 实战踩坑清单：唤醒、误触发、声音安全与功耗

这一节挑几个我真实踩过、也看社区同行反复踩的坑展开。这些坑不影响demo，但直接影响产品能否长期用下去。

6.1 唤醒阈值不是越高越好，要分环境做自适应

唤醒模型通常输出 0~1 的置信度，阈值设 0.5 还是 0.8，体验截然不同。阈值低了，电视声、键盘声、旁人说话都可能误唤醒，后台自动录一段"莫名其妙"的音频；阈值高了，用户喊好几遍都不理，交互彻底失败。我的建议是双阈值策略：低阈值进入"预唤醒"状态，继续监听 1 秒内的后续音频做二次确认（比如唤醒词之后的短句模式判断），高置信度才真正触发。相当于把"一次判定"改成"两级判定"，误唤醒率能降一个量级。

多说话人场景（办公室、家庭客厅）下还有声纹维度：可以注册常用用户的声音特征，唤醒后先做一次说话人确认，非注册用户直接不响应。这个功能成本不高，但对"只有我的手机能听我指令"这类产品体验帮助巨大。

6.2 流式 ASR 的 partial 是误操作高发区

第 2.2 节提到流式识别会不断吐出中间结果，这中间结果经常是错的。举个例子，用户在说"帮我给老板发消息说下午请假"，partial 可能在"帮我给老板"处停顿，如果代码把 partial 文本实时送进 LLM 做意图解析，系统可能在用户话还没说完时就触发了消息工具。解决方法是：意图解析只在 VAD 判定句子结束后触发；如果一定要在边说边解析（为了极低延迟），也必须引入"partial 置信度 + 用户停顿检测 + 执行前的确认 TTS"三重保险。

6.3 录音安全：重放攻击与敏感操作确认

语音指令天生容易被录音重放——攻击者把你设备旁边录到的"打开门锁"音频拿到设备附近播放，设备无法区分是不是本人在说话。完整防重放需要声纹识别加活体检测（比如要求用户读随机数字），成本不低。更务实的最小方案是：对高影响操作（删除数据、发送消息、解锁门锁）一律要求"语音 + 屏幕确认按钮"双重确认，低影响操作（记笔记、设闹钟）直接执行。把这套分级确认规则做进状态机，安全底线基本就守住了。

6.4 功耗：唤醒词常驻与 NPU 调度

端侧设备的功耗大头通常不是唤醒词模型（这类模型设计上就为低功耗优化），而是流式 ASR 和本地 LLM 的持续推理。我的经验是：ASR 和 LLM 不要同时常驻驻留，用完立刻释放；所有重模型推理尽量走 NPU 或 GPU，避免 CPU 长时间满载导致风扇狂转——风扇噪音反过来又干扰麦克风采集，形成一个很隐蔽的负循环。笔记本上尤其明显，我第一次全 CPU 跑流式 ASR 加本地 LLM，2 分钟后风扇声大到我以为测试脚本出 bug 了。

时延预算是另一个容易失控的指标。端侧语音从用户说完到系统回复，我的经验预算表大致是：

合计控制在 1.5~2 秒内，用户才能有"对话感"。一旦超过 3 秒，绝大多数人就会开始觉得卡。

7. 工具选型参考：不同团队怎么搭自己的技术栈

最后给一套可执行的选型参考。这套组合是我在小算力设备、普通桌面和带 NPU 的笔记本上都跑通过的最小集，你完全可以根据自己的硬件调整。

选型还取决于你团队的人力：如果你是个人开发者，我建议第一版直接做"云协同方案"——本地只负责唤醒、录音、VAD 和 TTS，ASR 和 LLM 走云端 API，两三天就能跑通完整语音记事本，再逐步把 ASR 和意图解析搬到本地。如果你做的是隐私敏感产品（医疗记录、会议录音），那 ASR、TTS 必须本地化，LLM 可以保留云端但要做脱敏。只有做严格离线设备（车载、工控、保密环境）才需要全套端侧模型加量化压缩，这时要把功能预期调低：0.5B~1.5B 的小模型能做工具调用，但做不到很强的开放式对话。

社区可以参考的开源项目不少：智能家居方向可以看 Home Assistant 的语音助手体系，桌面个人助理方向有 Hermes Agent、Pi Agent 这类把语音入口、笔记应用和桌面操作串起来的项目。它们的共同特点是都用事件驱动架构，把唤醒、识别、LLM、工具四层解耦。我的建议是不要直接照抄代码，而是把它们当作"骨架参考"——重点理解各自的事件定义、状态切换和工具注册方式，然后按自己的场景重写一层薄的运行时。

最后分享一个我自己的取舍原则：做语音 Agent 的任何功能之前，先问一句话——"这条语音指令错了，代价是什么？"代价低的直接执行，代价高的加一步确认，代价极高但非必要的干脆不做。把这个原则定下来，端侧语音 Agent 的体验底线基本就守住了。剩下能走多远，取决于你对场景的理解，而不是模型参数大小。