为什么这篇在现在特别有用
Agent 一旦开始“真干活”，评测就不能只盯一句回答。它会调工具、改状态、走分支；你要同时看两件事：最后做没做成，以及过程能不能接受。这篇真正有用的地方，不是再发明新词，而是把评测拆成工程里真能用的一组对象：task、trial、grader、transcript、outcome，再用 pass@k / pass^k 区分“偶尔能成”和“稳定能成”。[1]
先看主线
- 主线：为什么难评 → 怎么判分 → 指标怎么读 → 团队如何落地。
- 跳读位：文内
### 深度解析与「官方叙事与可核对事实」。
一、背景：Agent 评测为什么比聊天评测难一档
Agent 会在执行中改计划，这既是价值，也是难点：同一个目标，可能走出多条合法路径。你不能只看“它说了什么”，还得看“环境最后变成什么样”。[1]
文中术语（节选）：[1]
| 概念 | 含义 |
|---|---|
| Task | 单次测试：输入 + 成功标准 |
| Trial | 同一 task 的一次运行；常多次 trial 估稳定性 |
| Grader | 判分逻辑；可有多个 assertion |
| Transcript / trace | 全量轨迹（含工具、推理、中间结果）；API 上常对应完整 messages |
| Outcome | 环境终态（如 DB 里是否真有预订），可与 transcript 表面话术不一致 |
| Eval harness | 跑 eval 的基础设施：环境、并发、记录、聚合 |
| Agent harness | 让模型成 Agent 的脚手架；评的是 harness + 模型 合体 |
| Eval suite | 面向同一类能力的一组 tasks |
前沿模型还可能走出评测未覆盖的「更优解」：原文举 𝜏2-bench 中机票策略 loophole 一例，并指向 Claude Opus 4.5 发布说明——模型在既定评测脚本下可能「失败」却给出对用户更优的做法。提醒：静态步骤匹配易误伤合理创新。[1]
二、演进：从“一个分数”到“多裁判协同”
代码/确定性：字符串匹配、单测、静态分析、outcome 检查、工具调用模式、轨迹统计等——快、客观、易调试，但对合法变体脆弱。[1]
模型-based：rubric、自然语言断言、对比、多裁判共识——灵活，需与人标定。[1]
人类：SME、抽检、A/B——金标准，贵且慢。[1]
可 加权、全过才过或混合。
深度解析：LLM Grader 与「与人标定」债务
事实：模型-based grader 灵活。[1]
原文观点：需与人对齐。[1]
本文解读：每次换基础模型或工具栈，rubric 漂移都可能发生。最好长期保留 金标子集 和 双裁判 机制，否则自动化 eval 很容易“内部一致、对人不准”。
三、机制：能力集与回归集为什么要分开管
Capability / quality：故意选难例，低通过率当「爬坡」指标。
Regression：应接近全过，防迭代把旧能力搞丢。
爬上去的能力集可「毕业」为持续回归集。[1]
四、按场景落地：不同 Agent 的评测抓手
Coding：稳定环境 + 单测（如 SWE-bench Verified、Terminal-Bench 叙事）；可再加轨迹里的工具使用/代码质量 rubric。[1]
对话/客服：终态（工单、退款）+ 交互质量 rubric；常需模拟用户的第二 LLM；𝜏-Bench、𝜏2-Bench 等。[1]
Research：客观题可精确匹配；开放综述要 groundedness / coverage / 来源权威；BrowseComp「难找易验」；LLM 裁判需与人对齐。[1]
Computer use：沙箱真实 UI；WebArena、OSWorld 等；DOM vs 截图在 token/延迟上权衡。[1]
五、指标：pass@k 和 pass^k 到底在回答什么问题
pass@k 回答的是：多试几次，能不能至少成一次。
pass^k 回答的是：连续跑 k 次，能不能次次都稳。
前者偏“探索上限”，后者偏“生产可靠性”。[1]
k=1 时二者数值一致；k 大时叙事可相反。[1]
六、工程化：从第一版评测到持续维护
- 尽早开始：20–50 条真实失败转化即可；别等「几百条完美集」。
- 从手工已在测的开始；生产则挖 工单/支持队列。
- 任务无歧义 + 参考解 证明可解、grader 没写反；0% pass@大量 trial 更常是题坏而非模型废。[1]
- 正负例平衡（例：该搜/不该搜）；避免单侧优化。[1]
- Harness 与产线一致、每 trial 干净隔离，防共享状态造假或脏失败。[1]
- Grader：能确定性则确定性；少绑「固定工具顺序」；部分得分反映渐进成功。[1]
- 读 transcript：区分真错 vs 误判；公平感是 eval 健康度。[1]
- 警惕饱和：全过则只剩回归信号；难例要换新 hill。[1]
- 长期维护：基础设施团队 + 业务贡献题；eval-driven development。[1]
附录列了 Harbor、Braintrust、LangSmith、Langfuse、Arize Phoenix/AX 等工具。实操里更该优先做的，通常不是“再换个平台”，而是先把题目定义和 grader 质量打磨稳定。[1]
官方叙事与可核对事实：工具名录与「题好」
事实：文末列举业界框架。[1]
原文观点：基础设施重要，题与 grader 更重要。[1]
本文解读（推断）：采购 eval 平台前应先问：能否版本化任务集、能否与人审闭环——否则买的是仪表盘，不是质量。
七、边界：eval 很重要，但它不是唯一真相
自动化 eval 只能回答“在你定义的问题上，它今天表现如何”。要避免盲区，仍要和线上监控、A/B、用户反馈、人工读轨迹配合使用（原文用“瑞士奶酪”比喻）。[1]
结论与讨论
技术坐标
这篇最值钱的地方，是把“评测”从抽象 KPI 拉回工程对象：你知道该建什么集合、怎么判分、每个指标到底在回答什么问题。对团队来说，这比任何一次榜单结果都更可复用。
批判性问题
- 你的 grader 是否对 合法创新路径 误杀（静态步骤匹配）？
- Harness 与产线是否真一致——还是 eval 里用了「作弊」工具白名单？
- 全过之后的 饱和 是否让你停止加难例？
独立判断（事实 / 原文观点 / 本文解读）
| 类型 | 内容 |
|---|---|
| 事实 | 原文 URL；术语表与路线图为文内框架。[1] |
| 原文观点 | 多类 grader；能力 vs 回归；瑞士奶酪式互补监控。[1] |
| 本文解读 | 长期收益最大的是 题集治理 + transcript 复盘，而不只是加一个新看板。若业务 KPI 与题集脱节，团队也可能过拟合通过率——文中「饱和」正是在提醒：分数全绿不等于用户问题消失。[1] |
参考文献与延伸阅读
- [1] Demystifying evals for AI agents — Anthropic Engineering，2026-01-09
- [2] Building effective agents — harness / 多轮工具调用主线，与本篇术语互证
- [3] 𝜏2-Bench（arXiv）· GitHub — 原文 loophole 案例出处；𝜏-Bench 为前代设定
- [4] SWE-bench Verified · Terminal-Bench — 文内编码 Agent 基准入口
- [5] Effective harnesses for long-running agents · Agent SDK 概览 — 原文定义 agent harness 时的官方延伸链
- [6] Claude Opus 4.5 — 与 𝜏2-bench 案例交叉引用
附录所列 Harbor、Langfuse 等工具以原文页面及各自官网为准。
若刚接触 Agent：先读本文 第一节术语表，再读 [2] 建立 harness 概念；动手搭 eval 前把 [4] 打开看一眼「行业默认长什么样」。
