凌晨两点，你的两个 Agent 并行干完活回来了：一个重构了支付模块的函数签名，另一个在同一个文件里加了新功能，git merge 一声哀嚎，冲突标记铺满屏幕。这时候你让哪个 Agent 来解决？让 A 来，A 大概率觉得自己的重构更重要；让 B 来，B 觉得自己的新功能才是正事——当事人当裁判，从来就没有公平可言。Hermes 在 2026 年 8 月合并了一个叫 merge-reconciler 的技能（PR #83063），思路很简单：冲突的双方都别碰，派一个中立的第三方 Agent 来仲裁。

为什么当事人不能自己和解

这是整个设计的前提，也是技能文档里反复强调的观察：当一个 Agent 面对同伴的代码时，它天然带着偏见——要么觉得自己的改动更正确，顺手把对方覆盖掉；要么觉得对方的代码自己看不懂，干脆把自己的改动放弃。两个方向都不是好结果。更微妙的是，合并冲突常常不只是“代码加不上”，而是两个改动背后有各自的意图，只有把双方意图都拿到桌面上，才能判断某一块冲突到底该怎么处理。

merge-reconciler 把仲裁者设定为一个与冲突无关的第三方：它拿到双方的 diff，加上双方各自声明的意图，然后逐块裁决。这个技能本身是纯技能 + 文档，零核心代码改动——意味着任何 Hermes 用户开箱即用，不需要升级配置。

三种冲突，三种裁决规则

仲裁者不是和稀泥，而是把每一块冲突（hunk）分类后按规则处理：

冲突类型	含义	处理方式
disjoint-intent（意图不冲突）	两个改动服务于不同目标，可以共存	两个都保留，合并
same-question-different-answer（同一问题不同答案）	双方对同一个设计问题给了不同答案	按声明的意图二选一，并把决定明确写出来
superseded（已被取代）	一方的改动前提在另一方改动后不成立了	保留存活的一方，说明原因

规则里最反直觉的一条是不要折中：如果双方对同一个设计问题给了不同答案，仲裁者必须二选一，而不是“各取一半”拼出一个谁都没设计过的杂交方案。裁决过程还有一条中立契约：不偏袒任何一方、只改冲突区域（禁止顺手优化其他代码）、每个设计取舍都必须出现在最终总结里让人能否决。

怎么用：三种落地方式

方式一：独立使用。在冲突的仓库里加载这个技能，按流程从上到下执行：先 git merge-base <A> <B> 找到共同祖先，用 git log --oneline <base>..<side> 和 git diff <base>..<side> -- <file> 收集双方改动，再通过 kanban 任务摘要或 PR 描述确认双方意图，然后逐块分类、裁决、验证、提交。

方式二：delegate_task 派生中立 Agent。这是多 Agent 战役里最推荐的方式——用 delegate_task 派生一个子 Agent，任务消息里带上仓库路径、两个分支名、双方意图摘要，以及“按 merge-reconciler 技能执行”的指令。子 Agent 天然是第三方，没有偏袒动机。

方式三：kanban 原生落地。如果你们的并行开发走的是 kanban 流程，创建一个专门的仲裁卡片，指派给第三个 profile（不是两个 worker 的任何一个），把两个冲突卡片都挂为父卡片：

kanban_create(
    title="reconcile branch-a x branch-b",
    assignee="reconciler",
    parents=["t_a", "t_b"]
)

父链接会自动把双方的完成摘要带进仲裁者的上下文，卡片正文只需写明仓库路径和两个分支名。仲裁完成后用 kanban_complete(summary=...) 收尾，总结里列出每一块冲突的裁决。

什么时候别用它

技能文档明确划了边界：单个 Agent 自己工作内的冲突，或者锁文件、生成文件这类琐碎冲突，直接重新生成就行，不需要仲裁。它针对的是并行战役里“两个 Agent 各带意图改同一块代码”的硬冲突。另外如果双方的意图实在无法从提交信息、PR 描述或 kanban 摘要里恢复，那就上报，而不是瞎猜——意图缺失时强行裁决等于掷骰子。

多 Agent 并行是 Hermes 的强项，我们之前写过多 Agent 协作的 AGENTS.md 目录链，也整理过技能组合玩法。如果你想让 Agent 们各干各的还不打架，kanban 命令参考和完整的定时任务指南都能帮上忙。