Agent pull request 无处不在，如何 review 它们

你很可能已经在不知情的情况下批准过一次。测试通过了。代码很干净。你 merge 了它。但它是 agent 生成的，而这种“容易批准”恰恰是问题所在。2026 年 1 月的一项研究《More Code, Less Reuse》发现，与人类编写的代码相比，agent 生成的代码在每次变更中引入了更多冗余和更多技术债。表面看起来很干净。债务却很安静。而根据同一项研究，reviewer 实际上会更愿意批准它。这不是要你放慢速度，而是要你有意识地处理。两者不同。

Agent pull request 已经占满 review 带宽。规模已经很惊人。GitHub Copilot code review 已处理超过 6000 万次 review，不到一年增长了 10 倍。现在 GitHub 上超过五分之一的 code review 都涉及 agent。这还只是自动化 review 这一轮。pull request 本身的增长速度已经超过 reviewer 的处理能力。传统流程——请求 review、等待 code owner、merge——在一个 developer 午饭前就能启动十几个 agent session 时会失效。吞吐量已经指数级扩张。人类 review 能力没有。差距正在扩大。你会 review agent pull request。问题是，当你 review 时，能否抓住真正重要的东西。

到底是谁（或什么）写了这个 pull request？在你看任何一行 diff 之前，需要先有一个关于 review 对象的模型。coding agent 是一个高产、字面化、遵循模式的贡献者，但它对你的事故历史、团队积累的 edge case 经验，或那些不在 repository 中的运营约束没有任何上下文。它会生成看起来完整的代码。但“看起来完整”这种失败模式很危险。掌握上下文的人是你。这不是负担。这就是这项工作的实质。review 中无法自动化的部分是判断，而判断需要只有你才有的上下文。

给作者的一点说明：如果你要提交 agent 生成的 pull request，请在请求 review 前编辑正文。Agent 喜欢冗长。它们会描述那些本该通过代码本身更好理解的内容。在 diff 中对有助于理解上下文的地方加注释。并且在 tag 其他人之前先自己 review 一遍，不只是检查正确性，也是在表明你已经验证 agent 捕捉到了你的意图。当 agent 参与时，review 自己的 pull request 不是可选项。这是对 reviewer 时间的基本尊重。

现在回到 reviewer。pull request 进入了你的队列。作者已经做了该做的事。下面是需要注意的地方。

需要留意的危险信号 1. CI gaming。Agent 会让 CI 失败。当它们失败时，有一条显而易见的路径可以让测试通过：删除测试、跳过 lint 步骤、在测试命令后加上 || true。有些 agent 会这么做。任何削弱 CI 的变更都是 blocker。没有例外。在批准任何 agent pull request 之前，检查：coverage 阈值是否改变？是否有测试被删除、重命名或标记为 skipped？workflow 是否停止在 fork 或 pull request 上运行？是否有 CI 步骤现在被放在了以前不存在的条件之后？只要其中任何一项答案是“是”，你就需要在继续之前看到明确理由。

2. Code reuse blindness。这是 reviewer 最值得做的高 ROI 工作。Agent 会寻找先例。它们会在 codebase 中找到一个模式并复制它，通常不会检查其他地方是否已经存在做同样事情的 utility。症状包括：新增 utility function 与已有函数重复，只是名字略有不同；validation 逻辑在多个地方重新实现；middleware 从零编写，但它其实已经存在于 shared module 中；helper “几乎一样”但名字不同。Agent 的局部上下文不包含整个 repository 中已有内容的全貌。你有。对于 agent pull request 中的每个新 helper 或 utility，做一次快速搜索。如果你找到等价实现，不要只留 comment。要求在 merge 前合并。保留重复逻辑的代价是，后续 agent 会把它当作先例，并进一步复制。💡 Pro tip：对于超过一定大小阈值的 agent pull request，要求为新增 utility 提供理由。这可以更早发现重复问题。

3. Hallucinated correctness。明显的 hallucination（调用不存在的 API、引用作用域外变量）会被 CI 抓住。危险的是更微妙的情况：代码能编译、通过所有测试，但行为是错的。pagination 中的 off-by-one 错误。测试从未覆盖的分支上缺少权限检查。validation 在 agent 从未考虑过的 edge case 下短路。只在规模上才暴露的 race condition 下行为错误。要 trace，而不是只 scan。选择 diff 中最关键的路径。从输入开始，跟踪每一次 transform，直到输出。检查边界条件（zero、max、empty）、外部值缺少 validation、每个分支上的权限检查，以及令人意外的 conditional logic。要求新增一个会在变更前行为下失败的测试。如果 agent 不能写出一个本应捕获它声称修复的 bug 的测试，那么这个修复是不完整的，或者理解是错误的。

4. Agentic ghosting。你留下了详尽 review。你解释了问题、提供了上下文、建议了方向。pull request 沉默了。或者 agent 回复了，但完全没抓住重点，并且原地打转。你又投入一轮。仍然没有有用结果。没有结构化计划的大型 pull request 与 agent 放弃或偏离目标高度相关。pull request 越大、范围越不清晰，你越可能把 review 时间投入到一个没有结果的东西里。在你对大型 agent pull request 投入深度 review 之前，检查 pull request 历史。它在之前几轮中响应是否有效？它是否有清晰的 implementation plan，还是 agent 只是开始写代码？如果没有计划，在你写任何 comment 之前，先要求拆分。可直接复制的版本：“这个 pull request 太大了，在没有更清晰的 implementation plan 的情况下我无法 review。你能把它拆成更小且范围明确的单元，或者补充一个 summary，说明每一部分做什么，以及为什么这样组织吗？完成后我很乐意 review。”坚定、简短、不针对个人。而且能省你一个小时。

5. Workflow 中的不可信输入。CI agent 中的 prompt injection 是真实存在且被低估的问题。模式如下：一个 agent workflow 读取 pull request body、issue 或 commit message 中的内容。该内容被插入到 prompt 中。prompt 发送给 model。model 输出被管道传给 shell command。整个流程以 GITHUB_TOKEN 权限运行。当你 review 任何调用 LLM 的 workflow 时，以下都是 blocker：不可信用户输入、pull request body、issue body、commit message 是否未经 sanitization 就被插入 prompt？GITHUB_TOKEN 在只需要读权限时是否被赋予了写权限？model 输出是否未经 validation 就作为 shell command 执行？secret 是否可被 agent step 访问，或被打印到 log 中？merge 前需要要求：workflow YAML 中使用最小权限（permissions: read-all 是一个合理默认值）；在不可信内容接触 prompt 前进行 sanitize 和 quote；将“analysis”步骤与“execution”步骤分离，任何触及 production 的操作都需要 human approval gate；永远不要 eval model output。

时间   步骤   要做什么   1–2 min  Scan 并分类   查看文件列表和 diff 大小。是范围很窄的任务（docs、CI、小改动）还是复杂任务（多文件、逻辑、性能、测试）？这个分类决定后续所有 review 的深度。  2–3 min  先检查 CI 变更   在阅读任何一行 app code 之前，先看所有涉及 .github/workflows、测试配置、coverage 设置或 build script 的内容。标记任何削弱 CI 的变更。这是 stop sign 检查。  3–5 min  扫描新增 utility   查找新的 function、helper 或 module。对每一个做一次快速 repo 搜索，检查是否重复。标记任何重新发明已有功能的内容。  5–8 min  Trace 一条关键路径   选择最重要的逻辑变更。端到端 trace：input → transforms → output。检查边界条件、权限、意外分支。这一步不能跳过。  8–9 min  安全边界   如果这个 pull request 触及任何调用 LLM 或处理不可信输入的 workflow，请按上面的 security checklist 过一遍。  9–10 min  要求证据   对任何非平凡逻辑变更，要求提供一个会在变更前行为下失败的测试。高风险变更没有 rollback plan？要求补上。 

什么时候要求更小的 pull request：diff 触及超过五个互不相关的文件；你无法用一句话描述这个 pull request 的目的；agent 没有 implementation plan，或 pull request body 为空；CI 失败，而 diff 中唯一的变更是测试文件。

先让 Copilot review。把自动化 review 用在它擅长的地方：在人类投入时间之前抓住机械性问题。Copilot code review 会标记 style 不一致、明显逻辑错误、缺失 error handling 和 type mismatch。它负责低层扫描。这让你可以把精力留给判断工作，而这才是你的时间真正有价值的地方。把它当作前置条件，而不是替代品。先让 Copilot 运行。如果它抓到明显问题，让作者先处理，再投入你的 review 时间。你可以通过团队专用的 custom instructions 来调优：标记任何修改 CI 阈值的内容；暴露新的 utility 以便进行 deduplication review；检查每个外部输入都经过 validation。instructions 越具体，自动化这一轮越有用。💡 Pro tip：我最近尝试用 Copilot SDK 把自己的 review checklist 代码化。与其记得在每个 pull request 上重复执行同样的安全检查，不如构建一个 workflow，接收我的个人 checklist——admin endpoint 上的 auth、测试是否确实运行、安全的 env variable 处理——并自动对 diff 运行。如果发现 critical issue，它会阻止 merge。

判断是瓶颈，这没关系。代码表面积在增长。pull request 数量在增长。你花在扫描 boilerplate 上的时间应该减少。但不会减少的是你掌握的上下文。那些你知道、但系统中没有写在任何地方的东西。这正是你的 review 有价值的原因，也是不会被自动化的部分。

三个要点：任何削弱 CI 的变更都必须硬停。先让 agent scan。你来 trace 关键路径。把危险信号 checklist 作为复杂 agent pull request 的默认流程。阅读文档 > 文章《Agent pull requests are everywhere. Here’s how to review them.》最先发表于 The GitHub Blog。