适用读者：要判断"这个 Agent 能不能上线"、要设计评估集、要读厂商 benchmark 报告的人。
前置：S21-A01（评估与可观测）、J12（完成标准）。
覆盖旧文：A-4573（Agent 的评估，第 7 章，47,920 字符）→ 44 小节 / 约 4.8 万字符。
扩展点：E-S21-044（任务的四段定义）、E-S21-045（Pass@k 与 Pass^k 的分工）、E-S21-046（评估环境五要素 + 选型六维）。
上一篇：S21-J13 · 交互：观察与动作空间的扩展（模态与时机）
下一篇：S21-J15 · 模型后训练。
1. 一句话结论
Pass@k 衡量"能不能偶尔创造奇迹"，Pass^k 衡量"能不能每次都不出错"。 支付、退款、权限变更、生产部署这类场景，看的是后者。评估报告若不写清 k 次尝试的口径，数字就没有意义。
出处：《AI Agent 深入理解》第 7 章（
A-4573）。
$$
\mathrm{Pass@k}=1-(1-p)^k,\qquad \mathrm{Pass}^{k}=p^k
$$
复算：$p=0.6$、$k=5$ → Pass@5 $\approx 99.0%$，Pass^5 $\approx 7.8%$。同一组数据，两个结论完全相反。
2. 一条任务的四段定义（E-S21-044）
以 τ²-bench telecom 域为参照：
| 段 | 存什么 | 设计要点 |
|---|---|---|
| ticket | 给 Agent 的工单 | 只给现象（"上不了网"），不给根因 |
| user_scenario | 模拟用户的行为规范 | known_info / unknown_info / task_instructions |
| initial_state | 运行前的重置脚本 | 两侧状态都回同一起点 |
| evaluation_criteria | 评分标准 | 动作检查 + 环境断言 + reward_basis |
四个精妙处：
| 设计 | 做法 | 防的是什么 |
|---|---|---|
| 渐进式信息透露 | 把用户"不知道什么"建模成独立字段 | 多数基准一开局就给完整需求 → 考不出澄清能力 |
| 事实锚定 | 用户回答设备状态必须以工具返回为依据 | 否则模拟用户会被 Agent 忽悠着说"解决了" |
| 验收口径写死 | 只有测速 excellent 才算解决，good 不算 |
否则标准随对话漂移 |
| 信息不对称 | 故障在用户侧（飞行模式/漫游关），Agent 查库只能看到"配置正常" | 逼 Agent 学会引导用户排查 |
判据："用户多知道一点，任务就简单一分"。 评估设计的核心技巧，是控制信息不对称的程度。
3. 指标分工：能力上限 vs 业务可靠性（E-S21-045）
| 指标 | 定义 | 用在 |
|---|---|---|
| Pass@1 | 单次平均成功率 | 日常场景 |
| Pass@k | k 次里至少成功一次 | 探索型任务（给足机会的能力上限） |
| Pass^k | k 次全部成功 | 关键操作（每次都别出错） |
| Best@k | k 次里最好的那次 | 能力天花板 |
口径必须写清：k 次是同一任务的独立采样，还是生产流水线上连续 k 个任务。二者含义不同，混用会得出错误结论。
副作用处理：会产生副作用的操作不能"重试直到成功"——必须在沙盒/可回滚环境中采样，并把每次失败都计入可靠性指标。
4. 评估环境五要素（E-S21-046）
| 要素 | 内容 | 缺了会怎样 |
|---|---|---|
| 数据集 | 初始状态 + 工单 + 用户规范 + 验收标准，一条记录 = 一个用例 | 无法复现 |
| 环境状态 | 数据库记录 + 设备开关 + 剩余流量；必须可重置 | 两次运行不同起点 |
| 工具接口 | 两侧原子操作；不要高层抽象 | 抽象过高 → 考不出规划，退化为单次函数调用 |
| 评分标准 | 四层检查 + 聚合规则 | 结论不可比 |
| 执行协议 | 终止信号（如 ###STOP###）、轮数上限、耐心耗尽 |
无限对话 |
两类环境：
| 类型 | 有无对话方 | 考什么 | 例子 |
|---|---|---|---|
| 人机交互型 | 有（用户模拟器） | 沟通与引导策略 | τ²-bench telecom |
| 工具调用型 | 无 | 可观测状态变更的正确性 | 代码/数据/数学（测试代码判定） |
Verifiers 四类环境（按"跨轮状态 × 隔离"）：
| 环境 | 状态 | 工具 | 用例 |
|---|---|---|---|
SingleTurnEnv |
无 | 无 | 单轮问答、数学 |
ToolEnv |
无 | 多轮 | 搜索+综合 |
StatefulToolEnv |
有 | 多轮 | 改数据库 |
SandboxEnv |
有+隔离 | 多轮 | 跑代码+测试 |
要点：工具失败要返回清晰错误，而不是单一失败标志——否则 Agent 无法据此调整策略（接 J12 §5）。
5. 数据集设计的五个关卡
| 关卡 | 做法 |
|---|---|
| 难度分层 | 明确"简单/中等/困难"的判据，别只靠感觉 |
| 验证器 | 优先可执行断言（环境状态/测试），其次 LLM-as-a-Judge |
| 防泄漏 | 检查训练集与评估集重叠；防止"背答案" |
| 质量控制 | 双人标注/抽检；记录争议用例 |
| 长期维护 | 定期换题、版本化、保留旧版结果以便对比 |
失败归因：从整条轨迹定位首个错误，而不是只看结尾对错——否则永远不知道"错在哪一步"。
6. 选型六维：别被单点分数骗了
| 维度 | 要点 |
|---|---|
| 吞吐 | 输入吞吐（Prefill） vs 输出吞吐（Decode） |
| 延迟 | TTFT = 排队 + Prefill；p95 尾部延迟比均值更能反映体验 |
| 思考延迟 | 不同模型思考 token 数差数倍，且思考长度与效果不一定正相关 |
| 成本 | 便宜但成功率低 → 重试导致总成本更高；要算"每任务平均成本" |
| 性能 | Pass@1 / Pass@k / Pass^k / Best@k，按场景选 |
| 额度与鲁棒性 | RPM/TPM、高峰期限额、分布外与对抗输入、长时稳定性 |
预算—能力曲线：固定预算的单点成绩不足以判断长程能力。原文引述 RE-Bench 人机对照：每环境 2 小时预算下最佳 Agent 约为人类专家 4 倍；8 小时人类略超；累计 32 小时人类约为其 2 倍（属引述，待复算）。短预算领先不能外推成长时间优势。
7. 统计显著性：三个点的提升是不是噪声
| 做法 | 说明 |
|---|---|
| 配对比较 | 同一批任务上比较两个模型，而不是各自跑不同题集 |
| 置信区间/重复采样 | 报告方差，不只报点估计 |
| 多重比较校正 | 反复试多种配置，必然"发现提升"，要校正 |
判据：没有方差信息的"提升 3 个点"不是结论。 评估集越大，方差越小，但边际成本上升——先算清"要检出多大差异需要多少样本"。
8. 生产级评估基建
| 件 | 作用 |
|---|---|
| 消融基础设施 | 关掉某个特性，看它真实贡献多少 |
| A/B 测试 | 区分"机制"与"目标"——机制改了，目标指标是否真的动 |
| 双层特性开关 | 一层控制功能、一层控制模型/提示词版本 |
| 提示词敏感性评估 | 同一任务换措辞，看结果波动——波动大说明系统脆 |
| 隐私感知分析 | 评估数据本身不得泄露用户信息 |
仿真环境是评估与后训练的桥：保真度权衡（太真则贵、太假则无效）+ 领域随机化（防过拟合到窄分布）。这一条直接接 J15。
9. 反例与排障
| 现象 | 根因 | 处理 |
|---|---|---|
| 榜单很强、上线很差 | 看的是 Pass@k / 单点分数 | 改测 Pass^k + 自有工作负载 |
| 用户模拟器"配合演出" | 缺事实锚定 | 用户回答必须基于工具结果 |
| 评估跑两次结果不同 | 环境不可重置 | 写 initialization_actions |
| 数字好看但成本爆炸 | 只看单价不看重试 | 算每任务平均成本 |
| "改进了 3 个点" | 无配对/无方差 | 配对 + 置信区间 |
10. 自测
- $p=0.6$、$k=5$ 时 Pass@5 与 Pass^5 各是多少？业务该看哪个？
- 任务定义里为什么要单独建模"用户不知道什么"？
- 评估环境五要素，缺"可重置"会怎样？
- 为什么"重试到成功"不能当可靠性指标？
答案
- ≈99.0% 与 ≈7.8%；关键操作看 Pass^5。
- 考出需求澄清能力；否则一开局就给完整信息，任务被简化。
- 两次运行起点不同，结果不可比、不可复现。
- 重试隐藏了失败率；有副作用的操作还会造成真实损害。
11. 下一篇
S21-J15 · 模型后训练 —— 预训练 → Mid-training → SFT → RL 的四阶段分工、SFT 记忆与 RL 泛化的机制解释、"数据与环境比算法更重要"的三条经验（待写，章 8）。
本篇属于系列《S21 · Agent 工程与 MCP》。旧文来源：A-4573（第 7 章）；扩展点 E-S21-044/045/046。Pass@5≈99.0% 与 Pass^5≈7.8% 为按公式复算；RE-Bench 曲线与厂商数据属引述待核。