多 Agent 项目为什么容易在演示里好看，在业务里失控

我第一次看多 Agent 演示时，也会被角色之间的讨论吸引。一个负责规划，一个负责检索，一个负责审查，屏幕上连续出现消息，像一支团队正在工作。

但我把同一任务改成真实业务输入后，注意力很快从“角色是否聪明”转向三个问题：状态以谁为准，工具权限归谁，什么时候必须停止。

我的判断是，多 Agent 在演示里增加的是可见活动，在业务里增加的却是协调成本。角色越多不一定能力越强，但状态、权限、消息和失败路径会确定增加。

三个角色会产生不止三条关系

3个角色两两之间已经有3组直接关系；增加到5个角色，潜在的两两关系变成10组。并非每组都会通信，但团队必须定义哪些消息能被谁看到、谁能覆盖谁的结果。

演示任务通常只有一个共享目标，所有角色读同一份上下文。业务任务却可能涉及客户数据、财务字段和内部策略，不同角色不应获得同样权限。

这个例子告诉我：角色数量是表面复杂度，关系数量才是系统复杂度。

两份正确结果也可能形成一个错误状态

假设检索角色找到了新版政策，写作角色仍引用旧版摘要，审查角色只检查语言而没有检查版本。三个局部动作都能完成，最终结果仍然错误。

当 2 个角色并行更新共享状态时，系统要处理版本、覆盖和冲突；当任务重试 1 次时，还要保证已执行工具不会重复写入。演示通常从空状态开始，业务系统每天从历史状态继续。

这个例子告诉我：多 Agent 的核心不是对话，而是一个可以解释、恢复和校验的状态模型。

一个写权限会把错误从文字带进系统

研究角色只读文档，风险相对局部。若它还能写 CRM；执行角色能发邮件；协调角色能修改任务优先级，权限会沿消息链扩散。

即使只有 1 个角色被提示注入影响，它也可能把错误指令作为“研究结论”交给另一个有写权限的角色。后者并不知道上游证据已经被污染。

这个例子告诉我：权限不能跟随角色名称分配，而要按每个工具动作最小化，并在高风险动作前重新校验。

设想一个采购询价流程。研究角色读取 3 家供应商资料，比较角色整理价格，执行角色准备邮件，审批角色决定是否发送。若比较角色拿到的价格版本已经过期，后面 3 个角色都可能在错误前提上完成职责。角色分工没有修复证据问题，只让错误多经过了几道看似专业的工序。

多一轮讨论，就多一层成本和不确定性

一个单 Agent 流程若需要 3 次模型调用，多 Agent 讨论可能把它扩展成 8 次、12 次甚至更多。这里不假设固定倍数，实际要用日志核验，但调用轮次、上下文和等待时间都会随协作增长。

更麻烦的是预算不再只由输入决定。一次争论是否继续、失败后由谁重试、审查不通过要退回哪一层，都会改变调用数量。

没有最大轮次、最大工具调用和超时边界时，“让它们讨论到解决”为业务系统留下了开放账单。

我把这类风险叫作“协调债务”

协调债务指的是：为了增加一个角色，系统额外承担的协议、状态、权限、观测和停止条件。

它可以用五个问题检查：角色是否有独占职责；输入输出是否有 schema；共享状态是否有唯一写入规则；工具权限是否最小化；失败是否能归因到具体事件。

若新增角色只是在同一提示上换一个名字，却没有独占数据、工具或判断标准，它没有创造新的能力，只创造了新的消息。

这个框架的关键不是把 5 个问题逐项打勾，而是比较新增角色前后的净变化。若质量没有稳定提高，调用从 3 次变成 8 次，状态和权限还多出一层，项目承担的就是没有被业务价值偿还的协调债务。

常见失败不是模型不够聪明

第一类失败是职责重叠，两个角色都能改最终答案。第二类是共享记忆无限增长，旧信息持续污染新任务。第三类是审查角色没有明确规则，只会说“可以更完善”。第四类是任何角色都能调用高风险工具。第五类是没有终止协议，反复修改直到超时。

这些问题换更强模型可能短期缓解，却不会消失。它们属于系统设计，不属于提示词润色。

有些任务确实适合多 Agent

反例是职责天然独立、证据来源不同、结果可以明确合并的任务。例如一个角色从技术文档提取约束，另一个从合同模板检查条款，最终由固定规则汇总差异。

即便如此，也应先比较三种基线：单 Agent 加工具、确定工作流加专用步骤、多 Agent 协作。只有多 Agent 在质量或维护上有可验证优势，复杂度才值得接受。

开放式创意讨论也可以使用多 Agent，但它适合产生候选，不适合直接执行业务动作。

上线前要把约束写进协作协议

评估时还要把单 Agent 基线保留下来。对同一批任务，记录最终质量、需要人工修改的类型、调用轮次、工具失败和恢复路径。多 Agent 即使给出更丰富的答案，如果审核时间更长、失败更难定位，也未必改善业务流程。

不要用一次成功演示得出结论。至少要加入信息冲突、上游工具超时、角色给出不同建议和任务中途恢复等样本。真正的差异常常在失败输入里出现，而不是在标准问题上出现。

我会把走查写成一段协议，而不是功能清单：每个角色只有一个可验证职责，消息有结构化字段，共享状态有版本和唯一写入规则；工具权限按动作授予，高风险动作在执行前审批；任务有最大轮次、预算、超时和停止条件；每次状态变化都能回放，并始终保留单 Agent 与确定工作流作为对照。

这段协议的用途不是让架构显得完整。任何一项答不清，都意味着新增角色的协调债务还没有被项目接住。

下一步先删除一个角色

我现在再看那些热闹的演示，会先尝试删除一个角色。如果删掉后，只需把它的规则放进工作流，结果没有明显损失，那它原本就不是必要角色。

多 Agent 的成熟度不看屏幕上有多少人说话，而看系统能否回答：每个角色为何存在，出错时谁负责，任务何时停止。这个判断，正是控制协调债务的起点。