端侧语音Agent实战：从语音识别到LLM工具调用的工程化链路

1. 端侧语音 Agent 到底在解决什么问题

1.1 从“听懂话”到“办成事”的鸿沟

语音助手这东西，大家都不陌生。手机上的、音箱里的，喊一声“今天天气怎么样”，它能给你播报一段天气预报。但你要是说“帮我看看明天下午三点有没有空，有空的话订个会议室，顺便把会议主题发给参会的几个人”，大部分语音助手就卡壳了。这不是它“听不见”，而是它“听不懂”，更准确地说，它没有能力把一句话拆解成多个可执行的动作，再去逐一完成。

这就是端侧语音 Agent 要解决的核心问题：从被动的语音识别加简单指令匹配，进化到主动的任务理解、规划与执行。关键词里的“端侧”意味着整个推理过程跑在本地设备上，不依赖云端服务器。这件事的意义在于响应速度、隐私安全和离线可用性，但代价是算力受限，模型不能无限大，内存不能无限用，功耗还得控制住。

我最初接触这个方向的时候，以为无非就是把一个语音识别模型和一个大语言模型串起来，中间加个意图解析就完事了。实际动手才发现，从“听懂话”到“办成事”之间，隔着的不只是一个模型的距离，而是一整套工程化的链路设计。语音识别只是入口，LLM 是大脑，但真正让 Agent “办成事”的，是工具调用、状态管理、错误恢复和端侧资源调度这些看起来不那么“智能”的工程细节。

这篇文章适合谁看？如果你正在做端侧 AI 应用开发，或者对语音交互、LLM 本地部署、NPU 加速感兴趣，又或者你只是好奇“为什么我的语音助手这么笨”，那接下来的内容应该能给你一些实在的参考。我会尽量把每个环节的“为什么”讲清楚，而不只是罗列“怎么做”。

1.2 端侧部署的硬约束与软需求

端侧语音 Agent 和云端方案最大的区别，在于资源约束是硬性的。云端你可以堆 GPU 集群，端侧不行。一台手机、一个嵌入式设备，CPU、NPU、内存、功耗都是有限的。这就决定了你不能直接把一个 70B 参数的模型塞进去，也不能指望每次推理都跑满算力。

但端侧也有云端比不了的优势。首先是延迟，本地推理不需要网络往返，语音识别和意图理解的响应可以做到毫秒级。其次是隐私，语音数据不出设备，这对很多场景来说是刚需。第三是离线可用，没有网络也能工作，这在车载、工业等场景下很重要。

所以端侧语音 Agent 的设计思路，本质上是在“能力”和“约束”之间找平衡。你不能追求通用大模型那种什么都能聊的能力，而是要针对特定场景做裁剪和优化。比如一个车载语音 Agent，它不需要会写诗，但必须能准确理解导航、空调、音乐这些领域的指令，并且在噪声环境下也能稳定工作。

2. 核心链路的工程拆解

2.1 语音前端：不只是识别文字

很多人以为语音前端就是 ASR（自动语音识别），把声音转成文字就完事了。但在端侧 Agent 的场景下，语音前端要做的事情远不止这些。

首先是唤醒词检测。设备不能一直在跑完整的 ASR，那样功耗扛不住。所以需要一个轻量的唤醒词模型，常驻运行，检测到特定关键词才启动后续流程。这个模型通常很小，几十 KB 到几 MB，跑在低功耗的 DSP 或者 NPU 的小核上。

唤醒之后是语音活动检测（VAD），判断用户什么时候说完了一句话。这个环节很关键，因为如果 VAD 太敏感，会把环境噪声当成语音；如果太迟钝，会把用户的话截断。我试过用固定的能量阈值来做 VAD，在安静环境下还行，一到嘈杂环境就废了。后来换成基于神经网络的 VAD，虽然多了一点算力开销，但稳定性提升非常明显。

然后是ASR 本身。端侧 ASR 模型的选择，要在准确率、模型大小和推理速度之间权衡。目前比较常见的方案是用流式 ASR，边听边出结果，而不是等整句话说完再识别。流式 ASR 的好处是延迟低，但实现复杂度更高，需要处理 chunk 之间的上下文衔接。

实操心得：端侧 ASR 的准确率，很大程度上取决于声学模型和语言模型的配合。如果你的应用场景有大量专有名词（比如车载场景里的地名、联系人名），一定要做语言模型的定制化，否则识别结果会让你怀疑人生。

2.2 LLM 作为大脑：意图理解与任务规划

ASR 输出文字之后，接下来就是 LLM 的工作。在端侧语音 Agent 里，LLM 主要承担三个角色：意图理解、任务规划和工具调用决策。

意图理解相对简单，就是把用户的自然语言映射到预定义的意图类别。比如“我有点冷”映射到“调高空调温度”，“导航到公司”映射到“启动导航”。但实际场景中，用户的表达千变万化，同一个意图可能有几十种说法，这就需要 LLM 有一定的泛化能力。

任务规划是更复杂的一层。用户说“帮我安排明天上午的会议”，这句话背后可能涉及查日历、找空闲时段、创建会议、发送邀请等多个步骤。LLM 需要把这些步骤拆解出来，并且确定执行顺序。这里就涉及到Token 的管理问题。端侧 LLM 的上下文窗口通常比云端小，你不能把所有的工具描述、历史对话、用户信息都塞进去。我的做法是分层管理：系统提示词和工具描述放在最前面，历史对话只保留最近几轮，更早的对话做摘要压缩。

工具调用决策是让 Agent “办成事”的关键。LLM 需要判断当前任务是否需要调用外部工具，调用哪个工具，传什么参数。比如用户说“把空调调到 26 度”，LLM 需要输出一个结构化的调用请求：{"tool": "set_ac_temperature", "params": {"temperature": 26}}。这个结构化输出的格式，需要在提示词里严格定义，否则 LLM 可能会输出各种奇怪的格式。

2.3 工具调用与执行：从决策到落地

LLM 输出工具调用请求之后，真正执行的是后端的工具函数。这部分看起来简单，但实际工程中有很多细节要注意。

首先是参数校验。LLM 输出的参数不一定合法，比如温度可能超出范围，时间格式可能不对。工具函数必须做严格的校验，不能直接信任 LLM 的输出。我踩过的坑是，LLM 有时候会把“明天”理解成具体的日期，但格式不对，导致工具函数解析失败。后来我在工具函数里加了容错处理，支持多种日期格式。

其次是执行状态管理。一个任务可能涉及多个工具调用，中间任何一步失败都需要处理。比如创建会议时，查日历成功了，但发送邀请失败了，这时候需要回滚还是重试？我的做法是给每个工具调用定义明确的成功和失败状态，失败时根据错误类型决定是重试、跳过还是终止整个任务。

第三是结果反馈。工具执行完之后，需要把结果反馈给 LLM，让 LLM 生成自然语言的回复。比如“会议已创建，时间是明天上午十点，已通知参会人员”。这个反馈环节也需要 LLM 参与，不能简单地拼接字符串，否则回复会很生硬。

2.4 端侧推理引擎：OpenVINO 与 NPU 的配合

端侧推理引擎的选择，直接决定了整个系统的性能上限。目前主流的方案有 OpenVINO、ONNX Runtime、TensorFlow Lite 等。我选的是 OpenVINO，主要原因是它对 Intel 的 CPU、GPU、NPU 支持比较好，而且工具链比较成熟。

OpenVINO 的核心概念是模型转换和推理优化。你先把训练好的模型（比如 PyTorch 或 ONNX 格式）转换成 OpenVINO 的 IR 格式，然后在目标设备上加载推理。转换过程中可以做量化，把 FP32 降到 FP16 甚至 INT8，大幅减少模型大小和推理延迟。

NPU 的使用是端侧推理的关键。NPU 专门为神经网络推理设计，能效比 CPU 高很多。但 NPU 也有局限性，比如对算子支持不全，某些模型结构可能跑不了。我的经验是，先用 OpenVINO 的模型分析工具看看哪些层能跑在 NPU 上，哪些必须回退到 CPU。对于回退到 CPU 的层，可以考虑用模型裁剪或者算子替换来优化。

注意：NPU 的驱动和固件版本很关键。我遇到过同一个模型在不同驱动版本上推理结果不一致的情况，排查了很久才发现是驱动的问题。建议在项目开始时就锁定驱动版本，并且做好版本记录。

3. 实操过程与关键环节实现

3.1 环境搭建与模型准备

先说一下我的开发环境。主机是 Ubuntu 22.04，Intel Core i7 加集成 NPU。OpenVINO 版本用的是 2024.0，Python 环境是 3.10。模型方面，ASR 用的是 Whisper 的小型版本，LLM 用的是 Qwen2 的 1.5B 版本，都做了 INT8 量化。

模型转换的步骤大致如下。以 LLM 为例，先用 Optimum 把 Hugging Face 格式的模型导出为 ONNX，然后用 OpenVINO 的模型优化器转换成 IR 格式。转换命令大概是这样：

optimum-cli export openvino --model Qwen/Qwen2-1.5B-Instruct --weight-format int8 qwen2_1.5b_ov

转换完成之后，会得到一个包含.xml和.bin文件的目录。.xml描述网络结构，.bin存储权重。加载的时候用 OpenVINO 的 Runtime API：

from openvino.runtime import Core core = Core() model = core.read_model("qwen2_1.5b_ov/openvino_model.xml") compiled_model = core.compile_model(model, "NPU")

这里"NPU"是设备名称，也可以换成"CPU"或"GPU"。如果 NPU 不支持某些算子，编译时会报错，这时候需要回退到 CPU 或者做算子替换。

3.2 语音识别链路的搭建

ASR 部分我用的是 Whisper 的 ONNX 版本，通过 OpenVINO 加速。Whisper 的输入是音频的梅尔频谱图，输出是文字。端侧部署时，音频采集和预处理也很重要。

音频采集我用的是sounddevice库，采样率 16kHz，单声道。采集到的音频先做预加重和分帧，然后计算梅尔频谱图。这部分可以用librosa或者torchaudio来做，但为了减少依赖，我直接用 NumPy 实现了梅尔滤波器组。

import numpy as np def mel_filterbank(sample_rate, n_fft, n_mels): # 计算梅尔滤波器组 mel_low = 0 mel_high = 2595 * np.log10(1 + (sample_rate / 2) / 700) mel_points = np.linspace(mel_low, mel_high, n_mels + 2) hz_points = 700 * (10 ** (mel_points / 2595) - 1) bin_points = np.floor((n_fft + 1) * hz_points / sample_rate).astype(int) filters = np.zeros((n_mels, int(n_fft / 2 + 1))) for i in range(1, n_mels + 1): left, center, right = bin_points[i - 1], bin_points[i], bin_points[i + 1] for j in range(left, center): filters[i - 1, j] = (j - left) / (center - left) for j in range(center, right): filters[i - 1, j] = (right - j) / (right - center) return filters

这段代码看起来简单，但实际调试的时候花了不少时间。主要是梅尔滤波器的边界处理容易出错，特别是当bin_points有重复值时，会导致除零错误。后来加了判断，确保center和left、right不相等。

3.3 LLM 推理与 Token 管理

LLM 推理是端侧最耗资源的部分。1.5B 的模型，INT8 量化之后大概 1.5GB 左右，推理时还需要额外的内存做 KV Cache。在 8GB 内存的设备上，跑起来还算流畅，但如果你同时跑 ASR 和 LLM，内存就比较紧张了。

Token 管理是端侧 LLM 的一个核心问题。端侧模型的上下文窗口通常只有 2K 到 4K Token，而系统提示词、工具描述、历史对话加起来很容易就超了。我的策略是：

• 系统提示词和工具描述固定占用约 500 Token，这部分不压缩。
• 历史对话只保留最近 3 轮，每轮平均 100 Token，共 300 Token。
• 更早的对话做摘要，压缩成 100 Token 左右的摘要。
• 用户当前输入预留 200 Token。
• 输出预留 500 Token。

这样总共约 1600 Token，留出了足够的余量。如果工具描述特别多，可以考虑动态加载，只把当前任务相关的工具描述放进上下文。

实操心得：Token 计数不要用估算，一定要用模型对应的 tokenizer 来精确计算。我一开始用字符数除以 4 来估算，结果中文场景下误差很大，导致上下文经常溢出。

3.4 工具调用的实现与调试

工具调用的实现，我定义了一个简单的注册机制。每个工具是一个 Python 函数，带一个装饰器标注工具名称和参数描述：

TOOLS = {} def tool(name, description, params): def decorator(func): TOOLS[name] = { "function": func, "description": description, "params": params } return func return decorator @tool( name="set_ac_temperature", description="设置空调温度", params={"temperature": "整数，范围16-30"} ) def set_ac_temperature(temperature): if not isinstance(temperature, int) or temperature < 16 or temperature > 30: return {"status": "error", "message": "温度参数不合法"} # 实际调用空调控制接口 return {"status": "success", "message": f"空调已设置为{temperature}度"}

LLM 输出的工具调用请求，解析之后从TOOLS字典里找到对应的函数执行。执行结果再拼成提示词，让 LLM 生成最终回复。

调试工具调用的时候，最常见的问题是 LLM 输出的 JSON 格式不对。有时候会多一个逗号，有时候引号不匹配。我的做法是在提示词里明确要求输出 JSON，并且在解析时做容错处理，比如用正则提取 JSON 部分，或者用json.loads的strict=False模式。

4. 常见问题与排查技巧实录

4.1 语音识别不准的排查思路

ASR 不准是最常见的问题，原因可能有很多。我整理了一个排查顺序：

我遇到过一次很诡异的问题，识别结果总是多出一些语气词。排查了半天，发现是音频采集时缓冲区没清空，上一句的尾音被带到了下一句。后来在每次采集前加了缓冲区重置，问题就解决了。

4.2 LLM 输出格式不稳定的处理

LLM 输出格式不稳定，是端侧 Agent 开发中最头疼的问题之一。你明明在提示词里写了“请输出 JSON”，它有时候就是给你输出一段自然语言。

我的应对策略是多层防护。第一层，提示词里用 Few-shot 示例，给两三个输入输出的例子，让 LLM 模仿。第二层，输出解析时做容错，先用正则提取可能的 JSON 片段，再尝试解析。第三层，如果解析失败，把错误信息反馈给 LLM，让它重新输出。第四层，如果重试两次还是失败，就降级到规则匹配，用关键词来推断意图。

这套策略下来，格式问题的发生率从最初的 20% 降到了 2% 以下。剩下的 2% 主要是非常复杂的多意图输入，这种场景本身就需要更高级的规划能力，不是单纯靠格式约束能解决的。

4.3 NPU 推理报错的常见原因

NPU 推理报错，很多时候是模型转换的问题。OpenVINO 在转换模型时，会尝试把算子映射到 NPU 支持的算子集。如果某个算子不支持，转换会失败或者回退到 CPU。

常见的报错和解决方法：

• Unsupported operation：某个算子 NPU 不支持。解决方法是查找替代算子，或者把该层放到 CPU 上执行。
• Dynamic shape not supported：NPU 通常要求静态 shape。解决方法是在转换时固定输入 shape。
• Memory allocation failed：模型太大，NPU 内存不够。解决方法是做更激进的量化，或者把模型拆成多个子图。
• Precision loss：量化后精度下降太多。解决方法是改用 FP16 量化，或者对敏感层保留 FP32。

注意：NPU 的推理结果和 CPU 可能有细微差异，这是正常的。但如果差异大到影响业务逻辑，就需要检查量化配置是否合理。

4.4 端侧资源竞争的调度策略

端侧设备上，ASR、LLM、工具执行可能同时需要资源。如果调度不当，会出现卡顿甚至死锁。我的做法是给每个任务定义优先级：唤醒词检测最高，ASR 次之，LLM 推理再次，工具执行最低。高优先级任务可以抢占低优先级任务的资源。

具体实现上，我用了一个简单的任务队列，每个任务带优先级标记。调度器每次从队列里取最高优先级的任务执行。如果高优先级任务需要的内存不够，就暂停低优先级任务，释放资源。

这个调度策略在实际使用中效果不错，语音交互的响应延迟稳定在 500ms 以内。当然，如果你的设备资源更紧张，可能需要更精细的调度，比如按时间片轮转，或者用实时操作系统的优先级继承机制。

5. 性能优化的几个实战方向

5.1 模型量化与剪枝的取舍

模型量化是端侧部署的标配，但量化到什么程度，需要根据实际效果来定。INT8 量化通常能减少一半的模型大小，推理速度提升 30% 到 50%，但精度可能会有 1% 到 3% 的下降。对于语音 Agent 来说，这个精度下降通常是可以接受的，因为 ASR 和 LLM 本身都有一定的容错能力。

剪枝是另一个方向，但端侧 LLM 的剪枝比较麻烦，因为 LLM 的权重分布比较均匀，剪枝后容易导致生成质量大幅下降。我的经验是，对于 1.5B 以下的模型，量化就够了，剪枝的收益不大。对于更大的模型，可以考虑结构化剪枝，去掉一些注意力头或者中间层，但需要做大量的实验来验证效果。

5.2 缓存机制的设计

端侧 Agent 的缓存，主要用在两个地方：KV Cache和工具结果缓存。

KV Cache 是 LLM 推理的标配，用来避免重复计算历史 Token 的注意力。OpenVINO 的 LLM 推理支持 KV Cache，但需要手动管理。我的做法是给每个对话会话分配一个 KV Cache，对话结束后释放。如果内存紧张，可以限制同时活跃的会话数量。

工具结果缓存，是针对那些查询类工具的。比如用户问“今天天气怎么样”，天气查询工具的结果可以缓存几分钟，避免重复调用。缓存的 key 可以用工具名加参数哈希，过期时间根据业务场景来定。

5.3 功耗与发热的控制

端侧设备跑 LLM，功耗和发热是绕不开的问题。我的实测数据是，1.5B 模型在 NPU 上推理，功耗大约 3W 到 5W，连续跑 10 分钟，设备温度会上升 10 度左右。如果散热不好，会触发降频，推理速度下降。

控制功耗的方法有几个。一是动态频率调整，根据任务负载调整 NPU 的频率。二是批处理，把多个推理请求攒到一起跑，减少唤醒次数。三是模型分时加载，不用的模型及时卸载，释放内存和算力。

实操心得：如果你的设备有主动散热（比如风扇），可以把功耗阈值设高一点，换取更好的性能。如果是被动散热，建议把功耗阈值设低一点，避免过热降频。

6. 从 Demo 到产品的距离

6.1 稳定性比性能更重要

做 Demo 的时候，大家关注的是“能不能跑通”。但做产品，关注的是“能不能稳定跑”。我见过太多 Demo 很惊艳，但一到实际使用就各种崩溃的项目。

端侧语音 Agent 的稳定性，涉及很多方面。音频采集不能丢帧，模型推理不能内存泄漏，工具调用不能超时卡死，异常情况要有兜底方案。这些看起来都是小事，但任何一个小事出问题，用户体验就会大打折扣。

我的做法是，在开发阶段就引入压力测试。模拟连续语音输入、网络中断、内存不足等异常场景，看系统能不能正确处理。压力测试暴露出来的问题，往往比功能测试更有价值。

6.2 用户体验的细节打磨

语音 Agent 的用户体验，不只是识别准不准、响应快不快。还有很多细节会影响用户的感受。

比如反馈时机。用户说完话之后，如果系统没有任何反馈，用户会以为没听到。所以需要在 ASR 完成、LLM 开始推理、工具开始执行这些节点，给用户一个轻量的提示音或者视觉反馈。

再比如错误提示。工具调用失败时，不能简单地说“操作失败”，而要告诉用户失败的原因和可能的解决方法。比如“空调控制接口暂时不可用，请稍后重试”就比“操作失败”好得多。

还有多轮对话的上下文保持。用户说“调高温度”，系统问“调到多少度”，用户说“26 度”。这个多轮交互中，系统需要记住上一轮的意图是“调高温度”，才能正确理解“26 度”是温度值。这需要在对话状态管理上做好设计。

6.3 持续迭代的数据闭环

端侧语音 Agent 上线之后，怎么持续优化？关键是建立数据闭环。在用户授权的前提下，收集脱敏后的交互数据，分析哪些场景识别不准、哪些意图理解错了、哪些工具调用失败了。然后针对性地优化模型和提示词。

数据闭环的建立，需要注意隐私保护。我的做法是，只在本地做统计和聚合，不上传原始语音和对话内容。比如统计“导航意图的识别准确率”，只上传准确率数值，不上传具体的语音数据。

这个闭环跑起来之后，你会发现优化方向非常明确。哪些问题高频，哪些问题影响大，数据都会告诉你。比拍脑袋想优化点靠谱得多。

7. 一些踩过的坑和真实体会

7.1 不要低估音频前端的复杂度

我一开始把大部分精力放在 LLM 和工具调用上，觉得音频前端就是调个库的事。结果实际做下来，音频前端花的时间比 LLM 还多。回声消除、噪声抑制、自动增益控制，每一个都需要仔细调参。特别是回声消除，如果设备有扬声器，用户说话时扬声器也在放音，不处理好就会导致 ASR 识别到自己的声音。

7.2 工具描述要写得像“说明书”

LLM 调用工具的准确率，很大程度上取决于工具描述写得好不好。我一开始工具描述写得很简单，比如“设置温度”，结果 LLM 经常传错参数。后来把描述改成“设置空调温度，参数 temperature 为整数，范围 16 到 30，单位摄氏度”，准确率就上来了。

工具描述要包含：工具的功能、参数的名称和类型、参数的取值范围、返回值的格式。写得越清楚，LLM 越不容易出错。

7.3 端侧 LLM 的“幻觉”问题

LLM 的幻觉问题在端侧同样存在，而且因为模型更小，幻觉可能更严重。比如用户问“今天有什么安排”，LLM 可能会编造一个不存在的日程。解决方法是，对于事实性的查询，强制走工具调用，不让 LLM 直接生成答案。LLM 只负责理解意图和生成回复，事实数据必须来自工具。

7.4 测试用例要覆盖“边缘情况”

功能测试大家都会做，但边缘情况的测试往往被忽略。比如用户说话说到一半停了，或者同时说两个意图，或者用非常规的表达方式。这些边缘情况在实际使用中出现的频率不低，如果没处理好，用户就会觉得“这玩意儿不好用”。

我的做法是，专门建一个边缘情况测试集，每次模型或提示词更新，都跑一遍这个测试集，确保没有回归。

7.5 端侧部署的版本管理

端侧部署的版本管理是个容易被忽视的问题。模型版本、驱动版本、推理引擎版本、应用版本，任何一个版本不匹配都可能导致问题。我建议用配置文件把所有版本信息记录下来，每次部署前做一次版本校验。这样出问题的时候，排查起来会快很多。

8. 后续可以扩展的方向

端侧语音 Agent 这个方向，还有很多可以深挖的地方。比如多模态融合，除了语音，还可以加入视觉信息，让 Agent 能“看到”用户在指什么。再比如个性化适配，根据用户的使用习惯和偏好，动态调整 Agent 的行为。还有联邦学习，在保护隐私的前提下，让多个设备协同优化模型。

不过这些都是后话。眼下最重要的，还是把基础的链路做稳定，把常见的场景做扎实。端侧语音 Agent 的价值，不在于它能做多少事情，而在于它能把核心的事情做得足够好、足够快、足够可靠。用户不会因为你支持一百个功能就满意，但会因为一个常用功能经常出错而放弃。

我个人在实际操作中的体会是，端侧 AI 应用的开发，工程能力比算法能力更重要。模型可以调，参数可以试，但工程架构设计不好，后面会越做越累。所以如果你正准备入手这个方向，建议先把整体链路想清楚，再动手写代码。磨刀不误砍柴工，这话在端侧开发里特别适用。