更好的工具为何让 Copilot 代码评审变差：从工作流重写到成本降低约20%-未完纪

给智能体更好的工具，它理应把工作做得更好。直觉至少是这样。

当你发起拉取请求时，Copilot 代码评审会读取差异（diff），并探索周围的代码，以便在问题上线之前发现真正重要的问题。过去，它使用自己的代码探索工具。因此，当我们换上维护得更好、与 Copilot CLI 共用的 grep、glob 和 view 时，本以为这会是一次顺利的升级。

但基准测试的结果恰恰相反：评审成本更高，发现的问题却更少。

问题不在工具，而在指令。按照评审者实际阅读拉取请求的方式重写指令后，这次回归变成了收益：平均评审成本降低约20%，同时保持相同的评审质量。

下面讲述的是，我们如何调整工具周围的工作流并解决这个问题。

同样的工具，错误的习惯

如果你基于智能体框架构建过产品，多半也继承了框架的工具。它们能用，你就继续用，直到某一天，你的用途与它们最初的设计目标相差太远，工具开始悄悄妨碍工作。我们正处于这种情况。尝试共用 CLI 工具之前，Copilot 代码评审使用自己的代码探索工具。这层工具受早期智能体系统启发，借鉴了 SWE-agent 式仓库导航和 GitHub Copilot Autofix 的思路：列目录、搜索文件、搜索目录以及读代码。这些工具能工作，但专属于 Copilot 代码评审，设计依据也是当时模型的行为。早期的智能体编码模型调用工具较少，自动获取必要上下文的能力也较弱。因此，在少数几次工具调用中包含所有相关信息，就格外重要。

与此同时，Copilot CLI 的运行框架提供了一组受 Unix 启发的共用代码探索工具：grep、glob 和 view。越来越多的 Copilot 智能体产品也使用这个框架，包括 GitHub Copilot 云端智能体，所以对框架的改进可以让不止一个产品受益。我们想尽可能清理并共享基础设施，于是尝试在 Copilot 代码评审中使用 CLI 框架的工具。目标是减少重复实现，让代码探索工具有一个统一的改进位置，并更容易把改进推广到其他 Copilot 产品。

从纸面上看，迁移很简单：

原 Copilot 代码评审工具	GitHub Copilot CLI 工具	用途
list_dir	glob	打开代码之前，发现可能相关的文件和目录。
search_file 和 search_dir	grep	搜索匹配文本、符号或调用位置。
read_code	view	已知文件路径或行范围后，读取相关内容。

原有评审工具并不是简单的薄封装。搜索目录或读取某段代码时，它们不仅能返回命中或请求的行，还能附带周围的代码上下文。这增加了 token 成本，但也符合早期模型的需要：模型往往受益于自动包含的相邻上下文。

起初，我们希望只需把一套工具换成另一套。但离线基准测试表明，共用工具让评审智能体的效率和效果都变差了：平均成本上升，有用评论的数量下降。

执行轨迹揭示了仓库浏览循环

内部 Copilot 代码评审基准测试之所以有用，是因为它们展示的不只是最终分数，还包括智能体的行动路径：调用了哪些工具、返回多少输出、哪里出现错误，以及搜索是在向证据收敛，还是不断扩大。

第一次在离线基准测试中使用共用 CLI 工具时，智能体往往像是在浏览一个仓库，而不是调查某个拉取请求。它会广泛搜索、猜测可能的路径、大范围阅读、发现更多可搜索内容，然后把这些额外上下文一路带到后续步骤。

图1：调整之前——简化展示观察到的通用行为：扩大搜索、猜测路径、不断累积上下文。

这种模式不难理解。任务是“理解这个仓库”时，广泛探索确实有用。但评审者通常不会这样检查拉取请求。

我评审拉取请求时，会从 diff 出发，提出有针对性的问题：

这个函数在哪里被调用？
这个配置项在别的地方也使用了吗？
有没有采用相同模式的测试或辅助函数？
能够解释该行为的最小相邻代码范围是什么？

在明确自己要寻找什么之前，我不想打开仓库的大片区域。我想获取回答问题所需的最少上下文，避免不相关代码让评审负担过重。

这很重要，因为每个工具结果都会成为智能体工作上下文的一部分。额外文件内容可能持续进入后续推理，增加成本，有时还会让评审失去焦点。工具结果不是看完就扔的打印纸；对智能体而言，它是留在上下文窗口里的额外 token。

执行轨迹让这种差异变得清晰。共用工具本身没有问题；指令却在培养错误的习惯，使高效、有效的评审变得困难。

工具能够工作，但指令针对 Copilot CLI 的用途调优，隐含了不适合评审的工作流：智能体像通用编码助手一样使用 grep、glob、view，而不是像评审者。编码助手在修改前，可能需要摸清整片代码区域，确保不破坏其他角落。评审者通常从 diff 开始，判断变更是否引入问题，再寻找确认或排除问题所需的最小相邻证据。

Copilot CLI 或云端智能体采用的通用编码助手工具指令，适合交互式助手：开发者可能要求它理解仓库、规划变更、编辑文件，并持续多轮工作。

Copilot 代码评审的职责更窄：从拉取请求的 diff 出发，收集足够的周边证据，判断变更是否引入真实问题，并避免加载与评审问题无关的上下文。

因此，我们不能只把旧工具替换为 CLI 工具，而不做额外的提示词工作。问题变成了：怎样设计工具指令，让这些共用工具在代码评审场景中发挥作用？

按照评审者的工作流重写工具指令

后续迭代把指引明确限定为代码评审。我们希望 Copilot 代码评审遵循这样的流程：

从 diff 出发，形成具体的评审问题。
路径不确定时使用 glob，用 grep 查找候选文件、符号及调用位置。
读文件前，批量执行成本较低的发现操作。
只有知道需要哪个文件或行范围时，才使用 view。
批量读取聚焦的代码段，避免搜索一次、读取一次地反复交替。

用极度简化的表述，我们写入指令的行为是：

通用姿态：使用现有工具检查可能相关的仓库上下文。

评审导向的指引：从 diff 开始。先用 grep 和 glob 缩小范围，再用 view 读取精确证据。如果 grep 找不到相关上下文，改用更简单、正确转义的搜索重试；路径错误时转向 glob，不要猜测相邻路径。

例如，diff 修改了一个决定是否允许某项操作的授权辅助函数。评审问题不该是“展示调用此函数的所有文件的全部内容”，而可以更具体：“有没有请求处理调用方依赖它的旧行为？”

预期路径很短：

start from the helper changed in the diff 
grep for callers of that helper 
glob for likely route, handler, or controller files 
view the most relevant caller ranges 
decide whether any caller changes the risk

指引也改变了搜索失败后的恢复方式。输入让 grep 失败时，更好的下一步是一次更简单、修正后的搜索；路径错误时，更好的下一步是 glob，而不是猜测附近路径，再读取恰好存在的文件。这让智能体不容易把一个小工具错误发展成更大的探索循环。

图2：调整之后——提示词引导的评审行为：以 diff 为锚点，用 grep 和 glob 缩小范围，再用 view 读取聚焦的行范围。

措辞变化很小，效果变化却很大。智能体的节奏从“浏览、阅读、继续搜索”，变为“提问、收敛、阅读、判断”。

基准测试让我们调试行为，而不只是分数

共用运行框架提供工具，内部 Copilot 代码评审基准测试提供反馈循环。

我们可以运行相同的评审示例、比较工具轨迹、更新指令，再次运行。这让我们能问具体的问题：

智能体是先缩小范围，还是先大范围阅读？
是否批量执行了独立搜索？
是否只有在有理由时才调用 view？
工具指令的修改减少了错误，还是仅把错误转移到别处？
执行轨迹是否始终聚焦于 diff 相关证据？
评审是否保持了我们关心的质量指标？

最有用的信号不是“指令变好了”，而是更具体的行为变化：工具调用次数相近，但更多调用用于寻找相关证据，而不是反复扩大搜索。

这把产品层面的结果与可理解的工程行为联系起来。无需猜测分数变化的原因，我们可以直接检查产生分数的工作流。

结果：平均评审成本降低约20%

在生产环境中，相比对照组，调优后的行为带来了约20%的平均评审成本下降，并且没有出现足以阻止上线的质量信号。

成本下降并非来自工具本身，而是来自工具周围的工作流。共用代码探索工具、代码评审专用工具指令和内部基准测试，让智能体行为变得足够可见，进而能够调优。

构建智能体产品时，这个视角很重要。我们很容易把工具当作实现细节：换一个工具，再比较最终答案。但对智能体而言，工具界面是产品体验的一部分。它改变智能体注意什么、怎样搜索、携带多少上下文，以及何时认为证据足够。

工具描述和系统指令更接近 API 文档。含糊的 API 文档会让开发者困惑，导致低效或错误的决策；含糊的工具提示也会对大语言模型产生类似影响。小小的措辞变化，会通过改变智能体注意力的分配，影响成本、质量和调查过程。

同样的工具，不同的任务

我们还尝试把同样的聚焦式工具指令用于 CLI，但没有获得同样的收益。这是一个有用的反例，也是理解这一经验时的重要边界。

Copilot 代码评审围绕 diff 和评审问题展开。Copilot CLI 则处理更广泛的交互式编码任务，探索本身可能就是工作的一部分。它未必有一个唯一的 diff 锚点，用户可能在多轮对话中改变方向，一开始也未必能确定需要什么上下文。同一组 grep、glob、view 可以支撑两个产品，但工具周围的工作流必须适配产品。

启示是：当指令和基准测试与任务匹配时，共用工具才能有效扩展。

你可以亲自体验 GitHub Copilot 代码评审。