给 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

只看最终答案，很难判断一次升级为什么变差。答案可能碰巧正确，过程却绕了远路；也可能成本下降，只因 Agent 少读了关键文件。

调用轨迹能把这类差异摊开。GitHub 的内部基准记录了工具调用、返回内容、错误位置和搜索范围。工程师因此能判断 Agent 是先收窄还是先泛读，以及一次失败搜索有没有扩散成浏览循环。

Vercel 在 7 月 10 日为 Traces 增加了 Tree 和 Waterfall 视图。Tree 按父子关系展示 span，并把耗时较长的项排在前面；Waterfall 把所有 span 放到同一条时间轴上，显示并行执行和时间损失的位置（来源：Vercel Changelog）。

这项更新与 GitHub 的实验没有直接因果关系，却指向同一个工程动作：给 Agent 加工具前，先保存旧版本的轨迹基线。至少记录搜索次数、读取量、失败重试和最终质量。升级后逐项比较，团队才能知道成本花在了证据上，还是花在了闲逛上。

把“会用工具”写成可验证流程

一套可落地的改造可以分成四步。

第一步，写清任务锚点。代码审查从 diff 开始，客服处理从工单开始，数据分析从指标异常开始。Agent 每次扩展搜索前，都要说明新动作与锚点的关系。

第二步，给工具明确分工。廉价工具负责发现候选项，昂贵工具只读取已确认的范围。确定性操作交给代码，语义判断留给模型。

第三步，设置停止条件。证据足以支持或否定当前假设时就结束；搜索连续失败时回到锚点，避免把一个拼写错误放大成全仓库漫游。

第四步，用岗位基准验收。美团在一个超过 31 万行、90% 以上代码由 AI 辅助编写的系统中，把团队工程规范转成 AI Rule 和 Skill，并引入 Pre-PR 自查。AI 先处理规范、异常和一致性问题，工程师把注意力留给业务语义与方案符合度（来源：美团技术团队）。

基准不能只问“答案对不对”。还要检查 Agent 读了多少无关内容、遇错后如何恢复，以及何时决定停止。否则，团队可能用更好的工具换来更贵的错误。

别把工具箱当成生产力

给 Agent 接上更多 MCP、搜索接口和数据库很容易。每多一个工具，它就多一条可能走错的路。

GitHub 这次回归最有价值的地方，是把“模型变笨了”拆成了可以观察的工程行为：搜索过宽、读取过早、停止过晚。修复也没有依赖更强模型，只是让工具围绕审查任务重新排队。

下一次升级 Agent，先别数它多会了几招。看它是否用更少的无关动作，拿到了足够的证据。

工具箱越大，工作流越该克制。