当前位置：首页 > news >正文

Agent评估基准-τ-bench-SWE-bench与轨迹评估

news 2026/7/15 1:50:07

Agent 评估基准 · τ-bench / SWE-bench / 轨迹评估 / 工具调用准确率

定位：02-Eval §2 的任务级纵深专章。02 讲的是「单轮问答 + LLM-judge + 幻觉」，本篇只讲Agent 这个新维度——评估一个会调用工具、多步决策、跨轮维护状态的系统，为什么不能套单轮评估，怎么评才靠谱。
风格说明：机制型为主——从「轨迹 vs 单答案」的本质差异出发，拆解四大基准（AgentBench/τ-bench/SWE-bench/WebArena）的设计原理与陷阱，落到生产 Agent eval 的搭建方法。
前置阅读：02-Eval（LLM-judge / Hallucination / 金三角）；07-LLM-Agent执行循环（理解为什么需要轨迹评估）。

1. 本质：为什么 Agent 评估和单轮 LLM 评估是两回事

1.1 一句话定义

Agent 评估：衡量一个多步、有状态、会调用工具的系统，在完整任务上的表现——不只看最终答案，更要看决策轨迹（trajectory）：每一步选对工具了吗、参数对吗、该停的时候停了吗、不该调的时候没乱调吗。

1.2 单轮 vs Agent 评估的七维差异

维度	单轮 QA 评估	Agent 任务评估
评估对象	一条回答	一条轨迹（N 步动作序列）
正确性	答案对错	任务完成 + 中间步骤 + 无副作用
答案空间	文本相似度	工具调用组合爆炸，无法枚举
成本	一次推理	几十次推理 + 多次工具调用，跑一次很贵
可复现	高（温度=0 基本确定）	低（工具返回随机、模型采样、外部状态变化）
失败模式	错答/幻觉	工具选错/参数错/死循环/提前停/越权
指标	accuracy/F1/相似度	任务完成率 + 轨迹奖励 + 步数效率 + 安全

核心认知：单轮 benchmark 高 ≠ Agent 强。一个 MMLU 90 的模型，可能因为「该调工具时不调」「不该停时停了」而在 Agent 任务上拉胯。Agent 评估必须端到端跑任务。

1.3 评估「轨迹」的三个层次

Outcome-level（结果层）：最常用——任务最终成功了吗。简单但粗糙（蒙对的也算过）。
Trajectory-level（轨迹层）：逐步骤对照「专家轨迹」——有没有多余动作、有没有漏关键步骤。
Process-level（过程层）：最贵——用 LLM-judge 评估每步决策的合理性（即使路径不同，只要推理合理也给分）。

生产实践：Outcome 做门禁 + Trajectory 做诊断 + Process 做迭代优化。只看 Outcome 会漏掉「这次过了但靠运气」的隐患。

2. 四大基准深度拆解

依据各基准官方论文与仓库（L2/L3）。下表先给全貌，再逐个拆设计原理。

基准	任务域	评估层	交互轮数	核心指标	适合测
AgentBench	8 类（OS/DB/游戏/KG…）	Outcome	多轮	成功率	综合 Agent 能力
τ-bench	零售/航空客服（多策略）	Outcome + 策略一致	多轮	pass^k	业务 Agent + 工具
SWE-bench	真实 GitHub issue	Outcome（测试通过）	长链	解决率	Coding Agent
WebArena / VisualWebArena	真实网站操作	Outcome	多轮	端到端成功率	Browser Agent

2.1 AgentBench · 综合 Agent 能力

来源：清华等，THUDM/AgentBench（L2）。
设计：8 个环境——操作系统、数据库、知识图谱、卡片游戏、家庭模拟（ALFRED）、网页购物等，覆盖「是否会把模型当 Agent 用」。
为什么有意义：第一个跨域大规模 Agent 基准，能区分「能聊天」和「能行动」。
陷阱：任务相对脚本化，与真实业务 Agent（带工具 + RAG + 多轮谈判）有差距；部分环境已饱和（强模型接近满分）。

2.2 τ-bench · 业务 Agent 的「黄金标尺」（重点）

来源：Anthropic/Sierra，sierra-research/tau-bench（L2），论文 τ-bench (Yao 2024)（L3）。
版本注意：原始 τ-bench（airline/retail）仓库已标注outdated，最新版是τ³-bench——新增banking域和voice评测模态，并修复了 airline/retail 的任务缺陷。生产选型应优先 τ³-bench；学原理仍可读原论文。
设计精髓：模拟零售/航空/银行客服——用户有人设、有隐藏任务目标；Agent 可调一组业务 API（查订单、改航班、退款）；有一套业务策略（policy）约束（如「机票起飞前 24h 内不可退」）。评测不只看「任务完成」，还看是否符合策略。
关键创新 ——pass^k指标：

普通 pass@1 = 跑 1 次成功的概率。但 Agent 有随机性，「偶尔成功」和「稳定成功」差别巨大。pass^k= 跑 k 次全部成功的概率，强制衡量一致性/鲁棒性。一个 pass@1=0.8 但 pass^16=0.1 的模型，说明它不稳定——这正是生产环境最怕的。

为什么对零售/电商面试超对口：τ-retail 直接就是「电商客服 Agent」场景。面试提到 τ-bench 的 pass^k 会让面试官眼前一亮。
2025 现状：强模型（Claude/GPT-4 系列）在 τ-retail 上 pass^k 仍远低于 pass@1，说明 Agent 一致性是普遍短板。

2.3 SWE-bench · Coding Agent 的标尺

来源：Princeton，swe-bench/SWE-bench（L2，原princeton-nlp/SWE-bench已重定向至此），论文 ICLR 2024 Oral。
设计：从 12 个真实开源 Python 仓库拉取GitHub issue + 对应合并的 PR，让 Agent 修 bug。评判标准硬核且客观——跑仓库自带的单元测试，过了才算解决。
为什么是「最可信」之一：测试通过是客观的，不依赖 LLM-judge 的主观打分；用的是真实代码库，不是人造题。
变种：SWE-bench Lite（精简 300 题）、SWE-bench Verified（人工标注可解性）、SWE-bench Multimodal。
陷阱：只覆盖 Python；部分测试 flaky；「过测试」不等于「代码质量好」（可能 hardcode 跑通）。变种 LiveCodeBench 用「时间切分」防污染。

2.4 WebArena · Browser Agent 标尺

来源：CMU 等，web-arena-x/webarena（L2）。
设计：搭一套真实可交互的自托管网站（电商、论坛、CMS），给 Agent 一个任务（「帮我找最便宜的双人房并预订」），评估端到端操作是否成功。
为什么重要：Browser/Computer Use Agent 是 2025-2026 热点（见 06-Computer-Use），WebArena 是这个方向的基准。
变种：VisualWebArena（纯视觉，不看 DOM）、WorkArena（企业场景）。

3. 生产 Agent Eval 怎么搭（不套现成基准）

对齐 02-Eval §3「自建业务 eval」。现成基准测「通用能力」，生产 Agent 必须自建业务任务集。

3.1 五步搭建法

抽任务：从生产 trace 日志（08-可观测）抽 100-500 个真实任务，覆盖高频 + 长尾 + 边界。
标注：每个任务标「期望最终状态」+（可选）「专家轨迹」+「必须遵守的约束」（策略/安全）。
选评估层：优先 Outcome（客观可判）+ 关键步骤 Trajectory。
选 Judge：能规则判就规则（如「订单状态 == 已退款」）；不能则 LLM-judge（用比被测模型更强的模型当裁判）；高风险场景加人工抽样。
卡门禁：跑 k 次（如 k=5）取 pass^k，卡阈值（如 pass^5 ≥ 0.85）才发版。

3.2 Agent 专用评估指标清单

类别	指标	含义	门禁建议
完成	Task Success Rate	任务最终成功比例	≥ 85%
一致	pass^k	k 次全成功概率	pass^5 ≥ 0.7
效率	Avg Steps / Turns	平均步数（越少越好，防死循环）	不超过专家轨迹的 1.5x
工具	Tool Selection Accuracy	该调哪个工具选对的概率	≥ 95%
工具	Tool Param Accuracy	工具参数正确的比例	≥ 95%
成本	Avg Tokens / Task	平均 token 消耗（FinOps）	设上限
成本	Avg $ / Task	平均美元成本	设上限
安全	Policy Violation Rate	违反业务策略的比例	≤ 1%
安全	ASR（注入场景）	攻击成功率	≤ 5%（见 20-注入）
鲁棒	Latency P99	任务端到端延迟	按业务 SLA

3.3 轨迹评估的两种打分法

方法 A：基于专家轨迹的逐步匹配

deftrajectory_score(agent_steps,expert_steps):# 用编辑距离或步骤集合相似度衡量# 惩罚：多余动作（乱调工具）、漏动作（关键步骤缺失）extra=len(set(agent_steps)-set(expert_steps))missing=len(set(expert_steps)-set(agent_steps))return1-(extra+missing)/(2*len(expert_steps))

缺点：强行要求「走专家路径」，但 Agent 合理解法可能不同（殊途同归）。

方法 B：LLM-judge 轨迹合理性（推荐）

judge_prompt=f""" 你是 Agent 评估专家。以下是某 Agent 完成任务的完整轨迹。 请评估每一步决策是否【合理】（不必与专家路径完全一致，只要推理正确）。 轨迹：{trajectory}输出：每步 1-5 分 + 总体合理性评分 + 发现的问题。 """

实践经验：方法 B 更接近真实质量，但成本高（每条轨迹要调一次强模型 judge）。折中：Outcome 判通过/失败，只对失败的轨迹用 LLM-judge 定位根因。

4. Agent 评估的六大陷阱

对齐 02-Eval §2.2「benchmark 四大陷阱」。Agent 场景陷阱更多。

#	陷阱	表现	应对
1	结果对但靠运气	任务完成但步骤乱、绕远路	用 pass^k + Trajectory 评分
2	工具结果污染	Agent 依赖某 API 返回，换环境就崩	评测时 mock 多种返回（含异常）
3	过拟合任务集	在 eval 集刷高分，新任务拉胯	eval 集分留出测试集 + 持续更新
4	LLM-judge 偏见	强模型 judge 偏好同风格输出	多 judge 交叉 + 人工抽样校准
5	状态污染	跑多次任务，前一次改了数据库影响后一次	每次评测重置环境（snapshot/restore）
6	成本失控	跑完整 eval 集花几百刀	子集采样 + 分级评测（冒烟/回归/全量）

陷阱 5 是 Agent 专属：Agent 会改世界（下单、改数据），上一次跑的副作用会污染下一次。必须每次重置环境——τ-bench 的设计里就有 db restore 机制。

5. STAR 实战：电商客服 Agent 的 Eval 搭建

情境（S）：团队上线了「智能客服 Agent」，可查订单/发起退款/改地址。上线后客诉增加，但离线 eval 分数 90+，离线高分与线上翻车严重背离。

任务（T）：诊断原因 + 搭一套能预测线上表现的 Agent eval。

行动（A）：
根因：现有 eval 用的是「单轮 QA + LLM-judge 打分」（02-Eval 的老法子），没测工具调用和任务完成——模型答得好不代表会正确退款。
重建 eval：
从 trace 日志抽 300 个真实任务（覆盖退款/改地址/查物流/投诉）；
标注期望最终状态（如「订单 status=refunded」）+ 业务策略约束（金额上限、时效）；
评估层：Outcome（订单状态正确）+ Tool Trajectory（调对了 refund API 且参数对）；
每任务跑 5 次取 pass^5（暴露不稳定性）。
发现：离线 90 分的模型在真实任务 pass^5 只有 0.62，主因是「该多轮确认时提前停」「退款参数金额填错」。

结果（R）：针对 Top3 失败模式优化 prompt + 工具 schema + 加 HITL（20-注入 §5.3）后，pass^5 提升到 0.84；eval 分数与线上 NPS 相关性从 0.2 提升到 0.71。

6. 与相关章节的边界

主题	本章	去这里看
LLM-judge / Hallucination / 单轮评估	不重复	02-Eval
Eval 集治理 / Golden Set 生命周期 / RACI	不展开	10-Eval集治理
在线 A/B / 影子流量 / 隐式反馈	不展开	23-在线Eval
Harness 自动化评测工程	不展开	06-Harness
Agent 执行循环原理	仅引用	07-执行循环
Computer Use / Browser Agent	仅提 WebArena	06-Computer-Use

99. 面试速查 · 高频满分答

Q1：Agent 评估和普通 LLM 评估有什么区别？

三个本质区别：①评估对象——普通评单条答案，Agent 评一条轨迹（N 步动作序列）；②正确性——普通看答案对错，Agent 看任务完成 + 中间步骤 + 无副作用；③可复现性——Agent 涉及工具返回和采样，随机性强，所以要用pass^k（跑 k 次全过的概率）而非单次 pass@1。核心结论：单轮 benchmark 高 ≠ Agent 强，必须端到端跑任务。

Q2：什么是 τ-bench？它的 pass^k 为什么重要？

τ-bench 是 Anthropic 提出的业务 Agent 基准，模拟零售/航空客服，Agent 可调业务 API 且必须遵守业务策略（如「起飞前 24h 不可退」）。它的核心创新是pass^k——跑 k 次全部成功的概率。普通 pass@1 会被「偶尔成功」误导，而生产环境要的是稳定。一个 pass@1=0.8 但 pass^16=0.1 的模型，说明它靠运气，不能上生产。τ-retail 直接对口电商客服，面试提这个很加分。

Q3：SWE-bench 凭什么是最可信的 Coding Agent 基准？

因为它评测客观——从真实 GitHub 仓库拉 issue + 对应 PR，让 Agent 修 bug，用仓库自带的单元测试通过作为判定标准，不依赖主观的 LLM-judge。用的是真实代码不是人造题。变种有 Lite（精简）、Verified（人工标可解性）、Multimodal。局限：只覆盖 Python，过测试不等于代码质量好（可能 hardcode）。

Q4：生产 Agent 的 eval 怎么搭？说几个关键指标。

五步：从 trace 日志抽真实任务 → 标期望状态+策略约束 → 选评估层（Outcome+Trajectory）→ 选 Judge（能规则判就规则，不能用 LLM-judge）→ 跑 k 次取 pass^k 卡门禁。关键指标：Task Success Rate、pass^k、Tool Selection/Param Accuracy（≥95%）、Policy Violation Rate（≤1%）、Avg Steps（防死循环）、Avg $/Task（FinOps）。

Q5：Agent 评估有哪些坑？

六个：①结果对但靠运气（要 pass^k + 轨迹评分）；②工具结果污染（换环境就崩，评测要 mock 多种返回含异常）；③过拟合 eval 集（留出测试集 + 持续更新）；④LLM-judge 偏见（多 judge 交叉）；⑤状态污染——这是 Agent 专属，Agent 会改世界（下单/退款），上一次副作用污染下一次，必须每次重置环境；⑥成本失控（分级采样：冒烟/回归/全量）。

Q6：Trajectory 评估有哪两种方法？怎么选？

①基于专家轨迹逐步匹配——用步骤集合相似度，惩罚多余和漏动作，缺点是要求「走专家路径」，不容殊途同归；②LLM-judge 轨迹合理性——用强模型评估每步决策是否合理（不必与专家一致），更接近真实质量但贵。实践折中：Outcome 判通过/失败，只对失败的轨迹用 LLM-judge 定位根因，平衡成本和深度。