构建语音控制型AI代理

很多人以为构建语音代理就是把三件事接起来：语音转文字（STT）、大语言模型（LLM）和文字转语音（TTS）。按这个思路，用户说完话后，STT 先转写出完整文本，LLM 再生成完整回复，TTS 最后播放完整音频。这是最简单的顺序式架构，但它不是 2026 年生产级系统的标准，因为每一级都在空等前一级完全结束，延迟层层叠加，无法带来真实的对话感。

真正难的不是提示词，也不是模型，而是编排。语音本质上是一个话轮切换问题，而不是转写问题。流式语音识别、语义级结束检测、流式生成、打断处理，以及语音约束下的工具调用，这些环节共同决定了系统是像真人对话，还是像一棵挂了聊天机器人的电话树。

生产系统普遍采用流式模式：STT 把部分转写持续送给 LLM，LLM 把 token 流式交给 TTS，TTS 在 LLM 还在生成后文时就能播放第一句。这样能显著降低感知延迟，但对打断、缓冲和部分状态的处理要求更高。人跟人对话时，两个说话人之间的自然间隔约为 200 到 300 毫秒。超过 500 毫秒就会让人明显觉得慢，超过 3 秒多数用户会失去耐心甚至认为系统已经卡死。当前主流厂商的 speech-to-speech 系统首 Token 时间大多在 0.8 到 3 秒之间，所以架构选择本身，就已经决定了你的代理落在「自然」还是「被挂断」区间。

流式语音识别的第一项职责，不是“转写这段音频文件”，而是边接收音频边输出转写，并在确信用户说完后发出信号。生产级 STT 通常基于常驻 WebSocket 连接，音频按约 50ms 的小块发送，返回的是连续事件：先是一些 PARTIAL 事件，内容随新音频不断修正，最后出现一个不会再变的 FINAL 事件。下游逻辑只应该基于 FINAL 事件执行，PARTIAL 事件仅用于实时展示。实体信息的准确率至关重要——订单号、电话号码、专有名词只要听错一个数字，后续函数查找就会失败，而真人接线员本来可以通过确认来避免。

话轮检测是一个独立的组件，它不看转写文本，而是看音频流里的静音模式。它要回答的问题是：用户到底说完了没有？如果太急，就会打断对方思考中的停顿；如果太慢，每轮对话都会拖着尴尬的沉默。生产系统通常用两个数字来控制：最小静音时长，常见为 600ms，只有转写端也认为这句话语义完整时才结束话轮；最大静音上限，常见为 1500ms，即使句子听起来还不完整，也强制触发回应。面向老人护理、医疗等语速较慢的场景，可以把上限提高到 2500ms；而快节奏对话场景则可以把下限降到 300ms。这是一个可根据业务场景调整的策略，不是写死在架构里的常量。

除了上述环节，流式生成、打断处理和语音约束下的工具调用同样重要。LLM 生成回复时应把 token 持续送向 TTS，而不是等整段结束；打断处理（barge-in）要在用户插话时快速取消当前音频播放、回到监听状态；工具调用则要把函数决策放进延迟预算，必要时通过对话补充缺失参数，而不是让用户重复输入或等待。只有把这些编排问题一起解决，语音代理才真正谈得上「可对话」。