原文参考：Robert Xu, “Evaluating Skills”。本文为原创解读，不是翻译。

真正成熟的 Eval Harness，不会只盯着答案

今天做 agent 的团队，几乎没有不谈 eval 的。每个人都知道评测重要，几乎每个产品路线图里也都写着 evaluation、benchmark、judge、trace、dataset、offline/online loop 这些词。可一旦真的落到执行层，你很快就会发现一个有点尴尬的事实：很多所谓 eval harness，实际上只是”自动打分外壳”，并没有真正进入 agent 系统的黑箱内部。

它们确实能告诉你一些东西：成功率是多少、哪组 prompt 更好、哪个版本分数更高、哪个模型当前领先。

但它们最常缺少的恰恰是工程团队最需要的东西：agent 到底有没有调用正确能力、它成功是因为 skill 真起作用了还是碰巧绕过去了、它失败是不会没用误用还是环境出了问题、它为什么这次成功下次又不成功、这套评测究竟在测模型测 workflow 测 skill 还是测环境噪音。

LangChain 那篇《Evaluating Skills》之所以值得认真读，不是因为它提供了一套非常复杂的评测理论，而是因为它抓住了一个非常关键、非常现实的问题：一旦 agent 的能力来自动态加载的 skills、运行时环境、执行轨迹与工具编排，那么只看最终答案，几乎一定会误判系统。

在我看来，这篇文章真正推动的不是”如何评 skill”这么窄的问题，而是一个更大的转向：agent 的评测对象，已经不再只是输出，而是一个完整的执行系统。

一、为什么 output-only eval 正在快速失效

过去评模型，输出导向几乎是天然成立的。原因很简单：传统模型任务很多本来就是输入-输出映射。给一段文本做摘要、给一个问题答答案、给一句话做翻译、给一张图做分类。

这时候只看结果当然是合理的。因为过程并不是系统外显价值的一部分，过程本身也很难被稳定观察。

但 agent 不一样。agent 不是只”生成一个结果”，它是在环境里行动：读文件、调工具、触发技能、写脚本、执行命令、做重试、选择路径、在若干阶段里做状态转换。

所以，agent 的结果并不只是”最后一句答案”，而是它通过怎样一条执行路径，把能力组织成了最终结果。

也正因为如此，output-only eval 很快会遇到几个根本问题。

1. 相同结果，可能来自完全不同的系统行为

一个任务完成了，并不意味着 skill 有效。它可能是 agent 根本没用上这个 skill、误用了别的 skill 但凑巧也完成了、任务太简单 skill 是否存在都没差、环境里有隐含线索让 agent 绕开了关键能力。

如果你只看 pass/fail，就会把这些情况全部折叠成”完成”。

2. 失败也可能不是 skill 失败

一个任务没完成，也不一定说明 skill 设计差。它也可能是没被正确检索出来、skill 名称描述或触发条件设计不对、环境污染导致 agent 走偏、trace 里出现中途失败但最终又被别的噪音掩盖、任务本身判分方式不合理。

output-only eval 把这些完全不同的失败原因压成一个红叉。工程上几乎没有行动意义。

3. 团队会被”便宜的指标”绑架

最危险的是，output-only eval 很符合组织惰性。因为它简单、好看、容易出 dashboard、容易汇报，也最容易让管理者满意。

但它便宜，不代表它对。

我越来越觉得，output-only eval 之所以流行，不是因为它足够好，而是因为它最省事。问题在于，一旦团队真的拿它指导优化，就很容易掉进一种非常昂贵的错觉：分数在变，系统却没有真正变清楚。

二、skill evaluation 为什么是理解 agent eval 的最好入口之一

《Evaluating Skills》这篇文章的价值，就在于它选了一个特别好的切口——skills。

为什么 skill 是一个好切口？因为它天然会逼你正视 agent eval 的复杂性。

一个 skill 不是孤零零的一段提示词，它的生命周期涉及完整的能力链：从触发机制——能否被正确召回、在什么时机被激活；到理解过程——内容是否被 agent 准确解读；再到执行效果——是否真正改变了行为轨迹、是否让 agent 变得更高效或更稳定；最后还要考虑冲突问题——与其他 skills 的兼容性如何。

换句话说，测 skill，实际上是在测：

一种能力注入方式，是否在真实 agent 环境里，以正确方式被触发、被理解、被执行，并真正改变任务结果。

三、clean sandbox 不是工程洁癖，而是评测可信度的前提

文章特别强调 clean sandbox，这一点我非常认同，而且我觉得它的重要性还可以再往上提一级。

因为 agent eval 和很多传统 benchmark 最大的不同在于：环境是实打实的实验变量。

同样的 agent、同样的 skill、同样的任务，只要环境里有一点点残留差异，就可能跑出完全不同的结果。这些差异包括但不限于：目录里残留了上次运行产物、本地缓存让依赖安装绕过某些步骤、文件系统状态不一致、工具可见性不同、某些默认配置已经被上轮修改过、hidden fixture 让 agent 少走了几步。

这些东西在人类开发里也会带来问题，但对 agent 来说影响更大。因为 agent 很容易对环境中的偶然线索过度依赖，一旦这些偶然线索变了，结果就不稳定。

所以一个靠谱的 eval harness，至少应该保证：初始状态可重建、依赖环境可控、输入工件可重复、产出路径可检查、执行轨迹可回放。

如果这些条件不满足，那么所谓”对比不同版本 agent”本质上就是在不同泥地上跑步，然后假装比较的是鞋子。

四、artifact-based scoring：从”看起来做对了”到”系统真的产出了可验证结果”

这篇文章里我最想强推给工程团队采纳的一点，就是 artifact-based scoring。

为什么它这么关键？因为 agent 任务一旦稍微开放一点，传统”参考答案比对”会迅速失效。

例如一个 coding task，正确结果不一定是某一段固定文本，它可能是某个文件被创建、某个测试通过、某个 schema 满足约束、某个 evaluator 被写出来、某个数据集被正确上传、某段脚本确实能执行。

在这些场景里，最可靠的评分方式不是”像不像参考答案”，而是”有没有产出可验证工件”。

因为它天然契合 agent 的真实工作形态：agent 不是只给一句答复，它会留下代码、文件、配置、日志、测试状态和结构化输出。评测也因此从”主观判断输出质量”转向”检查外部事实是否成立”。

五、invocation、trace 与 failure taxonomy，才是 agent eval 真正开始成熟的地方

文章提到的 invocation 问题，在我看来是所有 skill eval 里最容易被低估的一层。

因为很多团队天然只盯最终任务成功率，却忽略了一个更关键的问题：这个成功到底是不是 skill 带来的。

至少有三种经典误判：success without invocation、invocation without contribution、invocation with collateral damage。

这类情况如果只看 pass/fail，会被错误归类为”技能生效”。

同样，trace 的价值也不是锦上添花，而是把”失败了”这件事拆开。没有 trace，你只能知道：没完成、很慢、成本高、输出不对。

但你不知道它到底怎么走偏的。是没发现 skill、用错 skill、读了太多无关文件、工具输出太大，还是环境把它绊倒了？

所以一个成熟的 agent eval，真正该同时具备三层能力：看结果、看行为、看失败属于哪一类问题。

我觉得这才是从”评分系统”跨到”诊断系统”的分水岭。

六、一个成熟的 eval harness，最终应该同时优化四件事

很多团队做 eval 时，最后只盯一件事：质量分数。可在 agent 场景里，这远远不够。

我更倾向把目标拆成四类：

质量（Quality）：任务到底做没做对。

效率（Efficiency）：用了多少轮、多少时间、多少工具调用、多少 token。

可靠性（Reliability）：同样条件下是否稳定，环境变化下是否脆弱。

解释性（Interpretability）：失败时能不能解释，成功时能不能归因。

这四个维度缺一个，系统都容易被误导：只看质量不看效率，系统可能正确但贵得离谱；只看效率不看质量，系统可能很快但经常绕过关键步骤；只看质量与效率不看可靠性，系统可能在 demo 稳生产飘；前三项都看但不看解释性，团队还是不知道怎么改。

所以我越来越觉得，一个真正成熟的 eval harness，最终不该只是给出分数，而应该生成一种结构化判断：结果如何、代价如何、稳定性如何、原因如何。

七、什么时候 output-only eval 仍然成立

为了避免把这篇文章读成一种”所有评测都必须重型化”的极端主张，我觉得也有必要补一层边界意识。

如果任务具备这些特征，output-only eval 依然可能成立：任务极短、路径很浅、中间过程几乎没有高价值差异、输出本身就是主要产品价值、失败代价低、不存在复杂技能注入工具链和环境耦合。

例如一些轻量改写、格式转换、单步生成任务，这时要求完整轨迹评测反而可能成本过高、收益过低。

所以真正成熟的判断，不是”永远不要 output-only eval”，而是：只有当过程信息会显著改变你对结果的解释时，过程评测才必须升级成一等公民。

八、把 eval 分成三层，组织才不会被一套指标拖偏

我越来越觉得，很多团队做 eval 的痛苦，来自他们试图用一套评测层同时满足三种完全不同的诉求：对外汇报、对内诊断、上线前 gatekeeping。

这三件事其实不该长得一模一样。我更建议团队把 eval 分成三个层：

第 1 层：summary layer——给管理层、产品侧、跨团队沟通用。指标要少、稳、可读，但明确承认这只是摘要层。

第 2 层：diagnostic layer——给工程和 eval 团队自己用。重点是 trace、failure slices、invocation、artifact quality、环境切片。

第 3 层：gate layer——用于上线前或版本晋升判断。它不追求解释全世界，而追求最关键的质量门槛和风险门槛。

一旦这三层被分开，很多组织里的沟通混乱会立刻下降。因为你不再试图用一个分数同时完成”汇报、诊断、决策”三件完全不同的事。

结语：真正成熟的 eval，不会只告诉团队哪里亮了红灯，还会告诉团队这盏红灯属于哪一种系统问题

如果我要给这篇文章最后留一句最适合收尾的话，那会是：

一个评测系统真正成熟的标志，不是它能不能不断报出红灯，而是它能不能让团队知道，这盏红灯到底是能力问题、触发问题、执行问题，还是环境问题。

只有做到这一点，eval 才真正从”评分装置”变成”系统理解装置”。

---

谁应该读这篇

这篇适合下面几类读者：

• 正在搭建 agent eval 平台的团队
• 在做 skills / prompts / workflow A/B 的 AI 工程师
• 想把 benchmark 从”汇报工具”变成”诊断工具”的技术负责人
• 在 LangSmith、OpenTelemetry、内部 tracing 系统上做整合的人
• 已经被”分数涨了但系统没更清楚”困扰过的人