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

两个 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%。

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

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

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

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