给 Agent 更好的工具，为什么反而更差？

2026 年 7 月 10 日，GitHub 公开了 Copilot Code Review 的一次失败升级。

团队把专用代码浏览工具换成 Copilot CLI 共用的 grep、glob 和 view。新工具维护更好，也能被多个 Copilot 产品复用。离线基准却显示，平均审查成本上升，抓到的有效问题变少。

团队重写工具指令后，生产环境的平均审查成本约下降 20%，审查质量保持在可发布水平（来源：GitHub Blog）。

工具升级只扩大能力边界，工作流才决定 Agent 把能力花在哪里。

更好的工具，引出了更差的浏览习惯

GitHub 从调用轨迹里找到了回归原因。

Copilot Code Review 收到一份 PR 后，需要判断改动是否引入缺陷。换上共享工具后，它开始按通用编码助手的方式行动：扩大搜索范围、猜测可能相关的路径、读取大段文件，再沿着新线索继续搜索。

这个姿态适合“理解整个仓库”，却不适合审查一份明确的 diff。每次工具返回的内容都会进入工作上下文。无关代码越积越多，后续推理的成本越高，注意力也更容易偏离改动本身。

GitHub 没有撤回工具迁移。团队改了调用顺序：从 diff 提出具体审查问题，先用 grep 和 glob 找候选位置，再用 view 读取能回答问题的最小代码范围。搜索失败时简化查询；路径不对时改用 glob，不再连续猜目录。

调整后的节奏可以压成四个动作：提问、收窄、取证、判断。Agent 仍然调用相近数量的工具，但更多调用落在相关证据上（来源：GitHub Blog）。

这里有个容易忽略的坑：团队通常会评估工具能否搜索、能否读文件，却很少评估 Agent 会以什么顺序调用它们。对 Agent 来说，工具说明更像运行时接口文档。描述里的一个模糊动词，可能变成几十次昂贵的探索。

通用工具可以共享，任务姿态不能复制

同一组工具服务不同产品，不代表它们该共享同一套使用说明。

Copilot CLI 面对开放式任务。用户可能让它理解仓库、制定方案、修改代码，并在多轮对话中改变方向。广泛探索有时就是工作的一部分。

代码审查有清晰锚点：一份 diff 和一个判断问题。审查者要确认改动是否制造风险，只需要足以支持结论的附近证据。GitHub 也尝试把同类的聚焦指令用于 CLI，但没有得到相同收益。这组反例划清了边界：有效的工具指令必须贴合岗位。

阿里 Open Code Review 的公开实践给出了另一个样本。项目方用 50 个开源仓库、200 个真实 PR 和 10 种语言构建评测集，由 80 多位工程师交叉标注。在这套基准中，Open Code Review 的最优 F1 为 25.10%，Claude Code 的最优 F1 为 14.13%（来源：阿里技术）。

这组数据来自项目方，不能当作独立第三方排名。它仍然展示了一种值得借鉴的工程分工：文件筛选和规则匹配交给确定性代码，Agent 负责需要语义判断的上下文召回。模型不用在每一步都“自由发挥”，评审行为会更稳定。

专业 Agent 的优势，常常来自更窄的决策空间和更清楚的停止条件。

先看轨迹，再改 Prompt