Agent拉取请求无处不在：如何审查它们

您可能已经在不知不觉中批准了一个Agent生成的拉取请求。测试通过了，代码看起来很干净，然后您就合并了。但问题恰恰在于这种轻松批准的态度。

根据2026年1月的一项名为“更多代码，更少重用”的研究，Agent生成的代码每次变更引入的冗余和技术债务比人类编写的代码更多。表面看起来很干净，但债务是悄无声息的。而且，同一项研究发现，审查者实际上更乐于批准这样的代码。

这并不是要放慢速度，而是要有意识地审查。两者之间存在区别。

Agent拉取请求已经饱和了审查带宽

数量已经惊人。GitHub Copilot代码审查已经处理了超过6000万次审查，在不到一年的时间里增长了10倍。GitHub上超过五分之一的代码审查现在涉及Agent。这仅仅是自动审查阶段。拉取请求本身正在以比审查者处理速度更快的速度激增。

传统的流程——请求审查、等待代码所有者、合并——当一位开发者在午餐前就能启动十几个Agent会话时，就崩溃了。吞吐量已经呈指数级增长，而人类的审查能力却没有。差距在扩大。

您将审查Agent拉取请求。问题在于，当您审查时，是否能抓住重点。

谁（或什么）实际编写了这个拉取请求

在查看一行差异之前，您需要了解您正在审查的对象。

编码Agent是一个高效、字面、遵循模式的贡献者，但关于您的事故历史、团队的边缘案例传说或不在存储库中的操作约束，它没有任何上下文。它会生成看起来完整的代码。但那种“看起来完整”的失败模式是危险的。

而您拥有那些上下文。这不是负担，而是实际的工作。审查中无法自动化的部分是判断，而判断需要只有您才有的上下文。

给作者的一个提示

如果您要提交一个Agent生成的拉取请求，请在请求审查之前编辑正文。Agent喜欢冗长，它们描述了那些通过代码本身更容易探索的内容。在差异中标注上下文有帮助的地方。在标记其他人之前，自己先审查一下，不仅是为了检查正确性，更是为了表明您已验证了Agent捕获了您的意图。

当涉及Agent时，审查自己的拉取请求并不是可选的，这是对审查者时间的基本尊重。

现在，回到审查者。拉取请求到达您的队列。作者已经完成了他们的部分。以下是需要注意的事项。

需要注意的危险信号

1. CI游戏

Agent可能会在CI中失败。当他们这样做时，他们有一条明显的路径来让测试通过：删除测试、跳过lint步骤、在测试命令后添加|| true。有些Agent会这样做。

任何削弱CI的变更都是阻塞点。完全停住。在批准任何Agent拉取请求之前，检查：

• 覆盖率阈值是否发生变化？
• 是否有测试被删除、重命名或标记为跳过？
• 工作流是否停止在fork或拉取请求上运行？
• 是否有CI步骤现在被门控在之前没有的条件下？

如果上述任何一项答案为“是”，则在继续之前需要明确的理由。

2. 代码重用盲目性

这是作为审查者可以做的最高ROI的事情。Agent会寻找现有模式，它们会在代码库中找到一个模式并进行复制，通常不去检查是否已经存在一个实现相同功能的实用程序。症状包括：新实用函数与现有函数名称略有不同但功能重复、验证逻辑在多个地方重新实现、从头编写已存在于共享模块中的中间件、以及名称不同但“几乎相同”的帮助函数。

Agent的本地上下文不包括存储库中现有的完整情况。但您有。

对于Agent拉取请求中的每个新帮助器或实用程序，快速搜索一下。如果找到等价物，不要只留下评论，请在合并前要求合并。遗留重复逻辑的代价是Agent会将其视为现有模式并进一步复制。

💡 专业提示：对于超过一定大小的Agent拉取请求，要求为添加新实用程序提供理由。这样可以及早捕获重复问题。

3. 幻觉正确性

明显的幻觉（调用不存在的API、引用超出范围的变量）会在CI中被捕获。但危险的是微妙的：代码编译通过、通过所有测试，但却是错误的。

分页中的差一错误、从未在测试中命中的分支上的缺失权限检查、在Agent从未考虑过的边缘情况下短路验证、仅在规模下出现的竞态条件下的错误行为。

追踪它，而不仅仅是扫描。选择差异中最重要的路径，从输入到每次转换再到输出进行跟踪。检查边界条件（零、最大、空）、对外部值的缺失验证、每个分支的权限检查以及令人惊讶的条件逻辑。

要求一个在变化前行为下失败的测试。如果Agent不能编写一个可以捕获它声称修复的错误的测试，那么修复是不完整的，或者理解是错误的。

4. Agent幽灵

您进行了一次彻底的审查，解释了问题，提供了上下文，建议了方向。然后拉取请求变得安静。或者Agent回应了但完全没抓住要点，在原地打转。您又投入了一轮。仍然没有有用的反馈。

没有结构化计划的大拉取请求与Agent放弃或方向错误高度相关。拉取请求越大、范围越不明确，您就越有可能投入审查时间而一无所获。

在您对一个大Agent拉取请求进行深入审查之前，检查拉取请求历史：它在之前的轮次中是否响应？它是否有清晰的实施计划，还是Agent只是开始编写代码？

如果没有计划，在您写任何评论之前，请求分解。复制粘贴版本：

“这个拉取请求太大了，没有更清晰的实施计划我无法审查。您能否将其分解为更小范围单元，或添加每个部分的作用及结构原因摘要？之后我很乐意审查。”

坚定、简短、不针对个人。这能节省您一个小时。

5. 工作流中的不受信任输入

CI Agent中的提示注入是真实存在且被低估的。模式如下：Agent工作流从拉取请求正文、问题或提交消息中读取内容，该内容被插入到提示中，提示发送给模型，模型输出通过管道传递给shell命令，整个运行具有GITHUB_TOKEN权限。

当您审查任何调用LLM的工作流时，以下是阻塞点：

• 不受信任的用户输入（拉取请求正文、问题正文、提交消息）是否未经消毒就被插入到提示中？
• GITHUB_TOKEN是否具有写范围而它只需要读访问？
• 模型输出是否在未经验证的情况下作为shell命令执行？
• 秘密是否对Agent步骤可访问或打印到日志中？

在合并前要求：工作流YAML中的最小权限（permissions: read-all是合理的默认值），在不受信任内容接触提示之前进行消毒和引用，将“分析”步骤与“执行”步骤分开，并在影响生产的步骤上设置人工批准门，永远不要eval模型输出。

系统化审查流程

时间步骤 | 做什么 --- | --- 1-2分钟 | 扫描并分类：查看文件列表和差异大小。是窄任务（文档、CI、小改动）还是复杂任务（多文件、逻辑、性能、测试）？这个分类决定了您后续的所有审查深度。

2-3分钟 | 首先检查CI变更：在阅读一行应用代码之前，查看任何涉及.github/workflows、测试配置、覆盖率设置或构建脚本的内容。标记任何削弱CI的内容。停止标志检查。

3-5分钟 | 扫描新实用程序：搜索新函数、帮助器或模块。对每个进行快速仓库搜索以检查是否有重复。标记任何重新实现现有功能的代码。

5-8分钟 | 追踪一条关键路径：选择最重要的逻辑变更，端到端追踪：输入→转换→输出。检查边界条件、权限、意外分支。这是您不能跳过的一步。

8-9分钟 | 安全边界：如果此拉取请求涉及任何调用LLM或处理不受信任输入的工作流，请运行上述安全检查清单。

9-10分钟 | 要求证据：对于任何非平凡的逻辑变更，要求一个在变更前行为下失败的测试。对于高风险变更，如果没有回滚计划，请要求一个。

何时要求更小的拉取请求：

• 差异涉及五个以上不相关的文件
• 您无法用一句话描述拉取请求的目的
• Agent没有实施计划或拉取请求正文为空
• CI失败且差异中唯一的变更是测试文件

让Copilot先审查

使用自动审查来承担其擅长的任务：在人类介入之前捕获机械性内容。Copilot代码审查会标记样式不一致、明显的逻辑错误、缺失的错误处理和类型不匹配。它处理低级扫描。这样您就可以腾出时间进行判断工作，这才是您的真正价值所在。

将其视为先决条件，而不是替代品。让Copilot先运行。如果它捕获了明显的问题，让作者在您投入审查时间之前解决。

您可以通过特定于团队的自定义指令来调整：标记任何修改CI阈值的代码、显示新实用程序以进行去重审查、检查每个外部输入是否经过验证。指令越具体，自动审查就越有用。

💡 专业提示：我最近尝试使用Copilot SDK将自己的审查检查清单编码化。为了不必记住在每个拉取请求上运行相同的安全检查，我构建了一个工作流，它获取我的个人检查清单（管理端点上的身份验证、测试实际运行、安全的环境变量处理）并自动针对差异运行。如果发现关键问题，它会阻止合并。

判断是瓶颈，但这没关系

代码的表面积正在增长。拉取请求数量正在增长。您花在扫描样板上的时间应该减少。

但不会减少的是您携带的上下文。您对系统的了解是任何地方都没有写下来的。这就是使您的审查有价值的原因，也是无法自动化的部分。

三个要点：

• 任何CI削弱都是硬性停止。
• 让Agent先扫描。您追踪关键路径。
• 对于复杂的Agent拉取请求，默认使用危险信号检查清单。

阅读文档 >