Agent Evaluation 的三层结构
一句话收获：评估不是给答案打一个分，而是建立环境、方法和决策闭环。
这个场景在解决什么问题
怎么知道一个 Agent 到底行不行？很多人以为"评估"就是给它的答案打个分（比如 8 分）。但这是错的——评估要解决的不是"答案好不好看"，而是"能不能可复现地测、用什么方法验证、测完能不能做准入决策"。
这个场景的目标（goal）是：实现可复现环境、验证方法和准入决策。观察点（observation）是：从一个冻结任务构建完整评估链——拿一个被"冻结"的任务（环境、输入都固定），搭起从环境到方法到决策的完整评估链。
它值得单独学，因为它纠正了"评估=打分"的误解：评估是建立环境、方法和决策的闭环，分数只是中间的一环，只有进入决策才有工程价值。
先理清这条判断链（文字版）
评估是一条三层链，从下往上：先保证环境可复现，再定"成功"的验证方法，最后把结果变成决策：
- 先看评估环境——固定初始状态、工具、数据、模型和 Harness，还能重置，先保证可复现。
- 再看成功义务——把对象、状态、权限、证据、成本和停止拆成可验证条件，完成由独立义务决定。
- 然后看验证器分层——确定字段用程序、开放语义用 Rubric 或 Judge，优先用确定性证据。
- 最后看评估决策——按可靠性、失败类型、成本、风险决定准入、灰度或回退，保护指标和红线同时检查。
逐层详解
第 1 步：评估环境
原文：固定初始状态、工具、数据、模型和 Harness，并能重置。
白话：评估的第一步，是把运行环境"钉死"——初始状态、能用的工具、喂的数据、用的模型、跑在哪个 Harness（运行框架），全都固定下来，并且能一键重置回初始状态。
类比：像做科学实验，得先固定实验条件（同样的试剂、同样的温度、同样的仪器），并且每次都能恢复到初始状态，否则两次实验结果没法比。
举例：评估"订单处理 Agent"，固定初始状态=一个干净的测试数据库、固定工具集、固定测试数据、固定模型版本、固定 Harness 配置，跑完一次能重置回初始，再跑第二次。
为什么重要：环境不稳定时运行结果不可比较。如果每次跑的环境都飘来飘去（数据变了、工具变了、模型换了），那两次结果根本没法比较，评估就失去意义。
怎么验证（证据点）：
- 初始状态：初始状态是被明确定义和固定的。
- 版本冻结：数据、工具、模型的版本都冻结。
- 清理方式：有明确的清理/重置方式能回到初始。
别踩的坑（边界）：同一文字任务不等于同一运行环境。两个"文字上一样"的任务描述，如果背后环境不同（数据不同、工具不同），就不是同一个运行环境，结果不能直接比。
落地检查：先保证可复现。落地时的第一优先：先让环境能复现，环境不可复现，后面评估全是空中楼阁。
第 2 步：成功义务
原文：将对象、状态、权限、证据、成本和停止拆成可验证条件。
白话：评估"成功"不能只看最终答案，要把成功的标准拆成一条条"义务"（obligation）：操作的对象对不对、状态对不对、权限有没有越界、证据全不全、成本超没超、什么时候该停止——每条都变成可验证的条件。
类比：像验收一个装修工程，不能只看"房子看起来还行"，要拆成"水电通没通、墙面平不平、预算超没超、有没有按时交房"一条条验收。
举例："订单处理"的成功义务拆成：对象=改的是正确的那个订单；状态=订单状态最终是"已完成"；权限=没越权动别的订单；证据=有操作留痕；成本=调用次数在预算内；停止=到达终止条件后确实停了。任何一条不满足都不算成功。
为什么重要：最终答案可能掩盖局部越界。只看最终答案"对不对"，可能掩盖了过程中偷偷越权、偷偷超成本的问题——答案对，但过程违规，也不能算成功。
怎么验证（证据点）：
- 义务清单：成功义务被拆成清单列出来。
- 外部证据：每条义务有外部证据支撑。
- 否决条件：有"一票否决"的硬条件（比如越权直接失败）。
别踩的坑（边界）：运行结束不能作为唯一成功标准。程序跑完了、没报错，不代表成功——"跑完了"只是最弱的标准，成功要由独立的义务来决定。
落地检查：完成由独立义务决定。落地时"完成"不能由 Agent 自己说，要由一套独立的义务清单逐条判定。
第 3 步：验证器分层
原文：确定字段和状态用程序，开放语义用 Rubric 或 Judge，并抽查一致性。
白话：验证器要分层：能确定的东西（字段对不对、状态对不对）用程序断言来验；开放的语义（这回答写得合不合理）用 Rubric（评分标准）或 Judge（LLM-as-a-Judge，用大模型当裁判）来评；同时要抽查这些验证器之间的一致性。
类比：像阅卷，选择题用机器判（程序断言），作文题用评分标准或老师来判（Rubric/Judge），还要定期抽查老师判得准不准（一致性）。
举例："订单状态是不是'已完成'"这种确定字段，用程序断言直接查数据库；"给用户的解释是否清晰得体"这种开放语义，用 Rubric 打分或让 Judge 模型评；还要抽几条，看看程序断言和 Judge 的判断是否一致。
为什么重要：不同对象需要不同证据强度。确定性的东西要强证据（程序直接验），开放的语义只能弱证据（评分/裁判），不能用同一种方式验所有东西。
怎么验证（证据点）：
- 程序断言：确定性字段/状态用程序断言验证。
- 来源核验：涉及事实的，核验它的来源。
- Judge 边界：明确 Judge 能验什么、不能验什么。
别踩的坑（边界）：LLM-as-a-Judge 不能验证权限和外部写入。让大模型当裁判，只能评"语义好不好"，它没法验证"权限有没有越界""外部系统有没有被写对"——这些必须用确定性手段。
落地检查：优先使用确定性证据。落地时的原则：能确定验证的，优先用程序/确定性证据，Judge 只用来兜那些确实开放的部分。
第 4 步：评估决策
原文：根据可靠性、失败类型、成本和风险决定准入、灰度或回退。
白话：评估的最后一步，是把分数变成决策——根据可靠性（稳不稳）、失败类型（怎么失败的）、成本、风险，决定这个 Agent/改动是"准入"（正式上）、"灰度"（小范围试）、还是"回退"（退回去）。
类比：像考试成绩不只是个数字，还要据它决定"能不能录取、要不要先试读、还是直接拒"。
举例：评估完订单 Agent，发现可靠性 99%、失败主要是边界小错、成本可控、风险低，决策=准入上线；如果可靠性 80%、有越权风险，决策=回退重做或灰度小范围试。
为什么重要：分数只有进入决策才有工程价值。一个 8 分，如果不落地成"上还是不上、灰度还是回退"，就只是个数字，没有工程意义。
怎么验证（证据点）：
- 样本与重复：样本量够不够、有没有重复运行看稳定性。
- 失败分布：失败集中在哪、是什么类型。
- 决策门槛：准入/灰度/回退的门槛是事先定好的。
别踩的坑（边界）：平均分提高不证明所有边界改善。平均分上去了，可能是"大部分简单题做对了"，但关键边界/红线反而更差了——平均分不能代表边界都变好。
落地检查：保护指标和红线同时检查。落地时不能只看平均分，要同时检查"保护指标"（不能退化的底线）和"红线"（绝对不能碰的硬条件）。
落地可行性小结
本场景涉及的核心技术栈：Harness（运行框架）、可复现环境（冻结初始状态/工具/数据/模型）、成功义务（obligation）、程序断言、Rubric（评分标准）、LLM-as-a-Judge（大模型当裁判）、准入/灰度/回退决策。
真实落地要检查的事：
- 评估环境要冻结初始状态、工具、数据、模型、Harness，并能重置。
- 成功标准要拆成对象/状态/权限/证据/成本/停止的可验证义务，设否决条件。
- 验证器分层：确定性用程序断言，开放语义用 Rubric/Judge，并抽查一致性。
- 决策要有事先定好的门槛，同时查保护指标和红线，不只看平均分。
常见坑：
- 环境不稳定就开测，结果不可复现、不可比较。
- 只看最终答案，掩盖了过程中的越权和超成本。
- 拿 LLM-as-a-Judge 去验证权限和外部写入（它做不到）。
- 只盯平均分，忽略红线失败，以为"整体变好"。
回顾
- 评估不是打分，是"环境 → 方法 → 决策"的闭环。
- 评估环境必须冻结初始状态/工具/数据/模型/Harness，保证可复现。
- 成功由独立义务决定（对象/状态/权限/证据/成本/停止），不是"跑完就算"。
- 验证器分层：确定性用程序断言，开放语义用 Rubric/Judge，优先确定性证据。
- 分数只有进入准入/灰度/回退决策才有价值，且要同时查保护指标和红线。