跨国深谈← 返回←文字稿看着没问题,通话却出事了——语音智能体的调试困境

文字稿看着没问题,通话却出事了——语音智能体的调试困境

关联

人物 Fuad

公司 Arise

概念 语音智能体 · OpenInference · OTEL · trace · 评估 · 延迟 · 智能体

语音智能体正在爆发式增长：GPT Realtime 刚发布，Vercel 也刚上线语音智能体功能。

但从 White Castle 的点餐机器人 Linda 到 McDonald’s 的自动化点单，这个领域有一个致命问题——它极其脆弱，而且很多故障你根本看不见 。

为什么说“日志在撒谎”？

Fuad 放了一段 AI 生成的通话录音：用户说“我要给订单 14 退款”，智能体回答“好的，已开始为订单 40 办理退款”，用户纠正“不，是 14”，然后确认完成。

单看文字稿，你会以为智能体正确纠正了自己。但听音频就会发现真相：智能体在用户说完之后沉默了 2.4 秒；

它抢在用户话音未落时就开口说话，把用户打断；把 14 听成了 40；而且语气平板机械。退款实际办在了订单 40 上——一个严重错误。

这些全是音频层面的问题。「如果你只是读模型的文字输出，你完全不知道出了什么事」。

要看见通话，而不是读通话

Fuad 的核心主张是：

调试语音智能体，必须把音频、文字稿和调用链放在同一个界面里看，再加上具体指标——首音频响应时间、延迟、打断事件、情绪分析等等。

他用了一个类比：

如果你凌晨两点在排查一通客户电话，能在几十亿条调用记录里快速过滤、排序、定位到出问题的那一段，才是关键 。

实现上，Arize 把音频的语义约定映射到了开源的 OpenInference 规范上。

这套规范是开放免费的，可以把 OpenAI、Google 等不同供应商的模型统一成一个可查询的数据结构，不用为每家单独写解析代码。

评估也要针对音频，而不是文字稿

只对文字稿做大模型打分是不够的。语气和情绪必须基于原始音频来判断——正面的、中性的还是负面的，不能靠猜。

首音频延迟在客服场景里仍是硬指标，打断、转写漂移、任务是否成功，也都值得直接对着音频跑评估 。

更进一步的思路是“智能体当裁判”：

不只分析对话，而是真的去访问工具和第三方系统，检查智能体是不是按权限访问了该访问的东西。

终极目标：自我修复的软件

Fuad 描绘了一个闭环：观察、评估、改进。

他举例说，一个运维智能体可以自动排查高延迟问题——比如发现工具返回的结果没有截断，导致上下文过载——然后自动写好修复、部署到开发环境，把之前失败的调用重放一遍验证效果。

「你早上醒来，看到一个 PR，里面写着问题的来龙去脉和修复报告，你只需要点批准或拒绝」。

他的收尾提醒很直白：你能接受一个执行股票交易的智能体犯这种错吗？不能。

那一个帮你点芝士汉堡的 McDonald’s 智能体，也不该被放过。

本集带走

• 语音智能体的很多故障（延迟、打断、听错数字、语气）在文字稿里完全不可见，必须听音频、看调用链才能发现。
• 调试语音要把音频、文字稿、追踪和指标放在同一视图，并统一成可查询的开源数据规范（OpenInference）。
• 评估要基于音频本身：情绪、语气、首音频延迟、打断事件，而不只是对文字稿打分。
• “观察—评估—改进”的闭环可以做到自动化：智能体自动定位故障、提出修复、重放验证，人只做最终审批。
• 对语音智能体的质量标准应该向编码智能体看齐，点汉堡的智能体也不该出错。

尽管对一个帮你点芝士汉堡的麦当劳智能体来说，赌注看起来可能低一些，但你也不应该接受它。
You shouldn’t be OK with it, though the stakes might seem a little lower for a McDonald’s agent that’s ordering you a cheeseburger either.
—— Fuad · [16:55]

而且就我个人而言，如果我凌晨 2 点在麦当劳，结果收到 600 个芝士汉堡，我会相当恼火。
And personally, I’d be pretty pissed off if I was at McDonald’s at 2 a.m. and I got 600 cheeseburgers.
—— Fuad · [02:30]