网络研讨会回顾：欧洲最大保险公司之一如何将 AI 智能体投入生产

保险客户很少会在一切顺利时来电。他们通常在发生事故后、需要提出理赔时，或正处于真正的危机中时打来电话。这次对话会影响之后的一切，而且往往是客户与保险公司唯一一次真正的互动。

Admiral 每年在英国、意大利、法国和西班牙处理数百万次这类对话。如今，他们正使用 智能体 在保持合规的同时协助处理这些对话。 

在 这场网络研讨会中，Admiral 团队介绍了具体做法：选择首个用例，从第 0 天起让法务和合规团队参与，以及如何将可用原型推进到生产环境，如今只需数小时即可发布变更，而非数周。

核心要点

• 起步范围要聚焦，但必须真实。 Admiral 的首个生产用例是其英国贷款业务中的结算报价。这个用例范围明确，可在合理周期内上线，同时仍涉及电话系统和后端集成，足以验证架构，而无需一次解决所有问题。
• 扩展前提高标准，而不是降低标准。 Admiral 从第 1 天起就面向生产环境构建，重建治理节奏以跟上技术发展，并通过范围明确的试点项目，从第 0 天起让法务和合规团队参与。
• 监管只是底线，不是全部设计。 Admiral 在监管要求之上增加了内部规则，对必须可证明的事项采用确定性逻辑，并将脆弱或情绪困扰的客户转接给人工客服。
• 真正的工作从生产环境开始。 每次智能体变更都会通过完整的模拟测试套件，并从 1% 的流量逐步发布至 100%。这个周期已从数周缩短至数小时。

起步范围要聚焦，但不能过窄

Admiral 的首个生产用例是其英国贷款业务中的结算报价。这是一个刻意控制范围的起点，而非清单上最棘手的问题。Kampa 将这种方法描述为：先选择一个国家和一条业务线进行试验，再逐步扩展。

Neely 表示，这正是能进入生产环境的部署与停滞不前的部署之间的区别：用例必须足够聚焦，才能在现实的时间内解决；同时也必须足够复杂，才能真正检验周边系统。结算报价之所以适用，是因为对话路径有限，却仍涉及电话系统和后端集成，足以验证架构，无需试图一次解决所有问题。

这一选择有几个关键因素：

• 范围明确，复杂性真实。 用例需要有足够的变化来测试电话系统和后端集成，而不只是预设好的理想流程。
• 快速进入生产环境。 开发周期越长，真实对话产生真正改善智能体所需反馈的时间就越晚。Neely 将其称为“最后的 20%”，即只有真实客户开始与系统交谈后才会显现的部分。
• 兼顾规模和影响。 Admiral 从简单、高频的互动场景入手，在这些场景中，缩短等待时间和加快问题解决速度能显著改善客户体验。

扩展前提高标准，而不是降低标准

Admiral 的管理层明确表示，智能体应提高合规和测试标准，而不是降低标准。Kampa 直言，验证标准必须比以往更严格，因为智能体偏离脚本或违反规则的风险，与人工客服作出判断的风险性质不同。

这一标准体现在团队早期作出的 3 项承诺中：

• 为生产环境构建，而不是做概念验证。 Kampa 要求团队从第 1 天起就以正式上线为目标进行设计，而不是开展一个永远无法扩展的小型实验。
• 治理节奏要跟上技术发展。 Kampa 指出，若一个治理流程需要 6 个月才能批准某项内容，那么到发布时，获批的技术可能已经过时。Admiral 重建了审核节奏，以匹配底层模型和工具的变化速度。
• 从第 0 天起让法务和合规团队参与。 当被问及法务和合规团队何时加入项目时，Kampa 和 Clark 都立即回答：第 0 天。他们采用范围明确的试点项目（规定数量的通话），而不是无限期地等待批准。

让监管定义底线，而非决定全部设计

Clark 明确指出，英国、意大利、法国和西班牙的监管要求各不相同，例如是否必须告知客户正在与 AI 对话，以及在某些司法辖区是否必须提供转接人工服务。Admiral 构建智能体时考虑了这些差异，同时避免让任何来电者通过“升级”转接，逃避本可解决的对话。

某些对话完全不由智能体处理：Admiral 会将脆弱或情绪困扰的客户转接给人工客服，并训练 AI 识别触发这种转接的信号。

Kampa 将更广泛的方法概括为分层设计：“监管只是底线。”在此之上，还有 Admiral 自身的内部规则和文化标准，有时比监管要求更严格。

这种分层也决定了 Admiral 在何处使用确定性逻辑和非确定性逻辑。Clark 解释说，非确定性推理适合用于理解来电者意图或识别情绪困扰；而对于企业需要证明的内容、必须作出的监管声明，或必须引导客户走的流程，则必须采用确定性逻辑，绝不允许智能体即兴发挥。

Neely 介绍了 ElevenLabs 的 workflow 结构如何在实践中支持这一点：智能体由一组专业子智能体构成，并设有确定性关卡，例如身份验证。系统会根据是否满足条件来解锁或限制功能，而不是让模型自行判断允许做什么。

与流程负责人共同构建

Admiral 和 ElevenLabs 没有采用业务需求与工程开发之间的传统交接方式，而是举办了现场研讨会，让了解用例的人员、工程团队和电话系统团队共聚一室。Neely 表示，首次研讨会在 4 到 5 小时内就产出了可运行的智能体 v0，并接入后端和电话系统。Kampa 和 Clark 随后可以在内部演示，以获得继续开发的批准。

Clark 表示，这种紧密协作的重要性不止于第一个原型：业务负责人如今足够接近技术，能够自行进行一些变更，因为研讨会将平台视为迁移现有业务流程的方式，而不是引入陌生的新流程。Kampa 还将此与更广泛的变革管理联系起来：尽早让领导层、中层管理者和一线员工参与，使技术成为业务实际运营的一部分，而不是一个附带项目。

真正的工作从生产环境开始

上线后，Admiral 对待每一次智能体变更，无论大小，方式都相同：先作为一个分支通过完整的模拟测试套件，再面向客户发布。Clark 描述道，先从 1% 的流量开始发布，实时观察客户满意度和问题解决指标；当数据稳定后，再扩展至 100%。这个周期已从数周缩短至数小时。

这一迭代过程中有两点尤为突出：

• 本地化语言，而不只是翻译文字。 Admiral 最初以英语编写所有提示词和 workflow，发现法国、西班牙和意大利的表现不如英国。随后，他们不再从英语翻译，而是用各市场的母语重写提示词，从而获得更符合当地客户期望和文化的回复。
• 必须认真对待模拟测试，不能把它当作形式。 Neely 表示，编写一个能通过少量模拟测试的提示词看似容易，但构建真正能对智能体施加压力的测试套件，并预先定义清晰的成功标准，才是更困难也更重要的工作。Admiral 现在会在每次变更发布前，运行数百到数千次模拟对话。

在成果方面，Kampa 指出，处理时长是最突出的指标：由 AI 主导的对话通常能比人工主导的对话更快达成相同结果，部分原因是系统加载时不会出现无声等待。她还表示，客户满意度（CSAT）和问题解决率通过反复测试和调整，在各个市场逐步提升，而非一次性跃升。

刚开始时，可以从中借鉴什么

Neely 给刚开始这项工作的团队的建议是：选择一个范围明确的用例，快速投入生产环境，并让真实客户对话，而不是更多的上线前测试，来发现边缘情况。Clark 补充说，一旦两端的集成（电话系统和内部系统）得到验证，扩展到更多用例的速度会越来越快，因为团队已知道哪些评估和指标最重要。

Kampa 在结尾提出了更长远的目标：不仅要实现对话自动化，还要利用同一 AI 层，通过实时转写、下一步最佳行动提示和培训模拟，直接支持人工客服。

正如主持人总结的，这场对话贯穿始终的主线是：监管与 AI 并不矛盾。从第 1 天起就以可审计性、一致性和人工升级转接为设计重点，让 Admiral 的智能体更加严谨，而非相反。

观看完整会议

观看完整会议，包括现场构建演示和观众问答。