打造持久的语音智能体：前线工程实践的经验总结

大多数企业在支持环节长期依赖“分流”来衡量点式解决方案，也就是减少来电量和人工客服的介入。但分流并不等于问题解决，两者之间的差距正是客户体验断裂的地方。要弥合这一差距，客服不仅要能获取数据，还要能直接操作相关系统。这样，客服可以处理退款、引导客户完成结账流程，并在需要时将完整上下文交接给人工客服。企业因此能够大规模处理客户互动，显著减轻人工支持团队的压力，同时提升双方体验。与 Revolut 的最新部署中，这家服务全球 7,000 万用户的金融科技公司，将问题解决时间缩短了 8 倍，通话成功率达到 99.7%。

企业在推进如此大规模的变革时，必须采取迭代方式，紧密结合公司核心使命，并由高层推动。在技术层面，面对非结构化环境时，天然存在风险，必须谨慎管理。让智能体能在客户关系管理（CRM）系统中操作、修改销售订单或升级工单时，治理模型和技术模型同样重要。此时关注点不再是智能体能否胜任实际工作，而是如何安全、可控地反复部署。

本文结合我们的实践经验，分享从首次部署到全流程扩展，如何打造真正成功的语音智能体。

智能体上线与传统软件上线的区别

在深入探讨智能体构建前，值得将语音智能体的部署与企业几十年来一直在做的传统软件部署做个对比。以此为视角，智能体可分为两大部分：传统软件组件和核心编排器。

软件：

软件：可观测性与治理

核心编排器

核心编排器组件本身更难预测，但它们决定了智能体在回答质量和感知延迟上的运行表现。与传统软件不同，这些组件处理的是自然语言和音频，输入空间几乎无限，措辞、上下文、背景噪音或用户行为的微小变化都可能导致输出结果发生显著变化。因此，常规测试并不足够：智能体即使在数百个测试用例中表现完美，实际生产中仍可能出现难以预料的问题。版本管理、A/B 测试、电话接入和首条消息配置等功能。这些组件上线后基本不会变化，行为高度可预测。通过成熟的工程实践，企业可以快速迭代这些功能，并通过完善的指标、追踪和日志，深入了解其线上表现。该层的延迟优化有明确路径：缓存、连接池、基础设施扩容和协议优化等，效果可控。

该层的延迟也更难预测，受模型推理时间、音频伪影、工具调用链以及生成式系统本身的波动影响。要管理好这些组件，需要不同的工作方式——围绕评估框架、生产监控，并根据真实对话数据持续迭代，而不仅仅依赖上线前的假设。

这种区别决定了组织采用的方式：应从相关但风险较低的场景入手，随着对系统信心提升再逐步扩大规模。

发布周期

选择试点场景

对于刚开始采用语音智能体的团队，选择合适的试点场景是最关键的早期决策之一，而且这与技术本身的关系比大多数人想象的要小。那些能快速取得成果、避免陷入无休止 POC 的团队，往往有一个共同点：他们能清晰回答以下问题。

对于刚开始引入语音智能体的团队，选对试点场景是最关键的早期决策之一。这其实和技术关系不大。那些能快速取得成果、避免陷入无休止 POC 的团队，往往能清晰回答以下几个问题。

• 这个场景如何带来可衡量的业务价值？首选场景不是技术上最有挑战的，而是最能推动业务已有目标的。衡量标准包括收入影响、成本降低、客户满意度等管理层已在关注的指标。如果无法直接关联业务价值，智能体的迭代很难持续，技术也难以证明自身价值。
• 用户是否能立刻理解智能体的范围和用途？范围不清是从开发到上线最常见的偏差来源。用户不了解智能体能做什么、不能做什么时，会用各种方式试探其边界，这些往往超出评测覆盖。范围明确的智能体能从首条消息就设定好预期，并优雅处理超出范围的请求。
• 什么样的互动算好，什么算差？能否转化为具体评估标准？好的互动不仅仅是任务完成，还包括用户被倾听、适时升级，以及结果符合业务目标。评估标准分为两类：平台自动采集的量化指标（如任务完成率、升级率），以及需要分析对话内容的转录标准。提前定义转录标准，能让团队有明确目标，也自然形成上线门槛。当智能体持续通过评估标准、平台指标稳定后，就可以放心上线。没有标准，上线只能靠主观判断。
• 性能与可控性如何权衡？当前阶段哪个更重要？智能体自主性越高，互动越自然灵活，但越容易超出安全边界。通过收紧提示词和升级逻辑可以降低风险，但也可能让体验变得僵硬。两者都不是绝对正确。过早限制只会变成高级 IVR，过快放开则会带来难以承受的支持压力。每个阶段如何平衡，决定了模型配置、升级逻辑，以及知识放在提示词还是外部数据源中。

初始开发落地

进入执行阶段时，团队可以借鉴软件领域早已成熟的方法。测试驱动开发（TDD）为智能体在开发过程中始终对齐核心指标提供了框架。

进入执行阶段，团队可以借鉴软件开发中成熟的方法。测试驱动开发（TDD）为智能体在整个构建过程中的核心指标对齐提供了框架。

有了初步测试后，智能体开发从系统提示词开始。这里定义了智能体的规则、语气和处理方式：该做什么、不该做什么，以及在边界场景下如何表现。高质量的系统提示词不仅关注内容，也重视结构。将指令分区、相关内容归类、避免条件表达，都能显著提升智能体的一致性。此时我们通常会参考提示词指南。智能体测试，反复验证智能体应有的具体行为。前者最好通过回顾真实人工通话来完善，后者则从一组初始行为出发，随着新需求和边界场景不断扩展。

除了系统提示词，还需配置智能体的核心组件：LLM、文本转语音（TTS）模型和音色。LLM 选择主要是延迟与性能的权衡，速度快的模型通常推理能力略弱，反之亦然。TTS 选择则取决于场景需求，比如表达力、低延迟或多语种支持。音色既是技术决策，也是品牌决策，直接影响每位来电者的感受，因此既属于品牌和市场团队，也属于工程团队。这意味着音色选择可以与开发流程并行进行，不会成为前后端的瓶颈。ElevenAgents 提供超过 10,000 种音色，如无合适，也可克隆或自定义。

此外，还可为智能体扩展知识库、

基础搭建完成后，智能体即可进入测试阶段。知识库、工具和渠道配置。每增加一项功能，能力提升的同时也带来更多测试需求。无论是电话集成、外部数据库访问，还是代表客户操作，都应先用评估标准严格验证再扩展。添加工具时，系统提示词和工具描述要明确指引何时、如何调用，确保智能体用得对、用得一致。

迈向生产就绪

在基础阶段定义的测试和评估标准应用于已开发的智能体后，开发进入高效循环：补充测试、定位失败、更新系统提示词或配置、再次运行。此阶段大多数失败并非模型问题，而是提示词问题。单独看似清晰的指令，在对话中可能变得模糊。初始测试未覆盖的边界情况会逐步暴露，每个都可转化为新的 Next Turn 测试。何时停止迭代有明确标准：当智能体多次稳定通过评估标准，且平台指标如任务完成率、升级率在可接受范围内波动时，就可以上线。这也是为何上线前要先定义标准，否则上线与否只能凭主观判断，目标也会不断变化。

实际中，大多数团队发现少数反复出现的失败模式占据了主要问题。最常见的有提示词歧义（智能体收到冲突或不明确指令，导致行为不可预测）、工具误用（在错误场景调用工具或未按需调用）、升级偏差（过度升级或未及时转接）。这些都可以通过优化提示词解决：收紧相关指令、增加明确示例或调整升级阈值通常就足够。关键是上线前要及时发现并修正。

最常见的错误是把测试通过当作保证，而不是信号。只覆盖理想流程的测试很容易通过，但意义不大。拒绝、对话中断、模糊输入和大量工具调用等场景的覆盖才有价值。同样，跳过模拟测试、只做回合级测试会遗漏一些只有完整对话才会暴露的问题，比如上下文丢失或错误累积。只要反复出现的失败模式被解决，智能体能优雅处理各种边界情况（而非完美），继续在预发布环境迭代的价值就会递减。这时，真实对话才是更有价值的信号来源。

上线并不意味着迭代结束，而是学习重心从模拟测试转向生产转录。定义上线的评估标准成为衡量实际表现的基线，后续循环也由此展开。

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

测试定义并运行后，流程中的短板会很快暴露。通过

此阶段最重要的原则是验证每一次变更，而不是想当然。一个修复可能解决了某个问题，却悄然引入新的问题。ElevenAgents 支持版本管理，可让团队先在小部分用户中测试新版本，再逐步全量上线。这样能确保改进确实带来正向效果，而不是把问题转移到其他地方。

可能出现的问题版本管理，团队可以先在小范围用户中测试新版本，再逐步全量上线。这样能确保优化真的带来提升，而不是把问题转移到别处。

此阶段最严重的错误就是跳过分批上线，直接推送到全部用户。没有分阶段上线，就无法隔离每次变更的影响，规模一大后几乎无法判断哪些因素真正影响了平台指标的提升或回退。把全部用户当作测试环境不仅风险高，还会丧失后续决策所需的可观测性。

除了上线策略外，还有两种常见失误值得警惕。第一是过度关注近期失败。某次高曝光对话出错后，团队往往急于修补，但未经过完整测试的提示词调整，常常导致原本稳定的行为出现回退。每一次变更，无论多小，都应视为新一轮迭代并充分测试。第二是评估标准漂移。随着时间推移，团队可能在压力下无意识地降低测试通过门槛。最初定义的评估标准应始终作为锚点。如果觉得标准过严，正确做法是有意识地调整，而不是让标准逐渐松懈。

有信心地扩展规模

流量提升应基于信心，而非时间。只有当智能体多次稳定通过评估标准、平台指标趋于稳定、分批上线未出现明显回退时，才适合扩大规模。

此阶段常见问题是：多少流量才足以得出结论？每批少于 100 通电话的分支，波动太大，难以可靠评估结果。25 通电话 60% 通过率和 100 通电话 60% 通过率，信心完全不同。除了数量，样本还应覆盖各种真实输入，包括边界情况、少见意图和只有大批量才会暴露的失败模式。

流量越大，优缺点都被放大。核心失败模式未解决前贸然扩展，只会带来难以逆转的支持压力。

持续迭代

知道何时停止和知道修什么一样重要。迭代有边际效益递减，智能体持续达到评估标准时，就是暂停的信号。此时，继续调整的风险大于收益。

“持续达标”在不同场景下表现不同。数据接入有限或集成不完整的团队，升级率 50% 可能就是现实上限，直到这些限制被解决。数据接入良好的情况下，最佳部署通常目标是任务完成率 80% 以上、升级率低于 20%。比单一数字更重要的是稳定性：连续几周生产流量表现稳定、测试无明显回退，才是真正的信号。当下一轮迭代的边际收益小于回退风险时，就该停止了。

这并不意味着工作结束。新需求出现时，流程会从头再来。首次开发时的规划问题，第二次同样适用。不同的是，第二轮团队已有测试集、评估基线和运营经验，这种积累正是让组织从语音智能体中获得长期价值的关键，而不是一直停留在概念验证阶段。

总结

我们观察到，能真正实现从分流到解决的团队，都是在开发前明确“好”的标准，迭代过程中保持纪律，并把每次上线当作下一步的基础。对话式智能体不是一次性部署——真实对话总会暴露测试未覆盖的边界情况，优化工作也不会因上线而停止。

ElevenAgents 正是基于这一现实打造。智能体测试、对话分析和分批上线，是将概念验证转化为真正能大规模解决客户问题系统的基础——而不仅仅是分流。这才是真正值得努力的目标。

ElevenAgents 正是基于这一现实打造。智能体测试、对话分析和分批上线，是让概念验证真正变成大规模解决客户问题系统的基础——而不仅仅是转移问题。这才是真正值得关注的差距。