Ryanair 把 12 个客服智能体并成 1 个

欧洲最大的低成本航空公司每天要处理 12 万次客服对话，覆盖 7 种语言，原来的架构是 12 个各管一块的智能体。2026 年 2 月，这套架构被换成了一个智能体。换完之后，八成会话在机器人里结束、不必转人工，按旅客人数摊下来的客服接触量降了 70%；从 2024 年 10 月上线算起，这套系统累计给过一千万条回答，准确率 94%。这些数字出自 AWS 的案例研究与客户署名，属于厂商与客户联合发布，没有独立审计。

同一个问题，两家公司给出相反答案

同一周的另一个案例走的是反方向。Crocs 的客服与导购智能体由多个专精智能体组成，外面套一个统一的编排器，从概念到上线用了五个月；之后要加电话通道，用七周就把语音版本发了出去，靠的是复用已经做好的动作与指令，而不是为电话重写一套。

两家公司都上了生产，方案方向相反，区别不在谁更先进，而在边界画在哪里。把这两个案例并排看，能看出一个比「多智能体更好还是更差」更有用的判断标准。

合并省下的是每一跳

按话题拆开的架构，成本藏在每一次转手上。一次路由就是一次往返延迟、一个新增的失败点，以及一次上下文传递——而上下文每传一次，就有丢信息的可能。当所有意图共享同一个入口、又读写同一个后端时，拆分付出的这三样代价换不回对应的能力：问行李和问退款，要查的是同一张订单。

换模型的收益恰好说明了同一件事。响应时间从 18 秒压到 2.9 秒，这一步没有增加任何推理能力，但它把等待压进了用户愿意等的时间以内。解决率是等待的函数：答案再对，让客户干等 18 秒，人早就走了。

换句话说，会话内解决率这类指标看起来像能力，实际上由三样东西共同决定——回答的准确度、系统的延迟，以及转人工的规则设在哪儿。只优化其中一样，指标不会动。

该拆还是该并：看后端，不看话题

把两个案例放在一起，判断标准其实很短：两个用例是否共享同一个后端、同一批意图。共享，就合并；需要跨系统取实时数据，就按数据源拆。Crocs 拆出来的边界是订单管理系统，不是「导购」和「售后」这样的业务名词；名词是人的分类方式，数据源才是系统的边界。

还有一条经验来自语音那次上线。七周能加上电话通道，是因为动作和指令被复用，而不是为电话重写一遍。同一条标准也适用于合并：这套动作能不能被下一个通道直接用，比架构图上画几个方框重要得多。

模型怎么选：拿自己的一万二千条真实问题当考卷

这个项目在选型上做了一件值得抄的事：拿 5 个基础模型在 1.2 万条真实生产客服问题上做对照，最后选中的模型把响应时间改善 84%，准确率提高 25%。这是厂商口径的数字，但方法本身独立于数字。

测试集必须是自己历史上的工单，因为它带着你的业务词、你的断句习惯、你的错别字分布和你的语言组合。公开榜单测的是别人的分布，在别人的分布上领先，不代表在你的分布上够用。这一步做完，选型才有可以复核的结论。

护栏放在发送路径上

案例里还有一句容易读漏的话：每条回答在发给客户之前，都要经过一套多模型、多维度的评分。质量判断被放在了发送路径上，不是事后抽样。

两种做法的成本结构不一样。事后抽查发现问题，代价是客户已经看到了；发送前拦截，代价是延迟增加一点。客服场景通常愿意做这笔交换，因为一次错答带来的赔付、投诉与信任损失，比几百毫秒贵。反过来，如果业务对延迟的容忍度极低，拦截就要设定好降级动作，而不是让请求一直卡着。

合并要还的三笔账

把 12 个智能体并成一个，收益出现在延迟和运维上，代价会出现在另外三个地方，立项时最好提前认下来。第一笔是上下文：原来每个智能体自带一小段提示，合并后要设计一套共享的上下文结构，否则意图之间会互相污染。第二笔是策略：按话题拆分时，各块的规则可以各写各的；合并之后，规则冲突必须在同一个地方解决。第三笔是回退：原来某一块出问题可以单独下线，合并之后只能整机灰度。

这三笔账不构成反对合并的理由，它们只是合并的入场费。付不起这笔费用的团队，往往会在合并后靠加提示词来打补丁，最后把单智能体做成了没有编排的多智能体。

这条路的边界

• 分母问题。八成是机器人接到的会话里不需要转人工的比例，不是全部客服接触量。退款争议、航班中断这类边缘情况仍然落在人身上，人没有消失，只是接触点前移了。
• 单点暴露面。合并之后一个智能体服务 7 种语言和全部意图，模型或依赖出问题时的影响面比多智能体更大，需要灰度、回滚和降级策略。
• 来源性质。所有数字由供应商与客户联合发布，没有独立审计，引用时要写明这一点，也不要把它当成行业基准。
• 通道差异。语音与文字的用户容忍度不同，语音对停顿和打断更敏感；同一套动作复用之后，超时与打断的处理仍要重新调。

这次没有回答的问题

案例里没有说 70% 的接触量下降是在多长的窗口里实现的，也没有说转人工之后的满意度变化，以及合并之后是否出现过单点故障。这几项在别家项目里可以直接补测，买方不该拿一个漂亮的截面数字，替代自己的时间序列。更实际的问题是两个季度之后：合并后的智能体要不要定期重新评测，评测集要不要跟着新出现的业务场景（例如新的行李政策、新的退改规则）一起更新。案例没有回答，但这类项目一年内一定会遇到。

70% 的接触量下降，落在成本表上是哪一行

接触量按每名旅客摊算，这个口径很关键。它意味着节省不是裁掉七成人手，而是业务量涨上去的时候，客服不必按同样比例加人。案例里的说法也是这个意思：按传统做法，客服规模要随咨询量线性增长，这套系统让容量扩张与人数脱钩。

所以评估这类项目要看的不是当期省下多少钱，而是单位成本的斜率：每增加一百万旅客，需要多配多少客服人力。斜率变了，收益会随着业务增长累积；斜率没变，就只是当年少花了点预算。

从 12 个并成 1 个，迁移过程该长什么样

案例只说了 2026 年 2 月完成合并，没说过程。按可复用的工程顺序，这类迁移通常分三步：先把原来 12 个智能体的日志与意图标签并成同一份评估集；再用单智能体跑影子模式，并行接收请求但不对外回答；对比解决率、响应时间与转人工率，确认没有回归之后再分流量切换。这三步的价值在于每一步失败都能退回去，而不是一次性把客服通道交出去。

影子模式只覆盖能观测到的部分。真实会话里的长尾意图、语音通道的打断行为、客服人员自己的处理习惯，都要在切了流量之后才验证得到。灰度窗口不能省，看完离线数据就切是这类项目最常见的翻车方式。

我们的判断

智能体的数量是延迟和运维成本的决定，不是能力分档。把 12 个并成 1 个能写成案例，是因为收益落在了指标上——延迟、解决率、单位旅客的接触量——而不是落在架构图上画了几个方框。

第二个判断：按数据源拆，按话题合。话题是人的分类方式，数据源是系统的边界。按话题拆，请求会在智能体之间来回跑；按数据源拆，一次请求通常只需要取一次数。

第三个判断：选型不要交给榜单。能带走的证据只有一种，就是拿你自己的工单样本，让候选模型在你自己的分布上比一次，并把结果留在验收材料里。

上线前该定下来的四件事

• 先算意图覆盖与后端共享度：共享一个后端且意图在同一通道，优先单智能体；需要跨系统实时数据，按数据源拆。
• 把响应时间的分位值写进上线门槛，不要只留在性能报告里。在这个场景里，延迟就是转化。
• 用最近 30 天的工单做选型对照，要求每个候选模型在你的样本上给出可复现的结果。
• 护栏放在发送路径上，并提前定好拦截之后的动作：转人工、换模型，还是拒绝回答。
• 把重新评测写进运维计划：新的业务场景和新的退改规则上线后，评测集要跟着更新，否则解决率会随时间悄悄下滑。

先把指标口径对齐，再谈自动化率

客服行业里同一个指标在不同公司口径不同：解决率的分母是机器人接到的会话还是全部来电，转人工算不算失败，重复来电怎么计。口径不统一，两个项目的数字没法比，团队之间也会为了指标好看把难题往人工那边推。项目开始前把口径定死，比选模型更值得花时间。

一个可用的做法是同时看两侧的数：机器人侧的会话内解决率，加上人工侧的单位接触时长。只盯前者，团队会把边界往人工推；只看后者，又会把不适合自动化的意图硬塞给机器人。两侧一起看，才能判断这次调整是真的解决了问题，还是把问题搬了家。

把这次合并接到自己的预算模型上

客服自动化的预算通常卡在科目上：人力预算属于运营，平台和评测属于技术，两笔钱不在同一张表里。结果是最需要花钱的地方——评测集、护栏、灰度期的人力——反而最难批，因为它的收益要等一年才出现在人头表上。

把单位成本斜率写进财务模型，是绕过这个卡点的一个办法：把「每百万旅客新增客服人力」当成一个可预测的科目，再算自动化投入能把这根斜率压低多少。这样一来，投入和收益就在同一个口径里对话，不必等年底看人头数。

还有一个预期要在立项时说清楚：第一年通常看不到斜率变化。灰度、评测与人工并行的成本都压在前期，收益从业务量继续上涨的第二年才开始累积。拿第一年的结算去评估这类项目，结论几乎一定是错的。把这条写进立项材料，也能避免管理层在第一个季度结算之后误判项目失败。

参考来源

• AWS 案例研究：Agentic AI Handles 120,000 Daily Chats Using Amazon Nova at Ryanair
• PYMNTS：Crocs Puts One AI Agent in Charge of Sales and Service（2026-09-22）
• Salesforce 客户案例：How Crocs built a retail superagent with Agentforce