Agent 评估基准 · τ-bench / SWE-bench / 轨迹评估 / 工具调用准确率定位02-Eval §2 的任务级纵深专章。02 讲的是「单轮问答 LLM-judge 幻觉」本篇只讲Agent 这个新维度——评估一个会调用工具、多步决策、跨轮维护状态的系统为什么不能套单轮评估怎么评才靠谱。风格说明机制型为主——从「轨迹 vs 单答案」的本质差异出发拆解四大基准AgentBench/τ-bench/SWE-bench/WebArena的设计原理与陷阱落到生产 Agent eval 的搭建方法。前置阅读02-EvalLLM-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 任务完成了吗Trajectory 每步对吗Process 为什么这么决策Outcome-level结果层最常用——任务最终成功了吗。简单但粗糙蒙对的也算过。Trajectory-level轨迹层逐步骤对照「专家轨迹」——有没有多余动作、有没有漏关键步骤。Process-level过程层最贵——用 LLM-judge 评估每步决策的合理性即使路径不同只要推理合理也给分。生产实践Outcome 做门禁 Trajectory 做诊断 Process 做迭代优化。只看 Outcome 会漏掉「这次过了但靠运气」的隐患。2. 四大基准深度拆解依据各基准官方论文与仓库L2/L3。下表先给全貌再逐个拆设计原理。基准任务域评估层交互轮数核心指标适合测AgentBench8 类OS/DB/游戏/KG…Outcome多轮成功率综合 Agent 能力τ-bench零售/航空客服多策略Outcome 策略一致多轮pass^k业务 Agent 工具SWE-bench真实 GitHub issueOutcome测试通过长链解决率Coding AgentWebArena / VisualWebArena真实网站操作Outcome多轮端到端成功率Browser Agent2.1 AgentBench · 综合 Agent 能力来源清华等THUDM/AgentBenchL2。设计8 个环境——操作系统、数据库、知识图谱、卡片游戏、家庭模拟ALFRED、网页购物等覆盖「是否会把模型当 Agent 用」。为什么有意义第一个跨域大规模 Agent 基准能区分「能聊天」和「能行动」。陷阱任务相对脚本化与真实业务 Agent带工具 RAG 多轮谈判有差距部分环境已饱和强模型接近满分。2.2 τ-bench · 业务 Agent 的「黄金标尺」重点来源Anthropic/Sierrasierra-research/tau-benchL2论文 τ-bench (Yao 2024)L3。版本注意原始 τ-benchairline/retail仓库已标注outdated最新版是τ³-bench——新增banking域和voice评测模态并修复了 airline/retail 的任务缺陷。生产选型应优先 τ³-bench学原理仍可读原论文。设计精髓模拟零售/航空/银行客服——用户有人设、有隐藏任务目标Agent 可调一组业务 API查订单、改航班、退款有一套业务策略policy约束如「机票起飞前 24h 内不可退」。评测不只看「任务完成」还看是否符合策略。关键创新 ——pass^k指标普通 pass1 跑 1 次成功的概率。但 Agent 有随机性「偶尔成功」和「稳定成功」差别巨大。pass^k 跑 k 次全部成功的概率强制衡量一致性/鲁棒性。一个 pass10.8 但 pass^160.1 的模型说明它不稳定——这正是生产环境最怕的。为什么对零售/电商面试超对口τ-retail 直接就是「电商客服 Agent」场景。面试提到 τ-bench 的 pass^k 会让面试官眼前一亮。2025 现状强模型Claude/GPT-4 系列在 τ-retail 上 pass^k 仍远低于 pass1说明 Agent 一致性是普遍短板。2.3 SWE-bench · Coding Agent 的标尺来源Princetonswe-bench/SWE-benchL2原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/webarenaL2。设计搭一套真实可交互的自托管网站电商、论坛、CMS给 Agent 一个任务「帮我找最便宜的双人房并预订」评估端到端操作是否成功。为什么重要Browser/Computer Use Agent 是 2025-2026 热点见 06-Computer-UseWebArena 是这个方向的基准。变种VisualWebArena纯视觉不看 DOM、WorkArena企业场景。3. 生产 Agent Eval 怎么搭不套现成基准对齐 02-Eval §3「自建业务 eval」。现成基准测「通用能力」生产 Agent 必须自建业务任务集。3.1 五步搭建法1 从真实日志抽任务2 标注专家轨迹/期望3 选评估层OutcomeTrajectory4 选 Judge规则/LLM-judge/人工5 卡门禁多跑取 pass^k抽任务从生产 trace 日志08-可观测抽 100-500 个真实任务覆盖高频 长尾 边界。标注每个任务标「期望最终状态」可选「专家轨迹」「必须遵守的约束」策略/安全。选评估层优先 Outcome客观可判 关键步骤 Trajectory。选 Judge能规则判就规则如「订单状态 已退款」不能则 LLM-judge用比被测模型更强的模型当裁判高风险场景加人工抽样。卡门禁跑 k 次如 k5取 pass^k卡阈值如 pass^5 ≥ 0.85才发版。3.2 Agent 专用评估指标清单类别指标含义门禁建议完成Task Success Rate任务最终成功比例≥ 85%一致pass^kk 次全成功概率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任务端到端延迟按业务 SLA3.3 轨迹评估的两种打分法方法 A基于专家轨迹的逐步匹配deftrajectory_score(agent_steps,expert_steps):# 用编辑距离或步骤集合相似度衡量# 惩罚多余动作乱调工具、漏动作关键步骤缺失extralen(set(agent_steps)-set(expert_steps))missinglen(set(expert_steps)-set(agent_steps))return1-(extramissing)/(2*len(expert_steps))缺点强行要求「走专家路径」但 Agent 合理解法可能不同殊途同归。方法 BLLM-judge 轨迹合理性推荐judge_promptf 你是 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 集分留出测试集 持续更新4LLM-judge 偏见强模型 judge 偏好同风格输出多 judge 交叉 人工抽样校准5状态污染跑多次任务前一次改了数据库影响后一次每次评测重置环境snapshot/restore6成本失控跑完整 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 个真实任务覆盖退款/改地址/查物流/投诉标注期望最终状态如「订单 statusrefunded」 业务策略约束金额上限、时效评估层Outcome订单状态正确 Tool Trajectory调对了 refund API 且参数对每任务跑 5 次取 pass^5暴露不稳定性。发现离线 90 分的模型在真实任务 pass^5 只有 0.62主因是「该多轮确认时提前停」「退款参数金额填错」。结果R针对 Top3 失败模式优化 prompt 工具 schema 加 HITL20-注入 §5.3后pass^5 提升到 0.84eval 分数与线上 NPS 相关性从 0.2 提升到 0.71。6. 与相关章节的边界主题本章去这里看LLM-judge / Hallucination / 单轮评估不重复02-EvalEval 集治理 / Golden Set 生命周期 / RACI不展开10-Eval集治理在线 A/B / 影子流量 / 隐式反馈不展开23-在线EvalHarness 自动化评测工程不展开06-HarnessAgent 执行循环原理仅引用07-执行循环Computer Use / Browser Agent仅提 WebArena06-Computer-Use99. 面试速查 · 高频满分答Q1Agent 评估和普通 LLM 评估有什么区别三个本质区别①评估对象——普通评单条答案Agent 评一条轨迹N 步动作序列②正确性——普通看答案对错Agent 看任务完成 中间步骤 无副作用③可复现性——Agent 涉及工具返回和采样随机性强所以要用pass^k跑 k 次全过的概率而非单次 pass1。核心结论单轮 benchmark 高 ≠ Agent 强必须端到端跑任务。Q2什么是 τ-bench它的 pass^k 为什么重要τ-bench 是 Anthropic 提出的业务 Agent 基准模拟零售/航空客服Agent 可调业务 API 且必须遵守业务策略如「起飞前 24h 不可退」。它的核心创新是pass^k——跑 k 次全部成功的概率。普通 pass1 会被「偶尔成功」误导而生产环境要的是稳定。一个 pass10.8 但 pass^160.1 的模型说明它靠运气不能上生产。τ-retail 直接对口电商客服面试提这个很加分。Q3SWE-bench 凭什么是最可信的 Coding Agent 基准因为它评测客观——从真实 GitHub 仓库拉 issue 对应 PR让 Agent 修 bug用仓库自带的单元测试通过作为判定标准不依赖主观的 LLM-judge。用的是真实代码不是人造题。变种有 Lite精简、Verified人工标可解性、Multimodal。局限只覆盖 Python过测试不等于代码质量好可能 hardcode。Q4生产 Agent 的 eval 怎么搭说几个关键指标。五步从 trace 日志抽真实任务 → 标期望状态策略约束 → 选评估层OutcomeTrajectory→ 选 Judge能规则判就规则不能用 LLM-judge→ 跑 k 次取 pass^k 卡门禁。关键指标Task Success Rate、pass^k、Tool Selection/Param Accuracy≥95%、Policy Violation Rate≤1%、Avg Steps防死循环、Avg $/TaskFinOps。Q5Agent 评估有哪些坑六个①结果对但靠运气要 pass^k 轨迹评分②工具结果污染换环境就崩评测要 mock 多种返回含异常③过拟合 eval 集留出测试集 持续更新④LLM-judge 偏见多 judge 交叉⑤状态污染——这是 Agent 专属Agent 会改世界下单/退款上一次副作用污染下一次必须每次重置环境⑥成本失控分级采样冒烟/回归/全量。Q6Trajectory 评估有哪两种方法怎么选①基于专家轨迹逐步匹配——用步骤集合相似度惩罚多余和漏动作缺点是要求「走专家路径」不容殊途同归②LLM-judge 轨迹合理性——用强模型评估每步决策是否合理不必与专家一致更接近真实质量但贵。实践折中Outcome 判通过/失败只对失败的轨迹用 LLM-judge 定位根因平衡成本和深度。一页 Checklist是否用任务级端到端评估而非单轮 QA是否跑了多次取 pass^k 衡量稳定性评估任务是否来自真实 trace覆盖长尾和边界是否同时测 Outcome 关键步骤 Trajectory工具调用是否测了 Tool Selection Param Accuracy是否测了策略一致性Policy Violation Rate评测环境是否每次重置防状态污染工具返回是否 mock 了多种情况含异常/空/超时LLM-judge 是否用比被测模型更强的模型 抽样校准是否分级评测冒烟/回归/全量控制成本官方文档与源码一级依据Agent 评估· 本章基准定义与机制依据官方源码L2与论文L3指标门禁阈值为面试示意。写作规范docs/official-sources-registry.md §0L1 · 官方文档Anthropic - Evaluating LLMsOpenAI - Evaluating AgentsL2 · 官方源码 / 基准sierra-research/tau-benchτ-bench · Anthropic/Sierra · 含 τ³-bench 最新版swe-bench/SWE-bench原 princeton-nlp/SWE-bench 已迁移至此THUDM/AgentBenchweb-arena-x/webarenaopenai/openai-agents-python evalsL3 · 论文τ-bench: A Benchmark for Tool-Agent-User Interaction (Yao 2024)SWE-bench: Can LLMs Resolve Real-World GitHub Issues (Jimenez 2023)AgentBench (Liu 2023)WebArena (Zhou 2023)