我的语音代理测试现在包含600秒断崖
摘要
作者描述了一次语音代理通话在600秒时被无预警切断的情况，并提出了一种优雅处理最大通话时长的测试方法，包括切断前警告和状态保存。
我曾以为长语音通话已基本解决，直到有一次我在开车时使用，它正好在600秒时被切断。令人烦恼的不仅是超时本身，而是通话在思路进行到一半时突然结束，没有警告、没有总结、也没有清晰的下一步。转录记录虽然存在，但整个工作流感觉被抛弃了。现在我把最大通话时长视为一个质量保障（QA）用例，而不是基础设施细节。我的测试方法：- 让通话超过预期限制 - 在切断前发出警告 - 捕获简短总结 - 保留转录记录 - 写入重试或下一步动作状态如果代理无法优雅地收尾，那么该通话还不能投入生产。它可能完美地处理正常轮次，但在用户需要连续性的关键时刻却显得支离破碎。对于构建语音代理的人：你们会测试最大通话时长/收尾行为吗？还是主要测试中断和延迟？
相似文章
我最喜欢的最小语音助手测试：让它追问缺失的问题
语音助手的一个简单测试：给出一个不明确的指令（例如“使用存档地址”），看看助手在确认前是否会要求澄清。后续问题的质量揭示了助手的可靠性。
为服务型企业运行生产级语音代理6个月：延迟计算远比演示所暗示的复杂。
在为服务型企业运行语音AI代理6个月后，作者揭示了现实世界中的延迟是双峰的（中位数约800ms，p95约2.4s），而p95决定了用户的感知。诸如VAD误触发、长提示词下函数调用退化、以及TTS质量等问题比LLM的选择更重要，而多语言支持则增加了显著的成本。
我们的语音代理p99为280ms，竞争对手为450ms，但用户却觉得我们的更慢。我们测量了原因。
一个语音代理团队发现，尽管端到端延迟更低（280ms对比竞争对手的450ms），但由于糟糕的打断响应时间（380ms对比60ms），用户感知更慢。他们确定了三项修复措施——内存锁定、VAD阈值调整和更小的TTS块——将100ms阈值下的打断率从41%提升至89%，让用户感觉更快。
EVA-Bench：评估语音代理的新型端到端框架
EVA-Bench 提出了一个全面的端到端评估框架，用于评估语音代理，模拟真实的多轮对话，并通过新颖的准确度（EVA-A）和体验（EVA-X）指标衡量语音特定故障模式下的性能。该基准包含企业领域的 213 个场景以及用于口音和噪声鲁棒性的扰动套件，揭示了当前系统的显著差距。
EchoChain：面向中断场景的全双工状态更新推理基准
EchoChain 是一项全新基准测试，旨在评估 AI 模型在用户中途打断时修正正在进行中的回复的能力。该基准提炼出三种典型故障模式（上下文惯性、中断遗忘、目标偏移），结果表明，在当前评估的实时语音模型中，无一系统的通过率突破 50%。