并行 agent 卡在哪：33,596 个 PR 里，跨 agent 冲突率是同一个 agent 的两倍

凌晨两点，你挂了三个 Codex agent 在三个 worktree 上干活。一个改 API，一个改前端组件，一个补测试。

早上起来，三个 PR 都在，测试都绿。但只有一个能干净合进去。另外两个都改了 src/shared/types.ts，撞得满屏冲突标记，谁先合谁后合，得你亲自拍板。

这事通常被归到"运气不好"或者"任务没拆好"。2026 年两拨独立的研究团队第一次把它量化了，数字比想象中难看。

数字先摆出来#

Xu、Subramanian 和 Karthik 三个人分析了 AIDev-pop 数据集里 33,596 个 agent 提交的 PR，覆盖 2,807 个仓库，时间跨度从 2024 年 12 月到 2025 年 7 月，来源包括 Codex、Copilot、Devin、Cursor 和 Claude Code。

40.2% 的仓库里存在时间上真正重叠的 agent PR 对。 更刺眼的是后半句：这些重叠的 PR 占了全部 agent PR 的 79.4%。把窗口从"精确重叠"放宽到一周，仓库比例升到 53.4%，PR 比例到 95.0%。

你发的每个 agent PR，有八成概率同时在跟另一个 agent 抢同一个合并目标，而这两个 agent 互相看不见对方。

另一个数据集 AgenticFlict 在 AIware 2026 上发布，规模更大：59,000 多个仓库、14.2 万个 agent PR，整体冲突率 27.67%，从中提出 33.6 万个细粒度冲突区域。两拨人用的是不同数据集、不同方法，结论方向一致。

同一个 agent 并行，冲突率就砍一半#

研究团队用无头的 git merge-tree 重放了 716 次三方合并，结果分得很开：

对比类型	文本冲突率	95% 置信区间
同一个 agent 的 PR 对	19.8%	16.8%–23.2%
不同 agent 的 PR 对	41.7%	33.1%–50.9%

两个区间不重叠，差异在统计上站得住。跨 agent 的 PR 对，冲突率差不多是同类的两倍。

原因是研究者给出的两条，都挺具体：

一是不同 agent 对同一个问题会做不同的架构选择。一个把函数就地重构，另一个直接删掉、另起一个替代实现，于是产生 modify/delete 冲突。这类冲突在所有冲突区域里占 26.8%，不是边角。

二是 agent 之间没有任何协调协议。它们看不到对方的分支，也没有认领或锁定文件的机制。worktree 隔离解决的是"别同时写同一个目录"，解决不了"两个分支动了同一个文件"。

这两件事得分开看。worktree 是防事故的，不是防冲突的。

冲突分三种，结构性的最贵#

研究把冲突区域分了三类：

内容冲突 57.6%：两个 agent 改了同一批行。就是 git merge 会打标记的那种，最常见，也最好修。
修改/删除冲突 26.8%：一个改了文件，另一个把它删了或者挪走了。这底下是"这个组件该不该存在"的分歧。
新增/新增冲突 15.1%：两边独立创建了同路径、不同内容的文件。

关键在于后两类加起来占了 42%，这两类没法机械合并。git 不知道该听谁的，因为这不是文本问题，是两个架构决策打架，必须有人（或另一个 agent）做判断。

另一个值得记的数字：84.4% 的冲突落在源码文件上，lockfile 只占 3.9%。 也就是说 agent 撞车撞的是业务逻辑，不是依赖版本号那点噪音。

按语言看，共同活跃度差别很大：Go 约 92%，Ruby 约 87%，Python 约 84%，TypeScript 约 75%，C++ 约 56%，HTML 约 44%。Go 排第一大概率是因为它大量出现在跑着多个自动化 agent 的基础设施仓库里（Dependabot、Renovate、Codex 一起上）。高吞吐仓库（超过 100 个 PR）共同活跃度约 90%，低吞吐（少于 6 个 PR）只有 53%。

文本冲突只是最上面那层#

研究者特意强调，19.8% 到 41.7% 这个区间是保守下限。他们把集成摩擦分了三层：

文本冲突：git 合不了 diff。这是被测量到的部分。
构建冲突：文本合干净了，但编译不过、lint 不过。没有被测量。
语义冲突：编译过、测试也过，但逻辑互相矛盾，跑起来结果不对。完全没有被测量。

三层是叠起来的。所以"git merge 干净"是必要条件，不是充分条件。CI 必须挡在每次合并前面，语义层面的对错还得靠人，或者靠另一个独立上下文的 agent 去审。

语义冲突在单 agent 场景里很少见，因为同一个 agent 的架构假设前后一致。一旦换成两个 agent，各自的假设都自洽，凑到一起就是矛盾。测试经常测不出来，因为两边各自的测试都是按自己的假设写的。

成本冰山#

研究报告里点了三项下游成本，大多数团队没在算：

CI 算力白烧。 一个冲突的 PR 在发现不可合并之前，照样触发 CI 跑一遍。跨 agent 冲突率 41.7% 意味着接近一半的跨 agent CI 运行是浪费的。

token 预算被吃掉。 自动解冲突（原 agent 自己解，或者专门派一个 resolver）要烧 token。按 GPT-5.6 Sol 每百万 token 5 美元输入、30 美元输出算，一个复杂的结构性冲突反复试几次，光 token 就是 1 到 5 美元。这个数字单看不大，乘上团队每天的 PR 量就不小了。

维护者疲劳。 研究发现大部分 agent PR 只经过一个人类 reviewer。当这个人还得手工解 agent 解不了的结构性冲突，并行带来的收益很快就还回去了。

Codex CLI 这边能做什么#

Codex CLI 现成的机制基本对得上这几条：

worktree 隔离是底线，不是解药。 /agent 命令默认在独立 worktree 里起子 agent，各自有目录、分支、索引，共享提交历史。它挡住的是最狠的那种事故（两个 agent 同时写同一个工作目录），挡不住分支合并时的文件级冲突。

按文件边界拆任务。 84.4% 的冲突落在源码上，所以最有效的一招是把 agent 的任务按目录切开，让每个 agent 只拥有一组文件：

## 并行任务边界
- Agent 1: `src/api/**`，只改 API 端点
- Agent 2: `src/ui/**`，只改前端组件
- Agent 3: `tests/**`，只补测试覆盖
⚠️ 任何 agent 不得在未批准时修改 `src/shared/**`

这段话写在 AGENTS.md 里，配合 requirements.toml 的做法，能让仓库里所有 agent 守同一套边界。

用 PostToolUse hook 提前发现冲突。 与其等 PR 提交时才发现，不如每次写文件后就把 git merge-tree 跑一遍，跟目标分支比一次：

#!/bin/bash
# .codex/hooks/post-tool-use-conflict-check.sh
TARGET_BRANCH="${CODEX_TARGET_BRANCH:-main}"
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
if [ "$CURRENT_BRANCH" != "$TARGET_BRANCH" ]; then
  MERGE_BASE=$(git merge-base "$TARGET_BRANCH" "$CURRENT_BRANCH")
  CONFLICTS=$(git merge-tree "$MERGE_BASE" "$TARGET_BRANCH" "$CURRENT_BRANCH" 2>&1 | grep -c "CONFLICT")
  if [ "$CONFLICTS" -gt 0 ]; then
    echo "⚠️ $CONFLICTS merge conflict(s) detected against $TARGET_BRANCH"
    echo "Consider rebasing or coordinating with other agents."
  fi
fi

冲突在写的时候就暴露，比在 PR 页面暴露便宜得多。

串行合并，不要并发合并。 父 agent 一个一个合子 PR，每合一个就把后面的 rebase 到最新目标分支上。这听着笨，但它把"N 个分支互相冲突"降级成"N 个分支依次冲突"，后者每次只有一个变量。

能用单 agent 并行就别用多 agent。 19.8% 对 41.7%，省下的不只是解冲突的时间。

社区里还有一类做法是认领协议，比如 agent-traffic-control：agent 动手前先认领任务和文件范围，写进一个共享注册表。这等于把原来被动的、撞了才处理的方式，改成动手前先排好。

我的看法：并行度看的是合并带宽#

这批数据里最值得注意的其实不是 41.7% 有多高，而是 19.8% 有多低。

同样是把任务拆开并行跑，只要"脑子"是同一个，冲突率就砍一半。这说明架构决策的一致性，比并发数量更值钱。多开一个 agent 带来的算力，很容易被多出来的一份架构分歧吃干净。

再往下想，现在社区所有的解法（文件所有权、认领协议、串行合并）本质上都不新。这些是人在做并行开发时的老规矩：划分模块、认领任务、排队合并。agent 没有让软件工程的老问题消失，它只是把这个问题压缩到几个小时里就能撞上一回，让你没法再用"我们团队沟通得挺好"糊过去。

所以真正的可并行度，不看你有多少 token 预算，看你的模块边界切得多干净。边界切不干净，多加一个 agent 只是多加一份冲突。AgenticFlict 那个 27.67% 的整体冲突率，某种程度上就是行业当前模块化水平的体检报告。

研究本身也在喊话，说要"程序化编排机制"和"正式的工作区实时通信协议"。这两样东西出来之前，协调的活儿只能压在 harness 层，也就是 AGENTS.md、hooks、父 agent 的任务分配这几块。这块做得好不好，直接决定了你的 agent 团队是加速器还是排队机。

参考来源：When Agents Collide: What 33,596 Pull Requests Reveal About Merge Conflicts in Multi-Agent Development（Daniel Vaughan，2026-07-28，2026-11-07 更新）；原始论文 Xu, G., Subramanian, A., & Karthik, N. (2026), AI Agent Pull Requests on GitHub: Frequency, Structure, and Merge Conflict Rates, arXiv:2607.04697；AgenticFlict 数据集，AIware 2026，arXiv:2604.03551。