用多个 AI Agent 同时在同一个仓库跑 Worktrees 简直是噩梦，Foremerge 能在写代码前就掐掉意图冲突

如果你现在已经习惯了使用 Cursor 或者 Claude Code 这种具备强自主能力的 AI Agent 来处理并行任务，那么你一定经历过那种令人绝望的时刻：当你给两个不同的 Agent 分配了两个看似独立的功能模块，并让它们在各自的 Git Worktrees 中并行开发时，你以为效率翻倍了，但实际上你是在为最后的合并阶段埋坑。

在大多数人的认知里，Git 冲突（Merge Conflict）是开发中的常态，而且好解决。只要代码行没有重叠，或者即便重叠了，通过简单的手动对比也能快速理顺。但真正让开发者感到恶心的是所谓的「逻辑冲突」。

举个最典型的例子：你让 Agent A 去重构支付模块，Agent A 经过分析决定把 PaymentService 类给删了，换成更具体的 StripePaymentService；而与此同时，Agent B 此时正兴致勃勃地在另一个分支给 PaymentService 增加 PayPal 的支持。在 Git 的视角里，这两个操作可能发生在文件的不同行，或者根本没有产生物理上的冲突。Git 根本不知道这两个 Agent 实际上在打架，直到你进入 PR 阶段，在进行代码审查或运行集成测试时，你才惊觉这两个 Agent 之前一直在互相拆台。这种冲突的代价极高，因为此时你必须在两个已经写完的 Feature 之间做选择，或者强迫其中一个 Agent 重新推翻之前的逻辑重新写。

Foremerge 解决这个问题的思路非常暴力且高效：它主张在 Agent 动笔写代码之前，就强迫它先进行「挂号」。

简单来说，Foremerge 在 Git 之上增加了一个协调层。它要求 Agent 在开始任何实际的代码修改之前，必须先发布自己的意图（Intent）以及这次修改的影响范围（Scope）。如果两个 Agent 打算对同一个符号（Symbol）执行互斥的操作，Foremerge 会在代码被写出来之前就直接发出预警，从而在源头上掐掉逻辑冲突。

那么，具体怎么让 Agent 在动笔前先“挂号”呢？

首先需要明确的是，Foremerge 并不是那种会随意篡改你 Git 历史记录的复杂工具，它本质上是一个用 Rust 编写的二进制文件。为了保证轻量和高效，它的状态并不存储在复杂的服务器中，而是存放在 Git 公共目录的一个 SQLite 文件里。这种设计保证了它能与现有的 Git 工作流无缝集成，而不会引入沉重的依赖。

其核心逻辑非常简单：Agent 必须先声明自己要做什么。如果系统检测到冲突等级较高，就会直接拦住 Agent，防止其继续执行后续的写操作。

我们可以通过一个具体的命令行场景来模拟这个过程。

假设 Agent A 准备开始执行重构任务，它在动笔前会先调用 Foremerge 发布自己的意图：

foremerge intent publish --agent "$A" \
    --summary "Replace PaymentService with StripePaymentService" \
    --scope symbol:PaymentService=replace

在这个指令中，Agent A 明确告知了协调层：它的目标是 PaymentService 这个符号，且操作类型是 replace（替换）。

此时，如果 Agent B 尝试在另一个 Worktree 中启动一个扩展任务，它也会尝试发布意图：

foremerge intent publish --agent "$B" \
    --summary "Add PayPal support to PaymentService" \
    --scope symbol:PaymentService=extend

Agent B 声明它同样在操作 PaymentService，但它的操作类型是 extend（扩展）。

在这种情况下，Foremerge 的协调层会立即介入。由于一个 Agent 打算执行 replace（破坏性操作），而另一个 Agent 打算执行 extend（增量操作），这两者在逻辑上是互斥的。在 Agent B 真正开始写代码之前，Foremerge 就会返回一个 HIGH destructive_vs_additive 的冲突结果。

这意味着在 Agent B 浪费 Token 和时间去写那些注定会被删掉的代码之前，冲突就已经被发现了。开发者或者 Agent 调度系统可以根据这个预警，决定是让 Agent B 等待 A 完成，还是调整两者的分工。

这种机制将冲突的发现时机从「代码合并后」提前到了「代码编写前」。在 AI Agent 驱动的开发模式下，这种前置的协调至关重要，因为它将原本不可预测的逻辑碰撞转化为了可量化的意图冲突。