先自己答，再对照讲解。讲解后附来源。术语保持英文。
🎯 学习重点：离线有可复现 ground truth，线上有真实分布但信号嘈杂，二者不可互相替代。
讲解要点：两者回答不同的问题。离线评估回答「这个版本比上个版本好吗」——在固定金标集上可复现地对比，有 ground truth（金标答案/期望终态），能定位到层（检索/工具/生成）与题（哪个 task 回归），可做 CI 门禁。线上监控回答「用户现在遭遇什么」——真实分布、真实事故，但没有评分所需的 ground truth、信号噪声大、被动（问题先到用户）。官方把二者列为互补：自动化评估是上线前与 CI 的第一道防线，生产监控上线后检测 distribution drift 与未知失败；只用其一会产生「虚假信心」（离线集漂离真实分布）或「反应式救火」（回归靠用户报告）。加分点：线上失败应回流成离线金标题——监控喂评估。 来源: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents（访问于 2026-08-30）
🎯 学习重点：先从真实失败建最小金标集，再接 CI，最后建立线上回流。
讲解要点（官方 0→1 路线图的产品化压缩）：
来源: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents、https://platform.claude.com/docs/en/test-and-evaluate/develop-tests（访问于 2026-08-30）
🎯 学习重点：默认按 outcome 评分，只有业务规则明确约束顺序时才检查路径。
讲解要点：agent 常会走出评估设计者没预料的合法路径（换个顺序调用工具、用另一种查询措辞），如果 grader 严格校验固定调用序列，这些创造性解法会被误杀，评估变得过脆 (brittle)——官方明确警告这一点。所以 grader 应校验终态与关键约束（订单改对了没、退款合规没），而非逐步路径。例外：顺序本身是业务/安全规则时（必须先 verify_identity 才能 process_refund；必须先人工审批才能删除生产数据），顺序断言就是产出的一部分，必须硬校验。架构师判断口径：问「这条顺序违规是否本身就是事故」——是则硬校验，否则只记观测指标不判 FAIL。 来源: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents（访问于 2026-08-30）
🎯 学习重点：judge 必须经 rubric、结构化输出、Unknown、人工一致性和版本回归约束。
讲解要点：① rubric 详细可执行（「第一句必须提到 X 否则 incorrect」级别，不是「回答要好」）；② 输出结构化（correct/incorrect 或 1–5，禁止自由文本评分）；③ 先推理后结论再丢弃推理（thinking 标签模式）；④ Unknown/信息不足出口，防 judge 幻觉；⑤ 按维度隔离 judge（语气、覆盖度、事实性各一个）；⑥ 人工校准：与人类专家对同一批样本打分对比分歧，分歧率达标才可接管；⑦ rubric 变更即重校准；⑧ 稳定后保留定期抽检。没有 ①–⑥ 的 judge 不应出现在 CI 门禁里——官方 CORE-Bench 案例（评分 bug 把 42% 压成假象，修复后 95%）就是 grader 未经验证就当真值的代价。 来源: https://platform.claude.com/docs/en/test-and-evaluate/develop-tests、https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents（访问于 2026-08-30）
🎯 学习重点：研发探索看至少一次成功，用户可靠性看每次都成功。
讲解要点：pass@k = k 次至少一次成功（随 k 升高）——适合内部研发爬坡与「成功一次就够」的工具型场景（编程 pass@1 最相关）。pass^k = k 次全部成功（随 k 降低）——适合面向用户的产品决策：用户要求每次都对；per-trial 75% 的系统 pass^3 ≈ 42%，这个难看的数字才是客服/交易系统的真实质量。k=10 时 pass@k 趋近 100%（总有蒙对的）而 pass^k 趋近 0%（总有一次翻车）——同一个系统，两个口径给出相反叙事，所以产品汇报必须两个都报，只报 pass@k 是报喜不报忧。 来源: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents（访问于 2026-08-30）
🎯 学习重点：先定位证据是否被检索，再判断回答是否使用并正确表达证据。
讲解要点：按管线因果链路由症状（模块 07 建立、模块 12 复用）：
来源: https://platform.claude.com/cookbook/capabilities-retrieval-augmented-generation-guide、https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents（访问于 2026-08-30）
🎯 学习重点：高通过率能力题应毕业到回归集，同时补充更难、更新分布的能力题。
讲解要点：饱和 = agent 通过了套件中所有可解任务，分数停在高位，不再提供改进信号，且此后真实的大改进只表现为小幅涨分（官方 SWE-bench Verified 从约 30% 到 >80% 的进程即饱和史；Qodo 因老套件 one-shot 题低估了 Opus 4.5 的长任务增益）。生命周期管理：① capability 题通过率爬到高位后毕业 (graduate) 成 regression 套件常驻跑（防漂移）；② 持续补充更难/新维度的 capability 题（Qodo 的做法：为长任务另建 agentic 评估）；③ 定期审计：分数异常（过高/过低/纹丝不动）都先怀疑套件本身；④ 题目换血：线上失败回流、过时题目退役。 来源: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents（访问于 2026-08-30）
🎯 学习重点：聚合完整任务的多轮输入、缓存、输出、工具和重试成本。
讲解要点：① 口径是任务不是请求：agent 任务 = N 轮调用 ×（input+缓存读写+output），跨轮上下文累积使 input 随轮数膨胀；② 重试放大：pass^k 概率下，用户侧每成功任务的成本 ≈ 单次成本 ÷ 任务成功率 + 失败残留成本；③ token 预算做成 grader（n_total_tokens 超预算 = trial FAIL），这比单请求 max_tokens 更贴近业务约束；④ 三指标并排：官方提醒 agentic 系统常以延迟成本换任务表现，质量报告必须附成本延迟变化，由业务方权衡；⑤ 工具面：Usage & Cost Admin API 做组织级用量/成本对账与告警，Datadog/Grafana/Honeycomb 等官方合作集成做 LLM observability 仪表盘。 来源: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents、https://platform.claude.com/docs/en/manage-claude/usage-cost-api、https://www.anthropic.com/engineering/building-effective-agents（访问于 2026-08-30）
🎯 学习重点：先排除流量与 UI 变化，再按检索、工具、模型、策略分层复放样本。
讲解要点：按层剥离，先找「什么变了」再找「哪层坏」：① 变更审计——最近 prompt/模型版本/工具/RAG 语料更新与告警起点对齐（离线回归套件对当前版本重跑：套件也挂 → 本地回归，走对应层修复；套件全绿 → 分布问题）；② 输入分布——按 query 聚类/长度/语言/客群拆分接管率，找恶化的子群体（营销活动引来新问法）；③ 检索层——对恶化子群体的查询跑 recall@k/precision@k（语料漂移：新内容没入索引/金标块失效）；④ 工具层——工具错误率/超时率、被拦截调用比例（下游 API 改动）；⑤ 生成层——抽样 transcript 人审 + groundedness 抽检（新问法触发无据作答）；⑥ 处置——回滚/热修 + 把恶化样本沉淀为新金标题回流评估集。 来源: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents（访问于 2026-08-30）
🎯 学习重点：逃逸指标是及时的行为代理，只能告知“可能变差”，不能单独给出根因。
讲解要点：逃逸指标是行为代理：用户不填评分表，但会用脚投票——重新措辞再问（没听懂/答非所问）、转人工（任务失败的高置信代理）、中途放弃。价值：① 无需 ground truth、自动采集、及时（相对 thumbs-down 更密集）；② 对「答案看着挺好但没用」的劣化敏感——LLM judge 常漏掉的「实际没解决问题」；③ 天然按用户视角聚合，适合版本对比与 A/B。边界（为何不能替代质量指标）：① 只能告诉你「变差了」，不能告诉你「哪层坏、为什么」——异常时仍要采样 transcript 分层归因；② 受产品 UI 影响（人工入口显眼度）、季节性波动，需先建基线再设阈值；③ 是滞后于离线评估的最终裁判，前置手段仍是金标回归集。注：改写率/接管率为业界通用叫法，非 Anthropic 官方术语。 来源: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents（访问于 2026-08-30；逃逸指标命名业界通用）
🎯 学习重点：按反馈速度、真实性、成本和可解释性匹配评估方法。
讲解要点（六方法矩阵）：自动化评估——上线前与 CI/CD，每次变更的第一道防线；生产监控——上线后，分布漂移与未知失败；A/B 测试——流量足够后验证重大变更（数天到数周出显著性）；用户反馈——持续 triage，失败例回流评估集；人工转录审读——每周抽样，建立失败直觉与「什么是好」的校准；系统性人因研究——校准 LLM judge 或评主观输出时的金标准。官方结论句：最有效的团队组合使用——自动化评估做快速迭代，生产监控做 ground truth，定期人审做校准。架构师要点：给每个方法配预算与负责人，而不是全押一头。 来源: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents（访问于 2026-08-30）
🎯 学习重点：环境隔离、生产同构、全量记录、可复现和可下钻缺一不可。
讲解要点：① 环境隔离：每 trial 从干净环境起，杜绝残留文件/缓存/git 历史造成的关联失败或虚假高分（官方亲历：Claude 翻前序 trial 的 git history 作弊）；② 与生产同构：eval 里的 agent 行为应与生产 agent 一致（同一 harness、同一工具集），否则测的是另一个系统；③ 全量记录：transcript + outcome + 评分明细都存档可回放（「读 transcript」是官方铁律的前提）；④ 可复现：固定随机性来源、锁定模型版本/温度，多 trial 汇总抑制剩余方差；⑤ 并发与成本控制：套件可并发跑但预算封顶（token 预算也是 grader）；⑥ 产物可审：分数异常时能下钻到 task→trial→grader 断言逐条核对。评估平台的 bug 会直接污染所有决策——CORE-Bench（42%→95%）是它的代价上限案例。 来源: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents（访问于 2026-08-30）
📚 目录