多 agent 不是为了更快达成一致，而是为了延迟污染、保留异议

type

Post

status

Published

date

Mar 20, 2026

slug

summary

多 agent 系统最危险的不是意见不合，而是过早收敛。三个实际问题：过早共享抹平独立判断、拒绝分支是高价值信号、共享状态版本错位是常见冲突源。设计建议：先独立产出再汇总、把拒绝分支写进 decision log、共享上下文版本化。

核心判断

多 agent 系统最危险的不是意见不合，而是过早收敛。当 agent 彼此能看到对方的中间结果，多样性会被迅速抹平，最后产出一份委员会正确的平庸答案。真正有价值的信号，往往藏在被拒绝、被重写、被延后委派的分支里。

多 agent 协作是当前 agent 系统设计的热门话题，但讨论大多集中在角色分工、编排流程和状态机上。很少有人注意到一个更隐蔽的问题：系统在协同的名义下，正在丢失多样性。

agent 在产出阶段互相可见，会自然趋同。这不是协作效率高，而是判断提前被污染了。好的多 agent 设计应该先让每个 agent 独立完成自己的判断，再汇总对比。

编排层里被 rejected、rewritten、deferred 的 delegation，往往比成功执行的步骤更能说明系统在哪卡住了、哪条路径有争议、哪个边界需要重新画。但这些分支很少被记录进 decision log。

多 agent 冲突中，相当一部分不是目标分歧，而是不同 agent 读到了不同版本的 MEMORY.md、TOOLS.md 等共享文件。这类问题在开发时很难复现，但在长时间运行后频繁出现。

多数文章谈多 agent 会讲 tracing、workflow、状态机，但很少把分歧与拒绝本身视为需要保留的系统资产。一个被记录下来的拒绝决策，在回放和排障时的价值远高于十条成功日志。