--- id: "OmyqelTwpOo" title: "如何打造经得起打断的语音智能体" channel: "AI Engineer" host: [] guests: ["Jesse Hall"] date: "2026-10-26" updated: "2026-10-27" duration: "20:55" duration_seconds: 1255 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=OmyqelTwpOo" canonical: "https://pod-exp.pages.dev/OmyqelTwpOo/" transcript_jsonl: "https://pod-exp.pages.dev/OmyqelTwpOo/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["AI 智能体","AI 基础设施","模型评测"] series: ["AI 基础设施"] --- # 如何打造经得起打断的语音智能体 > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** 本期讨论如何构建能自然应对打断的实时语音智能体，尤其是金融服务等出错代价较高的场景。演讲者指出，语音交互的体验不只取决于模型快不快，而取决于整场对话能否顺畅完成：排行榜测单个组件，却不能替你选出适用于具体业务的完整技术栈。团队应关注用户真正听到首段音频、听到第一句话的时间，并让智能体在慢速工具调用时继续交流。轮次检测还应理解音频中的语调和停顿。最后，演讲者建议用模拟来电者反复测试真实工作流、工具调用、隐私与最终状态，为自己的用例建立个性化基准。 ## [0:14] 实时智能体与后台智能体 · YouTube **讲者：** 今天我们要谈语音智能体。我们平时接触的大多数智能体都在后台做事：替我们写代码、做研究。我们交给它一个任务就走开，回来再看；多等十秒、十分钟，有时甚至十个小时，我们通常也不在意，而且觉得这很正常。 但过去一年左右，你可能已经接触过另一种智能体：实时智能体。比如打电话给药房、航空公司，或者像我前几天打电话给汽车经销商时遇到的那种。通话过程中，你做了一件最像人的事：开口打断它。你插话、把它弄糊涂，整场对话就垮掉了，听起来一点也不自然。然后你做了我每次都会做的事：说“接线员”，按零，要求转人工。 那我们怎么解决这个问题，让智能体尽可能像人？比如在金融场景里，客户打电话安排一笔付款，中途又改了金额、改了日期，而智能体没跟上，就会出问题。尤其在金融领域，风险要高得多。我们该怎么解决？ ## [1:47] 面向金融服务的拟人语音智能体 · YouTube **讲者：** 今天要谈的是如何为金融服务构建更像人的语音智能体。想到好的语音智能体，首先会想到延迟：我们希望它尽可能快。但延迟只是问题的一部分，它有一个有限的预算，稍后会讲到。这里的关键词是“像人”：我们的目标是让语音智能体尽可能自然、尽可能像人。 最近谈语音的人不少。有些人你们可能认识：Sam 对语音模型很兴奋，他说语音模型正在改变我们与 AI 交互的方式。这话没错吧？右下角还有个名字挺奇怪的人，Swyx，不知道你们听没听过。他说语音是“最初的模态”；要让通用人工智能与我们的意图对齐，正确的模态是优秀的语音 AI 工程。这是个相当大胆的说法。还有这里的 JCal 说，我们先学会说话，之后才学会阅读。语音是我们最自然的交互界面。那么，怎么才能让它尽可能自然、尽可能像人？ 举手调查一下：在场有谁做过语音智能体并部署到生产环境？好，我看到几只手。你们中的一些人知道开发时会遇到哪些挑战。还没做过的人，可能见过很好的例子：你们用过 ChatGPT 的高级语音模式和 ChatGPT 对话吗？好，这就引出一点：OpenAI 选择了 LiveKit 来提供这项功能。这是一个很好的语音智能体应用案例。 ## [3:46] LiveKit 与语音管线 · YouTube **讲者：** LiveKit 是面向这类拟人智能体的开源实时框架与基础设施。智能体可以听、看，并与另一端的人交谈。所以我们其实不只是在谈语音。人与智能体可以通过多种方式交互：语音、视频、数据流，甚至物理 AI。我们也有机器人部门。不过语音是切入点，是最自然的交互模态，也有很多挑战。今天我们就聚焦语音。 ## [4:21] 级联管线与语音到语音模型 · YouTube **讲者：** 传统语音智能体采用所谓的级联管线，由三个模型协同工作：语音转文字模型、大语言模型（LLM）和文字转语音模型，它们必须配合一致。还有另一类实时模型，也就是语音到语音模型，可以替代这条管线。不过这是较新的做法，虽然在进步，但还不能满足所有用例。即使如此，我们仍得在传统的三模型管线和语音到语音模型之间选择。选项太多、复杂度太高，该从哪里开始？看看我们要选择的东西：数百种模型、数十家供应商…… ## [5:05] 排行榜不能替你选出整套方案 · YouTube **讲者：** 快速举手调查：有谁曾根据排行榜选模型？榜上排名第一的是哪个，就选哪个来用？我们来谈谈为什么这对实时智能体行不通。不能只挑排行榜最前面的模型，因为排行榜评的是模型这个组件，而我们交付给用户的是一场对话；我们需要把它们组合起来评估。 举个例子：来电者想付账单，说“我想在3号付款”，语音转文字模型却听成了30号。LLM 接下来就按30号来规划，并把这个日期传进系统。LLM 并不知道语音识别模型听错了，于是错误就这样一路向下传递。排行榜只看单个模型，既看不到也评判不了整个问题。 而且排行榜通常用干净音频给模型打分，可真实来电者可能正用免提在车流中打电话，后座还有孩子。因此我们得根据真实世界的场景和案例评估自己的智能体。 假设我们掉进排行榜陷阱，挑了一个模型。大家总会先问“我该选哪个模型？”，于是看排行榜选一个。但真正该问的是：“针对我的用例，我应该上线哪一套技术栈？”这正是我们要弄清楚的问题：该如何回答？ ## [6:46] 衡量首段音频时间，而非首字节时间 · YouTube **讲者：** 在回答这个问题之前，假设你已经选了几个模型，开始测它们的表现。比如在测试 TTS 供应商，供应商仪表盘报告“首字节时间”是210毫秒，看起来非常快。但我们实际测试过不少热门供应商，首字节发出后，用户最多还要等四分之三秒才听到声音。所以，一个字节不等于音频。 我们真正要看的是“首段音频时间”：用户要等多久才能实际听到声音？应该测首段音频时间，而不是首字节时间。想象一下，付款已经处理了，你问“我的付款成功了吗？”，然后听到两秒钟的沉默。这可一点也不能让人安心。我们需要测量来电者实际听到的这段空档。 ## [7:52] 衡量首句时间，而非首个 Token 时间 · YouTube **讲者：** 大语言模型也有同样的问题。文本侧给出的指标是“首个 Token 时间”，但 Token 不等于音频。TTS 不能拿到一个 Token 就开始说话，它实际上需要完整的一句话才能开口。所以我们真正要测的是“首句时间”。 生成 Token 很快的 LLM，不一定也是最快说出第一句话的 LLM。因此我们应该关注首句时间。还有一点是多数排行榜不会测量：这些智能体还得执行实际操作…… ## [8:38] 像人一样处理缓慢的工具调用 · YouTube **讲者：** 智能体不只是陪我们聊天，还需要在后端执行操作：查询一笔交易、查看付款状态、提交争议。这些操作可能要花2、10、40毫秒……那要怎么处理？怎么把40秒甚至更长的延迟藏起来？其实藏不住。该问的是：人在这种情况下会怎么做？ 人会在系统执行操作时一直沉默吗？不会。人会说：“等我一下，我查查看。系统有点慢，马上就好。”或者趁后端系统运行时接着问另一个问题。这就是像人的行为：同时处理多件事。既然人能做到，智能体为什么不能？这是个设问，因为它们能，而且应该能。 实现方式大致如此。这是我今天唯一要展示的代码：一次普通的工具调用，关键就在其中一行。那一行的更新，也就是对这个工具调用使用 `async/await`，就是整个诀窍；它把麦克风控制权交还给智能体，让对话和工具调用不再共用同一个执行线程。它们现在彼此独立。这样智能体就能在后端执行工作的同时继续对话，因此表现得更像人。别光听我说，接下来有个简短演示。 ## [10:14] 演示：酒店预订智能体 · YouTube **讲者：** 我准备了一个简短演示，我们来听听效果。 **酒店智能体：** 感谢致电镀金玫瑰酒店。有什么可以帮您？ **来电者：** 嗯，我想订一间房。 **酒店智能体：** 您想订哪几天？ **来电者：** 下周，从周三到周五。 **酒店智能体：** 下周三，也就是7月30日，到周五8月1日，对吗？ **来电者：** 对。 **酒店智能体：** 会有几位客人入住？ **来电者：** 两位。 **酒店智能体：** 我们有两张床的 Queen 房、双人床的 King 房、两张 Queen 床的房间、套房或顶层套房，您想选哪一种？ **酒店智能体：** 您想要城市景观还是海景？ **来电者：** 海景。 **酒店智能体：** 可以告诉我预订姓名吗？ **来电者：** Jesse Hall。 **酒店智能体：** 是 Jesse Hall 吗？ **来电者：** 是。 **酒店智能体：** 您的电子邮箱是什么？ **来电者：** me@me.com。 **酒店智能体：** me@me.com 正确吗？ **来电者：** 对。 **酒店智能体：** 您的电话号码呢？ **来电者：** 555-123-4567。 **来电者：** 对。 **酒店智能体：** 我需要一张信用卡来担保房间。卡号是多少？ **来电者：** 我们先停在这里。 **讲者：** 好，你们可以看到，对话一直在继续，没有尴尬的停顿。我甚至打断了它，它也顺着接了下去。对话没有崩溃，也没有变得不自然。我们还可以看到过程中发生的工具调用和它执行的操作：它确实在和后端通信，并保存我提供的每一项信息。 不过，它不会等后端说“好了，保存了，你可以问下一个问题”，再继续；也不会每录入一项都等“保存好了，再进行下一项”。它会立刻转到下一步，让对话持续下去。如果工具调用返回错误或出了别的问题，它就会纠正自己，说“让我核实一下”，根据具体情况处理。最糟的情况下，如果它一直有问题，就会把我转接给人工。这就是我们的智能体应该有的表现方式。 ## [12:33] 轮次检测：知道什么时候该听 · YouTube **讲者：** 还有一个维度：让智能体知道什么时候该说、什么时候该听，什么时候要继续听。这叫轮次检测。LiveKit 内置了轮次检测器，多数轮次检测器只听转写文本，它还会听音频本身：节奏、音高和语调。 我们公布了相关数据。表现领先的另一种方案，在9.9%的情况下仍会打断用户、截断用户的话；在我们的用例中，我们的方案是4.5%。这些数字来自酒店智能体等用例。它是开源的，你可以用自己的数据集运行这些评测，看看得到什么数字，看看自己的结果是否更好。 这只是让语音智能体更像人的一小部分：让它知道什么时候该停止说话、什么时候该听。比如我想付款，说：“我想支付500……55.23美元。”大多数轮次检测器会在“500”时就停下来，因为它看到转写里有500，又发现停顿了两秒，就以为我说完了。但我们的检测器会听出我的语调，知道我还没说完，于是继续等我。 ## [14:04] 延迟预算 · YouTube **讲者：** 现在来看看延迟预算，也就是来电者最后一个音节与智能体第一次发出可听见的回应之间的间隔。轮次检测器判断来电者何时说完；语言模型根据暂定转写开始准备回应；随后 TTS 尽可能快地开始生成语音。 你选择的每个模型、每个函数、每次交接，都得挤进这个窗口。窗口有限，大小固定。如果能把延迟控制在大约1.5秒以内，通话还能继续，对话也能维持；但到了1.5秒，就开始让人觉得有点不对劲。如果两轮之间能缩短到500或600毫秒，就真的开始有人的感觉了。 所以问题不是“我能有多快？是不是只要越来越快就行？”答案不是这样。真正该问的是：在这个延迟窗口里，我能塞进多像人的智能体？延迟是一项预算，我们知道怎么把东西放进预算里，但目标仍然是让它尽可能像人。 把这些因素合起来看，“我该选哪个模型？”这个问题原本就无法靠排行榜回答，因为排行榜评分的是模型，而我们交付的是一场对话。现在来回答真正的问题：我们该怎么挑模型？应该选哪些模型？ ## [15:44] 用模拟来电者评测整套技术栈 · YouTube **讲者：** 我们要做的是测试整场对话。拿一个完整、能工作的智能体——刚才听到的酒店接待智能体就有真正的后端，不只是演示，它确实能用，而且是开源的——然后用模拟来电者去测试它。 模拟来电者可以追求目标、改变主意、打断、含糊地说话；我们还可以加入背景噪音，让场景更接近现实，再让所有这些模拟用户与智能体交互。我们可以跑文本模拟，只测试业务逻辑；也可以跑音频模拟，测试语音识别能力、轮流发言，以及整条语音管线。 每个场景都应该说明来电者想要什么、智能体应该采取哪些行动，以及预期结果是什么。然后给结果打分。酒店测试要看正确的预订是否写入数据库；金融测试要看是否扣取了正确且获授权的金额。我们要确认所有预期结果都实现了，但不能只看任务是否完成，因为智能体可能会钻完成率的空子。还得确认它采取了正确的步骤：本来两步就够，它有没有做了十步？有没有幻觉出一次函数调用？这些都要放进整场对话中测试。 之后换掉技术栈中的模型。智能体和场景保持不变，只更换模型，再重复测试。每个模型看到的输入都完全相同，逐字节一致。换模型、跑一轮，再换模型、再跑一轮，反复执行。这样我们就为自己的智能体、自己的用例建立起一套个性化基准。现在有多少个智能体，就可以有多少套基准。把它用于自己的智能体，就能找出哪些模型最适合自己的情境；这是找到适合自己的模型的唯一方法。 这也能捕捉意外情况。对你来说，最快给出答案的模型就是合适的模型，对吧？但它可能不是排行榜第一名，而是最适合你的用例的模型。这些基准、模拟和整套方法都是开源的。你可以自己查看，拿去测试自己的智能体，看看它表现如何。 ## [18:35] 评测结果与上线前检查清单 · YouTube **讲者：** 这是我们的酒店智能体基准测试结果。对酒店接待智能体来说，排名最高的 LLM 是运行在 LiveKit Inference 上的 Gemma 4 31B。看第二行：同一个模型放在另一家供应商上，速度更慢。LiveKit 针对语音工作负载优化了推理服务。LiveKit 不绑定某一种模型，你可以使用任何想用的模型；把模型接进来，评估哪个最适合你的用例。 如果你只记住这场演讲的一件事，请记住：语音智能体不只是“接了个扬声器的聊天机器人”。它复杂得多，是一个需要像人一样响应的实时系统。我们需要尽可能让它像人，并从这个角度评估它，才能把它做好。 这里有一份检查清单，大家可以拍下来：设定来电者实际感受到的延迟预算；测量首段音频时间和首句时间；确认关键日期；凡是涉及金融或金钱的事项，都要确保有相应检查；访问账户前验证身份；慢速工具运行时继续听，保持对话进行；反复用模拟测试完整对话；测试最终状态、隐私保护、非必要的工具调用和轮次交接。发现问题后，把它们转成回归测试场景，一遍遍持续测试。 从你最在意的一种工作流或一种故障开始，然后持续迭代、运行测试，听对话，再检查后端发生了什么。我希望在不久的将来，我们都能给这类语音智能体打电话，即使对它插话、把它弄糊涂，它也能顺着接下去，带来非常像人的体验。这就是我们的目标。现在我需要在座的每个人去把它做出来。谢谢。