多智能体不是越多越聪明：一场生产事故逼出的编排真相

你以为多加几个 Agent 就能把系统变聪明？这场分享给了相反答案。一次真实的生产级翻车，把“多智能体协作”的幻觉撕开：真正能落地的不是炫技的自治，而是冷静的编排、状态与补偿。

从“一个 Agent 很美”到“一群 Agent 很乱”

演讲一上来，Sandipan 就泼了一盆冷水：单个 Agent 在 demo 里几乎总是表现完美，但一到生产，多 Agent 往往是灾难的开始。

他讲了一个真实的生产部署经历：在信用决策系统中，多个 Agent 各司其职——拉数据、评估风险、给出结论。设计之初，每个 Agent 单独测试都没问题，但一旦同时运行，系统开始出现不可预测的行为：结果不一致、重复决策、甚至互相“打架”。

问题不在模型能力，而在复杂度的指数级膨胀。从一个 Agent 到多个 Agent，不是线性增加难度，而是引入了并发、依赖、状态漂移和失败传播。Sandipan 的判断很直白：如果你没提前设计协作方式，多 Agent 不是“团队”，而是“群聊失控”。

协作还是编排：两条路，只有一条能活下来

当系统从单 Agent 走向多 Agent，第一道分岔路出现了：Choreography（协作） vs Orchestration（编排）。

协作听起来很性感：每个 Agent 都是自治的，通过消息彼此响应，系统“自组织”完成任务。但现实是，这种模式在规模化时极其脆弱——没有全局视角，就没有全局一致性。

Sandipan 给出的结论很明确：生产系统更需要 Orchestration。

在编排模式下，有一个中心化的 Orchestrator：它不做具体业务判断，但负责决定“谁在什么时候做什么”。这听起来像是倒退回传统架构，但恰恰是这种“不性感”的设计，让系统可控、可调试、可恢复。

一句话点破本质：“自治解决的是局部最优，编排解决的是系统生存。”

真正让系统崩掉的，不是模型，而是状态

如果说架构选择决定了上限，那状态管理决定了你能不能活到明天。

多 Agent 系统的核心难题不是推理，而是：
- Agent 之间如何共享数据？
- 如何避免 race condition？
- 一个 Agent 的中间结果，什么时候算‘可信’？

Sandipan 直接给出判断：状态管理是多 Agent 的半壁江山。

另一半是什么？数据契约（Data Contracts）。

每个 Agent 不是“想输出什么就输出什么”，而是必须遵守明确的输入输出约定。没有契约，Agent 之间的集成会迅速变成隐性耦合，任何一个改动都会引发连锁反应。

这也是很多团队踩过的坑：他们在调 prompt、调模型，却忽略了最工程化、也最关键的部分。

失败不是意外，而是默认路径

在生产环境里，有一件事是 100% 会发生的：失败。

Agent 会超时、会返回脏数据、会在关键步骤“脑补”。Sandipan 强调，如果你的设计假设 Agent 总是成功，那系统迟早会把你送进事故复盘会。

因此，他引入了补偿模式（Compensation Pattern）：
- 不追求一次性成功
- 每一步都设计可回滚、可修正的补偿逻辑

这不是优雅问题，而是生存问题。真正成熟的多 Agent 架构，看起来反而很“保守”：它预设失败，拥抱失败，并为失败准备好第二条路。

一张生产级架构图背后的三句话

在展示完整的生产架构后，Sandipan 用三句话收尾，几乎可以当成多 Agent 的生存法则：

第一，Agent chaos 是不可避免的——别幻想完全可控。
第二，中心化不是罪，失控才是。
第三，工程纪律，比模型聪明更重要。

这不是对 Agent 能力的否定，而是对现实的尊重。多 Agent 真正的价值，不在于炫目的自治，而在于被良好约束后的稳定产出。

总结

如果你正在或即将构建多智能体系统，这场分享给出的不是灵感，而是止损指南。优先考虑编排而不是协作，把状态和数据契约当成一等公民，并假设每个 Agent 都可能在最糟糕的时刻失败。行动建议很简单：回头看看你的系统，有没有一个清晰的 Orchestrator？状态是否集中且可追踪？失败路径是否被认真设计过？能回答这三个问题，你已经超过了大多数团队。

关键词： 多智能体系统， AI Agent， Orchestration， 状态管理， 生产架构

事实核查备注： 需要核查：演讲者姓名拼写（Sandipan Bhaumik）；视频发布时间（2026-04-08）；案例为信用决策系统但未披露具体公司；术语使用是否与原视频表述一致（Choreography vs Orchestration、Compensation Pattern）。