Agent丨在多 Agent 协作中，如何解决冲突、分歧以及争议无法收敛的问题？

type

Post

status

Published

date

May 7, 2026

slug

agent32

summary

一、为什么多 Agent 会产生冲突？

多 Agent 的冲突并不只是“两个 Agent 意见不同”。在真实系统里，冲突至少有七类。

冲突类型	典型现象	危害
结论冲突	A 认为 bug 来自缓存，B 认为来自数据库事务	最终答案不稳定
证据冲突	不同 Agent 引用不同来源，甚至来源时间不同	RAG 幻觉、过期信息被采信
方案冲突	架构师建议重构，性能 Agent 建议局部优化	返工、范围失控
权限冲突	Plan Agent 理论上只读，却通过子 Agent 写文件	安全边界被绕过
资源冲突	两个 Agent 同时改同一个文件	覆盖、合并失败
状态冲突	Agent 对任务完成状态认知不同	卡死、重复执行
目标冲突	一个 Agent 追求速度，另一个追求安全	决策标准不一致

Claude Code 文档直接提醒：两个 teammate 编辑同一文件会导致覆盖，因此应该拆分任务，让每个 teammate 拥有不同文件范围；同时也建议从 review、research、bug investigation 这类边界清晰的任务开始，而不是一上来做并行实现。(Claude Code)

OpenCode 的经验也说明，权限冲突不能只靠 prompt 约束。OpenCode 文档提供 per-agent permission 配置，支持对 edit、bash、webfetch 等工具设置 allow、deny、ask；但其 GitHub issue 中也出现过“父 Agent 禁止写入，但通过 task/subagent 路径间接写文件”的问题，issue 建议让 deny/false 权限向子 Agent 传递，避免子 Agent 获得比调用者更高的能力。(OpenCode)

二、核心结论：不要让 Agent 自由争吵，要让它们在协议中竞争

多 Agent 冲突治理的核心不是“辩论”，而是下面这条链路：

任务拆分 → 角色隔离 → 独立产出 → 冲突检测 → 有界辩论 → 仲裁决策 → 执行落库 → 失败升级

可以把它画成这样：

这和 Claude Code Agent Teams 的设计很接近：Team Lead 负责创建团队、派发任务、协调工作；teammates 是独立 Claude Code 实例；共享任务列表用于 claim 和 complete；Mailbox 用于 Agent 间通信；任务 claim 使用 file locking 防止并发抢占。(Claude Code)

AutoGen 也采用类似思想，只是更偏框架层。它的 Group Chat 模式由 group chat manager 选择下一个发言者，向对应 Agent 发送 RequestToSpeak，Agent 再向公共 topic 发布消息；SelectorGroupChat 还提供 termination condition，例如出现 TERMINATE 或达到最大消息数时停止，避免无限循环。(Microsoft GitHub)

三、从成熟系统看冲突治理的工程模式

1. Claude Code Agent Teams：共享任务列表 + 计划审批 + Hooks 质量门

Claude Code Agent Teams 的关键点不是“多个 Agent 同时跑”，而是它给多 Agent 协作补上了协作原语：Team Lead、Teammates、Task List、Mailbox。它还支持复杂或高风险任务先进入只读 plan mode，teammate 提交计划后由 lead 审批，拒绝则继续修改，批准后才进入实现阶段。(Claude Code)

这对冲突处理非常关键，因为很多争议不应该在代码已经改完后才发现，而应该在 计划阶段 就暴露。例如：

Security Agent：这个方案会修改认证流程，风险较高。
Architect Agent：这个方案能减少复杂度，但需要数据库 schema 变更。
Lead：拒绝直接实现，要求先补充迁移方案、回滚方案和测试覆盖。

Claude Code 还支持 Hooks：TeammateIdle、TaskCreated、TaskCompleted 可以在 teammate 即将 idle、任务创建、任务完成时触发；Hook 返回特定错误码可以阻止任务创建或完成，并把反馈发回 Agent。这个机制本质上就是“把质量门从 prompt 变成工程控制点”。(Claude Code)

2. Anthropic Research：主控 Agent 综合，而不是让子 Agent 直接定稿

Anthropic Research 的多 Agent 系统采用 orchestrator-worker 模式：LeadResearcher 分析问题、制定策略、创建多个 specialized subagents 并行搜索，subagents 独立探索后把发现返回给 lead，lead 再综合答案并决定是否需要追加研究。Anthropic 也强调，多 Agent 更适合宽度优先、可并行探索、信息超过单上下文窗口、工具复杂的任务；对强依赖、需要共享同一上下文的任务并不总是合适。(Anthropic)

这给冲突治理一个重要启发：最终答案的控制权应该集中在综合层，而不是谁先完成谁说了算。如果每个 Agent 都能直接面向用户输出，冲突就会暴露给用户；如果所有输出都进入 evidence ledger，再由 synthesizer 统一裁决，系统就能把冲突变成内部可控流程。

Anthropic 还提到，Agent 系统是高度 stateful 的，错误会复合；他们结合 retry、checkpoint、tracing、错误恢复和模型自适应来提高生产可靠性。对多 Agent 冲突而言，这意味着每一次仲裁都应该可恢复、可审计、可复现，而不是靠一次模型输出决定。(Anthropic)

3. LangGraph Supervisor：Supervisor 通用，但要小心“传话损耗”

LangGraph Supervisor 是典型中心化多 Agent 架构：一个 supervisor 接收用户输入，选择子 Agent，子 Agent 返回后控制权回到 supervisor，只有 supervisor 面向用户输出。LangGraph 的实现支持 specialized agents、tool-based handoff 和 message history 管理。(GitHub)

但 LangChain 的多 Agent benchmark 也指出，naive supervisor 容易出现“telephone game”问题：子 Agent 的结果被 supervisor 二次改写，可能引入错误。为降低这种损耗，LangGraph Supervisor 后续加入了减少 handoff message、forward_message 等机制，让 supervisor 可以直接转发子 Agent 响应，而不是重新生成完整内容。(LangChain)

这说明：冲突仲裁不是“让 supervisor 重新总结所有东西”，而是要保留原始证据和原始产物。否则综合层会成为新的幻觉来源。

4. OpenClaw：强隔离适合多身份协作，但共享状态需要显式设计

OpenClaw 的 multi-agent routing 把每个 agentId 视为一个完整隔离的 persona，拥有自己的 workspace、AGENTS.md/SOUL.md/USER.md、本地 notes、auth profile、session store。这样的隔离能降低身份串扰和记忆污染。(OpenClaw)

OpenClaw 的 QMD memory engine 则把 BM25、向量检索和 reranking 放在一个 local-first sidecar 中，并能索引 session transcripts、项目文档和团队 notes。对多 Agent 分歧而言，这类记忆系统可以作为“证据账本”的检索基础：不是让 Agent 凭印象争论，而是让它们回到可检索、可引用、可重排的材料上。(OpenClaw)

不过 OpenClaw 相关 RFC 也暴露出一个工程现实：即便已有 agents.list、bindings、sessions_spawn、sessions_send 等基础原语，真正做 coordinated team 仍然需要手动创建多个 workspace、配置身份和通道、手写通信模式，并且缺少共享状态机制。(GitHub)

这正好证明本文观点：多 Agent 冲突治理不是模型能力问题，而是分布式系统问题。

四、冲突治理层应该怎么设计？

建议把多 Agent 系统拆成 6 层。

1. Agent Layer：角色要互补，不要重复

不要创建 5 个“都很聪明的通用 Agent”。更好的方式是让角色之间形成结构性张力。

角色	职责	冲突价值
Planner	拆任务、定义成功标准	防止实现先行
Researcher	找证据、查文档、检索上下文	防止凭空推断
Critic / Devil’s Advocate	反驳方案、寻找失败路径	防止过早共识
Implementer	写代码、生成变更	负责落地
Tester	跑测试、构造反例	提供客观反馈
Security / Risk	权限、安全、隐私、破坏性操作	防止高风险动作
Judge / Arbiter	综合评分、裁决、升级	处理不可收敛

Claude Code 的示例也推荐在不确定根因时生成多个 teammate 研究不同假设，并让它们互相尝试推翻对方理论，类似科学辩论；文档指出，这能缓解顺序调查中的 anchoring bias。(Claude Code)

2. Protocol Layer：不要让 Agent 输出散文，要输出结构化提案

每个 Agent 的输出都应该是 proposal，而不是自由文本。

这个结构能让系统做三件事：

比较 claim 是否冲突。

比较 touchedResources 是否冲突。

检查 evidence 是否足够支撑结论。

没有结构化协议，多 Agent 争议就只能靠另一个 LLM 读长聊天记录，这会把仲裁问题变成新的幻觉问题。

3. State Layer：用任务图和锁减少资源冲突

Claude Code Agent Teams 的 shared task list 有 pending、in progress、completed 三种状态，任务还可以声明依赖；pending 任务如果依赖未完成则不能被 claim，claim 使用 file locking 防止 race condition。(Claude Code)

工程上可以抽象成：

资源锁要遵循一个原则：

一个 Agent 可以读很多资源，但写资源必须有 owner。
多个 Agent 可以给同一文件提建议，但不能同时写同一文件。

这也是为什么多 Agent 更适合并行 review、并行 research、并行假设验证，而不是多个 Agent 同时改同一模块。

4. Evidence Layer：所有争论都必须回到证据

多 Agent 讨论最危险的状态是：Agent A 说“我认为”，Agent B 说“我不同意”，然后两边继续扩写理由。生产系统里应该要求：

没有证据的观点只能作为 hypothesis，不能作为 decision。

RAG 场景尤其如此。建议维护一个 evidence ledger：

OpenClaw 的 QMD 设计给了一个很好的参考：它把 BM25、向量检索、reranking、query expansion、本地索引、session transcript 检索放在同一 memory sidecar 里。多 Agent 争论时，可以让 Researcher Agent 负责补充证据，Critic Agent 负责检查证据是否过期、是否来自低质量来源，Judge Agent 只裁决有 evidence id 的 claim。(OpenClaw)

五、冲突检测：不要等 Agent 自己说“我们有分歧”

冲突检测应该是系统能力，而不是 Agent 自觉。

每个冲突都应该被归一成统一结构：

这里最重要的是 blockedActions。一旦出现 high 或 critical 冲突，系统应阻止写文件、发邮件、删数据、调用外部接口等不可逆动作，直到冲突解决。

六、有界辩论：辩论要有轮数、格式和退出条件

多 Agent debate 不是没有价值。ChatEval 就把多个 LLM 组成 referee team，让它们讨论并评价生成文本；后续研究也讨论了多 Agent debate、majority voting、adaptive stopping 等机制。(arXiv)

但 debate 的风险也很明显：Agent 可能过早迎合共识，出现 sycophancy；也可能固执己见，导致无法收敛。相关研究指出，多 Agent debate 中的 sycophancy 会造成 premature consensus，Agent 可能为了和谐而放弃正确答案。(arXiv)

所以工程上不要做开放式辩论，而要做 bounded debate：

每一轮 debate 要限制格式：

这比“你们继续讨论直到达成一致”可靠得多。

七、仲裁策略：规则优先，测试其次，LLM Judge 最后

冲突仲裁不应该全部交给 LLM Judge。更稳的优先级是：

仲裁优先级建议

优先级	仲裁方式	适用场景
P0	硬规则	权限、安全、隐私、不可逆操作
P1	客观测试	单元测试、lint、benchmark、回归测试
P2	证据评分	RAG、事实判断、技术选型
P3	LLM Judge	架构设计、文案质量、主观权衡
P4	人工升级	高风险、低置信、无法复现、价值观判断

OpenCode 的权限案例说明，能力边界必须由系统强制，不能只靠模型“应该遵守”；Claude Code 也在 agent teams 中让 teammates 默认继承 lead 的 permission settings，降低子 Agent 权限漂移风险。(GitHub)

八、争议无法收敛怎么办？

争议无法收敛时，系统不能无限消耗 token。Anthropic 明确指出，多 Agent 系统 token 成本很高：其数据中 agent 通常使用约 4 倍于普通 chat 的 token，多 Agent 系统约 15 倍于 chat；Claude Code 文档也提醒 agent teams 的 token 使用会随 active teammates 数量增加，适合 research、review、新功能等高价值任务，不适合 routine task。(Anthropic)

因此要设置非收敛处理策略。

1. 最大轮数

多数工程场景下，2 轮已经足够。超过 2 轮还不能收敛，往往不是“还没讨论够”，而是缺少证据、目标不清或需要用户取舍。

2. 稳定性检测

可以参考 adaptive stopping 的思想：如果多轮之后 Agent 结论分布不再变化，就停止辩论，而不是继续烧 token。相关研究用稳定性检测来判断 judge consensus dynamics，并尝试在提高准确率和计算效率之间折中。(开放评论)

工程上可以简单实现：

3. 安全 fallback

如果无法收敛，按风险选择 fallback：

场景	fallback
代码实现冲突	不写代码，只输出两个方案和推荐实验
事实冲突	标记为“不确定”，列出冲突来源
权限冲突	默认拒绝，要求人工确认
架构冲突	选择可逆、低耦合、低迁移成本方案
RAG 证据冲突	优先 primary source、更新来源、可验证来源
文件写冲突	拆分 owner，或进入 PR review 流程

4. 人工升级

人工升级不等于失败。生产系统应该把人工升级设计成标准路径。

对用户来说，最差体验不是“Agent 问我一个问题”，而是“Agent 自信地做错了不可逆决策”。

九、RAG 场景下的多 Agent 分歧如何处理？

RAG 多 Agent 常见结构是：

RAG 的争议通常不是 Agent 本身，而是证据来源不同：

向量检索召回了语义相关但过期的 chunk。

BM25 找到了关键词匹配但上下文不足的 chunk。

rerank 选中了表面相关但事实不完整的 chunk。

不同来源对同一事实有不同版本。

历史记忆和最新文档冲突。

解决办法是把检索结果变成 evidence ledger，而不是直接变成 prompt stuffing。

如果 top evidence 之间互相矛盾，Answer Agent 不能直接生成最终答案，而应该进入 conflict resolution：

Anthropic Research 也对比了传统 RAG 的静态检索与其多步搜索架构：传统 RAG 取相似 chunk 后生成回答，而多 Agent research 会动态查找、根据新发现调整搜索、再综合高质量答案。(Anthropic)

十、源码级实现：一个 ConflictResolver 的最小骨架

下面是一个可落地的 TypeScript 风格骨架，重点不是语法，而是流程。

注意几个细节：

PolicyEngine 在 LLMJudge 前面。

runObjectiveTest 在 debate 前面。

LLMJudge 只处理低风险、不可客观测试的问题。

HumanEscalationService 是正式路径，不是异常路径。

每次 resolution 都要带 reason，方便审计。

十一、权限冲突：必须做 transitive capability

多 Agent 系统最容易漏掉的是“权限传递”。如果父 Agent 没有写权限，它调用的子 Agent 也不能获得写权限。否则就会出现“Plan Agent 不能写，但它 spawn 一个能写的 Agent”的绕过路径。

这个设计和 OpenCode issue 中的建议一致：deny/false 应覆盖 subagent/task permissions，task 不应获得比 calling agent 更大的权限。(GitHub)

十二、避免争议失控的 Prompt 模板

多 Agent Prompt 不应该只写“请合作完成任务”，而要写清楚冲突协议。

Judge Prompt 则应该避免“选一个你喜欢的答案”，而要要求它基于 rubric 裁决：

十三、生产级 Checklist

落地多 Agent 冲突治理时，可以按下面这份 checklist 做。

模块	必做项
角色设计	每个 Agent 有明确职责、工具、权限、退出条件
任务系统	任务有 owner、状态、依赖、验收标准
锁机制	写文件、数据库变更、外部动作必须加锁
证据账本	每个 claim 绑定 evidence，不允许裸结论
冲突检测	自动检测结论、资源、权限、证据冲突
辩论协议	最大轮数、固定格式、稳定性停止
仲裁机制	规则 > 测试 > 证据 > Judge > 人工
权限继承	子 Agent 权限不得超过父 Agent
质量门	测试、lint、安全扫描、Hook 阻断
可观测性	trace 每个任务、proposal、decision、action
失败恢复	checkpoint、retry、resume、safe fallback
用户体验	无法收敛时给选项，而不是假装确定

Anthropic 的生产经验也强调，Agent 系统中小错误会级联成大行为差异，因此需要 tracing、checkpoint、retry、错误恢复、渐进部署和结果导向评估；对多 Agent 系统尤其如此。(Anthropic)

十四、最终建议：多 Agent 冲突治理的黄金法则

先定义谁有权做决定，再让 Agent 讨论。

没有仲裁权的多 Agent 群聊，只会把分歧暴露给用户。

让 Agent 独立产出，再结构化比较。

不要让第一个 Agent 的结论污染后续 Agent。

所有结论必须绑定证据。

RAG 场景尤其要区分 primary source、secondary source、generated content、memory。

权限、安全、不可逆动作必须由系统控制。

Prompt 不能替代 capability enforcement。

辩论必须有边界。

最大轮数、稳定性检测、置信度阈值、人工升级缺一不可。

不收敛时要诚实。

输出“当前无法可靠裁决，原因是 X，需要 Y”，比强行给答案更可靠。

优先选择可逆方案。

架构、代码、数据库、外部 API 操作，只要争议未解决，就优先 plan、diff、dry-run、PR，而不是直接执行。

多 Agent 协作的本质不是“多个模型更聪明”，而是把复杂任务拆成多个可验证、可审计、可回滚的决策单元。真正成熟的多 Agent 系统，不是最会聊天的系统，而是最会处理分歧的系统。