我现在越来越不相信“这个编码代理看起来还不错”这种判断了。因为它通常只意味着两件事：要么演示做得顺，要么你刚好让它撞上了一个适合发挥的样例。真正进入工程环境之后，问题不是它能不能偶尔写出一段对的代码，而是它在重复任务里能不能稳定地走对流程、少犯同一类错、让审阅成本真的下降。

OpenAI 在 2026 年初公开的《Testing Agent Skills Systematically with Evals》很值得开发者重视。它的价值不是再告诉你“要做评测”，而是把评测粒度往下压了一层：不要只评模型输出，要评技能本身。这个转向我很认同，因为编码代理真正可维护的部分，往往不是模型参数，而是你给它封装出来的工作流、skill、资源文件和执行约束。

为什么“看起来不错”很危险

很多团队测编码代理，做法其实很像试玩：给它一个任务，看它能不能改对。这个方法的问题很明显。你看到的是一次结果，看不到的是：

• 它是不是走了不该走的路径；
• 它是不是读了太多无关文件；
• 它是不是用了成本过高的工具组合；
• 它这次成功只是碰巧，还是流程本身已经稳定。

编码代理最容易制造的一种错觉，就是“最后 diff 看上去没问题”。但真实开发里，最终结果只是成本的一部分。另一个更大的成本，是为了得到这份结果，系统到底绕了多少弯、制造了多少噪音、留下了多少下次还会复发的不确定性。

为什么我更看重技能级评测

因为技能级评测更接近真实维护对象。模型升级通常不是你能控制的，但技能、流程和 harness 是你自己的资产。只要你把高频任务抽成 skill，真正该问的问题就变成了：

• 这个 skill 在同类任务上成功率多高；
• 失败时最常见的原因是什么；
• 每次运行平均要读多少文件、调多少工具、花多少轮；
• 升级 skill 之后，是变稳了，还是只是变复杂了。

这类问题一旦开始被量化，你对编码代理的判断就会从“主观印象”转向“工程资产质量”。这才是我觉得评测真正有价值的地方。

skill: fix-failing-tests
dataset:
  - case: missing import after refactor
  - case: flaky assertion under retry path
  - case: wrong fixture scope
metrics:
  - task_success
  - files_touched
  - tool_calls
  - reviewer_edits_after_agent
  - rerun_success

上面这个结构不复杂，但它已经足够把评测从“它会不会修 bug”变成“它是怎么修 bug 的”。

真正该测的，不只是正确率

很多人一谈评测就想到 pass rate。我觉得这不够。对编码代理来说，至少还有三类指标经常被低估。

• 路径效率：是不是总要读半个仓库才开始动手；
• 审阅成本：人类要花多少时间才能确认这次改动可信；
• 回归稳定性：同一类任务下次再来，会不会犯回同样的错误。

我尤其看重“reviewer_edits_after_agent”这类指标。因为很多代理并不是完全做错，而是做得差一点点，最后还要人花很多时间收尾。这个成本如果不算进去，很容易高估代理的真实价值。

为什么这件事对个人开发者也重要

有些人会觉得，评测是大团队才需要的。我的判断正好相反。个人开发者更该早一点做最小评测，因为你没有多余时间反复踩同一个坑。只要某个任务你一周会交给代理做 3 次以上，它就值得被记录和比较。

你不需要上来就做完整评测平台。一个 CSV、一个小脚本、十几个真实 case，就足够暴露很多问题。最重要的是别只记“成功了几次”，而要记“失败集中在什么模式”“哪种资源文件最有帮助”“哪种提示改动只是增加 token，没有增加稳定性”。

被夸大的地方也要看到

当然，我也不想把评测说成银弹。评测同样有代价：

• 数据集很容易过拟合你当前的任务习惯；
• 一些指标好看，不代表在新场景下还成立；
• 写 graders 和维护 case 本身也要时间；
• 如果任务边界本来就不清楚，评测会先暴露产品定义问题。

但这恰恰是它值得做的原因。评测不是为了证明系统很好，而是为了尽早让你看到它到底哪里不稳。

如果半天时间只能做一件事

我会选一个最常见的技能，比如“修测试失败”或者“补最小回归测试”，收集 10 个真实 case，固定 skill 说明和资源文件，连续跑两轮。然后只看三件事：成功率、人工收尾时间、重复错误是否下降。

只要这三项开始有记录，你就已经比大多数“感觉它挺好用”的使用方式更接近生产思维了。

我的判断

编码代理接下来真正的护城河，不会只是模型更强，而是有没有把高频任务沉淀成可测、可改、可迭代的技能资产。技能级评测不会让系统自动变好，但它会让你知道哪里值得改、哪里只是幻觉。对个人开发者和小团队来说，我会把这件事列为现在就该投入的工程习惯。别再满足于“演示跑通了”，真正值钱的是“同类任务下周还能稳稳跑通”。

参考来源类型：OpenAI Developers 官方博客与 Cookbook（Testing Agent Skills Systematically with Evals、Agents/Evals 相关 Cookbook）。