最近和一些团队聊 Multi-agent，能强烈地感觉到一种错位：

AI 还没真正跑进业务结果，Agent 的数量已经先卷起来了。

这种技术的虚无主义，让我意识到一个问题:

Multi-agent 一定是最优解吗？

答案是显而易见的，不是。

Databricks 和 Anthropic最近有两组公开案例，让我更确定一件事：multi-agent 一旦进入生产，最先暴露出来的往往是两个问题——运行时可靠性，以及 Agent 间的协调成本。

两个公开信号

在一场公开分享里，Databricks 的 Sandipan Bhaumik 用一个金融审批场景说明了 multi-agent 进生产后的典型故障：多个 Agent 围绕共享状态交接时，状态传播延迟和缓存一致性问题，会让错误在系统继续运行的情况下静默扩散。公开转述里提到，该案例在上线初期曾出现显著比例的风险评级错误。

这里提示的机制很关键：缓存里的旧状态被当成新事实读出来，再经由并发交接继续往下传，最后放大成一致性问题。

另一边，Anthropic 在公开介绍自己的 multi-agent research system 时，也给了一个很难忽视的对照：任务表现比单 Agent 高 90.2%，但 Token 消耗是 15 倍。

这组数字来自他们自己的系统统计，不是外部测评。而且他们公开承认过早期运行中的几个典型问题：简单查询一度被同时分发给 50 个 sub-agent，出现过无限爬网和重复劳动；同一个 Prompt 跑两次，协作过程也会完全不同。

先爆炸的是状态

Databricks 那个案例里，真正值得看的是那条很熟悉的事故机制：一个 Agent 刚写入新状态，另一个 Agent 还拿着旧快照继续计算，随后又把旧结果写回去。

公开转述里给出的根因方向，就是缓存一致性让 Agent 读到了过时状态，并在并发更新时触发覆盖问题。

把 Agent 从 1 个加到 5 个，团队主观感受只是多了几个角色；系统层面实际增加的，却是更多交接面、更多共享状态同步点，以及更多失败补偿节点。复杂度在这里是非线性抬升。

人看流程图时，容易看到能力叠加；线上系统先付出的，是协调成本。

这就是 multi-agent 不可避免的协调成本。

更隐蔽的一类风险是，边界已经断了，系统却没有把故障显出来。某个关键字段的取值一变，下游工具调用没报错，Agent 还会自动补全缺失字段，继续生成一段看似完整的说明。

页面上全是通顺的人话，但是交接就是断掉了。

这也是为什么生产里最危险的故障类型，是”返回成功，但状态已经脏了”——错话会被立刻发现，脏状态不会。

在那场分享里，他们给出的兜底思路也很典型：先用 Schema 校验挡住静默失败，再用补偿把错误状态收回来。

限流和重试一旦进来，同一笔任务还会被系统放大。下游 Agent 拿到的已经不是同一个快照，业务侧第二天看到的只是说明文字前后不一致；运行时真正发生的，却是幂等失效和重试放大。

很多团队第一次排障，会盯着模型回复看半天，却忽略了任务已经被系统重放多次。只有把每次 Agent 动作写成带版本的新记录，对账和回滚才有依据。

如果流程天然串行，只有一个 Agent 按固定模板跑完，再交给人做最终审批，这类问题未必会立刻爆出来。但只要多个 Agent 共享状态、并发写入、互相交接任务，第一次生产事故就会先暴露在一致性与协调层。

先坏的是状态。

热闹不等于产能

可如果第一次事故明明先出在状态层，为什么团队排障还总从 Prompt 开始？

因为 demo 把最显眼的输出质量摆在台前，把最贵的运行时成本藏在幕后。

再加上模型团队盯回答质量，平台团队盯队列、权限和 tracing，责任一拆开，排障自然会先去看最可见的那一层。

太多 multi-agent demo：左边是一句任务描述，右边是几个角色轮流发言，最后拼出一份像样的报告。十分钟里最容易让人上头的，是那种”像团队在协作”的感觉。

可热闹不等于产能。

Anthropic 公开给出的那组数字，刚好能把这层幻觉撕开。multi-agent research system 的任务表现比单 Agent 高 90.2%，但 Token 消耗是 15 倍。

至少在这类系统里，性能、稳定性和单位任务成本很难沿同一条曲线一起改善。

做 demo 时，主持人卡住了，手动点一下重跑，观众通常看不出来。上线后同样的重跑，会先撞上并发或配额限制，再把整条任务队列拖慢。

你在测试环境看到的是一次偶发卡顿，在生产里看到的，已经是队列延迟、任务堆积和重试放大。

他们内部还出现过一个很典型的误用：用户只输入一个简单查询，系统却同时拉起 50 个 sub-agent 去搜网页、汇总材料，最后只是把相似结论换着说。

惊人的是系统不知道什么时候该停。

另一个坑，只有开始做评测后才会暴露。昨天通过的 case，今天再跑一遍，Agent 的协作顺序已经变了；答案也许还对，过程却换了。

对工程团队来说，真正麻烦的是你很难界定：到底是哪一步发生了回归。

也正因为协作路径会漂，Anthropic 才把实践收成五种受限模式：prompt chaining、routing、parallelization、orchestrator-workers、evaluator-optimizer。

这更像是在给复杂度装护栏，而不是鼓励角色自由扩张。

框架最容易制造的错觉，就是角色越多，能力越高。但对审批、客服、配置、对账这类确定性交付任务来说，demo 里最迷人的那部分，也是上线后最先吞成本的那部分。

选型的分水岭

一旦可靠性、回归和权限都开始吞噬收益，问题就从”能不能做”变成了”有没有资格把它放进生产”。

真正要上线时，会议室里的问题会突然变样。白板上不再写”要不要再加一个 reviewer agent”，而是”状态写哪儿”“权限怎么切”“失败能不能回滚”。

如果没有长会话持久化，一个 40 分钟的任务在第 38 分钟被发布打断，前面子任务就得重跑。

你把生产图真正画出来时，最占地方的是四件事：谁能动数据，状态存在哪，出错怎么回，问题怎么追。

Databricks 在那场分享里给出的兜底组合很典型：LangGraph 管工作流编排，Unity Catalog 管治理和权限，Delta Lake 存状态版本，MLflow 追每次调用和 handoff。

工具名不是重点。重点是，协调税最后都会落到状态、边界、回滚和追踪上。

权限边界也比很多团队预期更早成为问题。一个跨 CRM、文档库和工单系统的 Agent，只要多拿一档写权限，回滚难度就会上一个量级。

在生产里，谁有资格改线上数据，比团队想得更早成为问题。角色分工画得再漂亮，也顶不住一次越权写入。

行业现在补的，是运行时的洞。

Anthropic 最近补的两类能力就很说明问题：先把工具和数据源接成更稳的通用接口，比如 MCP；再把状态持久化、沙盒管理和 tracing 做成托管能力，比如 Claude Managed Agents。官方也明确强调，生产环境要做 full production tracing，并避免发布打断长会话。

至少从这些信号看，他们在补的是可靠性。