[Agentic AI F25] Agent Evaluation 与 Green Agent 项目

LaTeX 源码 · 观看视频

字段	内容
作者/整理	基于课程团队授课内容整理
来源	Berkeley RDI
日期	2026-08-18

课程定位：评估既是测量科学，也是 Agent 基础设施

这讲同时承担两项任务：建立 LLM Agent evaluation 的概念框架，并把课程项目具体化为可运行的 Green Agent。两部分不是行政内容与技术内容的拼接。一个 benchmark 只有被实现成可重复启动环境、驱动 participant agent、收集轨迹并计算指标的系统，才真正具备可用性；反过来，项目代码若没有 outcome validity、污染控制和偏差分析，也只是一个会返回数字的脚本。

为什么 Agent 时代更需要评估

slides 3--8 从最基本的问题开始。evaluation 是对模型和 Agent 的系统性、可重复测量，用来判断能力是否进步、比较方案并决定能否部署。它贯穿训练、开发、模型选择和上线监控。传统 LLM 多为静态 text-to-text；Agent 具有工具、记忆、多步推理和环境交互，输出不再只是文本，而是会改变外部状态的轨迹。因此一次成功截图无法证明系统可靠，必须复现任务、环境和评分过程。

\lecturefigure{slides-images/slide-003.png}{官方 slide 3：LLM Agent evaluation 为什么重要} \lecturefigure{slides-images/slide-004.png}{官方 slide 4：evaluation 的系统性与可重复性定义} \lecturefigure{slides-images/slide-005.png}{官方 slide 5：训练、开发、选择与部署阶段都需要 evaluation} \lecturefigure{slides-images/slide-006.png}{官方 slide 6：公平比较、弱点发现与科学进步} \lecturefigure{slides-images/slide-008.png}{官方 slide 8：从静态 LLM eval 到有工具/记忆/多步环境的 Agent eval}

Evaluation 是决策接口

评估的产出不应只是 leaderboard 分数，而应支持四类决策：是否继续训练、选择哪个模型/Agent、哪个失败模式优先修复、是否达到部署门槛。每个指标都要绑定一个可执行动作；无法改变决策的数字只能算 telemetry，不能算完整 evaluation。

读图：从 output measurement 到 trajectory measurement

静态 LLM eval 通常固定输入并比较输出；Agent eval 还要记录初始状态、可用工具、每一步动作、工具返回、环境变化、终止条件和成本。若只对最终文字评分，模型可能在中间越权、破坏状态或依赖偶然缓存。slide 8 的本质是把评估单位从 response 扩展为 trajectory 与 outcome。

课堂提示：授课团队在开场明确说明，本讲会直接连接 phase-one project。原因是 Green Agent 本身就是 evaluator/orchestrator：它要准备环境、测试 White Agent、验证结果并汇报。项目的工程边界因此来自评估理论，而不是先写代码再补一套 rubric。

什么时候评：训练、开发、模型选择与生产

评估时点会改变数据和指标。训练期需要便宜、频繁、能定位问题的 regression set；开发期比较 prompt、tool policy、memory 与 harness；模型选择要在同协议下做公平比较；部署后则监控真实分布、延迟、成本、安全和 drift。课堂 slide 5 把这些阶段画在同一生命周期上，提醒团队不要把 benchmark 当成发布前一次考试。

阶段	核心问题	推荐证据	典型频率
训练	更新是否学到目标能力	自动 verifier、分桶 reward、轨迹统计	每个 checkpoint
开发	组件改动是否真实改善	固定模型、harness swap、错误归因	每次变更
选择	哪个组合更适合目标场景	盲测、置信区间、成本/质量前沿	发布候选
部署	线上是否持续满足边界	真实任务、漂移、安全、回滚指标	持续监控

不同生命周期阶段的 evaluation 任务

同一测试集不能承担所有职责

频繁调参会让开发者对固定测试集过拟合；生产流量又会出现训练时没有的工具版本、权限和用户行为。应把 smoke/regression、研究 holdout、上线 canary 和事故回放分层管理，并记录数据版本。一个分数在训练期有用，不代表足以批准高风险部署。

本章小结

Agent evaluation 的对象是“模型 + harness + tools + environment”的运行系统。它贯穿全生命周期，并必须为具体决策服务。接下来先建立任务与评分类型，再讨论 Agent-specific taxonomy 和 outcome validity。

任务与评分：Close-ended、Open-ended 与可验证性

评估协议的第一步不是选 judge，而是判断任务输出空间和正确性来源。close-ended 与 open-ended 描述答案空间；verifiable 与 non-verifiable 描述是否存在可执行 oracle。两个维度不能混为一谈：代码生成看似开放，但可由测试验证；多项选择答案封闭，却可能因为题目歧义没有可靠真值。

Close-ended：自动化容易，但协议仍会出错

slides 10--14 说明 close-ended task 的候选答案和正确答案数量有限，因此可用 exact match、accuracy、precision、recall、F1 等自动评分。情感分类、事实问答和选择题是典型例子。自动化降低成本，却不保证测到了真实能力：解析器、标签定义、类别不平衡、prompt 模板和数据污染都可能改变结果。

\lecturefigure{slides-images/slide-010.png}{官方 slide 10：close/open、verifiable/non-verifiable、static/dynamic 三组维度} \lecturefigure{slides-images/slide-011.png}{官方 slide 11：close-ended 与 open-ended 对照} \lecturefigure{slides-images/slide-013.png}{官方 slide 13：情感与事实问答的 close-ended 示例} \lecturefigure{slides-images/slide-014.png}{官方 slide 14：Accuracy、Precision、Recall、F1 与任务边界}

背景概念：Accuracy、Precision、Recall 与 F1

二分类中，Precision $=TP/(TP+FP)$ 表示预测为正的样本有多少真的为正；Recall $=TP/(TP+FN)$ 表示真实正例有多少被找出；$F1=2PR/(P+R)$ 平衡 precision 与 recall。Accuracy 在类别极不平衡时可能误导，例如 99% 样本为负时，永远预测负也有 99% accuracy。选择指标必须对应错误成本。

自动评分不等于客观

Exact match 可能把语义等价答案判错，宽松字符串规则又可能接受错误答案。close-ended benchmark 还可能只覆盖易自动化的窄任务，使团队误以为 Agent 整体能力提升。评估报告应列出解析失败、歧义样本、类别分布和人工复核结果。

Open-ended：先区分 verifiable 与 non-verifiable

slides 15--18 将开放任务进一步分为可验证和不可直接验证。数学证明、代码、环境状态变更虽然输出空间巨大，却可由 math verifier、unit tests 或 state oracle 检查；故事、写作和主观改写没有唯一真值，需要人类或 LLM judge 按 rubric 评价。核心问题不是“答案长不长”，而是是否存在可重复的结果判据。

\lecturefigure{slides-images/slide-015.png}{官方 slide 15：长文本、摘要、翻译与开放生成} \lecturefigure{slides-images/slide-016.png}{官方 slide 16：开放任务分为 verifiable 与 non-verifiable} \lecturefigure{slides-images/slide-017.png}{官方 slide 17：数学、代码和环境结果的可执行 oracle} \lecturefigure{slides-images/slide-018.png}{官方 slide 18：故事与写作等无客观 ground truth 的任务}

先找 oracle，再找 judge

若任务可通过程序、数据库约束或环境状态验证，应优先构造 deterministic oracle，并用 judge 处理解释质量等补充维度。直接用 LLM judge 替代可执行验证，会引入不必要的随机性和偏差。若没有 oracle，则必须把 rubric 拆成可观察维度，并用多评审、校准集和一致性分析控制噪声。

读图：可验证的是 outcome，不一定是整个过程

代码通过测试只验证已覆盖行为，未证明没有隐藏副作用；网页最终状态正确，也可能通过越权操作达到。Agent eval 常需组合 outcome verifier、trajectory constraints 和 safety policy。slide 17 给出 oracle 的入口，后面的 outcome-validity slides 会进一步讨论结果判据如何失真。

Human evaluation：金标准也有速度与一致性问题

slides 19--20 列出人工评估维度：整体质量、流畅性、一致性、事实正确、完整性、风格、语法和冗余。人类能够理解语境和微妙偏好，因此常被视为 gold standard；但人工评估慢、昂贵，存在 inter-annotator disagreement，同一标注者随时间也可能改变标准，而且流程不易完全复现。

\lecturefigure{slides-images/slide-019.png}{官方 slide 19：人工评估的质量维度} \lecturefigure{slides-images/slide-020.png}{官方 slide 20：人工评估的成本、一致性与复现问题}

人工评估不是“找三个人打分”

高质量 human eval 需要任务定义、rubric、正反例、培训、盲测、随机顺序、重复样本和 disagreement adjudication。应报告标注者背景、样本数、一致性指标与置信区间。对专业法律、医疗或安全任务，普通众包偏好不能替代领域专家判断。

老师强调：人工被称为 gold standard，是因为某些开放价值最终由人判断，不是因为人类标签无噪声。项目若把 human score 当绝对真值，会把标注偏见训练进模型。更稳健的做法是让人工负责校准、争议样本和高风险维度，让自动 oracle 承担可验证部分。

LLM as a Judge：扩展速度，也扩展偏差

slides 21--22 介绍用强 LLM 比较或评分候选输出。它便宜、快速、可按 rubric 扩展，且在部分任务上与人类高度相关；问题是 judge 可能不可靠、偏爱特定长度/风格、同源模型、答案位置，复杂推理还可能被表面流畅度欺骗。多次调用、chain-of-thought 或 judge ensemble 能降低方差，却不能消除系统性偏差。

\lecturefigure{slides-images/slide-021.png}{官方 slide 21：LLM judge 与人类评估的替代/补充关系} \lecturefigure{slides-images/slide-022.png}{官方 slide 22：LLM judge 的可靠性、偏差与重复调用问题}

术语消化：Pointwise、Pairwise 与 Reference-based Judge

Pointwise 对单个输出给分，易受绝对量表漂移；Pairwise 比较 A/B，通常更稳定但有位置偏差；reference-based judge 将候选与标准答案或 rubric 对照，适合有参考但不宜 exact match 的任务。Agent 轨迹还可做 step-wise judge，但成本高且会把 judge 的过程偏好注入评分。

Judge 与被评模型不能形成封闭自证

若同一模型家族生成训练数据、优化输出并担任最终 judge，系统可能学会其特定偏好。应使用可执行 oracle、不同来源 judge、人类校准和对抗样本作为外部锚点。报告中要固定 judge 版本和 prompt；在线模型更新会让历史分数失去可比性。

Static 与 Dynamic Eval：稳定比较和持续新鲜度的交换

前面讨论了谁来评分，这里转向测试题本身如何维护。一个 benchmark 若永远不变，会逐渐被训练数据和开发过程吸收；若每次都变，又失去历史比较。因此本小节把稳定 anchor 与动态新题放在同一版本体系中，明确两者分别承担回归和抗污染职责。 slide 23 对比静态 benchmark 与动态 benchmark。固定测试集易复现、易做长期趋势，但会饱和、泄漏并诱导针对性优化；动态 eval 持续或周期生成新任务，降低记忆和污染风险，却增加版本控制、难度校准和跨时间比较的成本。

\lecturefigure{slides-images/slide-023.png}{官方 slide 23：static benchmark 与 dynamic benchmark}

双轨评估策略

保留一个稳定 core set 做回归和历史比较，再用 rotating/dynamic set 检测新能力、污染和适应性。动态题必须保留生成器、seed、难度与 verifier 版本，必要时用 anchor items 将不同批次标尺对齐。新鲜不等于高质量，动态生成同样需要人工审计。

本章小结

任务类型决定评分方法：close-ended 适合自动指标，open-ended 要先寻找 oracle，再决定 human 或 LLM judge。任何 judge 都需要校准，static 与 dynamic 则在可比性和抗污染之间权衡。下一章把这些基础维度组织成 Agent-specific taxonomy。

Agent Eval Taxonomy：能力、应用与广覆盖评估

基础任务类型回答“如何评分”，taxonomy 回答“评分覆盖什么”。课程将 Agent eval 分成三层：specific capability、specific application、general set of applications。三层不是高低等级，而是不同诊断粒度。能力评估便于定位工具调用、规划或记忆缺口；应用评估检验完整工作流；广覆盖套件用于比较通用 Agent 的能力轮廓。

Specific capability：把复杂 Agent 拆成可诊断能力

slides 27--30 汇总 survey 中的能力类别。规划/推理、function calling/tool use、self-reflection、LLM-based evaluation、memory 等都可单独构造任务。能力 benchmark 的优势是控制变量清楚：例如 BFCL 关注函数选择和参数，memory benchmark 关注跨轮信息保留。缺点是模块分数不能自动预测端到端成功，真实应用会把多个能力以时序方式耦合。

\lecturefigure{slides-images/slide-027.png}{官方 slide 27：规划与推理类 Agent capability benchmark} \lecturefigure{slides-images/slide-028.png}{官方 slide 28：Function Calling 与 Tool Use benchmark} \lecturefigure{slides-images/slide-029.png}{官方 slide 29：Self-Reflection 与 LLM-based evaluation capability} \lecturefigure{slides-images/slide-030.png}{官方 slide 30：Memory capability benchmark}

读图：能力名称背后要落到可观察行为

“规划”可以测子目标分解、顺序约束或重规划；“工具使用”可测工具选择、参数、时机和错误恢复；“记忆”可测写入、检索、更新与遗忘。若 benchmark 只用任务名称分类，却没有明确失败判据，不同论文的同名分数不可比较。能力 eval 应输出细分错误，而不只是一个 aggregate。

模块高分不等于组合可靠

Agent 可能分别通过 tool-use 与 planning benchmark，却在真实任务中因计划与工具状态不同步失败。组合系统还会出现错误传播、预算竞争和权限冲突。能力 benchmark 适合诊断和回归，应用 benchmark 才能检查接口契约和长链路可靠性。

Specific application：用真实工作流检验系统闭环

slides 32--36 覆盖 web agents、software engineering、scientific agents、conversational agents 以及医疗、教育、法律、管理和金融等应用。应用评估的任务、工具、数据和用户目标更接近真实环境，能够暴露流程错误；但每个 domain 有自己的安全、许可和专业标准，分数可迁移性有限。

\lecturefigure{slides-images/slide-032.png}{官方 slide 32：Web Agent benchmark} \lecturefigure{slides-images/slide-033.png}{官方 slide 33：Software Engineering Agent benchmark} \lecturefigure{slides-images/slide-034.png}{官方 slide 34：Scientific Agent benchmark} \lecturefigure{slides-images/slide-035.png}{官方 slide 35：Conversational Agent benchmark} \lecturefigure{slides-images/slide-036.png}{官方 slide 36：医疗、教育、法律、管理与金融应用}

应用评估的四层真实性

任务真实性：目标是否来自真实需求；环境真实性：工具、数据和约束是否接近生产；行为真实性：模型是否需要完整交互而非一次生成；后果真实性：错误成本和安全边界是否被表达。为了可复现，benchmark 常简化环境，因此“realistic”应具体说明保留和省略了什么。

课堂提示：应用 benchmark 容易被误用为行业准入证明。课程列出大量论文，是为了展示评估空间，而不是说在某个医疗或法律 benchmark 得分高就可以部署。高风险领域还需专家审查、真实流程验证、监管合规和持续监控。

General set：广覆盖不是简单求平均

能力和应用评估各自聚焦局部，general set 则试图回答模型跨任务迁移是否稳定。本小节关注任务权重和汇总方法：如果没有能力剖面、难度分桶与成本信息，一个总分会把“少数领域很强、关键领域失效”的系统包装成通用 Agent。 slide 38 展示 general Agent benchmark 试图跨任务/应用测量通用能力。这类套件适合比较 Agent 系统的能力轮廓，但任务权重会隐式定义什么叫“通用”。如果 coding 占比过高，综合分会偏向代码模型；若简单任务很多，平均值会掩盖难题失败。

\lecturefigure{slides-images/slide-038.png}{官方 slide 38：General Agent Evaluation 的跨应用集合}

综合分必须带能力剖面

报告总体分时同时给出 domain、难度、工具、轨迹长度和成本分桶；说明权重与缺失数据处理；避免用平均值掩盖安全关键失败。通用 Agent 的目标不是每项相同，而是在任务分布变化时保持可预测、可诊断的性能。

本章小结

能力层负责定位，应用层负责闭环，general set 负责广覆盖比较。一个成熟 eval program 通常三层并存：快速 capability regression、少量高保真 application scenario，以及周期性的 broad suite。

什么是 Good Eval：Outcome Validity 与失效模式

有了任务集合，下一问题是分数是否真的代表目标能力。课程采用 outcome validity 作为核心：评估结果应与任务意图、真实成功和可接受过程一致。一个稳定、可重复但测错目标的 benchmark，仍然是坏评估。

Outcome validity：测到“真正完成”，而不是替代信号

slides 40--41 用 Agent 执行链说明，用户请求经 Agent、工具和环境产生结果，evaluation system 必须判断该结果是否满足意图。若只评分最终回复，可能忽略环境没有改变；若只检查状态，可能忽略回复误导用户；若只看 reward，又可能遗漏成本和违规。

\lecturefigure{slides-images/slide-040.png}{官方 slide 40：Good eval 的 Agent--environment--evaluator 结构} \lecturefigure{slides-images/slide-041.png}{官方 slide 41：Outcome validity 在完整执行链中的位置}

Outcome validity 的三个一致性

意图一致：评分规则对应用户真正目标；状态一致：环境中的事实变化与声明一致；过程一致：达到目标没有违反权限、安全或资源约束。三者至少需要分别观测。Agent “说已完成”不是 outcome，工具返回成功码也不一定代表业务状态正确。

文本、代码、状态变更与多步推理的不同判据

slides 42--45 分别给出四类 outcome。文本结果可检查内容、依据和指令满足；代码生成需构建、测试、静态分析与人工质量；环境状态变更要做 state matching 和约束检查；多步推理既看最终答案，也要防止 shortcut、随机猜中和过程违规。不同 outcome 需要不同 oracle，不能统一成 LLM judge。

\lecturefigure{slides-images/slide-042.png}{官方 slide 42：文本结果的内容、依据与约束判断} \lecturefigure{slides-images/slide-043.png}{官方 slide 43：代码生成的构建、测试与质量验证} \lecturefigure{slides-images/slide-044.png}{官方 slide 44：环境状态变更的 state matching} \lecturefigure{slides-images/slide-045.png}{官方 slide 45：多步推理的答案、过程与一致性验证}

读图：Outcome-specific oracle

文本任务可使用 claim verification、引用检查和 rubric；代码任务使用编译、unit/integration tests、lint、安全扫描；状态任务比较数据库/DOM/API 后态与目标不变量；推理任务可用最终答案、proof checker、步骤约束和重复采样。应把强确定性 oracle 放在主评分，将主观 judge 限于可读性或解释等维度。

测试通过并不证明实现正确

测试覆盖有限、环境可能被修改、随机性可能碰巧成功。代码 Agent benchmark 应隔离测试、保护 verifier、检查 diff 范围并运行 hidden tests；状态任务要验证无关字段没有被破坏；多步任务要检查重复执行是否幂等。Outcome validity 是证据组合，不是单一绿灯。

Ways Eval Can Go Wrong

slide 46 汇总数据噪声/偏差、任务不真实、数据不平衡、shortcut、评估成本与不可靠 judge 等失效模式。更隐蔽的问题是 Goodhart's law：当分数成为优化目标，系统会寻找规则漏洞。Agent 有工具和长轨迹，投机空间比静态模型更大。

\lecturefigure{slides-images/slide-046.png}{官方 slide 46：数据、任务、shortcut、成本与 judge 失效模式}

评估失效审计表

风险	证据	缓解
数据偏差	分桶表现、来源分布	重采样、补充真实长尾
污染	重合检索、异常熟悉度	私有/动态题、时间切分
Shortcut	高分轨迹异常短或违规	hidden checks、过程审计
Judge 偏差	人类校准、位置/长度敏感	随机化、多 judge、oracle
成本失控	token、工具、wall time 分布	预算上限、成本前沿

本章小结

Good eval 的中心不是指标数量，而是 outcome validity。文本、代码、状态和推理需要不同证据；数据、judge 和 harness 都可能失效。下一章用 benchmark case study 检查这些原则如何落地。

Benchmark Case Studies：从目标到数据生成与验证

课程没有只列 benchmark 名称，而是先给出构造问题：目标是什么、Agent 做什么、benchmark 如何评价、数据怎样生成、如何保证质量。读案例时应比较其 task pipeline、oracle、真实性和污染风险，而不是只看榜单。

案例方法：先画数据与执行流水线

slides 48 与 50 把 benchmark 设计拆成目标、任务、测试过程和 data pipeline。一个可维护 benchmark 需要明确任务来源、环境初始化、participant interface、结果收集、评分和质量审查。若数据生成不可复现，分数波动无法归因；若任务目标模糊，再精确的评分也没有意义。

\lecturefigure{slides-images/slide-048.png}{官方 slide 48：案例分析先问 goal、task 与 evaluation} \lecturefigure{slides-images/slide-050.png}{官方 slide 50：good benchmark 的构造与 data pipeline}

Benchmark datasheet 最小字段

任务意图、来源与许可；环境与依赖版本；Agent 可见信息和工具；oracle/metric；成功与失败样例；难度与分布；污染风险；成本预算；已知限制。把这些字段写成机器可读 metadata，才能支持重跑、切分和跨版本比较。

CyberGym：漏洞复现中的容器、补丁与 verifier

slides 51--53 展示 CyberGym：从真实漏洞/补丁构造容器化任务，让 Agent 在代码环境中发现或利用漏洞，并用 PoC、patch 或测试验证。其价值是任务与真实安全问题相关；难点是构建环境、依赖、漏洞可复现性和安全隔离。补丁本身可能泄漏答案，数据生成必须防止把 ground truth 暴露给 participant。

\lecturefigure{slides-images/slide-051.png}{官方 slide 51：CyberGym task、environment、PoC 与 patch pipeline} \lecturefigure{slides-images/slide-052.png}{官方 slide 52：CyberGym 模型表现与案例结果} \lecturefigure{slides-images/slide-053.png}{官方 slide 53：CyberGym 数据生成、复现与 contamination analysis}

读图：安全 benchmark 的双重边界

一方面要让漏洞真实可执行，另一方面不能让实验逃逸 sandbox 或泄漏危险能力。环境应禁用外网、限制资源、记录系统调用并销毁实例；评估应区分找到漏洞、生成有效 exploit、修复漏洞和不破坏其他功能。单一成功率不能概括不同安全目标。

tau-bench 与 tau2-bench：对话、工具和双控制

slides 54--57 描述零售/航空等场景中的对话 Agent。tau-bench 用用户模拟、policy、数据库/API 和任务结果评估工具使用；tau2-bench 进一步让用户侧也能调用工具，形成 dual-control environment，更接近双方都可改变状态的真实流程。数据由 schema、policy 和任务模板生成，成功由最终数据库状态与约束共同判断。

\lecturefigure{slides-images/slide-054.png}{官方 slide 54：tau-bench 的用户、Agent、工具与数据库} \lecturefigure{slides-images/slide-055.png}{官方 slide 55：tau-bench 数据生成、tool schema 与 pass@k} \lecturefigure{slides-images/slide-056.png}{官方 slide 56：tau2-bench 双控制交互结构} \lecturefigure{slides-images/slide-057.png}{官方 slide 57：tau2-bench 数据、验证和可靠性度量}

Pass@k 与可靠性

若同一任务运行 $k$ 次，pass@k 常衡量至少一次成功的概率；生产系统还关心 pass$^k$ 或多次都成功的稳定性。Agent 有随机策略和模拟用户，两者都会贡献方差。报告平均成功率时应同时给重复运行分布、失败类型和成本，否则“一次能做成”会被误解为可靠服务。

Simulator realism 是隐藏变量

用户模拟器若过于合作，会高估 Agent；若语言模式单一，模型可识别 benchmark；policy 与数据库若简化，也会遗漏真实异常。tau 类 benchmark 支持受控比较，不证明所有客服流程都能自动化。应加入 adversarial user、工具故障、权限限制和真实对话回放。

GDPval：专业任务与真实经济价值

前几个案例主要依赖程序化环境，GDPval 则把评估推向专业知识工作。本小节需要同时观察 deliverable 质量、领域专家判断和任务的经济相关性，并警惕把一份可评分产出直接外推为岗位级自动化结论。 slides 58--59 介绍 GDPval，任务来自不同职业的知识工作，强调 deliverable 的现实性和专业评审。它试图把模型输出与经济活动联系起来，而非只测学术题。难点在于专家时间昂贵、任务可能包含机密背景、rubric 主观且不同职业难以放在同一标尺。

\lecturefigure{slides-images/slide-058.png}{官方 slide 58：GDPval 的职业任务与经济相关性} \lecturefigure{slides-images/slide-059.png}{官方 slide 59：GDPval 数据生成、专家评审与局限}

读图：Economic relevance 不等于自动化比例

benchmark 能测某些专业 deliverable 的质量，不直接告诉我们岗位有多少工作可被替代。真实生产还包含沟通、责任、隐性知识、数据访问和组织流程。GDPval 更适合比较模型在工作样本上的能力边界，并发现哪些任务需要专家监督。

CRMArena：业务流程与 hidden state

slides 60--61 将 Agent 放入 CRM 场景，要求理解客户、销售和服务数据并执行多步操作。环境状态复杂、字段关系多，成功不仅是语言正确，还要数据库变更符合业务规则。数据 pipeline 需要 schema、任务模板、初始状态和 ground truth transition。

\lecturefigure{slides-images/slide-060.png}{官方 slide 60：CRMArena 的 CRM 环境、角色与任务} \lecturefigure{slides-images/slide-061.png}{官方 slide 61：CRMArena 数据生成、验证与限制}

业务 benchmark 的权限与幂等性

真实 CRM 有角色权限、审批、重复提交和审计要求。benchmark 若允许 Agent 直接写所有字段，会高估能力并忽略风险。应检查动作是否授权、重复执行是否安全、无关记录是否被修改，以及失败后能否回滚。

LegalAgentBench：长文档、检索与专业判断

slides 62--63 介绍法律 Agent 任务，涉及检索、引用、问题回答和程序化流程。法律文本长、术语精确、时效性强，数据需要律师或可靠来源验证。字符串匹配难以评价论证，LLM judge 又可能被流畅度欺骗，因此要组合 citation validity、source coverage、规则检查和专家复核。

\lecturefigure{slides-images/slide-062.png}{官方 slide 62：LegalAgentBench 的法律任务与工具环境} \lecturefigure{slides-images/slide-063.png}{官方 slide 63：LegalAgentBench 数据生成、验证与限制}

案例对照：oracle 从哪里来

Benchmark	主要 oracle	最难边界
CyberGym	PoC、patch、tests	隔离、复现、答案泄漏
tau/tau2	final DB state、policy	用户模拟与多次可靠性
GDPval	专家 rubric	主观性、成本、职业可比性
CRMArena	state transition、规则	权限、幂等、隐藏关系
Legal Agent	引用、规则、专家	时效、长文档、责任

本章小结

案例表明 benchmark 质量来自任务目标、环境、数据 pipeline 与 oracle 的协同。每个案例都牺牲部分真实性换取复现性，因此必须公开限制。下一章将 benchmark 包装成 Green Agent，使它可以在 AgentBeats 式平台上自动运行和汇报。

Green Agent：把 Benchmark 实现成可运行评估服务

前面的 benchmark 都包含 task、environment、participant 和 evaluator。课程项目将 evaluator/orchestrator 封装为 Green Agent，把被测系统称为 White Agent。颜色只是角色名：Green Agent 代表评估方，负责准备测试、驱动交互、验证 outcome 和提交报告；White Agent 是 participant，不应获得 hidden test、ground truth 或 evaluator 内部状态。

Testing my Agent：从静态题目到多 Agent 协议

slide 65 用考试类比说明，评估者必须独立于考生。Green Agent 不仅发送问题，还可能启动环境、提供工具接口、控制预算、收集消息并在结束后评分。White Agent 则实现待测能力。平台还可能有 participant agents 或环境服务。角色分离是防止答案泄漏和保证可替换性的基础。

\lecturefigure{slides-images/slide-065.png}{官方 slide 65：Green evaluator、White participant 与测试角色}

Green/White 信任边界

White Agent 只能看到完成任务所需的公开接口；Green Agent 可访问 hidden cases、ground truth 和评分逻辑，但不能修改 participant 的输出来“帮助通过”。所有消息、工具调用和环境变更应记录。评估代码与 participant code 分仓或分进程运行，可降低意外泄漏和依赖冲突。

Evaluator 也可能成为攻击面

White Agent 的输出可能包含 prompt injection、超长内容或恶意参数，诱导 Green Agent 泄漏答案或执行危险工具。Green Agent 应把 participant 内容当不可信输入，使用结构化协议、最小权限、超时/资源限制和独立 verifier。评估者不是天然安全的“上帝进程”。

职责与完整 assessment flow

slides 67--69 逐步展开 Green Agent 职责：准备 environment、分发任务、驱动/观察 participant、验证结果并把报告提交平台。完整 flow 从平台确认 agents ready 开始，Green Agent 再 orchestration interaction，最终 metrics 被计算并上传。这个流程把 benchmark 论文中的一次实验变成可重复服务。

\lecturefigure{slides-images/slide-067.png}{官方 slide 67：Green Agent 的准备、交互、环境、验证与报告职责} \lecturefigure{slides-images/slide-068.png}{官方 slide 68：Green Agent 作为 evaluator 和 orchestrator} \lecturefigure{slides-images/slide-069.png}{官方 slide 69：平台、Green、White、environment 的完整 assessment flow}

读图：控制平面与数据平面

平台负责 agent discovery、任务生命周期和结果登记，可视为控制平面；Green/White 消息、工具调用和环境状态是数据平面。控制平面不应理解任务语义，Green Agent 不应承担平台账户和全局调度。边界清楚后，同一 Green benchmark 才能测试不同 White Agent，同一 White Agent 也能接入多个 benchmark。

一次评估 run 的状态机

建议使用状态：CREATED $\rightarrow$ READY $\rightarrow$ RUNNING $\rightarrow$ VERIFYING $\rightarrow$ REPORTED，并为 TIMEOUT、FAILED、CANCELLED 定义终态。每次状态转换保存时间、agent 版本、environment digest 和错误原因。没有显式状态机，网络重试容易重复启动任务或重复计分。

Green Agent 如何构建

slides 70--71 给出典型组成：task loader/selector、orchestrator、environment、metric modules 与 report writer。prompt-based toolkit 可以帮助开发者描述任务和角色，但真实 benchmark 仍需代码初始化环境、处理协议和执行 verifier。课程提醒，有些项目需要 2--3 个 Agent，有些还包含 user simulator、service simulator 或额外 judge。

\lecturefigure{slides-images/slide-070.png}{官方 slide 70：Green Agent 的任务、orchestrator、环境与 metric 组件} \lecturefigure{slides-images/slide-071.png}{官方 slide 71：Prompt-based toolkit 与多 Agent 拓扑}

组件职责表

组件	职责
Task loader	读取公开/hidden case，生成 run-specific task，不泄漏答案
Environment manager	创建、重置、销毁隔离环境，固定依赖与 seed
Orchestrator	发送 kickoff、路由消息、执行预算/超时、判定结束
Verifier/metric	从 outcome/trajectory 计算指标并返回可解释证据
Reporter	生成结构化结果、版本元数据和失败日志，提交平台

课堂提示：Green Agent 的智能程度取决于 benchmark。可执行 unit test 足够时，evaluator 应尽量确定；开放任务可能需要 judge Agent。不要为了“Agentic”而让所有组件都由 LLM 决策，确定性代码更便宜、可复现，也更不易被 participant 操纵。

本章小结

Green Agent 是 benchmark 的运行时封装：它管理环境与交互、保护 hidden evidence、计算 metrics 并报告。角色、权限、状态机和组件边界决定评估能否可信复现。

两类项目路径：集成 Existing Benchmark 或构建 New Benchmark

slide 72 将课程项目分为两类。Type 1 选择已发表 benchmark，完成 AgentBeats 集成并分析原 benchmark 的质量问题；Type 2 从新能力出发构造 benchmark。两条路径都不是简单软件作业：前者必须研究 validity、bias 和 limitation，后者必须证明任务价值、环境真实性与评分可靠。

\lecturefigure{slides-images/slide-072.png}{官方 slide 72：Existing benchmark integration 与 new benchmark 两类项目}

Type 1：集成不等于包装 API

slides 73--74 规定 Type 1 的目标和额外分析。团队要阅读论文/代码，明确 task formulation、数据来源、metric 与已知限制；把原 interface 适配为平台协议；复现实验；再做 benchmark quality analysis，例如 contamination、难度、bias、reliability、environment difference 和 failure mode。

\lecturefigure{slides-images/slide-073.png}{官方 slide 73：集成现有 benchmark 的目标、团队与参考材料} \lecturefigure{slides-images/slide-074.png}{官方 slide 74：除平台集成外还需 benchmark quality analysis}

复现先于改造

先在原仓库/原协议下复现论文基线，再做 Green Agent 适配。否则分数差异无法判断来自 participant、环境版本、接口实现还是 benchmark 本身。保存原始 commit、依赖锁、数据 checksum 和 baseline output，形成迁移前后的证据链。

Type 1 workflow 与 SWE-bench Verified

slide 77 是 progressive build 的最终工作流：integration、benchmark quality analysis、metrics、bias/limitation、correction/expansion。slide 78 用 SWE-bench 与 Verified 说明已有 benchmark 也可能包含难以复现、测试不公平或题目不清的问题；人工筛选和修订可提高 outcome validity，但也改变任务分布，需要公开版本差异。

\lecturefigure{slides-images/slide-077.png}{官方 slide 77：Type 1 的集成、质量分析、指标与修订完整 workflow} \lecturefigure{slides-images/slide-078.png}{官方 slide 78：SWE-bench 与 SWE-bench Verified 的问题筛查}

读图：Verified 的价值和边界

Verified 集合通过人工审查提升 task clarity 和 test fairness，使分数更可解释。它不意味着原集合所有未入选任务都无价值，也不证明新集合没有污染或覆盖偏差。报告应注明 benchmark 版本，并分别讨论 reliability 与 representativeness：更可靠的小集合可能覆盖更窄。

Correction 不能偷偷改标尺

修复测试、环境或题目后，历史分数通常不可直接比较。应发布新版本、迁移说明、受影响 task 列表和 baseline rerun。若只在本地修补却沿用原 benchmark 名称，会制造无法审计的 leaderboard。

Type 2：新 benchmark 从有用场景和可验证 outcome 出发

slides 79--80 要求新 benchmark 覆盖尚未被良好测量的能力，任务应反映 useful real-world scenario，并能持续、低成本生成或维护。数据来源可以是人工、合成、真实日志或其组合；关键是难度、真实性、许可和 oracle。团队还需说明为何现有 benchmark 不足，而不是仅换领域名词。

\lecturefigure{slides-images/slide-079.png}{官方 slide 79：从零创建 benchmark 的目标} \lecturefigure{slides-images/slide-080.png}{官方 slide 80：真实场景、持续数据生成与任务来源要求}

新 benchmark 的 novelty 检查

能力新颖：测到现有套件缺失的行为；环境新颖：引入真实工具/状态约束；测量新颖：更可靠地验证已有任务；数据新颖：覆盖新的分布或动态生成。Novelty 应对应评估价值，而不是为了不同而不同。若只是换数据集，必须证明分布变化会暴露新的失败模式。

可扩展任务生成的质量门

任务生成器应输出 task、initial state、allowed tools、ground truth/constraints 和 provenance；随后经过 schema validation、可执行性检查、难度估计、去重、污染扫描和人工抽样。生成速度不是目标，能持续产生有效、可分离且不泄漏答案的任务才是。

本章小结

Type 1 强调可靠迁移与质量审计，Type 2 强调任务价值与测量设计。两者都要版本化环境和指标，并用 baseline 证明 Green Agent 的实现没有改变原本要测的能力。

Green Agent 设计清单：Task、Environment、Metrics、Test Cases

slides 82--85 给出从目标到测试的四步。顺序很重要：先选要评价的 task，再设计 participant 运行环境，然后定义 metrics，最后用 test cases 覆盖成功、失败与边界。若先写 Agent 再找指标，通常会得到只验证 happy path 的项目。

Step 1：选择明确且有价值的任务

任务描述应包含用户目标、Agent 可用信息、允许动作、终止条件和不可违反约束。例如 ticket-booking agent 不只是“订票”，还包括日期/预算/偏好、库存变化、支付权限和取消规则。一个 benchmark 可以含多个 task family，但每类都要有清楚 outcome。

\lecturefigure{slides-images/slide-082.png}{官方 slide 82：选择要评价的 task}

避免把产品名称当任务定义

“测试客服 Agent”过于宽泛；“在给定订单状态和政策下完成退款，保持审计字段一致且不越权”才可验证。任务越模糊，rubric 越依赖 judge 主观解释，模型也越容易用语言表面掩盖失败。

Step 2：环境必须可复现、隔离且表达真实约束

任务目标确定后，环境决定 Agent 实际能看到和改变什么。本小节从 observation、action、permission 与 reset 四个接口检查复现性：环境既要保留真实约束，又必须隔离外部副作用，并能在每次 run 前回到可验证的初始状态。 slide 83 要求设计 Agent 需要运行的 environment：可交互 UI、数据库、API、工具和隐藏状态。环境初始化要确定，执行后可重置，外部依赖应 mock 或固定版本。若使用真实网络服务，要记录响应或接受不可复现性，并为故障与限流设计测试。

\lecturefigure{slides-images/slide-083.png}{官方 slide 83：环境、网页/API、动作与状态反馈}

Environment contract

定义 observation schema、action schema、permission、timeout、resource budget、state transition 和 terminal condition。Green Agent 只通过 contract 控制环境，White Agent 只获得允许接口。每次 run 保存 initial/final state digest 和 tool trace，便于复现。

Step 3：Metrics 要覆盖成功、质量、成本与风险

slide 84 以订票为例：不仅看是否订到，还看价格、行程是否满足用户要求。通用 metrics 可分 outcome success、constraint satisfaction、trajectory efficiency、robustness 和 safety。多指标可以形成 Pareto frontier；若必须汇总，权重和硬门槛必须公开。

\lecturefigure{slides-images/slide-084.png}{官方 slide 84：Green Agent 的 success rate 与用户约束指标}

硬门槛与软评分分离

越权、数据泄露、环境破坏等应作为 hard fail，不应被高质量文字补偿；价格、步骤数、延迟等可做软评分。总分前先检查硬约束，避免加权平均把严重事故“平均掉”。

Step 4：Test cases 要覆盖失败恢复和 adversarial behavior

slide 85 要求设计多样 test case。除了正常成功，还应有无库存、工具超时、用户改需求、冲突约束、重复消息、prompt injection、非法参数和部分完成。test suite 应分 public examples 与 hidden tests，防止 participant 对固定题目硬编码。

\lecturefigure{slides-images/slide-085.png}{官方 slide 85：多样 test cases 与 rubric 示例}

Test matrix

类别	目的	示例
Happy path	验证基本能力	信息完整、工具正常
Boundary	验证规则边界	预算恰好、日期临界
Failure	验证恢复	API 超时、库存变化
Adversarial	验证安全	注入、越权、答案诱导
Metamorphic	验证一致性	等价改写、顺序变化

Project grading rubric：新建与集成路径的不同责任

slides 87--88 分别给出新 benchmark 和 existing benchmark rubric。新建侧重 goal/novelty、scope/scale、validity、reliability、realism；集成侧重原 benchmark analysis、faithful implementation、quality audit、evaluation validity、reliability 与 correction。共同要求是可复现、文档完整并能解释限制。

\lecturefigure{slides-images/slide-087.png}{官方 slide 87：New benchmark project grading rubric} \lecturefigure{slides-images/slide-088.png}{官方 slide 88：Existing benchmark integration grading rubric}

把 rubric 变成验收证据

每个维度附可检查 artifact：novelty 对应 related-work matrix；validity 对应 oracle tests 与人工审计；reliability 对应 repeated-run variance；realism 对应真实任务来源与简化说明；implementation 对应 baseline parity；analysis 对应错误分桶、bias 和 limitation report。只有文字自评不足以得分。

本章小结

高质量 Green Agent 从任务定义开始，经环境 contract、指标和测试矩阵落地，再用路径特定 rubric 验收。设计顺序能防止“代码能跑但不知道测了什么”的常见失败。

Tau-bench Coding Walkthrough：从论文接口到 AgentBeats

课程最后用 Tau-bench 展示如何把论文 benchmark 转为多 Agent 服务。实现分为 interface analysis、workflow design、kickoff script、Green Agent、White Agent 与平台 integration。重点不是复制代码截图，而是理解每个进程拥有的状态和协议。

先梳理 interface：谁知道答案，谁可以调用工具

slide 91 给出原则：被测 Agent 应能在给定 task 上求解；Green Agent 提供允许的工具并像真实用户一样交互。slide 92 要求先读论文，再读 codebase，写出 task formulation、user simulator、tools、database 和 verifier 的映射。slide 94 的最终 build 指出两个挑战：cross-agent tool use 与迁移原 evaluation。

\lecturefigure{slides-images/slide-091.png}{官方 slide 91：Interface 原则与 Green/White 分工} \lecturefigure{slides-images/slide-092.png}{官方 slide 92：从论文 task formulation 到 codebase} \lecturefigure{slides-images/slide-094.png}{官方 slide 94：跨 Agent tool use 与 evaluation migration 两个挑战}

Interface inventory

列出每个角色的输入、输出、可调用工具、持有状态和秘密：White Agent 持对话与公开工具；user simulator 持隐藏用户目标；environment 持数据库；Green Agent 持 task/metric 与 orchestration；平台持 run metadata。任何 secret 同时出现在 participant prompt 都会造成泄漏。

Workflow：Kickoff、对话、终止与评分

slide 95 给出 workflow：kickoff script 连接平台与 agents，发送启动消息；Green Agent 开始测试并路由交互；结束后调用 metric，提交 report。需要定义谁先发言、turn limit、tool routing、用户模拟结束条件、White Agent 提交 final 的格式，以及异常如何编码。

\lecturefigure{slides-images/slide-095.png}{官方 slide 95：Kickoff script、Green Agent 与 White Agent workflow}

消息 envelope

建议每条消息含 run_id、sender、recipient、type、payload、timestamp、sequence 与 trace_id。Tool result 使用结构化 schema，不把异常堆栈直接拼入自然语言。sequence 防止乱序，run_id 防止并发串线，trace_id 连接平台日志与环境动作。

Kickoff script：最小控制平面

slide 96 的代码展示启动入口。Kickoff 解析 agent card/endpoint，创建或连接 run，向 Green Agent 发送测试请求并等待结果。它不应包含 benchmark 评分逻辑，否则平台调用和 benchmark 语义耦合。重试必须幂等，避免网络超时后重复创建环境。

\lecturefigure{slides-images/slide-096.png}{官方 slide 96：Kickoff script 代码结构}

启动脚本常见故障

硬编码 endpoint、没有 timeout、把 credential 写日志、重试重复计分、进程退出后环境未销毁。应使用配置/secret manager、明确 deadline、idempotency key 和 finally cleanup。脚本越小，越容易在不同平台重用。

Green Agent：Orchestrator、User Simulator 与 Evaluator

slide 97 展示 Green Agent 实现。它加载 task，初始化环境，与 White Agent 多轮交互，必要时扮演用户或调用 user simulator，最后读取 final state 并评分。自然语言交互与确定性 metric 应分层：LLM 可生成用户行为，代码负责权限、状态和硬指标。

\lecturefigure{slides-images/slide-097.png}{官方 slide 97：Green Agent 的 orchestrator 与 evaluator 实现}

Green Agent 内部状态

至少保存 task spec、environment handle、turn count、messages、tool trace、budget、termination reason、raw metric evidence 与 final report。不要只保存聊天文本；数据库 diff、API response 和 verifier output 是 outcome validity 的关键证据。

White Agent：被测策略必须可替换

slide 98 展示 White Agent 作为 participant。它接收用户/Green 消息，调用公开工具，生成回复。benchmark 不应依赖某个特定模型 SDK；用 Agent Card/A2A 或稳定接口描述 capability，使不同实现都能被同一 Green Agent 测试。White Agent 的本地日志可用于调试，但正式评分只依赖 Green/环境侧证据。

\lecturefigure{slides-images/slide-098.png}{官方 slide 98：White Agent participant 实现}

不要让 White Agent 自报成功

participant 的 “done” 只表示请求结束，不是任务成功。Green Agent 必须独立读取环境状态并运行 verifier。若让 White Agent返回 score 或 ground truth comparison，模型可以直接优化自我声明，评估失去可信性。

AgentBeats integration：可发现、可复现、可观测

slide 99 列出实现完成后的平台工作：hosting、access、reproducible/open、report result/trace、package protocol。slide 102 展示 Google ADK 等开发/日志工具。集成的目标是让平台发现 agent、启动相同版本、查看 trace 并获得结构化 metric，而不是要求所有项目使用同一内部框架。

\lecturefigure{slides-images/slide-099.png}{官方 slide 99：AgentBeats hosting、访问、复现、trace 与协议集成} \lecturefigure{slides-images/slide-102.png}{官方 slide 102：ADK 与在线 logging 工具}

可复现发布包

包含源码 commit、容器镜像 digest、依赖锁、agent card、环境变量 schema、任务数据版本、运行命令、sample trace、baseline result 和许可证。秘密与私有测试通过受控存储注入，不进入镜像。平台结果应引用所有 digest，保证半年后能重跑。

可观测性最小集合

run timeline、消息 trace、tool latency/error、token/compute cost、environment diff、verifier evidence、termination reason。公开 leaderboard 可只展示汇总，但项目调试和审计必须保留细粒度证据，并对敏感数据做脱敏和 retention policy。

本章小结

Tau-bench walkthrough 展示了从论文到评估服务的完整迁移：先冻结角色与 secret，设计协议和状态机，再分别实现 kickoff、Green、White 与环境 verifier，最后用可复现包接入平台。接口正确性和 evidence chain 比“代码看起来 Agentic”更重要。

从 Benchmark 到长期 Eval Program：综合设计与 Worked Example

完成一个 Green Agent 只是建立了单次测量能力。真正的 eval program 还要保证指标定义可审计、样本变化可追踪、分数有不确定性、失败能回灌、成本可接受。否则 benchmark 会在几轮模型迭代后失去区分度，或被团队无意中优化成“只会通过测试”的局部目标。

Metric Contract：在跑实验前冻结语义

每个 metric 都应有 contract：名称、单位、输入 evidence、计算公式、聚合方式、缺失值、硬门槛、置信区间和适用范围。Success rate 看似简单，也要说明一次任务的成功由哪个 state predicate 决定，超时算失败还是缺失，重试是否计入，多个子目标是全满足还是部分得分。没有 contract，同名指标会随实现者改变。

Metric contract 示例

订票成功率定义为：在 20 turn 与 $0.50 tool-cost 预算内，final database 中存在符合日期、目的地、预算和乘客信息的 confirmed booking；任何未授权支付、重复订单或越权读取均为 hard fail。该定义同时绑定 outcome、预算和安全，而不是只检查 Agent 回复中出现 “booked”。

聚合也会改变结论。Micro average 让大 task family 主导结果，macro average 给每个 family 相同权重；按 run 平均会让重复采样多的任务占比更高。对安全与高风险任务，不能把 hard fail 与普通低质量用同一连续分数平均。讲义提醒：先写 metric contract，再查看模型结果，可减少“看到数据后改规则”的 researcher degrees of freedom。

版本化 contract 时要区分 bug fix 与标尺变化。修正除零错误可能不改变语义，新增权限硬门槛则会重定义成功。后者应升级 major version 并重跑 baseline。Green Agent 的 report 必须包含 metric version，否则 leaderboard 上的数字没有可比基础。

不确定性：一次运行不是能力估计

Agent 具有 sampling、工具延迟、用户模拟和环境随机性，同一任务重复运行可能得到不同结果。若 $n$ 次独立运行中成功 $k$ 次，点估计为 $\hat p=k/n$，但小样本差异可能只是噪声。应报告二项比例置信区间或 bootstrap interval，而不是把 52% 与 54% 直接宣称为进步。

配对评估优先

比较两个版本时，尽量在相同 task、seed、environment snapshot 和 simulator trajectory 上运行，分析每个任务的成对差异。配对设计能抵消任务难度差异。若工具含真实网络随机性，应多次重复并把 environment error 与 model error 分开标记。

统计显著不等于工程显著。一个 0.5 percentage point 提升在百万请求规模可能有价值，也可能被推理成本翻倍抵消。报告同时给 effect size、置信区间、失败类型迁移和 cost delta。实践经验：对多指标反复挑最好结果会产生 multiple-comparison 假阳性，应预先指定 primary metric，并将探索性发现标注为待复现。

动态 benchmark 还存在标尺漂移。可在每批新题中保留 anchor tasks，用稳定 baseline model 估计难度变化；若 baseline 全面下降，先检查题目/环境，而不是立即解释为新模型退化。对 LLM judge，定期插入人工校准集，检测 judge 版本更新带来的 drift。

污染、饱和与 Benchmark 生命周期

污染不只指训练语料包含答案，还包括开发者反复看 hidden failure、prompt 针对固定 harness、公开 issue 泄漏测试，以及 evaluator 的模板进入模型合成数据。生命周期治理需要控制访问、记录 query、轮换数据、进行近重复检索，并为退役 benchmark 保留历史档案。

“没有公开答案”不等于没有污染

题目可能由公开网页改写，模型见过同源内容；代码任务的 patch 和 issue 可能同时出现在仓库历史；动态生成器也可能重复常见模板。污染分析应比较 task、source、solution 和中间 artifact，并用时间切分与来源隔离降低风险。

饱和时应先判断原因：模型真正掌握、题目太易、verifier 太宽、数据泄漏或 harness 提供过多帮助。直接加难题可能改变能力定义。更好的流程是保留旧 benchmark 作为 regression，发布新版本增加难度/分布，并用共同 anchor 建立 bridge。课堂提示：slide 23 的 dynamic eval 不是一次性替换，而是持续维护责任。

benchmark 应有状态：experimental、active、deprecated、archived。Experimental 可快速迭代但不用于正式排名；active 冻结协议并接受 bug report；deprecated 停止新比较但保留复现；archived 保存 artifacts。Green Agent 发布页应显示状态和 known issues，避免用户把早期项目当成熟标准。

Failure Taxonomy：把分数下降变成可修复信号

Agent 失败至少可分为理解、计划、工具选择、参数、环境观察、恢复、终止、verifier exploit 和安全违规。只记录 success/fail，训练团队无法决定补数据、改 prompt、换模型还是修平台。Green Agent 应输出结构化 failure code，并保留可支持该归因的 evidence。

失败归因的层次

首先区分 infrastructure failure（环境未启动、工具 5xx）和 participant failure；再区分 capability failure 与 policy violation；最后标记 root cause 与 downstream symptoms。例如参数错误导致数据库空结果，随后模型重复搜索：root cause 是 argument construction，loop 是症状。

自动归因可由规则和 judge 辅助，但高影响类别应人工抽样。错误标签本身也要测一致性。每个版本比较 failure transition matrix：哪些旧错误减少，哪些新错误出现。平均分上升但安全违规增加，通常不可接受。老师强调：评估的价值是暴露弱点；一个只给总分、无法定位的 benchmark 很难驱动进步。

失败样本回灌时要避免 test-to-train 泄漏。可抽象成新的 training family、保留原 hidden case、或从同一 failure mechanism 生成变体。事故回放可进入私有 regression set，但访问与训练使用需要隔离，确保最终 holdout 仍独立。

Evaluation Economics：测量本身也需要预算

Agent eval 可能比推理产品更贵：多次采样、长轨迹、外部工具、专家标注和 judge ensemble 都增加成本。评估设计应优化单位决策信息，而不是追求最大测试量。最便宜的规则检查先过滤，只有争议或开放结果进入昂贵 judge/人工；高风险任务即使昂贵也必须保留强验证。

分层评估漏斗

Level 0：schema、权限、静态检查；Level 1：快速 deterministic task；Level 2：完整 sandbox application；Level 3：LLM/human qualitative review；Level 4：小流量 canary。前层失败即可停止后层，减少无效成本。每层都记录覆盖和 false negative 风险。

成本指标至少含 tokens、tool calls、wall-clock、GPU/CPU time、human minutes 和 environment setup。将质量画成 cost-quality frontier，比较同一预算下谁更好，或同一质量下谁更便宜。若新 Agent 只靠 10 倍采样提升 1%，产品是否接受取决于任务价值。讲义提醒：benchmark 默认不计成本会激励不可部署策略。

评估平台自身也需 SLO：任务启动成功率、环境重置时间、结果延迟、重复运行一致性和数据完整性。若平台不可靠，模型分数的方差会被基础设施噪声污染。定期运行 known-good/known-bad canary Agent，验证 evaluator 能正确区分。

Worked Example：企业退款 Agent 的 Green Evaluation

假设要评价企业退款 Agent。Task family 包含正常退款、部分退款、超期申请、重复请求、欺诈标记和用户中途改意。Environment 包含订单数据库、policy service、payment sandbox 和客服对话。White Agent 可读订单、查询政策、发起授权动作；不能直接写数据库或绕过审批。

Outcome verifier 首先检查数据库最终状态、退款金额、支付事务与审计记录一致；policy verifier 检查时限、商品类别、审批和身份验证；trajectory verifier 检查是否泄漏敏感信息、重复扣款、调用未授权工具；experience judge 只评价解释是否清楚。任何财务不一致或越权为 hard fail，文字质量只在硬约束通过后计分。

Test families

正常成功用于基本能力；边界日期检查政策解释；支付 API 超时检查幂等重试；库存/订单状态变化检查重新观察；prompt injection 检查工具输出不被当指令；用户要求违法绕过检查拒绝与升级；重复消息检查不产生双重退款。

Metrics 包括 strict success、constraint satisfaction、unauthorized action rate、duplicate transaction rate、median turns、tool cost 与 explanation quality。每个 case 至少重复三次，报告配对置信区间。Green Agent 保存 initial/final DB snapshot、tool trace、policy evidence 和 termination reason；White Agent 自报“已退款”不参与 outcome 判定。

上线前，离线 benchmark 通过后进入 shadow mode：Agent 生成建议但不执行，人工比较；再对低风险退款做 canary，并设置金额/异常阈值和一键回滚。线上 incident 生成新的 failure family，而原事故 case 留在私有 holdout。实践经验：这一 worked example 展示课程全链路：任务定义、环境、outcome validity、Green/White 协议、metrics、test cases、成本和部署决策必须同时成立。

本章小结

长期 eval program 需要 metric contract、不确定性、生命周期、失败归因和成本治理。Green Agent 提供运行载体，benchmark science 提供可信测量；两者结合，分数才能持续驱动模型、系统和产品决策。

总结与延伸

全讲框架

前面从评估基础走到生产治理，本节将任务、环境、测量、项目与维护压缩成一张总表。读表时应把每行视为必需 artifact，而不是可选文档；任何一层缺失，都可能让高分失去可复现性或真实含义。

层次	核心问题	交付物
层次	核心问题	交付物
任务	要测什么，是否有 oracle	task spec、scope、constraints
环境	Agent 在哪里行动	versioned sandbox、tool contract
评估	分数是否代表真实 outcome	oracle/judge、validity audit
数据	task 如何生成和维护	pipeline、provenance、split
可靠性	重复运行是否稳定	variance、failure taxonomy
项目	benchmark 如何作为服务运行	Green Agent、protocol、report
治理	是否安全、可复现、可审计	permission、digest、trace

十二条核心结论

从 Eval 到 Green Agent

Evaluation 是系统性、可重复的决策接口。
Agent eval 的单位是 trajectory 与 environment outcome。
Close/open 与 verifiable/non-verifiable 是不同维度。
能用确定性 oracle 时，不应只依赖 LLM judge。
Human 和 LLM judge 都需要校准、一致性与偏差报告。
Static core set 与 dynamic rotating set 应双轨运行。
Capability、application、general-set eval 各有诊断职责。
Good eval 的核心是 outcome validity。
Benchmark 必须公开 data pipeline、限制与污染风险。
Green Agent 是 evaluator/orchestrator，White Agent 是 participant。
Existing integration 也必须做质量分析和 baseline parity。
可复现镜像、协议、trace 与 verifier evidence 是项目的一部分。

拓展阅读

Survey on Evaluation of LLM-based Agents：能力、应用与通用评估 taxonomy。
Outcome validity 相关工作：结果是否与真实任务意图一致。
CyberGym、tau-bench/tau2-bench、GDPval、CRMArena、LegalAgentBench。
SWE-bench Verified：benchmark 任务审查与可靠性提升。
AgentBeats、A2A 与 Google ADK：多 Agent 发现、通信与运行工具。

开放问题

当环境无法完全复现时，怎样报告 uncertainty？动态 benchmark 如何保持跨版本可比？Green Agent 如何抵抗 participant prompt injection？如何把安全违规设为硬门槛，同时保留多目标 Pareto 分析？这些问题说明 Agent evaluation 不是 leaderboard 的附属工作，而是未来 Agent 工程和科学方法的共同基础。