Copilot 代码审查复盘：更好的工具让智能体更差，指令才是关键
GitHub 把 Copilot 代码审查的专用代码探索工具换成维护更好的共享 CLI 工具（grep/glob/view），预期是干净的升级——结果基准显示审查成本更高、抓到的问题更少。问题不在工具，在指令：按「审查者实际读 PR 的方式」重写工作流指令后，退化翻转为审查成本降低约 20%、质量不变。
基础信息较完整，适合持续跟踪并等待更多验证。
记录
信号正文
GitHub 给 Copilot 代码审查换工具的初衷很合理：原有的专用代码探索工具层（源自 SWE-agent 式仓库导航的设计）虽然能用，但只服务这一个场景；换成驱动 Copilot CLI 的共享 Unix 风格工具（grep、glob、view）应该是次干净的升级。结果基准测试给出了反直觉的答案——审查成本更高，抓到的问题更少。
诊断结论是这次复盘的核心：工具没有问题，指令有问题。旧指令是围绕旧工具层的行为写的，直接搬到新工具上，智能体的探索方式就和「审查一个 PR」这件事错了位。团队按照人类审查者实际读 PR 的方式——以 PR 证据为锚点组织探索——重写了工作流指令，退化翻转为胜利：平均审查成本降低约 20%，审查质量保持不变。
这篇复盘的通用教训对任何智能体团队都成立：构建在智能体框架之上时，你继承的不只是工具，还有工具隐含的工作流假设；当你的场景与工具的设计初衷漂移得足够远，它们会安静地开始拖后腿。工具替换必须连同指令一起重写，且需要回归基准来暴露这类退化——没有基准，这次退化可能根本不会被发现。
为什么是现在
为什么重要
生产级智能体的负面结果复盘比成功案例稀缺得多。「更好的工具让效果更差」直指一个普遍盲区：工具与指令是耦合的整体，替换其一必须重写另一——而且没有回归基准，这类退化会被安静地上线。
背景
技术背景
智能体的行为由「工具能力 × 指令假设」共同决定：工具定义能做什么，指令定义怎么探索。继承自框架的工具带着隐含的工作流设计（这里是 SWE-agent 式仓库导航），当任务从「解决 issue」漂移到「审查 PR」，同一套探索模式就从助力变成开销。以任务的原生证据（PR diff）为锚点重写指令，是把通用工具重新对齐到具体任务的正确杠杆。
关注人群
谁该关注
下一步
学习路径
- 读原文，注意「换工具前后」的基准对比是怎么设计的
- 对照 Shippy 复盘的「确定性工具层」经验，理解工具层设计的两种取舍
- 为自己的智能体产品建立一个最小回归基准，再做下一次工具或提示词变更
关系网络
在技术网络中的位置
当前技术与相邻技术、技能和背景知识的连接，点击节点可继续探索。
延伸思考
后续问题
- 重写后的审查指令是否会开源或沉淀为可复用模式？
- 20% 成本降低在不同模型上是否稳定成立？
- 同样的「工具×指令错位」诊断方法能否用于其他智能体场景？
来源参考