四层评测：结果、过程、效率、风险

两个 Agent 都做对了，一个路径清晰可复现、一个反复试错靠偶然命中，只看最终结果会误判为同一水平。

两个 Agent 都把任务做对了：一个规划清晰、四步完成、换一批 case 依然成立；一个反复试错、撞了七次、最后偶然命中。只看最终答案，两者得分相同。但前者的成功可以复制，后者的成功只是运气。评测只记结果，等于把两种完全不同的工程水平算成同一档。

结果对了，不等于做对了

先分清楚两个词。Outcome 是环境的最终状态——数据库里是否真的存在那条预订记录；Transcript 是含输出、工具调用、推理和中间结果的完整记录。Agent 声称「已完成」不等于环境状态已经改变，验收以 Outcome 为准。这一步区分值得做成独立检查项，因为代码里的「完成判断」常常直接采信模型自己的陈述。

长程 Agent 的评测对象也随之改变：短程任务用（query, ground_truth, answer）三元组，长程任务要用（prompt, expected_behavior, trace）。expected_behavior 定义的是预期 Agent 达成的行为而非最终答案，trace 提供真实执行路径供评测。评的是「事情做成没有、怎么做成」，不是「说得好不好」。

前沿模型会顶到这套定义的边界。Opus 4.5 在 τ²-bench 上找到一处政策漏洞，用「违规」的方式把机票订成了——按 eval 的写法算失败，但对真实用户是更好的解。这不是评测写错了，而是提醒你静态 eval 会漏掉创造性解，也会把创造性解判成失败，所以人工抽检不能被机评完全替代。anthropic-evals

τ²-bench 的另一条满分轨迹把反向的问题拍成了照片。telecom 任务的 Agent 政策首段就规定「一次只能发起一个工具调用」，而第 4 条消息里 Agent 同时发出了按号码查客户和按姓名查客户两个调用；两条 env_assertions 均通过，reward = 1.0，验证器没有为此判错——因为这道题的 reward_basis 只聚合最终状态。这不是框架疏漏，而是二元奖励的固有代价：拿过程颗粒度，换一个跨模型可比的单一数字。两个案例互为镜像——一个把创造性解判成失败，一个把违规步骤判成满分。生产环境的评估要的通常更多：不只判对错，还要指出问题出在第几步。ai-agent-book

四层评测结构

评测对象是「模型 + 系统 + 工具 + 流程」的复合体，不是单一模型。美团图灵团队的四层结构可以直接搬用：meituan-agent-eval

归因也要跟着分层。报告不能只给一个分数，要定位问题出在规划、工具、环境还是 Skill——否则评测停留在「单次分析」，驱动不了针对性迭代。

四层还能反过来用：当用例 schema 写。τ²-bench 每条任务的 evaluation_criteria 就是四栏可勾选的校验——env_assertions 校验终态（移动数据可用、测速 200 Mbps 以上且评级为 excellent）、actions 校验关键动作是否真的发生、communicate_info 与 nl_assertions 校验必要信息有没有告知用户；最后由 reward_basis 决定这几栏如何聚合成一个分数。ai-agent-book 区别很实在：四层不是跑完之后报表上的四个口径，而是写用例时就得填进去的四栏——先声明这一题要校验哪几层，分数只是它们的一个聚合视图。

过程层要有东西可测，环境就不能把话说完。同一批任务把 known_info 限定为姓名、号码、所在国家三项，真正的故障原因（飞行模式开着、数据漫游关着）不在其中，Agent 只能靠提问引导用户去查；用户侧另有一套独立工具（check_status_bar、toggle_airplane_mode、run_speed_test），故障恰好落在运营商数据库看不见的那一侧。反过来，模拟用户必须被约束成「关于设备状态的任何回答都以工具返回为依据」，否则它会顺着 Agent 的引导确认问题已解决，评估就退化成两个模型互相确认。ai-agent-book

桥梁指标：让业务指标和 Agent 指标说得上话

离线指标涨了却说不清业务收益，是 Agent 评测最常见的失信方式。原因是指标体系中间缺了一层：业务指标（DAU、留存）和 Agent 层指标（意图识别准确率、检索有效性）不能直接映射，中间要有系统指标（召回、点击）把它们串起来。这三层桥梁必须由懂业务流程的人参与共建，否则你既回答不了「业务指标为什么变差」，也回答不了「模型能力提升为什么没带来业务收益」。meituan-agent-eval

人机一致率是机评的置信前提

主观指标不能直接丢给模型评。先把模糊指标下钻成多条 Rubric，再尽量二元化——是 / 否 / unknown。unknown 的占比是 Rubric 质量的探针：占比高说明这条问得含糊，该改的是定义而不是模型。

然后测两件事：人人一致率（不同人评同一条是否一致）和人机一致率（机器与人是否一致）。达到可信阈值（例如 85% / 90%）之前不允许机评规模化——人机一致率无保障的机器输出只是机器标注，不是自动化评测。美团 Beam 的二元化改造把人机一致率从 62% 推到 92%，数字站长达 99%。

评分问题当形式化规格来写

Rubric 不是「描述一下什么叫好」，而是拿给 judge 的规格书。Google 的四条设计原则 google-rubric：问题原子且不重叠——复合问题（「响应含 metadata 且输出为 JSON 吗」）逼 judge 猜哪个子句更重要，拆成独立 TRUE/FALSE；同一概念不测两遍，重叠会对单一错误双重惩罚。只评客观事实——用 RFC 2119 术语（MUST / MUST NOT）写规格，测负向约束（查「未建议废弃特性」而不是「是否用了最佳实践」），不评意图、质量这类需要解释的概念。只评 prompt 明确要求的内容——prompt 没要求引用就不因缺引用扣分；评目的地不评路径，不查 agent 是否用了特定工具，要评过程就让 agent 输出执行计划、评计划本身。上线前用 golden set 校准——先让领域专家人工标注，跑 judge 对比人工分，不一致通常说明 rubric 太歧义，迭代到对齐才上线。附带收益很实在：评严格布尔事实是更简单的任务，可以用更小更快的模型打分。

Judge prompt 本身也有四条工程规矩 aliexpress-eval：一个 prompt 只评一个指标——实测混合打分会让两项准确率都下降；先输出推理再给结论，失败时可解释；带上通过/不通过的对比样例做负例引导；严格 JSON 输出并给格式模板。判定通过与否时，每类数据集由一个主指标单独决定（端到端看完成率、模糊意图集看澄清率——追问优于猜测），其余指标只用来定位短板，不做全指标 AND——一个 case 挂多个指标时，AND 会把模块短板误判成整体失败。上游出错时下游指标标 skip 而不是 fail：路由决策错了，检索指标就不再反映检索模块的能力。幻觉评测的边界同理要划窄：只判 agent 是否忠实转述它获取的知识片段、工具返回与对话历史，不判信息来源本身对错——agent 是信息处理器，不是信息鉴定器。

标准由一个人拍板，分歧转为策略分支

标准未对齐时，你无法区分指标提升是真实效果还是标准抖动。所以评测标准要有单一负责人拍板拉齐：一个「独裁者」好过十个「民主者」，分歧时由他决定。

但专家之间的分歧不必强行统一。分歧往往意味着业务上确实存在多种优秀策略——AI 电销的激进派和细水长流派都能成单。共性部分建成评测体系，分歧部分转化为 Agent 的风格或策略分支，在不同测试集上分别评测，而不是当噪声抹掉。

起步阶段不要设计复杂精妙的体系：越复杂的指标越难执行和对齐，「让数据飞轮转起来」比「设计完备指标」重要。靠 Bad Case 暴露能力边界、Good Case 定义高质量范式持续喂养，美团履约数字站长一年从 20 余个指标扩展到近 200 个，是长出来的，不是设计出来的。meituan-agent-eval

评测闭环：从失败数据到系统自进化

评测如果仅仅停留在生成报表和打分排名，那么它就只是一道事后检验的关卡，无法从根本上帮助智能体持续变强。

企业级系统对评测的最终期待，是把评测过程中暴露出的每一次失败，转化为生产环境中的防护资产：

一方面，针对风险层暴露出的违规行为（例如智能体试图越权执行未授权的删除命令），系统不应仅仅在报表里记一次扣分，而应自动提取该动作的模式特征，直接将其转化为 Hooks 拦截器 在工具执行前的确定性拦截规则，确保同样的风险在生产环境中绝无发生的可能。

另一方面，针对过程层暴露出的推断偏差与工具误用，评测框架应提取首个致偏步骤的上下文切片，沉淀为回归测试集的一部分，并且引导离线经验学习管道提炼针对性的策略指引。

这种让评测直接反哺治理与规则制定的机制，在 保存经历不等于从经历学习 中有完整的工程实现展开。只有打通了「运行发现问题 → 评测精确定位 → 规则自动提炼 → 回归验证准入」这条闭环，四层评测才算真正发挥了它的核心工程价值。