基于李博杰《深入理解 AI Agent：设计原理与工程实践》第6章学习笔记。
开篇：一场决定成败的"考试"
想象两位产品经理同时拿到同一款新模型：小张凭直觉——"看起来很强，直接换！"；小李却先掏出自己的考题集，让新旧模型各做一遍，对比分数、算置信区间、跑小样本 AB 测试，两小时后给出结论："换，但先在退款场景压测三天。"一周后，小张的客服 Agent 因为新模型在某个角落的回归（regression）被用户投诉淹没，小李的系统却安然上线。
第 6 章的核心主张正是：评估体系的首要价值不是给当前系统打分，而是让你能快速、可靠地跟上模型演进。 没有度量的 Agent 迭代，只能靠直觉"捡了芝麻，丢了西瓜"。本章从三个层次构建完整的评估体系——评估环境（在哪里测）、评估方法（怎么判）、评估驱动的决策（测了干什么）。
一、两个关键认识：测的是"组合体"，要会"拆分诊断"
认识一：评估的对象不是模型，而是"模型 + Harness"的组合体。 同一模型在不同 Harness 下表现可能差异悬殊，有些团队仅靠优化 Harness 就显著提升了同一模型在终端任务上的表现。因此评估体系必须能区分两类本质不同的问题——"模型能力不足"与"Harness 设计缺陷"。
区分两者的手段是模型替换实验（model swap）：固定 Harness 只换模型。如果换更强的模型分数不涨，瓶颈在 Harness；如果分数随模型能力大幅波动，瓶颈在模型本身。这不同于消融实验（关闭 Harness 的某个组件看整体变化）——前者定位"瓶颈在哪一层"，后者定位"Harness 内部哪个部件重要"。
二、评估环境：两种范式
评估环境需覆盖五个要素：数据集、环境状态、工具接口、评分标准、执行协议。按交互形态分为两类：
| 维度 | 工具调用型评估 | 人机交互型评估 |
|---|---|---|
| 交互对象 | 真实或模拟的工具/API | 模拟用户（User Simulator） |
| 代表基准 | SWE-bench、WebArena | τ-bench、Mind2Web |
| 判定方式 | Verifier 逐步骤检查 | 模拟用户按评分表评判 |
| 关键难点 | 环境重置、状态隔离 | 用户行为的多样性与逼真度 |
工具调用型依赖 Verifier 检查 Agent 是否做出正确工具调用、参数是否合法、状态转换是否符合预期。人机交互型则要模拟真实用户：τ-bench 采用渐进式信息透露（Agent 需要时才给用户提供信息，而非一次性全部给出，考察主动询问能力）与双控环境（记录"用户真实意图"与"Agent 可用信息"两份状态）。
自动评估环境（AEvn） 进一步将两者统一为"两阶段两成分"：环境先按用户指令初始化一个参考场景，再让 Agent 自主探索，最后通过对照检查（如生成的日历安排是否与参考安排一致）判定结果。
三、评估任务数据集：五大核心挑战
- 明确性与开放性的张力：过于明确的指令让 Agent 退化为"填空题"，过于开放则难以自动评分。
- 真实性与可控性：SWE-bench 用真实 GitHub issue（真实但难控），τ-bench 用精心构造的模拟环境（可控但略失真）。
- 多样性与系统性：任务要广覆盖，但样本太少会漏测盲区；成本约束下需用层次化设计——GAIA 按难度分三级，从"读取单文件"到"多工具多步推理"。
- 评估成本：LLM 评判和人工抽检都昂贵，需在设计阶段就规划成本结构。
- 数据泄漏：训练数据污染是最大隐患。对策包括时间切分（只保留模型训练截止日期之后的数据）、去重、人工采样核对。经典案例：SWE-bench 原始版部分测试样本可被"口算"通过，社区人工修正后推出 SWE-bench Verified，GPT-4 通过率从约 29% 提升到约 33%（另一子集）；OSWorld 也历经两轮人工清洗迭代。
任务描述本身的精确性同样关键：指令中应包含判断任务完成所必需的全部约束（如"检查订单是否在 7 天退款期内"），缺失的约束会诱使 Agent 做出偏离预期的行为。
四、评估指标体系：过程指标与结果指标
结果指标回答"任务成了没有"：任务成功率、Pass@k、Pass^k、Best@k。三者差异巨大：
| 指标 | 含义 | 60% 成功率任务示例 |
|---|---|---|
| Pass@5 | 5 次尝试中至少 1 次成功 | ≈99%（乐观） |
| Pass^5 | 5 次尝试全部成功（顺序执行） | ≈7.8%（悲观） |
| Best@k | 让模型自我评估选择最好的一次 | 介于两者之间 |
过程指标回答"走得好不好"：行动合法率、工具调用正确率、路径效率（步数、token 消耗）、检索覆盖率。两者不可偏废——过程指标揭示瓶颈所在，结果指标给出最终判断。安全合规类指标则应设为"零容忍"：只要出现一次泄露凭证等违规行为，无论任务是否成功都应判定失败。此外还应辅以人工抽检 + 对抗式评审，防止 LLM 评判盲区与 reward hacking。
五、自动化评估方法：LLM-as-a-Judge 与 Rubric 四准则
用 LLM 当裁判高效但易被钻空子，关键在于Rubric（评分细则）设计，作者给出四准则：
- 专家指导：评分标准由领域专家撰写，非泛泛的"回答是否准确"。
- 全面覆盖：每个重要质量维度都有独立评分项，防止遗漏。
- 重要性权重：不同维度按对任务成败的贡献加权，而非简单平均。
- 自包含：Rubric 应可独立评估，不依赖上下文就能读懂"好与坏"的标准。
Rubric 还需加入否决项（如幻觉检测）——与质量维度正交，一个流畅礼貌但编造事实的回答，危害远大于简短准确的回答。衡量评判一致性用 Cohen's Kappa（建议 >0.7）。同源模型当裁判易有偏见，可引入多源异构评判；对长输出或含代码的任务，则用多模态 LLM 直接看图、听音、读渲染结果来评分。
配对比较（Pairwise）比绝对评分更稳定，可结合 Bradley-Terry/Elo 模型从成对胜负推断全局排名，但要注意位置偏差（随机交换先后顺序取均值）。示例 Rubric（YAML 形式）：
rubric:
- name: 操作正确性
weight: 0.4
criteria: "退款金额、订单号与工具返回一致"
score_range: [1, 4]
- name: 政策合规性
weight: 0.3
criteria: "动作符合 7 天退款政策"
score_range: [1, 4]
- name: 信息完整性
weight: 0.2
criteria: "告知金额、到账时间、退款编号"
score_range: [1, 4]
- name: 幻觉检测
weight: 0.0 # 否决项
veto: true
criteria: "不得编造工具未返回的信息"
六、统计显著性：别被噪声骗了
分数波动未必是真改进。噪声带宽由样本量与成功率决定：二项分布的标准误约 √(p(1−p)/n)。例如 n=30、成功率 80% 时，标准误约 7%，意味着"涨 5 个百分点"完全在噪声范围内。对策：
- 配对分析：同一测试集上比较新旧版本（McNemar 检验），消除样本间方差，比独立采样敏感得多。
- 多重比较陷阱：同时比较 6 个假设，即使每个 α=0.05，至少一个假阳性的概率约 26%——需做校正（Bonferroni 等）或减少并行比较。
七、从 Benchmark 报告到系统改进：一个完整闭环
作者以 AndroidWorld 假设案例演示"观察→假设→实验→决策"的闭环：
- 观察：Agent 在"打开应用→查找→执行"三个环节频繁失败。
- 假设分层：H1/H2（表层——工具参数错误、界面状态误读）、H3/H4（中层——任务分解逻辑差、误用了参数）、H5/H6（深层——模型语义理解弱、导航逻辑设计缺陷）。
- 实验验证：用 trace 分析统计"错误发生环节"，用模型替换实验区分瓶颈归属。
- 数据驱动决策：H1+H3 成立 → 优先修 Harness（提示词+工具）而非换模型；H6 优于 H5 → 改导航逻辑；H7/H8（条件化思考、手势控制）进入下一迭代。
能力标签矩阵（把任务失败按"能力类型 × 任务类型"交叉统计）能系统定位薄弱环节，避免"修了 A 忘了 B"。
八、生产级内部评估基础设施
- 消融实验：对 Harness 每个组件逐一开关，量化真实贡献。
- AB 测试：线上随机分流比较旧新版本，注意机制 vs 目标指标分开看，并设护栏指标（防性能退化）；小样本时用统计显著性的基线方法判断。
- 特性开关（Feature Flag）：双层开关——编译时（影响模型行为）与运行时（影响系统行为），实现灰度发布。
- 提示词敏感性评估：同一模型不同提示词扰动下分数方差大，说明系统对提示词脆弱，需强化工具设计与验证环节。
- 可观测性：Trace/Span 树记录每次工具调用的输入输出与耗时，OpenTelemetry 提供标准化采集，LangSmith 等平台沉淀轨迹数据；生产轨迹回流评估集可捕捉线上真实失败模式。
九、仿真环境：评估与后训练的桥梁
仿真环境（如 AWorld，提供 126 个工具函数、约 14.6 倍加速；RoboTwin2）兼具评估与训练双重价值：在仿真中定义奖励函数（RLVR），评估脚本即可转化为强化学习信号，形成"评估→训练"闭环。需注意保真度问题——仿真与真实世界差距过大时评估结论会失真，可用领域随机化（随机扰动环境参数）提升泛化鲁棒性。
小结与实践建议
本章核心：评估不是打分，而是决策系统——它让你在模型快速演进的竞争中以小时级速度做出切换决策，并持续区分"模型不行"与"Harness 不行"。
实践清单：
- 建立自有评估集，覆盖两种环境范式与五大数据集挑战；警惕数据泄漏（时间切分 + 去重）。
- 结果指标与过程指标并重，安全合规零容忍，人工抽检兜底。
- LLM-as-a-Judge 必须配 Rubric 四准则与否决项，用配对比较 + 统计显著性下结论。
- 遇到分数下降先做模型替换实验与消融实验，定位瓶颈再动手；用能力标签矩阵指导迭代。
- 生产环境沉淀 trace、回流评估集、AB 测试与特性开关，让评估嵌入 CI/CD。
下一篇进入第 7 章：模型后训练（Post-training）——评估之外，如何用强化学习与数据工程让 Agent 模型本身更强。
