Sergii Makarevych · Agent 评测方法解读 · 2026-10-19
原文：How to write and test agent skills with evals

为什么“装上以后感觉更好”不够

一份 Skill 可以让 Agent 多读文档、先写测试、记录计划，或者使用某套工具。执行轨迹因此显得更完整，但这些变化是否提高了任务质量，仍然是另一个问题。若最终结果没变，只是多用了上下文、工具调用和等待时间，那么看到的是行为变化，而不一定是能力提升。

这篇长文最有价值的划分，是把评估拆成两层：Agent 是否遵循了指令，以及遵循之后任务结果是否更好。 作者提出从可测目标出发，把 Skill 拆成行为假设，分别建立遵循度与效果指标，再通过对照和消融决定哪些规则值得保留。文章综合了多项研究与一个测试优先的示例，并非用一份统一实验得出了所有结论。

从评测设计角度，我们还需要把第三件事放在最前面：技能到底有没有被加载。未加载、加载后没执行、执行后没收益，是三个不同的诊断入口。

把一份长提示拆成可检查的假设

以“修改代码之前先写一个能复现问题的测试”为例，文字本身只描述动作顺序。要形成可检验的假设，还必须说明预期收益：它是否帮助发现原有缺陷，是否防止修复只通过表面检查，以及是否降低回归风险。

可以把评测记录组织成下面四层：

层次 要回答的问题 适合观察的内容
加载 本次运行是否真正读到了 Skill？ 加载事件、版本及触发条件
遵循 指定行为是否发生？ 文件改动顺序、命令、输出和退出码
效果 任务是否完成得更好？ 隐藏检查、既有功能回归、产物有效性
代价 为这些变化付出了什么？ 模型调用、上下文用量、时间及失败重试

这张表适合做故障定位，而不只是评分。如果加载失败，先检查发现和路由机制；如果行为没有发生，检查规则是否清晰或冲突；如果行为发生但质量没有变化，就需要重新审视这条方法本身。

尤其要防止“代理指标获胜”。测试数量增加不等于缺陷检测能力提高，计划更长不等于执行更稳健。对每个指标，都应该问：它增加时，什么真实收益本来应当随之发生？如果这个联系说不清楚，就不宜把它作为主结论。

对照组要拆开内容与上下文长度

作者建议比较没有 Skill、目标 Skill 和等长无关文本。这一步试图把具体指令的贡献，与增加上下文带来的影响分开。若 Skill 附带会话钩子，完整安装与仅加载正文也应分开观察；否则加载策略和文本质量容易混成一个总分。

对于实际项目，我会先固定模型版本、工具集合、仓库状态和任务输入，再明确规定各组怎样调用技能。这里有两个不同实验：一个研究技能内容在确定加载后是否有效；另一个研究真实安装条件下，路由能否在合适的任务上选择它。前者不该被随机漏加载污染，后者也不能通过强制调用掩盖选择问题。

等长无关文本同样不是天然无害的空白。它的内容、位置和长度都需要记录；否则一次不理想的对照，可能把目标 Skill 显得格外有效。更稳妥的解释是比较多种观察：任务质量、遵循行为、长度对照与必要的规则消融是否共同支持同一个判断。

怎样判断生成的测试确实有用

对于测试相关 Skill，关键产物不是测试文件的数量，而是它能否区分正确和错误行为。一个测试始终通过，可能因为没有有效断言，也可能因为没有覆盖任务涉及的差异。漂亮的名字和完整的注释都不能替代执行证据。

一种具体的评估方式，是把生成测试放回修复前的代码运行，再对与任务相关的少量变更或故障版本进行检查。同时使用 Agent 看不到的任务验收测试，避免由同一次生成过程同时定义需求、实现代码并给自己打分。

还要区分失败原因。导入错误、环境缺包和断言命中目标缺陷都能产生非零退出码，但它们提供的证据不同。若把所有红色结果都记为“成功复现”，遵循度会看起来很好，实际却没有验证缺陷。

Anthropic 在 Agent 评测中区分任务、一次运行、执行轨迹、最终结果与评分器，并讨论确定性检查和模型评分的不同用途。这种分层有助于避免把工具调用记录直接当作任务成功证据。Anthropic：Agent 评测

把“是否保留”变成有依据的决定

以下是把原文思路落实到技能维护时可用的判断表，不是一次已经完成的实验：

观察 优先检查什么 下一步
经常没有加载 描述、路由及触发条件 修复选择机制，单独测试内容效果
加载后遵循度低 表述含糊、要求冲突或不可执行 缩小规则，检查具体轨迹
遵循度高但质量持平 方法假设是否适合任务与模型 删除单条规则做消融
质量提高但成本明显增长 收益是否值得额外开销 比较更短指令及替代流程
平均分提高但部分任务退化 收益是否只集中于某类任务 限定适用范围，报告失败分布

如果要比较很多条件，评测本身也会成为工程项目。例如 20 个任务 × 5 组配置 × 3 次运行 = 300 次执行，这是设计规模的算术，不是效果结果。可以先用小样本排除配置错误，再把预算用于最有区分力的任务和关键差异。不能一边大量改规则，一边把同一组任务当作从未见过的最终检验。

哪些东西应当随 Skill 一起维护

值得长期保存的不只是指令文件，还包括它试图改善的目标、适用任务、可检查行为、评测条件和已知退化情况。模型、工具或项目依赖发生变化后，这些条件可能不再成立；旧版本有效不等于新版本自动有效。

对领域进展而言，这篇文章代表了一个有价值的转向：讨论重点从“怎样写出更像专家的指令”，转向“怎样证明一条指令值得进入日常工作流”。但遵循度和效果之间的相关性，仍不能单独证明因果；任务难度也可能同时影响两者，需要受控比较和消融来区分。

优先阅读原文的运行示例、遵循度／效果定义和对照设计。 对 AgentOps 而言，加载失败、执行偏离、方法无效和成本退化可以成为不同故障类型；把它们分开，才更容易决定是改提示、改路由，还是根本不使用这份 Skill。