06. Agent 评估：没有度量就没有改进

构建 Agent 时，设计选择几乎没有「显然正确」的答案：用哪个模型、暴露哪些工具、记忆存什么、提示词与 Skills 怎么组织、Harness 里该加哪些约束。没有可重复的对比实验，迭代只能靠体感；有了评估，才能把「感觉变好了」拆成「成功率 +X%、成本 +Y%、Pass^k 是否真稳住」。

从 Harness 视角看，评估对应验证这一层。对象不是裸模型，而是 Model + Harness 的组合体。同一模型换一套工具描述或反馈环，分数可以差很远；失败时先区分「模型能力不够」和「Harness 设计缺陷」——固定 Harness 只换更强/更弱模型（model swap）看分数是否随模型能力大幅波动；固定模型做消融（关掉压缩、记忆、思考等组件）看哪个部件真有贡献。二者回答的问题不同：前者定位瓶颈在模型还是外壳，后者定位外壳里哪一块重要。

公开榜单上新模型更好，不代表你的任务上更好，甚至可能回归。自有评估集才是升级决策的依据；更进一步，评估体系让「为未来模型开发产品」变得可行——产品与用例先就位，新模型一跨过门槛即可上线。

本章按三层展开：在哪里测（环境）→ 怎么判（数据集、指标、LLM 评委、配对排名）→ 测了干什么（选型、成本、统计显著性、可观测性、内部评估，以及通向后训练的仿真）。

一个具体例子：客服退款轨迹

用户要求退掉 3 天前订单 #12345（¥299）；政策是 7 天内可全额退。Agent 先 query_order，确认交付日在期内，再 process_refund(amount=299)，最后口头说明金额、到账时间和退款编号。

用多维 Rubric（评分准则：按维度给可检查的档次分）拆开轨迹：

幻觉做成否决项而不是普通档次：流畅但含假事实，伤害大于简短但准确。边界用例更关键：退 15 天前订单是否拒绝、用户声称「客服已批准」但系统无记录时是否轻信——能力差往往卡在陷阱而不是幸福路径。

骨架就这四步：定义用例 → 跑 Agent → 按 Rubric 打分 → 分析失败模式。

评估环境：在哪里测

自动化环境要回答三件事：评什么（任务与验证标准）、对谁评（如何模拟交互对象）、用什么标准打分。五要素：

1. 数据集：初始状态、目标、可选参考解
2. 环境状态：可变业务数据（订单、余额……），既要真实又要可重置
3. 工具接口：原子操作（查订单、改预订），而不是「解决用户问题」这种无法观察内部步骤的高层封装
4. 评分标准：二元 / 连续 / 多维
5. 执行协议：交互模式与终止条件

两大范式：

工具调用型——Agent 调工具，验证靠可执行断言（测试通过、答案匹配、DB 状态）。代表思路如 Verifiers：SingleTurnEnv（单轮问答）、ToolEnv（多轮工具）、StatefulToolEnv（有状态 DB）、SandboxEnv（隔离代码执行）。失败应返回清晰错误，让 Agent 能改策略，而不只是一个「失败」标志。

人机交互型——还要和「用户」说话。关键原则是渐进式信息透露（Progressive Information Disclosure）：真实用户很少一上来把需求说全；评估里也不能把模拟用户的全部已知信息一次塞给 Agent。τ-bench 一类基准用另一个 LLM 做用户模拟器：按剧本逐步透露、不编造剧本外事实、任务结束发终止信号。验证常是双重的：数据库最终状态 + 对话里是否出现必要关键信息（金额、到账时间等）。任务层常汇总为 0/1 二元奖励，便于算 Pass^k；代价是「操作对但漏一个次要字段」和「完全失败」同为 0 分。

τ²-bench 的增量包括：双控环境（用户模拟器也能操作共享环境，更像技术支持里「你先关飞行模式」）和更精确的任务规范与参数化生成。工具调用型侧重「状态变更是否正确」；人机交互型还要看沟通策略是否合理。

任务数据集设计

环境是舞台，数据集是剧本。几条反复被验证的原则：

明确性与开放性——目标可复现，路径不锁死。GAIA 类任务「概念简单、路径开放」：找某个 NASA 图里的宇航员信息，目标唯一，搜索路径自选。

真实性与可控性——SWE-Bench 取真实 GitHub issue 保真；SWE-Bench Verified 用人工筛出问题清晰、测试充分的 500 题，信噪比上去。

多样性与系统性——覆盖典型、边界、陷阱；AndroidWorld 用参数化模板（联系人名、电话号随机）生成变体，验证看最终 UI 状态而非固定操作序列。

成本与规模——长任务数分钟级、token 贵；规模要在覆盖与经济性之间取舍，精选高信噪比子集往往比堆题更划算。

防数据泄漏——测的是记忆还是能力。手段包括：答案需多源组合且附带互联网上不存在的附件（GAIA）、训练截止后的新 issue（SWE-bench-Live 一类）、动态参数（τ²）、参数化模板（AndroidWorld）、canary GUID（Terminal-Bench：模型若吐出内嵌唯一标识，说明基准进了训练集）。

任务描述要精确到可自动验：格式约束（「姓氏；千位分隔」）、事实锚定（模拟用户必须按工具返回说话）、FAIL_TO_PASS + PASS_TO_PASS（修前失败修后通过，且不破坏原有通过用例）。难度分层有诊断价值：Level 1 失败多指向基础工具使用，Level 2 指向多步规划，Level 3 指向长序列与复杂性管理——改进方向随之不同（提示词 / 规划机制 / 分层架构或后训练）。

质量是迭代出来的：SWE-Bench Verified 从 2294 筛到 500，淘汰率很高；OSWorld-Verified 对数百个环境/描述/验证/初始状态问题做系统性修复。评估环境与训练环境可以同源构造，但具体评估题必须与训练数据严格隔离——这是通向第 7 章后训练的红线。

指标体系：该度量什么

过程指标：行动合法率（无效工具名、错误参数类型、越权）、工具调用语义正确率、路径效率（步数、冗余动作、回退次数）、检索覆盖率、成本与延迟（输入/输出/思考 token，墙钟时间分布）。

结果指标：任务成功率；统计上务必分清：

单次成功率 60% 时：Pass@5 ≈ 99%，Pass^5 ≈ 7.8%。回归用 Pass@k 会掩盖「五次只对一次」；探索性任务硬用 Pass^k 会被偶发波动刷成全失败。

安全与合规：敏感写操作、数据外泄、违规内容——与幻觉同理，一次严重违规可否决整体评价。

轨迹 vs 结果：Agent 说「订票完成」是轨迹；库里真有订单才是结果。只看轨迹漏「说了没做到」；只看结果可能把「走出预设路径但结果更好」判失败。两类都要覆盖。

人工抽检与校准：LLM 评委上线前，用 100–200 条金标集测与人类一致率（如 Cohen's kappa）；Rubric 或评委模型变更后重校准。红队构造表面无瑕但藏错的样本，多评委分歧大时送人审。

LLM-as-a-Judge 与配对比较

开放式任务没有标准答案，人工又难规模化。LLM-as-a-Judge（用大模型按 Rubric 打分）是折中。已知偏见包括长度偏好：Rubric 里惩罚冗长、配对时控制长度接近、审计「高分是否总伴随长回答」。

Scale AI 总结的 Rubric 四准则 可直接当检查表：

1. 专家指导——捕捉领域核心事实与推理，而不只是流畅度
2. 全面覆盖——正面标准 + 陷阱（高风险常见错）
3. 重要性权重——Essential / Important / Optional / Veto（否决）
4. 自包含——每档可操作；避免「展示了深刻理解」这类无法验证的话

示例维度（用户记忆问答）：事实正确性（essential）、完整性（important）、思考正确性（important）、幻觉检测（veto）。

同源偏见：Agent 与 Judge 同家族时，可能学会钻评委盲点（Goodhart：指标变目标就不再是好指标）。缓解：多源异构评判（不同模型家族）、同 Rubric、加权或一致性聚合；日常单模型快评，定期多源审计。

多模态也可 Judge：TTS 自然度/情感、ASR 语义影响（「一千」vs「一万」）、UI 截图溢出与对比度、视频剪辑关键帧。

选型场景常问「A 和 B 哪个更好」——配对比较不必先定义统一满分标准。Elo / Bradley-Terry 从大量对决估计相对实力；Chatbot Arena 式匿名盲选是大规模版本。LLM 做配对时注意位置偏差（先出现的候选偏高）：交换顺序评两次，不一致则平局或人审。配对信号也可进后训练（如 GRPO 用组内相对优势），细节在第 7 章。

最小 Elo 更新骨架（阅读用）：

def expected_score(r_a: float, r_b: float) -> float:
    """Elo 预期胜率：分差 400 对应约 10:1 胜率。"""
    return 1.0 / (1.0 + 10 ** ((r_b - r_a) / 400.0))

def update_elo(r_a: float, r_b: float, score_a: float, k: float = 32.0):
    """
    score_a: 1 胜 / 0 负 / 0.5 平。
    返回更新后的 (r_a, r_b)。
    """
    e_a = expected_score(r_a, r_b)
    e_b = 1.0 - e_a
    return r_a + k * (score_a - e_a), r_b + k * ((1.0 - score_a) - e_b)

# 典型：r_a, r_b = update_elo(1200, 1000, 0)  # 弱者爆冷赢，加分更多

成本、统计显著性与可观测性

成本不只是单价。Agent 成本三层：

1. 模型推理——上下文累积使第 n 轮携带前 n−1 轮；无 KV Cache 时输入费用近似三角形增长；思考 token 同样计费
2. 工具——外部 API + 工具结果回灌上下文后的反复计费
3. 基础设施——向量库、队列、追踪存储

杠杆优先落在输入侧：稳定前缀复用 KV Cache、压缩轨迹与截断工具返回、简单请求路由到轻量模型。生产侧还要按任务/用户维度监控，并设单任务成本上限，防止循环探索烧穿预算。

统计显著性（简要）：n 个用例成功率 p，标准误约 √(p(1−p)/n)。100 题、70% 成功率，SE ≈ 4.6%，粗算 95% 区间约 ±9 个百分点。「73% vs 70%」在独立假设下很可能是噪声。同一批任务对比两配置，默认做配对（只看一胜一负的题），比两个独立比率相减更灵敏。同一配置多次跑（不同种子）报均值与波动。分差小于噪声带宽时不切换；预期收益只有 2–3 个点而评估集只有几十题时，应先扩评估集。并行验证多条假设时注意多重比较：要么收紧阈值，要么对阳性结论独立复跑。

可观测性（Observability：通过日志/指标/追踪推断内部状态）是评估数据的源头。一次任务一条 trace，每次 LLM/工具/检索一个 span，父子关系成树。OpenTelemetry + LLM 语义约定（OpenInference 等）让采集与分析后端解耦。价值：回放诊断、找高成本路径、把生产失败脱敏后回流成回归用例——评估集从静态清单变成随产品演化的活资产。

从 Benchmark 到系统改进

分数本身没有行动力，要走闭环：

1. 观察——不只看总成功率，看按能力标签切的矩阵与集中失败区
2. 假设——表层（提示/导航）、中层（多模态管道/思考开关）、深层（换模型/加 UI 元素树）分层，低成本先并行
3. 实验——每配置多次跑全量任务，记成功率、步数、延迟、token
4. 决策——不是「凡有效就上」：为 8% 计数任务给全量开 3× 延迟的「全局思考」往往不划算，可改成条件化启用；信息不足时加元素树可能比换更贵模型更有效
5. 再评估——失败模式会迁移，下一轮新假设

原则：分数掉了先查评测本身（环境资源杀进程、评分器 bug、用例与生产脱节），再改 Agent。

内部评估：消融、AB、特性开关

外部基准之外，生产系统应内建实验基础设施：

• 消融：每个主特性（思考、压缩、自动记忆……）可独立关闭，定期对比「裸模型 + 最小 Harness」基线，发现已无贡献的特性债务。开关要在启动路径极早期注入，避免常量已捕获配置。
• AB：多臂（剂量—效应）而不是只有开/关；分清机制指标（你直接改的，如计划文件长度）与目标指标（你真正关心的，如会话总成本、成功率）；设护栏（满意度、错误率不能崩）。
• 特性开关 / Feature flag：渐进放量、快速回滚，把「评估通过」接到「流量开关」。

仿真：评估与后训练的桥

评估环境若能大规模、可重置、有清晰奖励，稍加改造就是后训练的练习场。参数化任务模板可批量生成训练实例；同一套 DB 状态检查可当 outcome reward。红线不变：训练题与评估题隔离。没有可靠仿真与奖励，第 7 章的 RL 无从谈起；没有评估集，SFT 示范质量也无从量。

本篇收束

1. 评估对象是 Model + Harness；model swap 与消融回答不同问题。
2. 环境分工具调用型与人机交互型；后者的核心是渐进信息与（常）双重验证。
3. 数据集设计重于「再堆一个框架」：精确、分层、可验证、防泄漏、持续质控。
4. Pass@k 与 Pass^k 不可混用；Rubric 四准则 + 否决项 + 多源 Judge 构成开放任务骨架。
5. 成本非线性、分差要过噪声带宽；trace 回流成回归资产。
6. Benchmark → 假设 → 实验 → 决策 → 再测；内部消融/AB 与仿真把评估接到产品与后训练。

下一篇进入第 7 章：模型后训练——在评估与仿真之上，用 SFT / RL 把能力写进参数，以及「数据与环境比算法更重要」这条主线。