构建经久耐用的语音智能体：前线部署工程的一些经验教训

长期以来，多数组织都以“分流率”衡量客服环节的点式解决方案，也就是减少来电量和真人客服互动。但分流不等于解决问题，两者之间的差距正是客户体验容易崩坏的地方。要弥合这一差距，智能体不仅要能访问数据，还要能访问据此执行操作的系统。因此，智能体可以处理退款、引导客户完成结账流程，并在需要时带着完整上下文转交给人工客服。这让企业能够大规模处理客户互动，显著减轻人工支持团队的负担，同时改善通话双方的体验。在一次与 Revolut 的近期部署 中，这家服务全球 7000 万客户的金融科技公司将问题解决时间缩短至原来的 1/8，通话成功率达到 99.7%。

面对如此重大的变革，组织必须采取迭代方式，紧密围绕公司核心使命，并由高层强力推动。从技术层面看，在非结构化环境中进行推理存在固有风险，必须谨慎管理。赋予智能体跨客户关系管理系统（CRM）执行操作、在销售点系统中修改订单或升级案例的能力，意味着治理模型与模型本身同样重要。重点不再是智能体能否处理实际工作，而是需要哪些机制，才能安全、重复地部署它们。

本文将结合我们的经验，分享如何从首次部署开始打造成功的智能体，并扩展到整个组织的客户运营体系。

交付智能体与交付软件

在深入探讨智能体构建前，不妨将语音智能体的部署与企业数十年来一直在进行的传统软件部署作个对比。通过这一视角，智能体可分为两个不同组成部分：传统软件和核心编排器。

软件

核心编排器

传统软件组件主要用于提升智能体的交付能力和性能。对于 ElevenAgents，这包括 版本管理、A/B 测试、电话和首条消息配置等功能。这些组件部署后几乎不会发生漂移，因此行为高度可预测。借助扎实的工程实践，组织可以快速基于这些功能开展构建，并通过严谨的指标、追踪和日志体系，深入了解其生产环境表现。这一层的延迟优化遵循成熟模式：缓存、连接池、基础设施扩展和协议优化都是可靠且结果确定的手段。

核心编排器组件天生更难预测，但它们决定了智能体运行时的回答质量和感知延迟。不同于传统软件，这些组件处理的是自然语言和音频，其输入空间实际上没有边界；措辞、上下文、背景噪声或用户行为的微小变化，都可能随时间产生显著不同的输出。因此，仅靠传统测试并不足够：智能体可能在数百个测试用例中表现完美，却仍会以难以预料的方式在生产环境中失败。

这一层的延迟也更不确定，受模型推理时间、听觉伪影注入、工具调用链以及生成式系统固有变异性的影响。要管理好这些组件，需要不同的工作方法：围绕评估框架、生产监控建立体系，并愿意根据真实对话数据持续迭代，而非仅依赖部署前的假设。

这种差异决定了组织应如何采用智能体：先从与组织相关但风险较低的用例开始，随着对系统的信心增强，再有计划地扩展。

发布周期

选择先行用例

对于刚开始采用 语音智能体 的团队而言，选择合适的先行用例是早期最关键的决策之一。这件事与技术的关系也比多数人的预期更小。那些能迅速取得成果、避免陷入无休止 POC 深渊的团队，往往有一个共同点：能清晰回答以下问题。

• 这个用例如何带来可衡量的业务价值？ 起步时合适的用例，不是技术上最有趣的那个，而是最可能推动企业已关注结果的那个。这可以通过收入影响、成本降低、客户满意度，以及管理者已在跟踪并负责的其他指标来衡量。若无法直接关联业务价值，就难以证明为打造正确智能体所需迭代周期的合理性，技术还没机会证明自己，推进势头就可能停滞。
• 用户是否能立刻明白智能体的范围和目的？ 范围模糊是从开发到生产发生漂移的最常见原因之一。不了解智能体能做什么、不能做什么的用户，会以评估套件未曾预料的方式测试其边界。范围定义清晰的智能体会从首条消息起设定预期，并妥善处理超出范围的请求。
• 好的和差的互动分别是什么样，能否将其编码为一套具体的评估标准？ 好的互动不只是智能体完成了任务，更在于用户感到被倾听、在恰当时机完成升级，且结果符合业务意图。评估标准分为两类：平台捕获的定量指标，例如任务完成率和升级率；以及需要分析对话本身的转录文本标准。及早定义基于转录文本的标准，能为团队提供明确的构建目标，也会自然形成上线门槛。当智能体持续通过评估标准，且平台指标趋于稳定时，就可以有信心投入生产。没有明确标准，上线只能凭判断。
• 性能与控制之间有哪些取舍？现阶段哪个更重要？ 赋予智能体的自主性越多，互动就越自然灵活，但在经验证边界外运行的风险也越高。通过受限提示词和更严格的升级逻辑加强控制可降低风险，却可能让智能体显得僵硬。两个极端都不对。过早锁死的组织最终只会得到一个强化版 IVR；在建立信任前推进过快的组织，则会带来超过收益的支持负担。理解成熟度各阶段的平衡点，将影响模型配置、升级逻辑，以及智能体知识有多少放在提示词中，多少来自检索或结构化来源。

回答完这些问题后，组织就可以从战略转向执行，开始界定构建范围。

夯实初始构建

进入执行阶段后，团队可以借鉴几乎与软件本身一样悠久的方法论。测试驱动开发（TDD）为整个构建过程提供框架，让智能体始终围绕核心指标。

具体来说，开发团队和业务利益相关方应共同定义并构建两项基础成果：成功评估标准，用于明确单次通话和总体层面何为良好表现；以及智能体测试，用于反复验证智能体应表现出的具体行为。前者最好通过回顾真实人工通话来制定。后者则逐步构建：从一组预期行为开始，随着引入新行为和发现边缘情况不断扩展。

有了初始测试集后，智能体开发就从系统提示词开始。这里定义智能体的规则、语气和方法：该做什么、不该做什么，以及处于角色边界时该如何表现。精心设计的系统提示词，结构与内容同样重要。将指令拆分为标签清晰的部分、把相关指引放在一起、避免条件式表述，都能显著提升智能体行为的一致性。在这一阶段，我们常会参考提示词指南。

除系统提示词外，还要配置智能体的核心组件：LLM、文本转语音（TTS）模型和音色。选择 LLM 主要是在延迟与性能之间取舍：为速度优化的模型通常会牺牲部分推理能力，反之亦然。对于 TTS，合适的选择取决于用例最看重什么：富有表现力的表达、低延迟，还是多语言支持。不过，音色既是品牌决策，也是技术决策。它塑造组织给每位来电者留下的印象，因此是少数同样属于品牌和营销团队、而不只属于智能体工程师的配置决策之一。这意味着音色选择可以与其他开发工作并行进行，而不会成为开头或末尾的瓶颈。ElevenAgents 提供超过 10,000 种音色，如果都不合适，团队也可以克隆或创建自己的音色。

接下来，可选择为智能体扩展知识库、工具和渠道配置。每项新增功能都会解锁新能力，也会带来新的测试范围。无论是电话集成、访问外部数据库，还是代表客户执行操作，在扩展范围前都值得根据评估标准进行压力测试。添加工具后，系统提示词和工具描述会明确说明何时及如何调用它们，让智能体能在正确语境中稳定使用。

这些基础就绪后，智能体即可接受测试。

迈向生产就绪

在夯实阶段定义的测试和评估标准开始针对已构建的智能体运行后，开发便进入紧密循环：添加更多测试、识别失败、更新系统提示词或配置，然后再次运行。此阶段大多数失败并非模型失败，而是提示词失败。单独看似乎清晰的指令，在智能体于对话中途遇到时可能变得模糊。初始测试集未预料到的边缘情况也会浮现。每一种情况都能从对话本身创建为新的 Next Turn 测试。何时停止迭代有明确答案：当智能体在多次运行中持续通过评估标准，且任务完成率、升级率等平台指标稳定在可接受范围内。这正是为什么在构建前定义这些标准至关重要。没有它们，就绪与否只能凭判断，终点线也会不断移动。

实践中，多数团队会发现，少数反复出现的失败模式占据了大部分问题。最常见的是提示词歧义：智能体收到互相冲突或定义不足的指令，因而产生不可预测的默认行为；工具误用：智能体在错误语境调用工具，或该调用时未调用；以及升级漂移：智能体要么过于激进地升级，要么迟迟不转交本该交接的对话。每种问题都有提示词层面的解决方法。收紧相关指令、添加明确示例或调整升级阈值，通常就足够了。风险在于上线前没有发现它们。

团队最常犯的错误，是把通过测试套件当作保证，而非一种信号。只覆盖理想路径的套件很容易通过，却意义不大。覆盖拒绝、中途转向、模糊输入和大量工具交互，才能让结果更有分量。同样，跳过模拟测试、仅依赖单轮测试的团队，会错过一类只在完整对话中出现的失败，例如上下文漂移——智能体忘记早先轮次；或复合错误——通话早期的一个小失误逐步累积为糟糕结果。当解决反复出现的失败模式，且智能体能够得体而非完美地应对长尾边缘情况后，在预发布环境继续迭代的边际价值就会下降。此时，更有价值的信号来自真实对话。

上线并不意味着迭代结束，而是学习重心从合成测试转向生产环境转录文本。定义上线条件的评估标准，会成为衡量线上表现的基线，循环也由此继续。

反馈循环、评估与何时停止迭代

一旦定义并运行测试，流程中的缺口很快就会显现。通过 对话分析，团队可以准确定位互动出错的时刻，并据此创建新测试，确定需要改动的地方。最常见的干预都在提示词层面：收紧工具调用说明、为边缘情况添加更明确的指令，或澄清实践中被证明含糊的升级条件。有时问题更深层：若延迟或推理质量未达到用例需求，就需要重新审视底层模型配置。

这一阶段最重要的原则是验证变更，而不是想当然。解决一个失败的修复可能悄然引入另一个问题。ElevenAgents 支持版本管理，让团队先针对一小部分用户测试新迭代，再推广至更广泛的人群。这样可以确认改进是否真正改善结果，而非只是将失败模式转移到其他地方。

可能出什么问题

这一阶段影响最严重的错误，是跳过分支发布，直接将变更推送给全部用户。没有分阶段发布，就无法隔离任一变更的影响；在大规模场景下，几乎不可能了解究竟是什么导致平台指标改善或退化。把全部用户群当作测试环境不只是风险高，更会失去日后做出有把握决策所需的可观测性。

除发布策略外，还有两种失败模式值得防范。第一种是过度关注近期失败。当一段高关注度对话出错时，很自然会想立即大范围修补；但未运行完整测试套件就做出的反应式提示词修改，常常会使此前稳定的行为出现回归。每一项变更，无论多小，都应视为一次新迭代并相应测试。第二种是评估漂移。随着时间推移，团队可能在无意识中降低“通过测试”的标准，尤其在急于发布时更是如此。范围界定阶段确定的评估标准应始终是锚点。如果它们开始显得过于严格，正确做法是重新审视并有意更新，而不是任由标准非正式地逐渐松动。

有信心地扩展

增加流量是基于信心的决策，而不是基于时间。扩展的信号是：智能体在多次测试运行中持续通过评估标准，平台指标趋于稳定，且分支发布显示相较对照组没有明显回归。

这一阶段的常见问题是：需要多少流量才能得出结论？每个分支少于 100 通电话的批次，产生的方差过大，无法可靠评估结果。在 25 通电话中取得 60% 通过率，与在 100 通电话中取得 60% 通过率，代表截然不同的信心水平。除了达到规定数量外，批次还应足够大，以呈现全范围的真实输入，包括可能的边缘情况、不常见意图，以及只会在大规模下出现、很少在小样本中出现的失败模式。

更多流量会同时放大有效与无效的部分。在解决核心失败模式前就扩展，会造成难以收回的支持负担。

重复这一过程

知道何时停止，与知道该修复什么同样重要。迭代的回报会递减，正确的暂停信号是智能体持续达到范围界定阶段设定的评估标准。此时，进一步变更的风险大于收益。

“持续达到标准”的具体表现因情境而异。数据访问受限或集成不完整的团队，可能会发现，在解决这些限制前，约 50% 的升级率已是现实上限。数据访问充分时，表现最佳的部署通常以超过 80% 的任务完成率和低于 20% 的升级率为目标。比任何单一数字更重要的是稳定性：在连续数周的生产流量中表现一致，测试运行之间没有明显回归，才是真正的信号。当下一次迭代带来的边际收益小于回归风险时，就该停止了。

这并不意味着工作已经完成。当出现新需求时，流程会从头开始。首次构建时的范围界定问题，对第二次同样重要。不同之处在于，进入第二轮的团队已经拥有第一轮必须从零建立的测试套件、评估基线和运营经验。这种不断累积的优势，正是从语音智能体中获得持久价值的组织，与仍困在概念验证阶段的组织之间的区别。

结语

我们看到，能够弥合分流与解决之间差距的团队，会在开始构建前定义何为良好表现，在迭代周期中保持严谨，并将每次部署视为下一次的基础。对话式智能体不是一次性部署——真实对话会暴露任何测试套件都无法完全预料的边缘情况，改进工作也不会在上线时停止。

ElevenAgents 正是围绕这一现实构建的。智能体测试、对话分析和分支发布，是将概念验证转变为可大规模真正解决客户问题的系统的基础——而不只是转移问题。这正是值得弥合的差距。