揭秘 AI 智能体评测

Demystifying evals for AI agents

• evals
• agents

一句话总结#

没有评测，团队只能在“修好一个、又坏一个”的被动循环里打转。尽早用 20–50 个来自真实失败的任务起步，选对评分器，读评测记录，并把评测当成需要长期维护的产品资产。

为什么重要#

• 它是评测模块的总论，给出了一套可以通用的术语和流程，后面几篇（基础设施噪声、评测察觉、抗 AI 笔试）都可以放进这个框架来理解。
• 专门针对“智能体”：多轮、有状态、会改环境，错误会累积，模型还会想出评测设计者没预料到的解法。
• 非常可操作：给出了按智能体类型划分的评分方案示例和一份八步路线图。

核心概念（中英对照）#

方法 / 步骤#

1. 为什么要建评测#

• 早期靠手动测试、内部试用和直觉能走很远；但上线、规模扩大之后，没有评测就只能“盲飞”：等投诉、手动复现、修 bug、祈祷别的地方没坏。分不清真回归和噪声，也无法在发布前批量测试。
• 原文举了 Claude Code 的例子：先靠员工和外部用户反馈快速迭代，之后先为简洁性、文件编辑这类窄领域加评测，再扩展到过度工程等复杂行为。
• 客户案例：Descript（视频编辑智能体）按“别弄坏东西 / 照我说的做 / 做得好”三个维度建评测，从人工评分演进到由产品团队定义标准、定期人工校准的 LLM 评分；Bolt 在智能体已广泛使用后才开始建评测，三个月内搭起了包含静态分析、浏览器智能体测试应用、LLM 评委的体系。
• 评测还能加快换用新模型：有评测的团队几天就能完成评估和升级。同时还能“免费”获得延迟、token、单任务成本、错误率的基线，并成为产品与研究团队之间带宽最高的沟通渠道。成本在前期看得见，收益在后期累积，所以容易被低估。

2. 三类评分器#

单个任务的综合方式可以是加权（总分超过阈值）、二元（所有评分器都通过），或者两者混合。

3. 能力评测 vs 回归评测#

能力评测起点要低、要有“可以爬的山”；回归评测接近满分，用来防倒退。能力评测的通过率高了之后，可以“毕业”成为持续运行的回归套件。

4. 四类智能体怎么评（概括）#

5. 非确定性：pass@k 与 pass^k#

• pass@k：k 次中至少一次成功，k 越大越高；适合“只要有一次成功就行”的工具。编码场景通常最关心 pass@1。
• pass^k：k 次全部成功，k 越大越低；例如单次成功率 75%，连续 3 次全部成功约 42%；面向客户、要求每次都可靠的智能体更该看它。
• k=1 时二者相同；k 很大时一个趋近 100%，一个趋近 0。

6. 从零到一的八步路线#

7. 评测与其他手段的配合#

发布前和 CI 中以自动化评测为第一道防线；上线后用监控发现分布漂移；有足够流量时用 A/B 验证重大改动；反馈分诊和每周抽读记录作为常规；系统化人工研究留给评分器校准和主观输出。像瑞士奶酪模型一样，多层叠加。

原文附录还列了一些评测框架（Harbor、Braintrust、LangSmith、Langfuse、Arize Phoenix / AX），并提醒：框架只是工具，真正决定价值的是任务和评分器的质量。

图解#

图 1：智能体评测的组成#

flowchart TB
    Suite[评测套件 suite] --> Task1[任务 task]
    Suite --> Task2[任务 task ……]
    Task1 --> Tr1[试验 trial 1]
    Task1 --> Tr2[试验 trial 2]
    Task1 --> Tr3[试验 trial k]
    subgraph H["评测 harness（并发运行 / 记录 / 评分 / 汇总）"]
        Tr1 --> AH["智能体 harness + 模型<br/>在隔离环境中执行"]
        AH --> TS[记录 transcript<br/>输出、工具调用、推理]
        AH --> OC[结果 outcome<br/>环境最终状态]
    end
    TS --> G[评分器 graders<br/>代码 / 模型 / 人工]
    OC --> G
    G --> S[得分 → 汇总指标<br/>pass@k、pass^k、成本、延迟]

图解：每次试验都在隔离环境中运行智能体 harness 和模型，记录 transcript 与环境最终状态，再交给评分器（graders）打分并汇总指标。

图 2：从零到一的八步路线#

flowchart LR
    s0["0 尽早开始<br/>20–50 个真实失败"] --> s1[1 从手动检查与工单出发]
    s1 --> s2[2 无歧义任务 + 参考解]
    s2 --> s3[3 正反两面平衡]
    s3 --> s4[4 稳定、隔离的 harness]
    s4 --> s5["5 评产出不评路径<br/>部分得分、校准 LLM 评委"]
    s5 --> s6[6 读记录]
    s6 --> s7[7 监控饱和]
    s7 --> s8[8 明确负责人，开放贡献]
    s8 -. 新的失败变成新任务 .-> s1

图 3：能力评测“毕业”为回归评测#

stateDiagram-v2
    [*] --> 能力评测: 新能力，通过率低
    能力评测 --> 能力评测: 迭代智能体（爬山）
    能力评测 --> 回归评测: 通过率稳定很高，“毕业”
    回归评测 --> 告警: 分数下降
    告警 --> 回归评测: 修复后恢复
    能力评测 --> 已饱和: 能解的题全部通过
    已饱和 --> 新建更难的能力评测

图解：能力评测起步时通过率低，靠迭代智能体逐步“爬山”；通过率稳定后“毕业”为回归评测，分数下降就告警；能解的题全部通过说明评测已饱和，需要更难的新题。

图 4：多层评估的“瑞士奶酪”#

flowchart LR
    I[潜在问题] --> L1[自动化评测<br/>发布前 / CI]
    L1 -- 漏过 --> L2[线上监控]
    L2 -- 漏过 --> L3[A/B 测试]
    L3 -- 漏过 --> L4[用户反馈 + 每周抽读记录]
    L4 -- 漏过 --> L5[系统化人工研究]

关键原话#

“it’s often better to grade what the agent produced, not the path it took.” —— 通常更好的做法是评判智能体产出了什么，而不是它走了哪条路。

“Read the transcripts!” —— 去读评测记录！

实践建议#

• 本周就从 bug 跟踪和客服工单里挑 20 个真实失败，写成第一个评测套件。
• 每个任务都配一个参考解，并让另一位同事独立判断“这题算过还是没过”。
• 每个行为都同时测“应该触发”和“不应该触发”。
• 评分优先看环境的最终状态，而不是智能体自己说了什么；不死卡工具调用顺序。
• LLM 评委按维度拆开，允许回答“不知道”，并定期与人工打分对比。
• 每次试验使用全新、隔离的环境。
• 区分能力套件和回归套件，分别设定预期通过率。
• 面向客户的智能体，把 pass^k 加入看板。
• 分数异常（0% 或突然大涨）时，先读记录、查任务和评分器，再下结论。
• 笔者补充：给评测套件建 CODEOWNERS，像管理测试代码一样管理它。

延伸阅读#

站内笔记

• 第 12 篇：SWE-bench Verified 与 Claude 3.5 Sonnet
• 第 13 篇：基础设施噪声 — 第 4 步“稳定环境”的深入案例。
• 第 14 篇：BrowseComp 中的评测察觉 — 第 5 步“防绕过”的极端案例。
• 第 3 篇：为智能体编写高效工具 — 用评测驱动工具改进。
• 第 6 篇：think 工具 — pass^k 的实际应用。

原文引用的资源

• τ2-bench
• Terminal-Bench
• OSWorld
• Harbor 评测框架

本笔记依据 2026-10-17 抓取的在线原文撰写。原文：Anthropic,《Demystifying evals for AI agents》。