通用方法 · 深入
两个 agent 各自都对，合起来却撞车
Git 能合文本，合不了意图
让两个 agent 同时改一个项目，最贵的失败不是报冲突，而是根本不报。文本从来不会相撞 —— 会相撞的是意图：一个把字段从「字符串」改成「枚举」，另一个同时在按字符串写测试；两边各自都对、各自都能过，合起来才发现前提已经不同。Git 只看字符，看不见这件事。这一页给的做法是「先登记、再动手」：每个 agent 开工前把「我打算改什么、为什么、影响哪些文件」写进项目内的一处共享清单，其他 agent 开工前先读它；两边意图相撞时，由一段确定性算法（不经过模型）点名是哪两个 agent、撞在哪、并建议怎么拆。关键在两条反直觉的纪律：只比意图、不锁文件；告警是建议性的、不拦人。
方法 · 一图看懂
1
开工前先写意图 — 每个 agent 动手之前，把「要改什么 / 为什么 / 涉及哪些文件 / 期望什么不变」写进项目内的共享清单；写完才算开工 —
2
开工前先读清单 — 第二个及以后的 agent 起手第一件事是读这份清单，而不是读代码；先看有没有人正在动这块 —
3
相撞时点名不裁决 — 检测到两条意图重叠 ⇒ 由确定性算法点名两个 agent、说清撞在哪、建议拆分方式（改顺序 / 改边界 / 一方让路），⛔ 不自动替它们决定 —
4
只比意图不锁文件 — 不用文件锁（锁会把并行退化成串行）；靠「意图登记 + 人看得见的告警」把冲突提前暴露 —
5
告警是建议性的 — 算法只报告不拦人；要不要让路、怎么分，交回给发起方（人或上层编排），⛔ 不把模型塞进冲突检测里 —
6
把不可违的约束落成代码 — 真正不能让的规则（如「退款金额不得超过原始金额」）⛔ 不靠提示词祈求，写成系统内的断言：模型提议、软件强制 —
为什么 Git 看不见这件事
Git 的合并单位是文本行。两个 agent 一个改 `../workflows/` 下的模板、一个改同一模板引用的样式变量，在两个不同文件里各改各的 —— 合并毫无冲突，产物却是坏的。真正相撞的是「我以为的前提」：A 认为字段还是字符串，B 已经把它改成枚举。文本合并永远看不到前提，所以要在「写代码之前」这个时点拦。
为什么是「登记」而不是「锁」
文件锁看起来更稳，代价是把两个 agent 重新排成一条队 —— 那等于放弃了并行本身。而并行的价值恰恰是同一段时间里推进互不相干的方向。⇒ 登记法只做一件事：把「正在动什么」变成公开信息。信息一公开，多数冲突在动手前就自己消掉了（一方改边界、一方改顺序，或干脆约好先后）。
为什么检测绝不能交给模型
冲突检测要可复现、可解释、不许漏。同两条意图跑两次必须给出同一个结论；判断依据必须能指出来。模型两样都做不到 —— 它会漏、会飘、还会给出好听但错的原因。⇒ 用一条确定性规则判「哪些文件集合相交 ∧ 是否同一时刻」，判完把结论交给模型只做措辞（怎么把冲突说清楚）。判在算法、说在模型。
把「不能让的」从提示词搬到代码里
凡是系统层面不可违的规则，⛔ 不要写成提示词里的一句祈使句 —— 提示词的执行是概率性的。正确形态是模型提议、软件强制：模型算出一个退款额，系统在写库前用一行断言把它挡住。越重要的不变量，越要落在代码侧。同一原则也解释了为什么「冲突检测」不交给模型：它不是措辞问题，是不变量问题。
原理 · 为什么有效
并行 agent 的失败面不在「谁写错了」，在「两边都对但前提不同」。 Git 合的是文本，合不了意图 —— 所以要在写之前把意图变成公开信息。三条支柱：① 先登记再动手（意图进共享清单）② 只比意图不锁文件（保并行、不退化）③ 判在算法、说在模型（可复现 · 可解释 · 不漏）。再加一条兜底：真正不能让的规则写成断言，⛔ 不交给提示词。
适用场景
适合：一个项目上同时跑两个以上编码 agent（多个 IDE 会话 / 多个 CLI / 编排器派出的子 agent）· 多人各自带着 agent 改同一仓库；也适合任何「多个执行者各自有局部正确理由」的并行协作。
⛔ 不适合：只有一个 agent（无冲突可言）· 任务天然串行（就按顺序做，不必造这层）。
自测 · 5 问
我能说出「现在正在动这个项目的一共几个 agent」，以及各自打算改哪一块吗？
我的 agent 开工前写的意图里，有「期望什么不变」这一栏吗？（只写「改什么」是半个意图）
上一次两边撞车，是动手前发现的，还是跑完测试才发现的？
我的冲突判断有没有一处是「让模型看一眼说说看」？如果有 ⇒ 它不可复现
有没有哪条规则我是只写在提示词里、而系统侧没有断言的？（那一条早晚会被违反一次）
怎么上手 · 验证步骤
最小可行版本（一次会话内就能试）：在项目里放一个 `intents.jsonl`（或 `.git` 下的共享小库），规定三件事 —— ① 每个 agent 动手前追加一条 `{agent, 文件集合, 一句话意图, 时间}`；② 起手先读一遍全部未结清的条目；③ 每次追加后用一句确定性条件检查「文件集合是否相交」。相交就在终端打一行醒目告警，并列出双方条目。先不接自动拆分 —— 让告警被人看见，多数冲突当场就散了。
验证只看一件事：下一次两边撞车，是在「写代码之前」被告警拦下的，还是照旧在测试阶段才发现。若仍是后者，先检查第 ① 栏有没有写「期望不变」——只登记改动清单，等于没登记意图。