Agent 的评估

用哪个模型、给哪些工具、知识库存什么、记忆怎么做、提示词和 Skills 怎么组织、Harness 加哪些约束，这些设计选择都没有一眼就能看出的正确答案。评估用两种实验来做决定：对比实验一次只改一个变量，看效果怎么变；消融实验一次关掉一个组件，看它到底贡献了多少。

公开基准上更强的新模型，在你的任务上未必更好，甚至可能退化。只有在自己的评估集上跑一遍，才能做出数据驱动的升级决策。评估集建好以后，还可以“为未来的模型开发产品”：先把产品和评估集做出来，持续跟踪新模型，一旦达到门槛就上线。

τ²-bench 是 Sierra 开源的评估框架。我们取 telecom 领域里的一条任务：用户在法国，手机显示“No Service”，上不了网。真正的故障是两件用户自己都不知道的事：飞行模式开着，数据漫游关着。

一条好的任务定义，把“用户知道什么”“用户怎么说话”“状态从哪开始”“怎样才算解决”四件事都写进了数据结构，而不是靠一句提示词去约束。

// 删节版 · data/tau2/domains/telecom/tasks_small.json
"id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off",
"ticket": "用户手机无法上网，状态栏显示'No Service'。客户 John Smith，号码 555-123-2002，
           当前在法国。速度测试结果为 excellent 才算解决。不更换套餐，必要时愿意充值 2.0 GB 流量。",
"user_scenario": { "instructions": {
  "known_info": "You are John Smith with phone number 555-123-2002. You are currently abroad in France.",
  "unknown_info": null,
  "task_instructions": "…express mild frustration after the first unsuccessful attempt.
     You will consider the issue resolved only when speed test returns excellent …
     always ground your responses on the results of tool calls. … Never make up the results of tool calls." }},
"initial_state": { "initialization_actions": [
  { "env_type": "user", "func_name": "turn_airplane_mode_on" },
  { "env_type": "user", "func_name": "turn_roaming_off" },
  { "env_type": "assistant", "func_name": "enable_roaming", "arguments": { "customer_id": "C1001", "line_id": "L1002" } } ]},
"evaluation_criteria": {
  "actions": [ { "requestor": "user", "name": "toggle_airplane_mode" }, { "requestor": "user", "name": "toggle_roaming" } ],
  "env_assertions": [ { "func_name": "assert_mobile_data_status", "expected_status": true },
                      { "func_name": "assert_internet_speed", "expected_speed": 200, "expected_desc": "excellent" } ],
  "communicate_info": null, "nl_assertions": null,
  "reward_basis": ["ENV_ASSERTION"] }

双控环境：两侧都能改写状态

图 7-3 重画。用户执行 toggle_roaming 之后环境变了，Agent 必须重新调用工具才能知道结果，所以验证也覆盖了“Agent 有没有读到用户侧的操作结果”。

满分轨迹也可能违规：第 4 条消息里 Agent 一次发出了两个工具调用，而政策第一段就规定“一次只调用一个工具”。验证器只看终态，所以没有发现。这不是 τ²-bench 的疏漏，是二元奖励的固有代价：用过程粒度换来一个跨模型可比的数字。生产评估还需要指出问题出在哪里。

上一节五条任务通过了四条，0.8 是好是坏？如果是退款客服，五个用户里就有一个拿不到应得的退款；如果是挖漏洞的安全 Agent，五次命中四次已经很可观。差别在于业务对成功率要求多高。

评估环境要满足一点：给定同一个初始状态，同一个 Agent 应当得到可以比较的结果。拿刚才那条 telecom 任务对照，五个组成要素都已经齐了。

五个要素缺一个，评估就构不成可重复的循环。后面看其他基准时，也用这五项来对照。

人机交互型与工具调用型

代码生成、数据分析、数学求解这类任务没有对话对象，Agent 只和工具打交道，能不能通过执行验证决定对错，既不需要人工标注，也不需要模型评判。这类环境省掉了用户模拟器，其余四个要素还在，只是更简单：状态是文件系统或数据库，评分标准是一段测试代码，协议是“一直调用工具，直到给出答案或用完轮数”。

图 7-2 重画。工具调用型验证行动（可观测的状态变更是否正确），人机交互型验证引导（沟通策略是否合理）。

环境是舞台，数据集是剧本。同样五个要素，换一类任务填法就完全不同：任务从哪来，验证器能核实到多深，怎么防止被模型记住。

表 7-2 几个 Agent 基准的关键设计选择。

验证器：核实事实，不信自我陈述

Agent 很容易写出一篇报告说任务全部完成，但事实上根本没做完。评估框架必须核实机器能独立复核的事实。

难度分层：有诊断价值

防数据泄漏：三种手法

质量控制：基准是修出来的

自建评估集的三个来源

起步时只有公开基准和少量手写用例；上线一段时间后，生产回流的用例会成为主体。验证深度、参数化生成、防泄漏、质量维护，正是自建评估集最容易漏掉的几处。

前面的基准几乎全用确定性验证器：跑测试、断言 UI 状态、精确匹配字符串。它不花额外模型开销、完全可复现，能像单元测试一样进 CI。代价是只说对错，不说原因。τ²-bench 那条失败任务得 0 分，这个 0 不会告诉你是选错了线路还是漏了充值。

从公开基准走向生产，验证方式要沿着“能否机械验证”的谱系向右移。但能写成断言的检查继续用断言，LLM 评判只用在确实无法机械判定的维度。

LLM-as-a-Judge 流水线

开放式任务（写报告、处理投诉、创意内容）没有标准答案可比，人工评又贵又难规模化。让语言模型按专家定义的 Rubric 打分，在规模和专业判断之间取得平衡。

端到端评估只给“成功”或“失败”，不回答“为什么、从哪一步开始”。失败归因要标出错误类别、首次出现不可接受行为的步骤、对应的工具调用或模型输出，并附上可复核的证据。

归因的对象是轨迹里第一个让任务偏离的错误。后面的错误往往只是连锁反应，不能把最后一个报错当成根因。这件事可以借助 LLM，但不能完全依赖 LLM，因为失败归因常常反映的是产品问题，不只是技术问题。

端到端回归 vs 轨迹前缀回归

配对比较与 Elo

选型时常问“A 和 B 哪个好”。配对比较不需要绝对标准，只判谁更好。Elo 背后是 Bradley-Terry 模型：每个模型有一个潜在实力分，胜负概率由分差决定，Elo 是它的在线更新版。

选模型不是“选最强的”，而是按场景和评估结果在多个维度之间权衡。

吞吐和延迟分两个阶段看：Prefill 一次读入整个上下文，决定首字延迟 TTFT（= 排队 + Prefill）；Decode 逐 token 生成，决定出字速度，也决定思考要多久。

模型的行为策略：行动阈值

Agent 系统的成本

三层构成：模型推理（输入 + 输出 token，外加上下文累积和思考 token 两个放大器）、工具调用（外部 API、沙盒资源，以及工具返回注入上下文后被反复计费的 token；一次网页搜索就可能占 2000–5000 token）、基础设施（向量库、队列、数据库、日志与追踪存储）。

评估集有限，模型输出又有随机性，分数差可能只是抽样噪声。在 n 个用例上测得成功率 p，标准误约为 SE ≈ √(p(1−p)/n)，95% 置信区间约 ±1.96·SE。

100 个用例、成功率 70%，95% 区间约 ±9 个百分点。“新模型 73% 对旧模型 70%”不足以支持切换。

for task in paired_tasks:
    for seed in fixed_seeds:
        a = run(config_a, task, seed)
        b = run(config_b, task, seed)
        record_paired_delta(verifier(a), verifier(b))
return paired_bootstrap_or_mcnemar(all_deltas)

可观测性借自分布式系统：没法打开系统看内部，只能通过日志、指标和追踪推断，就像医生靠体温、血压、影像诊断。Agent 更难：同样输入可能不同输出，多轮推理和工具调用让路径极复杂，模型的“思考”对外不透明。

追踪直接沿用 span 树：一次任务是一条 trace，每次 LLM 调用、工具调用、检索都是一个 span，记录输入输出、起止时间、token 和错误。OpenTelemetry 是通用标准，OpenInference 等在其上定义 LLM 语义约定，采集与分析解耦，不被单一平台锁定。

LangSmith（同类还有 Langfuse、Arize Phoenix）把可观测性、评估、优化做成闭环：异步批量采集保证追踪不拖慢 Agent；支持 A/B 测试（分流、自动对比、快速回滚或渐进扩量）、提示词版本管理（每个版本关联运行时表现）和团队共享问题案例。

评估集不再是一次性构造的静态集合，而是随产品演化、持续贴近真实用户分布的活资产：今天线上暴露的失败，明天就是守住底线的回归用例。

先立一条原则：Agent 表现下降时，先查评测系统，再动 Agent。环境资源不足导致进程被杀（随机失败）、验证器 bug 把正确答案判错、用例与生产脱节，这些在数字上和模型退化一模一样，只有看完整轨迹才能区分。

图 7-8 给出的方法论闭环：观察 → 假设（表层 / 中层 / 深层三层框架）→ 分阶段实验 → 成本收益决策 → 迭代。从 Harness 工程看，这就是用评估数据定位 Harness 的薄弱环节（上下文不足？约束缺失？验证不够？反馈不及时？），改完再评。

最好的 Agent 产品不只接受外部评估，还内建了持续自评的基础设施。以开源通用 Agent OpenClaw 为例，结合头部 Coding Agent 的公开分析，把 ML 研究的实验方法嵌进产品工程。

外部评估告诉你“Agent 有多好”，内部评估基础设施告诉你“哪项改动让它变好了”。

消融开关必须在启动路径极早期注入（在任何模块级常量捕获配置之前），所以要从一开始就设计进架构。定期消融（如每次大版本前）能发现“特性债务”：曾经有效、但模型进化后已不再必要的特性。

评估的终点是改进。改进有三条路：调 Harness、把评估嵌入产品工程，以及最深入的训练。目标从“评估现有能力”扩展到“培养新能力”时，评估环境就要演化为仿真环境：一个能反复练习、自动打分的虚拟操场。

定义清晰的 Rubric 或验证器，本质上就是 RLVR 的奖励函数：验证脚本直接就是奖励脚本。但训练多出两个要求：可靠的 reset（每个 episode 都要回到确定、干净的初始状态，否则梯度被上一轮残留污染）和远高于评估的吞吐。

图 7-10 重画：OpenVLA 与 RoboTwin2 的闭环。指令“将罐子放入锅中”（move_can_pot）；成功 = 罐子在锅内且未掉落。

观察 → 假设 → 实验 → 验证 → 新认识 → 新假设：让 Agent 工程从经验驱动的“炼金术”转向数据驱动的科学工程。

常见误区