编程 agent 也需要交通管制

编程 agent 可能每个都写得不错，事情最后还是砸了。

想象一下：五个 pull request 同时出现，每个看起来都合理，也都通过了自己的测试。但这些 agent 互相不知道，大家改的是同一个代码库。

这会是团队大规模用 agent 之后的下一个难题。写代码越来越便宜，“谁改什么、先改什么”却没有变便宜。

团队需要一套 agent 交通管制 的规则：哪个 agent 能动哪块代码，什么先合，重复的活什么时候叫停。代码审查是补丁写完之后找问题。交通管制要赶在冲突的补丁写出来之前，就把它们拦住。

碰撞已经开始出现

7 月 6 日有一篇论文，研究 GitHub 上 AI agent 的 pull request，看了 2,807 个仓库、33,596 个 agent PR。重叠的程度很惊人。40.2% 的仓库出现过两个 agent PR 同时开着，这类成对的 PR 占了样本里全部 agent PR 的 79.4%。时间窗放宽到一周，有重叠的仓库升到 53.4%，95% 的 agent PR 都和别的 agent PR 撞过期。

重叠不一定就冲突。可是几个”工人”改同一个代码库，事先又没对过计划，冲突的机会自然多。

作者还把 747 对同时开着的 PR 重新跑了一遍 git merge。同一个 agent 的 PR，文本冲突率 19.8%；不同 agent 的，41.7%。不过后一组只占重叠 PR 的 0.5%，样本太小，这个差距我现在不敢太当真。

冲突的类型更值得看。冲突文件里 84.4% 是源代码，接近 42% 的冲突动了代码库的结构：这边删了一个文件，那边正在改它，或者两个分支各写了一个同名文件，内容还不一样。有时候 agent 争的根本不是那几行代码，而是一个文件该不该存在。

好补丁也可能来错顺序

审查代码，我们通常问：这个 PR 对不对？多个 agent 同时干活，就得先问另一个问题：这个活现在该开始吗？

一个 agent 抽出一个 helper，另一个在重写调用它的代码，第三个照着旧版本补测试，第四个在修某个文件的日志——第一个 agent 正打算删掉那个文件。

每个补丁单独看都没毛病，合在一起就是一团没人想要的麻烦。

所以 PR 多不见得是好事。毛病未必出在代码质量上，也可能是顺序错了，没人负责，或者太多 agent 挤在同一块代码里。

另外两项研究也指向同一个方向。Augmentation with Dilution 看了 11,097 个 GitHub 仓库，时间从 2023 年 1 月到 2026 年 5 月。团队用上 AI agent 之后，人的参与占比下降，新人占比掉了 3.7 个百分点，每个 PR 反而多花了 5.3% 的 review。代码多了，人的理解没跟上。另一篇论文研究 agent 怎么写日志，发现生成代码进了仓库之后，72.5% 的日志修复还是人做的。补丁是 agent 交的，摊子还得人收。

Agent 没有省掉审查和整合的活，只是把更多的活推到了这里。

交通管制具体怎么做

实际做法不复杂。agent 开工之前，先说清楚要改哪块代码、想要什么结果。要是别的任务已经占了同一块地方，系统就早点提醒，人来决定：合并任务，排队，还是停掉一个。

有些活本来就分先后。重构一般先合，靠旧结构的功能再跟上。数据库变更只该有一个负责人。一段实现马上要换掉了，就别再让 agent 给它补测试。

工具能发现重叠，拿主意还得靠人，总得有人对顺序负责。tech lead、code owner、产品工程师、经理，谁都行，头衔不要紧。要紧的是 agent 出活的速度，不能超过团队理解和消化的速度。

小 PR 还不够

团队手里已经有不少好办法：小 PR、merge queue、code owner、feature flag、勤 rebase，还有 CI。这些都有用。7 月 6 日那篇论文数的也只是文本冲突，不是构建失败或产品 bug。有的冲突可能一分钟就解决了，并行开发本来就会有 merge conflict。

但 agent 改变了新活开工的速度。一个人现在能同时开好几个分支，未必想清楚了它们怎么配合。

Merge queue 回答的是”这个 PR 现在能不能合”。交通管制问的是”这两个活当初就该一起开吗”。后一个问题来得更早，也更要命。两个 onboarding 补丁可以顺顺当当合并，产品里却留下两套 onboarding 的思路。一个 agent 删了某个 helper，另一个还在它上面盖新功能。Git 能给你看冲突，方向得有人定。

也要统计没有做的活

Agent 平台不该只报自己开了多少 PR。它还该告诉团队：多少重叠的活在写代码之前就发现了，多少任务排队等过重构，多少次两个设计打架、请人拍了板，多少 PR 及时停掉了，没变成 reviewer 的新负担。

早点停掉 agent 的活，可能恰恰说明系统管得好。代码便宜，收拾起来贵，就不划算。

我的预测，留着以后回头验证：到 2027 年底，认真用编程 agent 的团队，会把任务归属、先后顺序、重叠修改的限制写进日常开发流程。最好的流程不是十个 agent 往一个累坏了的 reviewer 那里扔十个 PR。它知道什么时候该等，什么时候该合并任务，什么时候干脆别写这个补丁。