语音 Agent 调试指南：快速定位故障源

出了问题：Agent 说了些莫名其妙的话，或者停顿了三秒，又或者完全误解了用户。真正的问题是：到底是哪一层出了故障？答案并不明显，而靠猜测排查的代价很高。

关于调试语音 Agent，有一件事几乎没人会提前提醒你：故障几乎从来都不发生在你以为的地方。

语音 Agent 给出了错误答案，不一定是 LLM 的问题。语音 Agent 听起来像机器人，不一定是 TTS 的问题。语音 Agent 似乎“听错”了用户，也不一定是 STT 的问题。

整个 pipeline 是串行的，每个阶段都会把结果传给下一个阶段。这意味着第一层发生的故障，在用户看来就像是所有环节都出了问题。

复合错误问题

语音 Agent 的错误会沿着 pipeline 以乘法效应叠加，而不是简单相加。

当 STT 和 NLU 各自的准确率均为 95% 时的端到端意图识别准确率

当第一轮对话中的用户意图被错误分类时，更高的通话放弃率

动手之前，先读懂 Pipeline

生产环境出现故障时，人们的第一反应往往是立即修改某些东西。请克制这种冲动。第一步永远应该是端到端追踪整通电话，找出究竟是哪个阶段产生了故障。

调试决策树

如果答案是 NO：问题出在 STT。检查背景噪声、口音或领域术语。修复方法包括微调模型或更换服务提供商。

如果答案是 NO：问题出在 LLM。检查 system prompt、context window，或者 RAG 故障，例如缺少上下文。

如果答案是 NO：问题出在 TTS。检查首段音频延迟、音素覆盖配置或发音模型。

STT：一个故障，污染所有环节

大多数语音 Agent 故障都源于 Speech-to-Text。真实环境中存在汽车噪声、各种口音以及糟糕的电话连接，这些因素可能让准确率产生超过 10 个百分点的波动。

术语问题：Deepgram Nova-3 在各项 benchmark 中处于领先地位，但在医疗等专业领域，如果不针对具体领域进行微调，其性能就会下降。在生产环境中，微调不是可选项，而是必需项。

LLM：通常不是问题所在

GPT-4o、Claude 或 Gemini 等现代模型的表现大体相近。这一层的故障通常源于含义模糊的 prompt、context window 溢出，或者检索质量不佳导致的幻觉。

TTS：延迟与质量

混淆延迟故障和质量故障，只会浪费排查时间。对于响应时间问题，解决方案是流式 TTS：第一个句子的 token 一到达，就立即开始语音合成。

黄金法则：把每次故障都变成回归测试

成熟的团队会为每次故障保留原始音频、STT 转录文本以及完整的 LLM 日志，防止同一个问题在未来版本中再次出现。