一家航空公司的客户可能在同一次服务中连续询问：航班是否延误、托运行李有什么限制、能否改签、退款多久到账，以及是否需要转人工。
按照业务部门和知识领域拆分 Agent，看起来很自然：行李一个、退款一个、预订一个、航班异常一个，再由一个编排层判断问题应该交给谁。这样的架构在原型阶段职责清楚，也容易并行开发。但当客户的问题跨越多个领域，系统就要反复分类、转交上下文、合并答案，还要处理不同 Agent 之间的冲突。
Ryanair 近期披露的生产案例给出了一个值得关注的反向信号。2026 年 2 月，该公司将原先 12 个领域专用 Agent 收敛为一个统一 Agent，用于处理行李、退款、预订和航班中断等问题。Ryanair 与合作方还用 1.2 万条真实生产问题评测了五个基础模型。案例称，新方案把响应时间从 18 秒降至 2.9 秒，并提升了准确性；目前系统每天处理约 12 万次客户交互，覆盖七种语言。[1]
很多企业仍在讨论“应该建多少个 Agent”，这个案例却提醒我们：Agent 数量不是能力成熟度，架构复杂度也不是业务价值。企业 AI 从试点走向规模化后，真正稀缺的是一套能够持续证明复杂性确有必要的机制。
多 Agent 很容易建立，复杂性却会永久留在系统里
拆分 Agent 并没有错。不同任务确实可能需要不同知识、工具、权限和风险控制。例如，查询行李政策与执行退款，显然不应拥有相同的行动权限。
问题在于，企业常把组织结构直接复制成技术结构：一个部门一个 Agent，一个系统一个 Agent，一个场景一个 Agent。每增加一个 Agent，通常也会增加一组长期成本：
原型演示往往只展示正确路由的一条路径，生产系统却要承担所有错误组合。如果一个请求先被错误分类，再携带残缺上下文交给第二个 Agent，最后由第三个 Agent 调用工具，那么每个组件单独“表现良好”，也不代表端到端结果可靠。
因此，多 Agent 不应是默认架构，而应是一项需要举证的设计选择。
- 谁来判断请求应该由哪个 Agent 处理；
- 上下文在转交时是否完整、是否重复、是否泄露；
- 多个 Agent 给出冲突判断时以谁为准；
- 模型、提示词、知识和工具变更后，要回归测试多少条路径；
- 一次失败究竟发生在模型、路由、工具还是交接环节；
- 客户跨领域提问时，谁对最终体验和结果负责。
先证明必须分开，再决定是否拆分
企业可以为每一次 Agent 拆分设置四类理由。至少有一类理由明确成立，拆分才有现实意义：
如果拆分理由只是“业务部门不同”“知识库不同”或“将来可能更灵活”，通常还不够。统一 Agent 同样可以按问题选择知识源、调用不同工具，并在工具层实施权限控制；不必把每一种差异都升级成独立自治单元。
更稳妥的做法，是维护一份简洁的复杂性账单：每个 Agent 记录其独立存在的业务理由、专属权限、输入输出契约、额外路由、回归范围、运行成本和退出条件。这样，架构评审讨论的就不再是“多 Agent 是否先进”，而是“这一层复杂性创造的收益是否仍然高于它带来的故障面”。
- 权限必须隔离：某项任务可以查询，另一项任务可以执行退款、修改订单或访问更敏感的数据；
- 失败后果不同：普通咨询答错可以纠正，高金额交易、合规判断或安全操作需要独立控制；
- 能力确有差异：某类任务需要专门模型、确定性算法、实时系统或特定语言能力，统一处理会显著降低效果；
- 运行特征不同：任务在时延、成本、并发、地域或可用性方面有明显不同，独立部署能够带来可验证收益。
统一不是把所有能力塞进一个提示词
从 12 个 Agent 收敛为一个，并不意味着系统内部只能有一个模型、一份知识或一种控制。Ryanair 的案例仍然使用多维、多模型的护栏评分，在答案到达客户前进行评估；多语言部分也结合了专门的翻译服务。[1]
这一区别很重要：统一的是客户任务与责任入口，不一定是所有底层组件。
企业可以把架构分成三层：
这种设计避免让客户理解企业内部如何分工，也避免依赖自然语言提示承担本应由确定性系统完成的权限控制。一个统一 Agent 可以负责理解完整意图、维护会话状态和组织结果，但退款是否允许、金额是否超限、订单是否可改，仍应由业务系统和明确规则决定。
所以，“单 Agent”不等于“大而全”，而是让一个责任主体管理用户任务，同时把专业能力和高风险动作保留在可验证的边界内。
- 任务层：面向客户或员工保持连贯的目标、上下文和结果责任；
- 能力层：按需选择模型、检索、翻译、规则引擎和专业算法；
- 控制层：在真正执行动作的工具端实施身份、权限、金额、审批和审计约束。
企业自己的真实问题，比通用榜单更有价值
Ryanair 案例中最值得借鉴的，可能不是选择了哪一个模型，而是用 1.2 万条真实生产问题比较五个模型。[1]
通用基准能说明模型的一部分能力，却很难覆盖一家航空公司真实发生的缩写、拼写错误、多语言表达、连续追问、航班中断和政策组合。NIST 的 AI 风险管理框架明确提出，AI 系统的性能或保障标准应在接近实际部署的条件下测量，并在生产中持续监控；测试集、指标与方法也应被记录。[2]
因此，企业在整合 Agent 时，应建立自己的“真实任务评测集”，而不只是准备一批标准问答。至少应包含：
评测指标也不应只有一个笼统的“准确率”。至少要区分事实正确、政策适用、工具调用成功、上下文保持、必要时澄清、应转人工而未转人工，以及客户最终是否解决问题。
NIST 在 2026 年发布的部署后监测研究还指出，预上线评测通常发生在受控环境中；生产监测对于验证真实场景可靠性、发现非确定性输出和动态输入带来的意外结果非常关键，而相关方法仍在发展中。[3] 换句话说，1.2 万条历史问题可以帮助做出上线决策，却不能替代上线后的持续观测。
- 高频单领域问题，验证基本正确性与响应速度；
- 跨领域连续问题，验证上下文是否在任务中保持一致；
- 信息不足或相互矛盾的问题，验证系统是否会澄清而非猜测；
- 需要调用业务系统的问题，验证参数、权限和执行结果；
- 历史事故、投诉与人工升级样本，验证已知失败是否复现；
- 不同语言、地区、客户类型和异常运营状态，验证表现是否稳定。
衡量整合效果，要同时看质量、体验与维护成本
Agent 收敛很容易被简化成一项降本工程，但减少组件数量并不必然改善业务。如果统一 Agent 在长尾问题上失去专业深度，或者扩大了一次故障的影响范围，系统只是把复杂性从架构图转移到了内部。
更完整的整合验收，应至少比较四组指标：
Ryanair 披露，自 2024 年 10 月上线以来，系统累计生成 1,000 万次回答，当前报告的准确率为 94%，客户服务联系量相对承运旅客数减少 70%；结合语音平台改造，累计节省超过 50 万个人工小时。[1]
这些数字来自 AWS、Ryanair 与合作方联合案例。公开材料没有完整说明“准确率”的判定口径、对照设计、人工小时核算方法、投诉变化、错误执行后果或完整投入，因此不能直接外推为其他企业的 ROI。尤其是案例提到的后续辅助销售仍处于推进中，不能把潜在收入写成已经实现的结果。
但该案例至少提供了一个可验证的方向：整合是否有效，不应只看少维护了多少 Agent，而应看端到端服务是否更快、更一致、更容易评测和运营。
- 客户结果：一次解决率、有效转人工率、重复咨询、投诉与事后纠正；
- 交互质量：端到端时延、跨领域连续性、答案一致性和多语言差异；
- 行动可靠性：工具调用成功率、重复或错误执行、越权拦截和可恢复性；
- 工程经济性：每次解决的推理成本、路由失败、回归测试量、变更周期和事故定位时间。
下一阶段的企业 AI，竞争力可能来自更少的接缝
企业 AI 的早期阶段强调快速发现场景，于是团队自然会不断新增 Agent。到了规模化阶段，重点应该从“还能再建什么”转向“哪些能力应该合并，哪些边界必须保留”。
一个成熟的架构不以 Agent 数量多为荣，也不执着于单 Agent。它会把每一次拆分视为成本，把每一次合并视为风险，并要求两者都由真实任务证据支持。
企业现在可以做一次具体盘点：
当团队能够回答这四个问题，Agent 架构才从概念设计进入经营设计。真正可规模化的企业 AI，未必拥有更多数字员工，而可能拥有更少的系统接缝、更清晰的责任入口，以及一套持续证明每层复杂性值得存在的证据。
- 哪些 Agent 只是因为部门、知识库或项目批次不同而被拆开；
- 哪些交接正在增加时延、丢失上下文或模糊最终责任；
- 哪些独立边界确实保护了权限、安全或专业能力；
- 是否有一套来自真实生产任务的评测集，可以比较整合前后的结果。
