多 Agent 协作：用预合并提前发现冲突

给 AI Agent 塞更多项目知识，它就会少犯错吗？KandiForge 作者 Kent Alstad 折腾了一年，得到的反馈并不乐观：知识覆盖面扩大了，行为却没明显改变。真正奏效的是观察多个 Agent 正在修改什么，在冲突发生时递上一条具体提醒。

这篇文章值得读的地方，是把注意力从「开工前该告诉模型多少事」，移到了「写代码时怎样尽早发现问题」。但要先分清：已有结果来自分支冲突监测，更完整的提前集成分析仍在规划中。

为什么一条冲突提醒比一堆项目知识更有用

作者在六个仓库里同时运行多个 Agent，每个 Agent 使用独立的任务分支和 worktree。worktree 可以理解为同一个仓库的独立工作目录，让多个任务各自修改文件。

他们已有一个 shadow merger：只要开放中的分支产生新提交，就在后台尝试把所有分支合到一起，找出哪些文件、哪些函数发生碰撞。受影响的 Agent 会在下一次命令或编辑前收到一行提示，例如：你的分支与 #489 都修改了这个文件。

它还会转发其他 Agent 遇到的失败，例如「另一个 Agent 三分钟前遇到了同样的错误」，也会提醒两个活跃会话正在处理同一区域。

提醒的价值来自具体、真实、及时。

此前，他们在每个提示中加入简报、记录命令、整理文件摘要，甚至把作者自己的纠正提炼成规则，在适用时触发。结果是行为没有明显改善，重复犯错在最初几天反而增加。

shadow merger 上线前，「合并前发现的问题数」每周都是零，因为没有机制检查；上线第一周记录到 79 个。

这个数字说明监测确实发现了此前没人统计的问题。但它不能直接证明少了 79 次线上故障，也不能说明这种方案比所有上下文方案都好。原文没有提供这样的对照。

没提交的代码，怎样提前进入检查范围

现有方案有一个盲区：它只看提交。Agent 可能改很久才第一次 commit，这段时间即使已经与其他分支冲突，shadow merger 也看不到。

作者不准备继续用提示要求 Agent 勤提交，而是设计自动检查点：

每个 Agent 回合结束后，由 hook 把当前 worktree 的改动提交到它自己的任务分支。提交只保存在本地，不 push，也不发生在集成分支上。Agent 随后正式提交时，再把这些检查点压缩合并进去，保持历史整洁。

这套机制计划通过统一的 hook 接线支持他们已有的各个运行环境，而不是绑定某一种 Agent 工具。目标是让 shadow merger 在一分钟内看到正在进行的工作。

这里有个关键状态差别：自动检查点仍在设计阶段，「一分钟内可见」是方案目标，不是已公布的实测结果。

原文也没有说清，自动提交如何处理未完成的改动，以及检查点压缩与 Agent 自己的 Git 操作如何协调。这些细节会直接影响落地成本。

把检查搬到组合后的代码上，能多发现什么

检查点的用途不只是提早发现文件冲突。作者希望持续构建一棵包含所有 Agent 最新改动的「影子代码树」，在真正集成前检查组合结果。这就是他所说的 pre-emptive integration analysis，提前集成分析。

大白话理解：每个人单独写的代码都可能没问题，放到一起却未必能跑。先在后台拼起来，就能提前看到相互影响。

计划中的检查分为几类：

• code watcher 在语法树上检查反模式，同时寻找重复代码和安全问题。
• SuperSmall 在每个检查点重新计算变更的结构与复杂度，把评审时的一次性评分变成持续反馈。
• 共享记忆检查新改动是否重复了记录过的失败路线，或者违背了团队已有决策。
• 用一台备用机器构建和测试组合后的代码，提前暴露集成失败。

发现问题后，系统尝试把结果归给引入问题的检查点，再通知对应 Agent。消息沿用那一行提示，在它下一次命令或编辑前送达，只提醒，不阻塞。

整个流程由后台服务响应提交触发，不轮询、不直接监视工作目录，也不在 Agent 会话内部运行分析。若反馈能被及时处理，正式评审时面对的就是剩余问题。

不过，这仍是一项按顺序推进的四部分计划：检查点提交、影子分支上的 watcher 与 SuperSmall、共享记忆检查、组合构建。第一部分尚在设计，后面的收益还需要验证。

我的判断

我认同作者把反馈放到实际改动之后。比起反复告诉 Agent「注意兼容其他分支」，指出它刚改的具体文件与谁冲突，更容易形成可执行的下一步。

但这不是放弃上下文的证据。项目约束、接口约定仍然帮助 Agent 决定怎么写；运行中的检查则负责发现它实际写错了什么。两者解决的问题不同。

与常见的分支 CI 相比，这个方案更关注多个未合并分支组合后的行为，也更早反馈。代价是需要维护影子集成环境、检查点历史和问题归因。两个分支各自通过测试、组合后才失败时，最后触发检查的提交未必就是唯一原因。

作者自己提出的验证指标比「发现 79 个问题」更有说服力：合并后因其他分支影响而需要补修的次数是否下降，代码写出到提醒送达要多久，以及 Agent 收到提醒后是否真的修改。

这些数据尚未给出。因此，已有监测值得借鉴，完整方案目前仍是有依据的工程设想。

能拿来做什么

• 多个 Agent 并行修改同一前端或 Node 项目时，可以先记录分支之间的文件与函数重叠，在下一步编辑前提供包含具体位置和相关分支的短提醒。
• 如果已有分支 CI，可以增加组合分支的构建与测试，检查尚未合并的改动是否相互破坏，再评估是否需要自动检查点。
• 评估这类机制时，同时记录提醒延迟、提醒后的实际修改和合并后的补修次数；发现的问题数量增加，只能先说明检查覆盖面扩大。
• 维护团队决策和失败记录时，可以尝试让检查器对照实际 diff 提示矛盾，同时保留人工判断，避免把过时记录当成永久规则。