Anthropic《Demystifying evals for AI agents》系统解读：三类评估器与 PPT Master 的评估缺口
原文：Demystifying evals for AI agents
实践项目：PPT Master
前置阅读：《Building effective agents》 · 《Agent Skills》 · 《Effective context engineering》 · 《Effective harnesses》 · 《Writing effective tools》
这是本系列的第六篇，也是基础系列的收束篇。
前五篇提出或校准了多项工程判断——串行页面生成、隔离 topic research、条件式 split、页面清单纪律和检查器输出契约。现行实现能验证单次运行的许多事实，但若要比较两种策略，仍需要把任务、试验和判据明确下来，否则无法证明改动后是变好还是变坏。
原文对这种状态有一句直接的判断：
The value compounds, but only if you treat evals as a core component, not an afterthought.
一、为什么 Agent 评估不同于模型评估
原文给出的理由是 Agent 的运行形态：
Agents operate over many turns: calling tools, modifying state, and adapting based on intermediate results.
让 Agent 有用的那些特性——自主、灵活、能适应中间结果——同时也让它难以评估。单轮评估无法捕捉多步骤交互中的 错误传播 与 状态累积。
以 Default Generate 的长篇演示文稿为例，一次生成涉及多次工具调用、文件写入和质量门。问"这次生成得好不好"，实际上是在问一整条链路；Quick 和原生 PPTX 路线则有不同的链路与成功条件。
二、基本概念
原文先统一了术语，这套词汇后面会反复用到：
| 术语 | 定义 |
|---|---|
| Task（任务） | 一个包含明确输入和成功标准的测试 |
| Trial（试验） | 对某个任务的一次执行尝试 |
| Grader（评估器） | 对表现的某个方面进行评分的逻辑 |
| Transcript（完整记录） | 包含全部输出、工具调用、推理过程的历史 |
| Outcome（结果） | 试验结束时环境的最终状态 |
| Harness（评估框架） | 端到端运行评估的基础设施 |
任务与试验的区分是理解非确定性的前提：同一个任务跑十次可能有十种结果，"通过率"是任务级的属性，而不是某次运行的属性。
三、三类评估器
这是原文最实用的一张对照。
代码/规则型
方法：字符串匹配、二值测试、静态分析、结果验证。
| 优势 | 劣势 |
|---|---|
| Fast, Cheap, Objective, Reproducible, Easy to debug | 对有效的变体过于敏感，缺乏细微差别 |
"对有效变体过于敏感"是它的典型失败：一个同样正确但表达不同的答案会被判错。
模型型（LLM-as-judge）
方法：基于规则的评分、自然语言断言、配对比较。
| 优势 | 劣势 |
|---|---|
| Flexible, Scalable, Captures nuance, Handles open-ended tasks | 非确定性，需要与人工评估者校准 |
原文强调校准不是可选项：
LLM-as-judge graders should be closely calibrated with human experts.
人工型
方法：专家审核、众包判断、抽样检查。金标准质量，但成本高、速度慢、难以规模化。
结论
原文的建议是 组合使用，而不是选一种。三类评估器覆盖的是不同性质的判断：机器能判定的事实交给代码，需要品味的判断交给模型并与人校准，最终标准由人定义。
四、处理非确定性
同一任务多次运行会得到不同成功率。原文给出两个指标：
| 指标 | 含义 |
|---|---|
| pass@k | k 次尝试中 至少一次 成功的概率 |
| pass^k | k 次试验 全部 成功的概率 |
原文的说明很尖锐：
At k=1, they're identical... By k=10, they tell opposite stories.
k=1 时两者相同；k=10 时它们讲的是完全相反的故事。一个 pass@10 很高但 pass^10 很低的 Agent，意味着"多试几次总能成"——对于研究型任务这可以接受，对于需要一次做对的生产任务则是灾难。
选哪个指标，取决于产品能否容忍重试。
五、如何从零开始
起步规模
20-50 simple tasks drawn from real failures.
20 到 50 个来自真实失败的简单任务。原文明确说早期效果明显，小样本就够——不要等到评估集完美再开始。
任务来源的优先级
- 从已有的手动检查开始；
- 把 bug 追踪器和用户支持里的真实失败转化成任务；
- 按用户影响排序。
任务质量标准
两位领域专家能独立做出相同的通过/失败判断。
以及一条重要的排错提示：
A 0% pass rate across many trials... is most often a signal of a broken task, not an incapable agent.
多次试验全部为 0，通常说明任务写坏了，而不是 Agent 无能。
样本平衡
Test both the cases where a behavior should occur and where it shouldn't.
只测"应该发生"的情况会导致单向优化——Agent 学会了总是触发某行为，包括不该触发的时候。
六、两种评估模式与常见陷阱
能力评估 vs 回归评估
| 模式 | 回答的问题 | 期望通过率 |
|---|---|---|
| 能力评估 | 这个 Agent 能做好什么？ | 从低通过率开始 |
| 回归评估 | 它是否还能处理原来能处理的？ | 应保持接近 100% |
两者的健康状态完全不同。回归评估一旦掉下 100%，就是明确的退化信号。
陷阱一：过度检查路径
There is a common instinct to check that agents followed very specific steps... We've found this approach too rigid.
检查 Agent 是否走了特定步骤过于刚性。同样的结果可以由不同路径达成，锁死路径等于禁止改进。
陷阱二：评估饱和
当 Agent 通过所有任务时，评估不再提供改进信号，需要持续创造更难的任务。
陷阱三：评估本身有 bug
原文给了一个惊人的例子：Opus 4.5 在 CORE-Bench 上最初得分 42%，发现评估问题后跳升到 95%。
由此引出全文反复强调的一条：
Read the transcripts.
读完整记录 是验证评估是否在公正测量的唯一方式。原文在结论的七条原则里把这条重复了两遍。
其他最佳实践
- 参考解：每个任务应有已知可行的输出，证明任务可解；
- 部分学分：多组件任务不应只有全对全错。"识别出问题但没能完成退款"的支持 Agent，明显好于两件都没做到的；
- 防作弊：Agent 不应能轻易绕过评估；
- 环境隔离：每次试验都从干净环境开始。
从概念转入实践
以下检查 PPT Master 的评估现状。结论是：它具备可复用为代码、模型和人工 grader 的候选表面，但这些表面当前主要服务生产流程；仓库没有正式、可复用的多路线 task/trial 套件——这个边界决定了它当前能发现什么、发现不了什么。
七、PPT Master 已有的三类候选 grader 表面
原文的三类评估器在 PPT Master 里都能找到可复用表面，但“生产门或交互界面存在”不等于“已经成为 eval grader”。只有把它放进固定 task/trial、定义 outcome 和评分合同后，它才承担评估职责。
| 类型 | 当前生产表面 | 当前职责与 eval 边界 |
|---|---|---|
| 代码/规则型 | project_manager.py validate；按 profile 使用的 svg_quality_checker.py；svg_to_pptx.py postflight 及底层 OPC 校验 | 分别检查 Default 规划制品语法、当前 SVG 合同、PPTX 包与报告关联；普通 flat Generate 尚无 §IX 与实际 SVG ordered roster 的通用交叉 grader |
| 模型型 | 当前依赖 Design Spec/Spec Lock 的可选 visual-review + 固定 rubric | 是会备份并直接修改 SVG 的生产审查；eval 只能只读复用 rubric，或在不可变副本上运行，不能直接拿该 stage 给原 outcome 打分 |
| 人工型 | 产出后的人工预览、批注或独立审核 | 是验收与编辑表面；只有放入固定 trial 协议并记录判据时才构成人工 grader |
Default 的两阶段 Confirm UI 属于运行前的 interactive trial configuration / human-in-the-loop gate：它设置沟通目标和生产条件，会改变 trial 输入，不评价 trial performance，因此不列为 grader 候选。
当前分工方向与原文建议一致：机器能判定的结构、Schema、包完整性与报告关联由代码判定，需要品味的判断可由模型对照 rubric 辅助，最终取舍由人决定。需要保留的边界是：生产职责相邻，不代表已经完成 eval harness、重复 trial 和 grader 校准。
这印证了第一篇解读里的那条原则——凡是机器能直接验证的事实，就不要让 LLM 用自然语言宣布成功。
可选模型型候选 grader 的设计细节
visual-review.md 有几处处理得比较讲究：
- 明确不重复静态检查：rubric 开头列出"已由静态检查器强制的主题，此处不要重复检查"；若静态检查未运行或未通过，子代理必须以
prereq_failed中止； - 保守阈值：
Subagents must apply the 明显 ("clearly bad") threshold — when in doubt, leave it. Better to under-fix than to oscillate. - 权限分层：品牌级问题（
spec_lock.md定义的 token）不由单页子代理修改，因为"违规会在每个使用该 token 的页面上重复出现"，应交给 orchestrator 聚合处理； - 结构化输出：每个子代理写出
<project>/.review/<page>.json。
"当有疑问时不动手"这条，正是对 LLM-as-judge 非确定性的一种务实约束：宁可漏改，不要反复摆动。
八、边界在哪里：尚无正式任务集与试验套件
有候选 grader，不等于有评估。
原文的六个概念里，PPT Master 有候选 grader、单次 outcome checks，也有服务生产的 workflow harness；但它没有统一执行 tasks、记录 trials、调用 graders 并汇总指标的 eval harness。仓库当前也没有正式、可重复运行的跨版本 task/trial 套件。这是能力边界，不自动意味着项目现在必须建设测试系统。
具体后果有三个：
1. 无法回答"改动是否有效"
例如，topic-research 已经改为隔离优先，但没有对 worker 与 fallback 路径做成同任务的重复试验；“串行核心页面是否优于并行页面”也仍是设计判断。若要比较这些方案，单次成功回执不够，需要固定输入与评价口径。
2. 没有回归保护
原文区分能力评估与回归评估，后者应保持接近 100%。以 2026-08-12 的 4e6ecbcb 快照计，Skill 内全部 Markdown 为 29702 行且持续演进；仓库没有用于比较 Agent 跨版本行为的正式任务套件。
prompt_audit.py 守护语料的静态属性（token 预算、引用完整性、注册表一致性），现有路线检查器守护单次产物；两者都不声称回答“改了这句话之后 Agent 行为是否退化”。
3. 无法度量非确定性
同一份材料生成两次，结果可能不同。当前没有数据回答：成功率是多少？失败集中在哪一步？是 pass@1 就稳定，还是要试三次才对？
第一篇解读里那个"顺序生成 vs 并行生成"的对照实验之所以一直没做，根本障碍就在这里——没有 trial 的概念，就没有可比的基线。
九、如果需要比较策略：一份最小研究框架
原文建议从 20–50 个真实失败任务起步。PPT Master 的当前清单有 21 个 Generate 展示项目，包含 Design Spec、SVG 和最终 PPTX 等结果制品，但它们不是四路线任务集，多数也没有标准化的 sources/ 输入目录。
因此它们只能提供题材与输出参考，不能直接当作可重放任务。下面是一份 仅在维护者确实要比较某项策略时 可采用的研究框架，不是 PPT Master 的现行路线图。
任务集构成
| 分层 | 数量 | 来源 | 目的 |
|---|---|---|---|
| 回归任务 | 3–5 | 为 Generate 单独整理可重放输入；展示样例只作输出参考 | 在明确改动前后比较已知正常路径 |
| 能力任务 | 按真实故障添加 | 从可复现失败转化，而不是预设未来问题 | 检验某项具体修复是否有效 |
| 负样本 | 按边界添加 | 不该触发某行为的真实案例 | 防止只优化正向触发 |
如果研究目标扩展到 Create Template、Fill Native 或 Enhance Native，需要为每条路线另建输入与 outcome 契约；现有 Generate 展示项目不能替代这些 fixture。
评估器分配
按原文"组合使用"的建议，三类各司其职：
| 判断内容 | 评估器 | 判据 |
|---|---|---|
| Default Generate 的 §IX 与实际 SVG ordered roster 一一对应 | 代码 | 需要新增一个同时读取两侧的最小 grader；现有通用 flat 检查器不证明该关系 |
| 当前 profile 的 SVG 结构合规、导出成功 | 代码 | 复用该 profile 的现有检查器 |
| 路线 outcome 完整 | 代码 | 按路线检查制品；不能统一要求 spec/lock |
| 视觉质量（确有需要时） | 模型 | 只读复用 visual-review.md rubric，或在不可变副本上运行；不得让生产 stage 修改被评分 outcome |
| 叙事是否成立、内容是否忠于源材料 | 人工抽样 | 定期校准模型评估器 |
其中"内容忠于源材料"必须有人工参与——这正是原文说的 LLM-as-judge 需要与专家校准的部分。
指标选择
按第四节的判据，PPT Master 属于 需要一次做对 的生产工具：用户不会为了一份 PPT 重跑五次。因此：
- 回归任务用 pass^k（k=3），要求三次全过；
- 能力任务用 pass@k，先看能力边界在哪。
部分学分
演示文稿生成天然是多组件任务，全对全错会浪费信号。建议的分档：
路线必需制品完整 → 基础分
计划与实际页面一致（适用路线） → 完整性分
当前 profile 的检查器 error 为 0 → 合规分
视觉 rubric 无 needs_human（只读评分时） → 质量分一次"生成了 20 页但有 2 页 error"的运行，明显好于"生成到第 8 页就中断"，评估应当能区分这两者。
环境隔离
原文要求每次试验从干净环境开始。对应到 PPT Master，若开展研究，应为每次 trial 使用彼此隔离、可安全清理的临时工作区，不复用已有制品，也不污染用户正在维护的项目。具体位置应服从运行环境与清理边界，而不是把试验目录硬编码成产品约定。
从哪里开始
如果维护者需要为某个具体改动建立比较基线，可以从很小的范围开始：
- 参考 3 个 Generate example 的题材与输出，分别整理可重放输入，各跑 3 次；
- 只用代码型评估器（新增的 §IX/roster 交叉 grader、现有 error 数和制品完整性检查）；
- 记录通过率和失败步骤分布。
这一步能回答这 3 个特定任务在当前环境中的重复通过情况，以及失败集中在哪一步；它不能外推为四条路线或全部题材的总体成功率。
十、把现行判断接到可选评估上
如果未来需要研究前面四篇涉及的判断，可以按“什么证据足以支持决策”重新组织：
| 来源 | 建议 | 验证方式 |
|---|---|---|
| 第一篇 | 顺序生成 vs 并行生成 | 同一 example 两种策略各跑 k 次，视觉连续性由人工盲评，结构合规由代码判定 |
| 第二篇 | topic research 的隔离与 fallback | 检查原始抓取是否隔离、两份导入制品是否被主代理完整读取，并比较最终 outcome |
| 第二篇 | split 的条件判断 | 结合页数、源材料与保留上下文，观察连续执行何时出现可复现退化 |
| 第三篇 | 页面 roster 的硬规则及通用自动交叉校验缺口是否造成真实问题 | 只在发现未被拦截的真实漂移后，建立对应负样本与最小 grader |
| 第三篇 | 有界备份是否满足恢复需求 | 从真实破坏场景验证默认导出备份和视觉审查备份能否恢复 |
| 第四篇 | 完整 failure issue 集的成本 | 在确有超大报告时比较完整读取与定向读取，不能复用已有 --format |
这里的原则不是把每个假设都变成项目任务，而是让 真实触发的改动 带着与风险相称的证据：机器可判定的事实先复用现有检查器，需要品味的比较再引入人工或模型 rubric。
十一、我的理解：评估是让判断可以累积
核心观点
没有评估的系统，每一次改进都是从零开始的赌注；有评估的系统，每一次改进都在前一次的基础上。
评估的产出不是"分数"，而是 让"我觉得这样更好"变成"这样确实更好"的转换机制。
回看这六篇解读，有一条线索贯穿始终：
- 第一篇提出"环境反馈是 ground truth"，但那讨论的是 单次任务内 的验证；
- 第三篇的上下文策略、第四篇的 harness 设计、第五篇的工具接口，每一层都留下了"这样做更好，但没法证明"的判断；
- 这一篇要补的，是 跨任务、跨版本 的验证。
两者的区别是：前者回答单次产物是否满足当前契约，后者比较系统在特定任务上的跨版本行为。PPT Master 当前以前者为主；是否补充后者，应由真实回归风险或明确研究问题触发。
如果 PPT Master 未来决定为某项行为变化建立评估，原文最值得保留的是第一条和最后一条：
早期开始（不要等待完美）……阅读完整记录。
基线可以很小，但必须使用可重放输入并明确适用范围；“读完整记录”则意味着不能只看通过率——失败发生在哪一步、工具与制品如何变化，这些信息才是下一轮决策的真正来源。没有具体改动或故障触发时，现有按需审计和路线质量门仍是更符合项目范围的做法。
十二、系列小结
本系列六篇解读的关系可以这样收束：
| 篇目 | 回答的问题 | 层次 |
|---|---|---|
| Building effective agents | 如何组织 LLM 与工具 | 架构 |
| Agent Skills | 知识如何分层存放 | 静态组织 |
| Effective context engineering | 运行时上下文如何管理 | 动态管理 |
| Effective harnesses | 如何跨会话保持连续 | 时间维度 |
| Writing effective tools | Agent 与环境的接口如何设计 | 接口 |
| 本篇 | 如何证明改动确实有效 | 验证 |
前五个问题决定系统能做到什么，最后一个问题决定它能否持续变好。