AI Agent 并行改代码总互相踩踏？Foremerge 把“意图冲突”提前暴露
当 Claude Code、Codex 或 Cursor 同时在一个项目里工作时，Git worktree 可以把文件改动隔离开，却解决不了更隐蔽的问题：两个 Agent 修改的是不同文件，但设计意图其实互相冲突。一个 Agent 把 PaymentService 替换成 Stripe 实现，另一个 Agent 仍然在旧的 PaymentService 上增加 PayPal 支持；Git 看不到重叠行，合并也可能成功，功能却被悄悄“接”到了即将废弃的抽象上。
Foremerge 是一个构建在 Git 之上的开源协调协议，项目使用 Apache-2.0 许可证，当前版本为 0.5.0。它不锁文件，也不让模型替你做架构决策，而是让 Agent 在写代码前发布自己的工作意图、语义范围、依赖和验证条件，再用确定性的规则发现潜在冲突。
它补上的不是另一个 Git merge
Foremerge 的核心对象不是 diff，而是 intent。Agent 会声明“我要改什么符号、进行什么操作”，例如：
Agent A: symbol:PaymentService=replace Agent B: symbol:PaymentService=extend
这两项声明即使来自不同 worktree，也会触发高等级的破坏性与新增操作冲突。工具会解释冲突涉及的两个 Agent、重叠范围和建议方向，例如先稳定一个 PaymentProvider 抽象。建议只是可审计的证据，最终决定仍由开发者负责。
这种设计也避免了依赖自然语言摘要。无论 Agent 把任务描述成“迁移支付服务”还是“替换 PaymentService”，真正参与判断的是结构化的 scope 和 operation。
五分钟跑通第一个检查
项目 README 给出的安装方式是下载并执行官方安装脚本：
curl -fsSL https://foremerge.com/install.sh | sh foremerge init foremerge setup all foremerge checks set test -- cargo test --all-targets foremerge doctor --client all
setup all 会尝试为 Claude Code、Codex 和 Cursor 安装对应的 skill 与 MCP 配置；它会保留无关配置，重复执行也不会反复改写。checks set 注册的是项目可以信任的验证命令，Foremerge 在接受工作之前自己运行检查，而不是直接相信 Agent 说“已经完成”。如果暂时没有合适的测试，也可以显式设置：
foremerge checks policy advisory
这种情况下，结果会记录为 UNVERIFIED，不会伪装成已经通过验证。
两个 Agent 的最小演示
完成初始化后，可以用 JSON 输出注册两个无 worktree 的演示 Agent，再分别发布意图：
STRIPE_AGENT=$(foremerge --json agent register \ --name stripe-agent --no-worktree | jq -er '.data.id') foremerge --json intent publish \ --agent "$STRIPE_AGENT" \ --task "modernize-payments" \ --summary "Replace PaymentService with StripePaymentService" \ --scope symbol:PaymentService=replace
另一个 Agent 用 symbol:PaymentService=extend 发布意图后，JSON 响应中的 conflicts 会给出冲突类型、严重级别、解释和建议，related_work 则列出相关工作及重叠范围。开发者可以继续用 work claim 表达当前工作上下文，但 claim 是可租约的提示，不是排他锁；第二个 Agent 仍然可以继续工作，只是会收到重叠警告。
更适合哪些团队
Foremerge 当前是本地优先的 pre-1.0 MVP：CLI、JSON API、MCP Server、SQLite 存储、确定性冲突检测和验证门控已经实现，但公开基准结果尚未发布，跨机器协作也不在当前范围内。因此它更适合以下场景：
- 一个开发者在本机同时运行多个编码 Agent；
- 团队已经使用 Git worktree，希望在代码落地前共享任务意图；
- 对“谁改了哪一行”之外的架构耦合特别敏感；
- 希望冲突判断可重复、可解释，而不是再交给一个模型打分。
它不是任务调度器，也不是沙箱。警告默认是 advisory，不会阻止 Agent；操作系统隔离、权限控制和 CI 仍然需要单独配置。这个边界反而很重要：Foremerge 负责让意图可见，Git 负责保存历史，测试负责判断结果，开发者负责做架构取舍。
它的价值不在于替代 Git，而在于补上 Git 对“为什么要改”的盲区。对于刚开始尝试多 Agent 协作的团队，先把它放在 shadow 式的观察流程中更稳妥：让工具记录冲突，再由团队回看哪些规则真正有用，最后才决定是否把验证门纳入日常流程。这样既不会因为一次误报阻塞开发，也能逐步形成可复用的协作约定。
我的判断
并行 Agent 的瓶颈正在从“能不能同时写代码”转向“能不能共享上下文”。单纯增加 worktree 数量，只会把冲突推迟到合并之后；把意图作为一等对象，才有机会在第一行代码写入前发现问题。Foremerge 目前仍处于快速演进阶段，公共 schema 可能变化，但它提出的分层方式值得借鉴：让 Agent 声明计划，用确定性规则做预警，把最终决策和验证留给人和真实测试。
相关链接