来源：抖音@老傅1024 视频解析 | 整理时间：2026-05-11 核心来源：Anthropic 工程博客《Demystifying Evals for AI Agents》
为什么"感觉它还行"不够用？
典型的痛点路径：改了个 Prompt → 手动跑几个 case → 感觉没问题 → 上线 → 用户反馈"变蠢了" → 无法定位是这次改动还是本来就有问题 → 修一个 Bug → 可能引入新 Bug → 永远在"救火"
没有评测 = 盲飞。根本无法区分"模型随机噪声"还是"真正退步"。
核心概念体系（术语表）
| 术语 | 含义 |
|---|---|
| Task（任务） | 一个测试用例，有明确输入和成功标准 |
| Trial（试验） | 对任务的一次完整执行（需多次以消除随机性） |
| Grader（评分器） | 评估输出质量的逻辑单元 |
| Transcript（记录） | 全程实录：对话 + 工具调用 + 推理过程 |
| Outcome（结果） | 最终环境状态 —— 结果 ≠ 声称（Agent 说"已预订"，数据库里有吗？） |
| Eval Harness | 运行评测的基础设施（发送指令、记日志、汇总分数） |
三种评分器：组合使用
① 基于代码的评分器（快、准、客观） 字符串匹配 / 单元测试 / 静态分析 / 工具调用验证
② 基于模型的评分器（灵活、语义化） LLM 打分 / 成对比较 / 多模型共识 ⚠️ 必须用人工校准，才能信任分数
③ 人工评分器（黄金标准） 专家审查 / A/B 测试 —— 用于校准 ② 的可信度
两种评测套件，缺一不可
能力评测（进攻）
- 问：“这个 Agent 能做到多好？”
- 用难题，初始通过率可能只有 30%
- 是"北极星指标"，指引研发方向
回归评测（防守）
- 问：“Agent 还在正常工作吗？”
- 用已知能解决的题，通过率应接近 100%
- 任何分数下降 = 系统退化报警
最佳实践：一道"能力题"被攻克并稳定后，应"毕业"升入回归套件。
核心反直觉原则
重结果，轻过程
不要评测 Agent 的具体步骤顺序，除非逻辑上必须如此。如果你惩罚了"捷径"，就扼杀了大模型最核心的创造力。评分产出物，不是 Trace（路径）。
最关键指标：pass@k vs pass^k
| 指标 | 含义 | 适用场景 |
|---|---|---|
| pass@k（命中率） | k 次机会里至少成功一次 | Copilot 类辅助工具（用户兜底） |
| pass^k（鲁棒性） | 连续 k 次全部成功 | 无人值守自动化 Agent |
致命陷阱：成功率 75% 听起来不错，但自动运行 3 次全对的概率只有 42%（0.75³）。做全自动 Agent 必须死磕 pass^k。
从零到一路线图（8 步）
- Step 0：现在就开始，不要等"数据够了再说"
- Step 1：从 Bug 追踪器 / 用户投诉里提取 20-50 个真实失败案例
- Step 2：写无歧义的任务（两个专家应能得出相同结论）
- Step 3：正负样本均衡（“该做什么"和"不该做什么"各占一半）
- Step 4：每次试验必须从干净环境开始（避免状态污染）
- Step 5：优先用代码评分器，只在必要时才用 LLM 评分
- Step 6：定期阅读 Transcript，别只看分数
- Step 7：警惕"评测饱和”（接近 100% 时该换更难的题了）
- Step 8：让领域专家持续贡献测试用例，评测套件是活的产品
“瑞士奶酪"多层防线
自动化评测（高频拦截90%）→ 生产监控 → A/B 测试 → 用户反馈 → 人工审查
每层都有漏洞，叠加才能拦住大部分问题。自动化评测负责高频低成本拦截，人工和生产测试处理剩下 10% 的长尾。
核心启示
Agent 开发要从 Vibe Check（感觉法）进化到 EDD（Eval-Driven Development，评测驱动开发）。
评测不只是测试手段，更是产品需求的定义工具——先写出"什么叫好的回答”，开发才有方向。
整理人：hongxinbo | 来源：抖音@老傅1024