title: “Merge Reconciler — Neutral third-party resolution of agent merge conflicts” sidebar_label: “Merge Reconciler” description: “Neutral third-party resolution of agent merge conflicts”

{/* 本页面由 website/scripts/generate-skill-docs.py 根据技能的 SKILL.md 文件自动生成。请直接编辑源文件 SKILL.md，而非此页面。 */}

合并协调器

作为中立的第三方来解决智能体之间的合并冲突。

技能元数据

参考：完整的 SKILL.md 文件

:::info 以下是当触发该技能时 Hermes 会加载的完整技能定义。当该技能处于激活状态时，智能体看到的指令即为内容。

::

合并协调器

作为公正的第三方，解决两个智能体分支之间的 Git 合并冲突。那些试图自行解决与同伴代码冲突的智能体，要么直接覆盖同伴的代码，要么放弃自己的修改——因为它们缺乏同伴的上下文信息，且容易偏向自身立场。而该技能正是为了解决这一问题：它作为一个中立的协调器，能够接收双方的差异内容以及双方明确的意图，最终生成合并后的结果，就像合并队列中的仲裁者一样。

适用场景

• 在并行任务执行过程中（如看板工程流水线、并行PR处理、多工作树重构），两个代理分支/工作树发生冲突。
• 当两个代理的工作内容出现冲突时，git merge 或 git rebase 操作会中止，且任一原始代理均不应自行尝试解决冲突。
• 请勿将此方法用于单个代理内部的工作冲突，也不适用于轻微的锁文件或生成文件冲突（此类情况应重新生成相关文件）。

前提条件

• 已检出包含中止合并操作的仓库，或知晓两个分支的名称，并拥有自行执行合并操作的权限。
• 双方的意图来源：看板任务完成摘要（在终端中运行 hermes kanban show <task-id> 获取）、PR正文，或至少每个分支的提交信息。
• 项目对应的构建/测试命令（如有）。

执行方法

独立运行 — 由人工操作者（或代理）在出现冲突的仓库中调用此技能：加载该技能后，按步骤从头到尾执行操作。

生成中性代理 — 多代理任务中的推荐执行方式：

• delegate_task：创建一个子代理，其任务信息需包含仓库路径、两个分支名称以及双方意图的完整摘要，同时还需附带执行该技能的指令。
• Kanban原生方案：创建一张分配给第三方账户（而非任意一名处理者的账户）的协调卡片，将两张冲突卡片均设为该卡片的父卡片——即使用kanban_create(title="reconcile branch-a x branch-b", assignee="reconciler", parents=["t_a", "t_b"])。这些父卡片会自动将双方的完成摘要带入协调者的工作上下文中；卡片正文中应注明仓库路径及两个分支的名称。

快速参考

公正性准则：绝不能偏袒创建你的那一方；仅修改存在冲突的区域（禁止擅自编辑其他内容）；对于每个设计问题的选择都必须在总结中明确列出。

执行步骤

1. 召集双方参与

• 通过终端运行命令：使用 git status 查看冲突状态并列出冲突文件，接着执行 git merge-base <A> <B>；对于每一方，分别使用 git log --oneline <base>..<side> 查看日志，并针对每个冲突文件使用 git diff <base>..<side> -- <file> 查看差异。在合并被暂停时，HEAD 代表其中一方，而 MERGE_HEAD 代表另一方。
• 收集每一方的意图：可通过 hermes kanban show <task-id> 查看任务完成摘要/元数据，或 PR 正文，或是上述日志中的提交信息。在修改任何文件之前，先为每一方用一句话概括其意图。
• 完成标准：能够用自己的话阐述双方的意图，并获取每个冲突文件的差异内容。

2. 对每个冲突代码块进行分类

• 使用 read_file 打开每个冲突文件，定位所有的 <<<<<<</=======/>>>>>>> 分隔符块。
• 根据已确定的意图（而非哪方修改看起来更合理），从快速参考表中为每个代码块指定唯一的类别。
• 如果一个代码块包含多个独立的决策（例如，既有关联性良好的新逻辑，又有双方处理方式不同的样式/圆角设置），则需将其拆分为多个子决策，并分别进行分类。
• 通常一个文件中会存在多种类别：某个代码块可能是设计冲突，而相邻的代码块则可能没有冲突。需逐个代码块进行分类，而非按整个文件处理。
• 完成标准：每个代码块都需有明确的类别标注以及简短的一行说明理由。

3. 在公正性原则下解决冲突

• 使用 patch 命令编辑每个代码块（如需整体重写文件，则使用 write_file）：
  • disjoint-intent → 合并两项修改，确保每个意图都能得到完整满足。
  • same-question-different-answer → 选择最能符合所指定意图的答案（例如，若任务要求结果准确无误，“严格验证”选项应优先于“快速默认”选项）。切勿在双方均未提出的情况下强行折中生成混合方案。
  • superseded → 保留有效的内容，删除过时的前提条件。
• 绝不可偏袒生成你的那个版本。如果各意图确实难以抉择，应上报问题（阻塞看板卡片或反馈情况）而非自行猜测。
• 除冲突标记外的内容一律不得更改——不得进行格式调整、重命名或随意修复。
• 通过 terminal 命令为每个已处理完成的文件执行 git add 操作。
• 当 search_files 在代码库中找不到任何 <<<<<<< 标记，且所有已处理文件均被标记为待提交时，即表示任务完成。

4. 验证

• 通过 terminal 运行项目的构建/测试流程；至少要导入或执行那些被修改过的模块。在合并后的结果中，必须能够观察到两种意图的表现（例如，A 方的新逻辑与 B 方的独立补充内容均应存在）。
• 完成合并操作：执行 git commit 命令（使用默认的合并信息并附上说明各代码块处理决策的文字即可）。
• 当验证通过且已生成合并提交时，即表示任务完成。

5. 归还成果

• 生成一份完整的总结，明确列出每个代码块的决策依据：文件路径:行号 — 类型 — 保留哪一侧 — 决策理由。对于那些针对同一问题但答案不同的代码块，需说明设计问题及所选择的答案，以便人工进行审核——绝不能隐匿任何设计决策。
• 使用看板功能时：执行 kanban_complete(summary=...) 命令；独立使用时则直接输出总结内容。
• 完成标准：当总结已生成并列出所有代码块时即视为完成。

常见陷阱

• 偏袒自身：若你是由存在冲突的某个智能体生成的，那么你在本质上就存在偏见——必须明确指出这一点，并刻意权衡另一方的意图。建议采用第三种处理方式以避免此类问题。
• 在设计冲突时选择“折中方案”只会产生一种无人设计过的混合结果；应选定一个答案并明确呈现。
• 按文件整体分类：文件中的代码块通常属于不同类型；若将整个文件归为同一类别，就会隐匿那些独立的修改内容。
• 擅自编辑会导致合并结果无法被审核，同时还会抢走原始智能体的决策权。
• 意图缺失：仅靠提交信息往往不够充分；建议使用看板总结或拉取请求正文来说明情况。如果无法明确任何一方的意图，则应上报问题而非自行猜测。
• 屡犯者：在多轮处理中，同一文件持续出现冲突，这属于高风险信号，而非常规的协调工作——需对此进行标记（例如添加 hotspot: <路径> — <原因> 的看板备注），以便调度器对该文件进行拆分处理，而非逐个处理其上的新冲突。

验证方法

• git status 显示目标分支上的代码状态为“干净”，且已存在合并提交记录。
• 不再存在任何冲突标记（即不存在 search_files 模式中的 <<<<<<< 标识）。
• 构建与测试均通过；双方的意图均已明确体现，或摘要中已明确说明被舍弃的意图。
• 回交摘要会列出每一块代码片段及其所属类别及选择理由。