当多个 AI Agent 同时提 PR：代码冲突、评审和 CI/CD 会变成什么样？

xiaominglao

218人浏览 · 2026-07-11 21:20:26

xiaominglao · 2026-07-11 21:20:26 发布

当多个 AI Agent 同时提 PR：代码冲突、评审和 CI/CD 会变成什么样？

AI 编程助手正在从“帮我补几行代码”变成“自动开分支、改代码、跑测试、提交 Pull Request”。当一个仓库里同时出现多个 AI Agent 提交 PR，问题就不再只是代码能不能写出来，而是这些 PR 能不能被安全、低成本地合并。

摘要

2026 年之后，AI Coding Agent 开始大量进入真实 GitHub 工作流。Codex、Claude Code、GitHub Copilot Coding Agent、Devin、Cursor Agent 等工具，已经可以在 Issue、分支和 Pull Request 层面参与软件开发。

这带来一个新问题：

如果多个 AI Agent 同时改同一个仓库，会发生什么？

近期两篇研究给出了很值得关注的数据：

2026-07-06 的论文 AI Agent Pull Requests on GitHub: Frequency, Structure, and Merge Conflict Rates 分析了 33,596 个 AI Agent PR，发现 AI Agent 并发提交 PR 并不少见，跨 Agent PR 的文本冲突率显著高于同 Agent PR。
2026-04 的 AgenticFlict 数据集分析了 107K+ 个可处理的 Agentic PR，发现约 27.67% 出现合并冲突。

这些结果说明：
AI Agent 不只是“个人效率工具”，它已经开始改变团队协作、PR 评审、分支策略、CI/CD 和代码所有权。

本文不讨论“AI 会不会取代程序员”，而是讨论一个更实际的问题：

团队应该如何管理 AI Agent 提交的 PR？

一、为什么 AI Agent PR 会成为新问题
二、近期研究给出的关键信号
三、AI Agent PR 和人工 PR 有什么不同
四、并发 PR 为什么更容易冲突
五、冲突不只发生在代码文本层
六、团队应该如何设计 Agent 分支策略
七、AI Agent PR 模板应该怎么写
八、CI/CD 应该增加哪些检查
九、合并队列和所有权规则
十、如何降低多个 Agent 同时工作的冲突率
十一、适合交给 Agent 的任务和不适合的任务
十二、一个团队落地清单
十三、总结

一、为什么 AI Agent PR 会成为新问题

过去 AI 编程助手更多是 IDE 内的辅助工具：

开发者写代码
↓
AI 补全或解释
↓
开发者决定是否采用

现在很多 AI Coding Agent 的工作方式变成：

开发者创建任务或 Issue
↓
Agent 拉取仓库
↓
Agent 分析代码
↓
Agent 修改文件
↓
Agent 运行测试
↓
Agent 提交分支
↓
Agent 创建 PR
↓
人类 Review 后合并

这个变化很大。

因为 AI Agent 进入了 Git 协作流程，而 Git 协作本身就有复杂问题：

多人改同一文件
分支长期不更新
PR 之间互相依赖
CI 状态不稳定
Review 责任不清
锁文件和配置文件频繁冲突
同一个 Issue 被多个 PR 重复解决

当参与者从“人”扩展到“多个 Agent + 多个人”时，这些问题会被放大。

以前团队主要管理：

人和人之间的协作

以后还要管理：

人和 Agent 的协作
Agent 和 Agent 的协作
Agent 产物和现有工程流程的协作

二、近期研究给出的关键信号

1. AI Agent PR 并发并不少见

2026 年 7 月的论文 AI Agent Pull Requests on GitHub: Frequency, Structure, and Merge Conflict Rates 使用 AIDev-pop 数据集，分析了：

33,596 个 Agent-authored PR
2,807 个 GitHub 仓库

研究发现，在严格的时间重叠条件下：

40.2% 的仓库出现过 co-active agent-authored PR pairs
这些 co-active pairs 覆盖了 79.4% 的 AI Agent PR

如果按一周协作窗口观察：

53.4% 的仓库出现过 co-active agent PR pair
覆盖 95.0% 的 AI Agent PR

这说明 AI Agent PR 不是零星现象。只要一个仓库开始使用 Agent，多个 Agent PR 同时存在的概率就会升高。

2. 跨 Agent 的冲突更高

同一篇研究还重放了真实三方 Git merge 操作，比较 co-active PR 的文本冲突率。

结果显示：

同 Agent PR 对：19.8% 文本冲突率
跨 Agent PR 对：41.7% 文本冲突率

这非常关键。

它说明不同 Agent 之间并不是天然能协作。它们可能：

对任务边界理解不同
修改同一模块
采用不同代码风格
重复实现类似功能
修改公共配置
生成互不兼容的结构调整

3. 冲突主要发生在源代码文件

研究还提到，在出现冲突的文件中：

84.4% 是源代码文件

而不是很多人直觉以为的依赖清单或 lockfile。

此外，约 42% 的冲突属于结构性冲突，例如：

modify/delete
add/add

这意味着冲突不只是“同一行代码被改了”，还包括：

一个 PR 修改文件，另一个 PR 删除文件
两个 PR 同时新增同名文件
一个 PR 重构目录，另一个 PR 在旧目录继续改
一个 PR 改接口，另一个 PR 继续调用旧接口

4. 更早的数据集也提示冲突不是小问题

2026 年 4 月发布的 AgenticFlict 数据集处理了 107K+ 个 Agentic PR，并识别出 29K+ 个存在合并冲突的 PR，冲突率约为：

27.67%

这个数字再次说明：
Agent PR 的集成成本不是可以忽略的小尾巴，而是团队需要认真治理的工程问题。

三、AI Agent PR 和人工 PR 有什么不同

AI Agent PR 并不是简单等同于人工 PR。

维度	人工 PR	AI Agent PR
任务理解	人会结合团队背景判断	依赖 Issue、指令文件和上下文
修改范围	通常知道哪些地方不要碰	可能为了完成任务扩大修改范围
沟通方式	可以解释动机和取舍	解释依赖生成质量
重构倾向	受经验和团队习惯约束	可能顺手重构无关代码
重复工作	人会主动沟通避免重复	Agent 可能不知道其他 Agent 正在做
风险感知	能识别业务敏感点	需要显式约束
合并责任	通常清楚负责人	需要人为指定 owner

AI Agent PR 最大的问题不是“代码一定差”，而是：

它缺少团队语境。

比如：

这个文件虽然看起来可以改，但其实是历史兼容逻辑
这个模块有隐藏业务约束
这个测试不能随便删
这个 API 被外部系统依赖
这个改动和另一个正在进行的重构冲突

人可能知道这些背景，但 Agent 未必知道。

四、并发 PR 为什么更容易冲突

多个 AI Agent 同时提 PR，本质上是多个“自动化开发者”在同一个代码库里工作。

并发冲突常见来源有五类。

1. 同一 Issue 被重复解决

例如：

Agent A：修复登录表单校验问题
Agent B：优化登录表单错误提示

两个任务看似不同，但都可能修改：

LoginForm.tsx
validation.ts
auth.test.ts

最终冲突。

2. Agent 默认扩大修改范围

为了完成一个小任务，Agent 可能顺手：

格式化整个文件
重命名变量
调整目录结构
修改工具函数
更新依赖
改测试框架配置

这些动作对单个 PR 看起来合理，但多个 PR 并行时就很容易互相踩。

3. 缺少模块所有权感知

人类开发者通常知道：

支付模块找谁 review
权限模块不能乱改
公共组件要兼容多个页面

Agent 不一定知道。

如果没有 CODEOWNERS、架构说明、模块边界说明，Agent 可能把跨模块修改当成普通操作。

4. 修改共享文件

共享文件最容易成为冲突点：

package.json
pnpm-lock.yaml
requirements.txt
pyproject.toml
Dockerfile
README.md
CHANGELOG.md
路由配置
全局类型定义
公共工具函数

尤其是 lockfile。
Agent 很容易在不同分支中安装依赖，导致锁文件大面积变化。

5. 分支长时间不更新

Agent 任务如果排队运行或长时间迭代，就可能基于较旧的 base branch 开发。

当主分支变化很快时，冲突概率自然上升。

五、冲突不只发生在代码文本层

论文统计的是 Git 文本冲突，但真实工程里的冲突还包括更多类型。

1. 语义冲突

Git 能合并成功，但逻辑不一致。

例如：

PR A 修改了函数返回结构
PR B 继续按旧结构调用

Git 不一定冲突，但运行时会出错。

2. 测试冲突

两个 PR 单独都能通过测试，合并后测试失败。

例如：

PR A 改了默认配置
PR B 增加了依赖默认配置的测试

3. 产品冲突

两个 PR 都符合各自 Issue，但合起来体验变差。

例如：

一个 Agent 改了按钮文案
另一个 Agent 改了交互流程
合并后页面逻辑不一致

4. 架构冲突

一个 PR 朝 A 方向重构，另一个 PR 朝 B 方向重构。

Git 也许能合并，但项目结构变得更混乱。

5. 安全冲突

Agent 为了让测试通过，可能降低校验、放宽权限或跳过异常处理。

这类问题不一定产生 Git conflict，但比文本冲突更严重。

所以团队不能只问：

有没有 merge conflict？

还要问：

合并后系统语义是否一致？
CI 是否覆盖关键路径？
安全边界是否被削弱？
业务规则是否被误改？

六、团队应该如何设计 Agent 分支策略

如果团队允许 AI Agent 创建 PR，建议单独设计分支策略。

1. Agent 分支统一命名

建议：

agent/{agent-name}/{issue-id}-{short-task}

例如：

agent/codex/123-fix-login-validation
agent/claude/124-update-readme-install
agent/copilot/125-add-unit-test

好处：

一眼看出是否 Agent 生成
方便统计
方便批量清理
方便配置 CI 规则

2. Agent PR 必须绑定 Issue

不建议让 Agent 随机创建“顺手优化”PR。

要求：

每个 Agent PR 必须关联一个 Issue
每个 Issue 同一时间最多一个 Agent 处理

这样可以减少重复劳动。

3. Agent PR 默认 Draft

建议 Agent 创建的 PR 默认是 Draft。

流程：

Agent 提交 Draft PR
↓
CI 自动运行
↓
人类检查 diff 和日志
↓
确认后 Ready for review
↓
进入正常 Review

不要让 Agent PR 一上来就和人工 PR 同等优先级进入合并队列。

4. 小步提交

Agent 任务越大，冲突概率越高。

建议限制：

单个 Agent PR 修改文件数 <= 10
单个 Agent PR 新增/删除行数 <= 500
单个 Agent PR 不做跨模块重构

具体数字可以按团队情况调整。

七、AI Agent PR 模板应该怎么写

团队可以单独给 Agent PR 准备模板。

例如 .github/pull_request_template_agent.md：

## Agent PR 信息

- Agent 名称：
- 关联 Issue：
- 任务类型：
  - [ ] Bug 修复
  - [ ] 测试补充
  - [ ] 文档更新
  - [ ] 小型重构
  - [ ] 依赖更新
  - [ ] 其他

## 修改范围

请列出本 PR 修改的主要文件和原因：

- 

## Agent 执行记录

- 是否运行测试：
- 测试命令：
- 测试结果：

## 风险自查

- [ ] 没有读取或修改密钥文件
- [ ] 没有修改 CI/CD 部署流程
- [ ] 没有修改生产配置
- [ ] 没有引入新依赖，或已说明原因
- [ ] 没有进行无关格式化
- [ ] 没有大范围重构

## 需要人工重点 Review 的地方

-

这个模板的目的不是让 Agent 写漂亮 PR 描述，而是让人类 Reviewer 快速判断：

它改了什么
为什么改
跑了什么测试
哪里需要重点看
有没有越界

八、CI/CD 应该增加哪些检查

AI Agent PR 进入团队后，CI/CD 要从“只跑测试”升级为“守住边界”。

1. 限制修改敏感文件

可以在 CI 中检查 Agent PR 是否修改了敏感路径：

.github/workflows/**
Dockerfile
docker-compose.yml
infra/**
terraform/**
k8s/**
.env*
secrets/**

如果修改了，自动加标签：

needs-security-review

或者直接阻止合并。

2. 检查修改文件数量

Agent PR 修改文件太多，Review 成本会明显上升。

可以设置规则：

修改文件数超过 15：标记 large-agent-pr
新增删除行数超过 800：要求人工确认

3. 检查 lockfile

如果 Agent 修改了：

package-lock.json
pnpm-lock.yaml
yarn.lock
poetry.lock
Cargo.lock
go.sum

应该要求说明：

为什么需要依赖变更？
是否只为了修复当前 Issue？
是否可避免？

4. 增加合并前 rebase / update 检查

多个 Agent PR 并发时，PR 必须基于最新主分支验证。

建议：

要求 branch up-to-date
启用 merge queue
合并前重新跑关键测试

5. 增加语义测试

不要只靠 lint。

Agent PR 至少应通过：

单元测试
关键集成测试
类型检查
构建检查
安全扫描

如果是前端项目，还可以增加截图或视觉回归检查。

九、合并队列和所有权规则

AI Agent PR 并发的核心治理工具有两个：

合并队列
代码所有权

1. 合并队列

多个 PR 同时绿灯，不代表它们合起来也绿灯。

合并队列的作用是：

按顺序模拟合并
↓
在合并后的结果上跑测试
↓
通过后再进入主分支

这对 Agent PR 尤其重要。

如果团队没有合并队列，至少要要求：

PR 合并前更新到最新 main
合并前重新跑 CI
同一模块多个 Agent PR 不能同时合并

2. CODEOWNERS

Agent 不应该绕过模块负责人。

可以使用 CODEOWNERS：

/src/auth/        @team-auth
/src/payment/     @team-payment
/.github/         @devops-team
/infra/           @platform-team

这样 Agent PR 修改敏感模块时，会自动拉对应负责人 Review。

3. Agent PR 标签

建议约定标签：

agent-pr
agent-codex
agent-claude
agent-copilot
needs-human-review
needs-security-review
large-agent-pr
conflict-risk

标签的价值是后续可以统计：

哪类 Agent PR 最容易冲突
哪个 Agent 产物最容易被合并
哪些模块最容易被 Agent 改坏
哪些任务适合交给 Agent

十、如何降低多个 Agent 同时工作的冲突率

1. 给 Agent 分配明确边界

不要同时让多个 Agent 做类似任务。

不推荐：

Agent A：优化用户模块
Agent B：修复用户模块 bug
Agent C：补充用户模块测试

2. 避免 Agent 做大重构

大重构适合人主导，Agent 辅助。

Agent 更适合：

补测试
写文档
修小 bug
简单迁移
局部类型修复
重复模式替换

不适合：

架构重构
跨模块接口调整
复杂性能优化
安全策略修改
生产部署流程修改

3. 每个 Agent PR 都要有任务边界说明

Issue 里应该写清楚：

允许修改哪些文件
不允许修改哪些文件
必须运行哪些测试
不允许引入新依赖
不允许格式化无关文件

示例：

目标：修复登录表单邮箱校验错误。

允许修改：
- src/components/LoginForm.tsx
- src/utils/validation.ts
- src/components/LoginForm.test.tsx

不允许修改：
- package.json
- 路由配置
- 认证接口
- 全局样式

测试要求：
- npm run test -- LoginForm
- npm run lint

这类指令比一句“帮我修一下登录 bug”可靠得多。

4. 合并前检查 PR 之间的重叠文件

如果两个 Agent PR 修改了同一组文件，应自动标记。

可以用命令查看当前 PR 修改文件：

git diff --name-only origin/main...HEAD

团队可以在 CI 中对比多个开放 PR 的修改文件，发现重叠后打标签：

conflict-risk

5. 禁止 Agent 自动处理另一个 Agent 的冲突

如果 Agent A 的 PR 和 Agent B 冲突，不建议直接让 Agent A 自动解决。

原因是 Agent 可能只追求“让 merge 成功”，但不一定理解两个 PR 的业务意图。

十一、适合交给 Agent 的任务和不适合的任务

适合交给 Agent 的任务

任务	原因
文档更新	风险较低，Review 成本可控
单元测试补充	边界明确，容易验证
简单 bug 修复	修改范围小
类型错误修复	可通过编译检查
Lint / 格式修复	自动化验证强
重复代码迁移	有明确模式
小型依赖升级	可通过测试验证

不适合直接交给 Agent 的任务

任务	风险
核心架构重构	影响面大
权限和认证逻辑修改	安全风险高
支付、订单、财务模块	业务风险高
CI/CD 和部署脚本	可能影响生产
大规模依赖升级	供应链和兼容风险
数据库迁移	回滚成本高
跨模块接口调整	容易产生语义冲突

简单说：

边界清楚、验证充分、影响面小的任务适合 Agent。
边界模糊、业务复杂、影响面大的任务不适合让 Agent 独立完成。

十二、一个团队落地清单

如果团队准备正式引入 AI Agent PR，可以按下面清单推进。

1. 规则层

Agent PR 必须绑定 Issue
Agent PR 默认 Draft
Agent PR 必须带 agent-pr 标签
单个 Issue 同时只允许一个 Agent 处理
Agent PR 不允许默认修改敏感目录
Agent PR 不允许直接合并

2. 权限层

Agent 只能在专用分支提交
Agent 无权直接 push main
Agent 无权触发生产部署
Agent 无权读取生产密钥
Agent 使用最小 GitHub Token 权限
MCP / 插件权限单独审查

3. CI 层

自动识别 Agent PR
检查修改文件数量
检查敏感路径变更
检查 lockfile 变更
检查是否更新到最新 main
合并前重新跑关键测试
高风险 PR 自动加 Review 标签

4. Review 层

CODEOWNERS 覆盖核心模块
至少一名人类 Reviewer
高风险模块需要对应负责人 Review
PR 描述必须列出测试结果
Reviewer 重点看无关修改和越界修改

5. 数据层

统计 Agent PR 合并率
统计冲突率
统计 CI 失败率
统计平均 Review 时间
统计不同 Agent 的成功率
定期复盘哪些任务适合交给 Agent

这套清单的目标不是限制 AI Agent，而是让它进入可治理的工程流程。

十三、总结

AI Coding Agent 进入 Pull Request 工作流后，软件开发正在发生一个微妙变化：

以前是人写 PR，AI 辅助。
现在是 AI 也能写 PR，人负责治理。

近期研究已经说明，Agent PR 的并发和冲突不是理论问题：

AI Agent PR 会在同一仓库中并发出现
跨 Agent PR 的文本冲突率更高
冲突主要发生在源代码文件
结构性冲突占比不低
文本冲突只是集成成本的下限

所以，团队不能只问：

这个 Agent 能不能写代码？

更应该问：

它提交的 PR 如何排队？
谁来 Review？
哪些文件不能改？
CI 如何拦截风险？
多个 Agent 冲突时谁决策？
合并后责任归谁？

AI Agent 的价值不是让仓库里堆满 PR，而是让高质量、小范围、可验证的 PR 更快进入主分支。

真正成熟的 Agentic Coding 流程应该是：

清晰任务
↓
小范围修改
↓
Agent 生成 Draft PR
↓
CI 自动验证
↓
人类 Review
↓
合并队列验证组合结果
↓
主分支保持稳定

当多个 AI Agent 成为团队成员时，最重要的不是“让它们更自由”，而是给它们更清晰的协作边界。

参考资料

AI Agent Pull Requests on GitHub: Frequency, Structure, and Merge Conflict Rates：https://arxiv.org/abs/2607.04697
AgenticFlict: A Large-Scale Dataset of Merge Conflicts in AI Coding Agent Pull Requests on GitHub：https://arxiv.org/abs/2604.03551
Collaborator or Assistant? How AI Coding Agents Partition Work Across Pull Request Lifecycles：https://arxiv.org/abs/2605.08017
Toward Instructions-as-Code: Understanding the Impact of Instruction Files on Agentic Pull Requests：https://arxiv.org/abs/2606.13449
Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub：https://arxiv.org/abs/2601.15195
GitHub adds Claude and Codex AI coding agents：https://www.theverge.com/news/873665/github-claude-codex-ai-agents