Jesse Hall：语音智能体要为对话而优化，而非只看排行榜

摘要

30 秒看懂

Jesse Hall 以金融服务为例，说明语音智能体一旦误听日期、无法处理打断或在后台工具运行时陷入沉默，就会让真实对话失去连贯性。单个模型的排行榜无法衡量整个对话体验，因此团队应测试完整语音栈，测量用户听见第一段音频和第一句话所需的时间，并让慢速工具异步运行。 Hall 还介绍了结合语音节奏和转录文本的轮次检测，以及用模拟来电者评测真实智能体的方法。团队应在约 1.5 秒的响应窗口内权衡延迟和自然度，并把失败情形持续加入回归测试。

1实时对话不能像后台任务那样等待写代码或做研究的后台智能体多等几秒通常没关系；语音智能体面对的是实时交谈。用户一旦打断它或改变支付日期，系统就必须跟上，不能让整段对话崩掉。
2排行榜评分组件，产品交付的是整段对话语音转录把“3 号”听成“30 号”后，后续模型会沿着错误信息继续执行。干净录音上的单项成绩无法反映嘈杂现实中的这一整条错误链。
3衡量用户实际听到的延迟首字节后可能还有四分之三秒的静音，首个 token 也不代表 TTS 已能开口。应记录用户听到第一段音频和第一句话的时间。
4慢速工具异步运行，让对话继续类似人类客服先告诉用户自己正在查询，智能体也可以让交易检索在后台继续，同时把麦克风控制权交还给对话。工具出错时，它可以核实并纠正，必要时转接人工。
5轮次检测要听音频，而不只是读转录LiveKit 的轮次检测器还会分析节奏、音高和语调。Hall 报告称，在他们的使用场景中，另一款方案打断用户的比例为 9.9%，LiveKit 为 4.5%；他说这些是针对自家酒店智能体等场景的评测结果。
6用模拟来电者比较完整语音栈让模拟用户改变主意、打断、含糊说话或制造背景噪声，并检查预期业务结果、工具调用步骤和整段对话质量。对同一智能体和场景逐个更换模型，才能找出适合该产品的组合。

要点建议

评估整段语音对话和实际业务结果，不要只按单个模型的排行榜选择组件。
测量用户真正听见第一段音频和第一句话的时间，而非首字节或首个 token。
让后台工具异步执行，把对话控制权交还给智能体，避免漫长静默。
轮次检测应结合音频节奏、音高和语调，减少用户还没说完就被打断的情况。
用会打断、改主意、含糊说话并带有背景噪声的模拟来电者测试完整系统。

主题语音 AI 智能体工程评估 AI cost & performance 产品与体验

全文

按章节阅读完整文稿

实时语音智能体为何容易失去连贯性

后台智能体可以多花一些时间完成任务，实时语音智能体却必须接住打断和变化。Hall 以金融服务中的支付金额和日期为例，说明语音系统出错会带来更高风险。

很多日常智能体都在后台工作：它们写代码、做研究，收到任务后就去执行。多等十秒、十分钟，有时甚至十小时，我们通常都能接受。但实时智能体不同。

过去一年里，你可能打电话给药房、航空公司或汽车经销商时遇到过实时语音智能体。对话中，人们会像平常一样插话、打断，甚至把智能体弄糊涂；如果它接不住，整段交流就会变得不自然，用户最后只好按 0 找真人。

金融服务里的风险更高。用户可能先安排一笔付款，中途又改金额或日期；如果智能体没跟上，就不只是对话体验差，还可能导致业务操作出错。

语音智能体要像人一样自然

Hall 将延迟视为重要约束，但认为目标不只是尽可能快，而是让智能体听起来像在自然交谈。他介绍了 LiveKit 的实时框架，并把重点放在语音场景。

构建语音智能体时，大家往往先想到延迟，觉得越快越好。Hall 认为延迟确实有预算限制，但关键目标是让智能体尽可能像人一样交流，而不仅是单纯追求更快。

语音是人类很自然的交互方式。LiveKit 提供开源实时框架与基础设施，让智能体可以听、看并与对方说话；Hall 这场演讲聚焦于语音，因为它带来了独特的实时挑战。

为什么模型排行榜选不出合适的语音栈

传统级联管线把语音转文字、LLM 和文字转语音串起来，也可以使用语音到语音模型。模型组件的排行榜看不到整段对话中的误听、用户打断和真实环境噪声。

传统语音智能体把三个模型串成一条管线：语音转文字、LLM 和文字转语音。另一种较新的做法是语音到语音模型，但现阶段也未必适合所有场景。团队需要在数百个模型和数十家供应商之间作选择。

排行榜为单个模型或组件打分，产品却要交付一整段对话。比如来电者说“3 号付款”，语音识别却听成“30 号”，LLM 接着按错误日期规划，后面的系统自然也会沿着错误结果执行。排行榜无法体现这条错误链；它们通常还使用干净音频，而真实来电可能来自车流噪声和后座孩子的背景声。

从首字节转向用户可感知的延迟

TTS 的首字节指标可能掩盖后续静音，LLM 的首个 token 也不代表已经生成可朗读的句子。Hall 主张测量用户听到第一段音频和第一句话的时间。

真正该问的问题不是“该选哪个模型”，而是“针对我的用途，该上线哪套技术栈”。在比较方案时，TTFB 看起来可能很快，例如 210 毫秒，但 Hall 称他们测试过的一些服务在首字节后还会静默四分之三秒。用户听到的并不是字节，所以更应测量从请求到第一段可听音频的时间。

LLM 的首个 token 同样不足以说明语音响应有多快，因为 TTS 通常要等到有完整句子才开始说话。因此团队应记录“首句时间”。生成 token 很快的模型，不一定能最快产出可以朗读的第一句话。

让工具调用在后台异步运行

金融语音智能体需要查交易、核实付款状态或提交争议，这些工具可能很慢。通过异步工具调用，智能体可以先继续对话，同时让后台工作独立运行。

语音智能体还得实际办事：查询交易、确认付款状态、提交争议。这些后端工作可能花几十秒，系统不可能把这段延迟藏起来。Hall 建议换个问题：人类客服这时会怎么做？

人类不会一直沉默等系统完成，而会先告诉对方“我查一下”，或者一边等待、一边继续问其他问题。智能体也应该能多任务处理。

Hall 展示的代码只多了一行异步更新：工具调用执行时，把麦克风控制权交还给智能体。这样对话线程和工具工作可以分开，智能体能继续说话，而后台查询仍在进行。

酒店预订演示中的持续对话

演示中，来电者预订酒店，智能体一边逐项收集信息，一边将数据写入后端。Hall 强调它不会等每项保存完成后才提出下一问，遇到错误还可以核实或转接人工。

酒店预订演示里，来电者说出日期、人数、房型偏好和联系方式。智能体可以被打断，但仍顺畅地推进预订流程。

Hall 指出，演示中的工具调用正在把信息写入后端，但智能体没有等每一项保存完再继续。若工具返回错误，它可以重新核实；问题无法解决时，则可以把来电者转接给人工。

结合语音信号判断何时轮到谁说话

LiveKit 的轮次检测器不只依据转录文字，还会分析节奏、音高和语调。Hall 展示了付款金额中途停顿的例子，说明音频线索能帮助系统等用户说完。

另一个关键能力是判断何时该说、何时该听，也就是轮次检测。LiveKit 的内置检测器除了分析转录文本，还会听音频中的节奏、音高和语调。

Hall 报告说，在他们的酒店智能体等使用场景里，另一种方案有 9.9% 的概率打断用户，LiveKit 的数字是 4.5%。他说明这些是他们针对自身场景得到的结果，并且相关评测可以开源运行，让团队用自己的数据集复测。

例如，用户要支付 555.23 美元，在说完“500”后停顿了两秒。只看转录文本的检测器可能以为用户已经结束；结合语调的系统则可能判断用户还没说完，继续等待。

把响应控制在有限的延迟窗口内

延迟窗口从来电者说出最后一个音节，到智能体发出第一段可听见的回应。Hall 认为约 1.5 秒是一个上限；缩短到 500–600 毫秒时，对话会更像人与人交流。

响应延迟窗口从来电者说出最后一个音节开始，到智能体发出第一段能听见的回应为止。轮次检测器判断用户何时说完，LLM 根据暂定转录准备回答，TTS 则尽可能早地开始生成音频。所选模型、函数调用和交接都必须落在这个有限窗口里。

Hall 认为，约 1.5 秒的等待还能维持对话，但已经会让人觉得有些不自然；如果两轮之间只有 500–600 毫秒，体验会更像真人交流。因此真正的问题不是怎样无限提速，而是如何在延迟窗口中容纳尽可能自然的智能体。

用模拟对话为自己的场景做基准测试

团队可以让模拟来电者追求目标、打断、改变主意或制造噪声，再检查对话结果和智能体执行的步骤。固定智能体与场景、逐一替换模型，便能构建适合自身用途的基准。

要选择合适的模型，就拿一套真实可用的智能体做完整对话测试。Hall 以酒店接待智能体为例：它有真实后端，不只是演示，并且可以开源检查。

团队可以让模拟来电者追求目标、改变主意、打断、含糊说话或带入背景噪声。文本模拟侧重业务逻辑；音频模拟则可以覆盖语音识别、轮流发言和整个语音管线。

每个测试场景都应说明来电者想做什么、智能体该采取哪些动作，以及预期结果是什么。酒店测试可以核实正确的预订是否写进数据库；金融测试则可以确认扣款金额是否正确并经过授权。

不能只看任务有没有完成，因为智能体可能用错误的步骤达到表面上的结果。测试还应检查它是否绕了不必要的步骤，是否编造了函数调用，以及整段对话是否符合预期。

接着保持智能体和场景不变，只替换模型，并让每个模型看到完全相同的输入。反复运行后，团队就能针对自己的智能体和用途建立个性化基准，找出最合适的组合，而不是照搬通用排行榜。

Hall 说，最适合某项用途的模型可能并不在排行榜顶部；有时，能最快给出正确结果的模型才更合适。他还表示，这套模拟和基准测试方法是开源的，团队可以用自己的智能体试跑。

评测结果与上线前检查清单

Hall 展示了酒店智能体的模型延迟对比，并强调语音智能体是实时系统，而不只是带扬声器的聊天机器人。他建议检查可感知延迟、关键金额和日期、身份授权、工具结果及整段对话。

Hall 展示了酒店智能体的首句延迟对比：Gemma 4 31B 在 LiveKit Inference 上为 381 毫秒，同一模型通过 OpenRouter 为 844 毫秒；Gemini 2.5 Flash 为 932 毫秒，GPT-4.1 为 1,097 毫秒，GPT-5.5 为 1,645 毫秒。这是该酒店场景的评测结果。他称 LiveKit 针对语音负载优化了推理服务，同时平台不绑定单一模型。

Hall 希望大家记住，语音智能体不是“加了扬声器的聊天机器人”，而是必须像人一样实时响应的系统。上线前应设定用户感知到的延迟预算，测量首段音频和首句时间，确认关键金额与日期，在访问账户前验证身份，并确保工具运行期间对话仍能继续。

团队还应反复模拟完整对话，检查最终状态、隐私保护、不必要的工具调用和轮流发言。每次发现失败，都把它变成回归测试场景，持续迭代；先从最关心的一项工作流程或失败开始，听回放并核对后端发生了什么。Hall 以邀请大家动手构建自然语音智能体作结。