Pull Request 正在变成知识导入

Pull request 原本是一种很紧凑的交易：我已经把活做了，这是 diff，请你判断它该不该进来。

编程 agent 正在削弱这个交易。它们让 diff 的生产成本，低于项目真正理解并拥有这段改动的成本。

所以，在 agent 参与越来越多的软件工作里，审查会被迫前移。关键问题不会只是：“这个 patch 要不要 merge？”而会变成：“这个项目应该吸收哪些知识、意图和风险？”

代码仍然可能以 pull request 的形式出现。但真正被导入的，已经不只是代码。它是一组关于项目应该变成什么样的主张。

Diff 正在变得太便宜

一个普通 pull request 里藏着很多人的工作。贡献者读了代码库，形成了对 bug 或功能的理解，试过几条路，放弃了其他方案，选了一个设计，写了测试，然后把这些压缩成一个 diff。

Reviewer 看不到全部过程，但可以假设这个过程有成本。一个不小的 patch，通常意味着贡献者至少和这个问题相处过一段时间。

Agent 会打破这个信号。

现在，一个贡献者可以让编程 agent 探索陌生代码库，改很多文件，生成测试，总结改动，并很快打开一个看起来合理的 PR。有时这很有价值。它能把模糊 issue 变成可运行的 patch。它也可能帮 maintainer 看到之前没想到的路径。

但便宜的 patch 会制造审查税。接收方项目仍然要判断：这个问题是否真实，设计是否合适，测试是否证明了正确的事情，改动是否创造了长期维护承诺，以及贡献者的本地语境是否真的对应项目优先级。

这些问题不会因为第一个 patch 变便宜而自动变便宜。

瓶颈不是打字，而是审查

最近几篇研究正在从不同方向逼近同一个问题。

最清楚的框架来自 6 月 25 日一篇关于 knowledge-based pull requests 的论文。它的建议很简单，也有点别扭，但别扭得有价值：不要把外部 agent 生成的 patch 默认当成可合并对象。把外部代码、测试和整理过的 agent 记录当成证据。先把它们转成项目可读的知识包。然后再让项目自己控制的 agent，在可信的仓库环境里重新生成候选代码。

这听起来很重。对于修错别字，确实太重。但对于跨越信任边界的高语境改动，这篇论文切中了关键：先决定知识要不要进入项目，再决定什么代码应该 merge。

这个区分很重要，因为验证能力没有跟上生成能力。The Verification Horizon 在 6 月 29 日更新的版本里指出，编程 agent 的奖励和验证面对的是移动目标。测试、rubric、用户和 agent verifier 都只是人类意图的代理。当生成器变强，固定验证器会饱和，也会被绕过。验证必须和被验证的系统一起演化。

说得直白一点：项目不能把判断外包给“测试通过了”。测试是论据的一部分，不是论据本身。

生态数据也指向同一个方向。一项 6 月 24 日覆盖 11,097 个 GitHub 仓库 的研究发现，在采用 AI 编程 agent 之后，人类贡献者密度下降，新人占比下降 3.7 个百分点，review depth 上升 5.3%。作者把这种模式叫作 augmentation with dilution：agent 不是简单替代人，而是在改变谁参与，以及负担被转移到哪里。

7 月 2 日一项企业案例研究让这个取舍更尖锐。一个 AI-forward 公司在明确的 “2x” 要求下，到 2026 年 4 月，人均 merged PR 吞吐量达到原来的 2.09 倍。但每位 reviewer 的负载也大约翻倍，自动化 review 超过了人工 review，而 merge 和 revert rate 基本保持稳定。

这既不是单纯的胜利，也不是单纯的警告。它是瓶颈迁移。

Agent 可以增加改动数量。它们不会取消“有人必须判断这些改动意味着什么”这件事。

PR 是一次责任转移

不那么好听的机制是：pull request 经常是一种责任转移。

Merge 之前，改动属于贡献者。Merge 之后，改动属于项目。项目要承担 bug report、边界情况、架构漂移、支持承诺和未来重构。

这在 agent 出现前就成立。Agent 只是让它更明显，因为 agent 可以生产工作，却不生产所有权。

外部 agent 可能生成一个 patch，解决某个用户的本地问题。这个 patch 甚至可能是正确的。但接收方项目要问的是另一组问题。

这是通用问题，还是本地绕过？往下都是同一类问题：这个抽象值不值得长期留着，它合不合路线图，坏掉以后谁来回答 issue，未来的贡献者能不能看懂这个分支为什么存在，Agent 又从贡献者的环境里继承了哪些隐藏假设。

这些不是代码风格问题。它们是项目所有权问题。

所以，有用的 artifact 可能会变得不像 diff，而更像一次导入声明：

• 用户需求是什么。
• 有什么证据说明它会反复出现。
• Agent 试过并放弃了哪些方案。
• 哪些测试代表了目标行为。
• 风险、未知和策略边界在哪里。
• 项目如果接受它，就等于同意维护什么。

代码只是这个知识包的一种呈现方式。它不应该是 reviewer 被要求吸收的唯一东西。

反方观点是速度

一个合理反驳是：这可能变成流程表演。

开源项目本来就缺 maintainer 时间。企业软件本来就有太多关卡。如果每个 AI 生成的 PR 都需要知识包、风险 memo 和项目侧重新生成，团队可能会把有用贡献埋在治理流程里。

对于小改动，这个反驳是对的。依赖版本 pin、错别字、漏掉的 import 或明显测试更新，不应该变成仪式。低语境工作的最好 agent 流程，仍然是小 diff、清楚测试和快速 review。

这篇文章的判断适用于语境成本高的地方：架构改动、安全敏感代码、客户特定修复、性能工作、公共 API、数据迁移，以及跨团队平台改动。在这些场景里，危险的地方不只是 agent 写了坏代码。危险在于项目还没吸收改动理由，就已经接受了改动。

正确规则不是“agent PR 需要更多文档”。正确规则是：“审查 artifact 应该匹配所有权风险。”

Maintainer 的工作更重要了

这指向的软件协作未来，和简单的生产力故事不太一样。

如果 agent 让外部 patch 变得充足，maintainer 就不只是代码检查员。他们更像项目知识的边境官。他们决定什么进入，什么需要翻译，什么应该拒绝，什么必须在本地规则下重新实现。

这不酷。但杠杆会在这里。

真正用好 agent 的项目，不一定是 merge 最多 AI 代码的项目。它们会在代码跨过边界之前，先让意图变得清楚。它们会要求贡献者和他们的 agent 带来证据、约束和被放弃的方案，而不只是一个绿色 check。

一个值得追踪的预测是：到 2027 年底，严肃使用 agent 的项目，会越来越少用 PR 数量衡量 review 质量，而更多看吸收质量。多少外部改动变成了项目拥有的意图？多少改动在本地策略下重新生成？多少改动因为项目不想承担责任而被快速拒绝？

如果这听起来比“agent 开 PR，maintainer 点 merge”慢，那是好事。有些速度是假的。它只是把成本推给了未来那个 maintainer：他必须弄清楚，项目到底在什么时候不小心同意拥有了什么。