Agent评估难在哪：五大基准与pass^k指标解析

为什么给 Agent 打分这么难

评估大语言模型（LLM）那一套用惯了，换成 AI Agent 会让人不太适应。LLM 的评估像标准化考试：题目固定、有标准答案，模型生成一次，自动判分就行。Agent 的评估更像盯着一个实习生在真实办公室里干活：环境在变，任务要分好几步做，结果往往没有唯一标准答案，每次跑出来还可能不一样。

Yehudai 等人在 ACL 2026 发表的综述把 Agent 评估的结构性难点归为三个，工程实践中同样绕不开。

头一个是终态判定。文本生成任务可以算 BLEU、ROUGE 分数，或者直接比字符串相似度。换成 Agent 就不行，比如让它“整理文件夹”或“修复代码 bug”，文本比对毫无意义。得去看数据库状态有没有更新、代码测试用例有没有通过、文件是不是真建出来了。按状态判定，比按文本判定复杂得多。

再一个是结果方差。同一个 Agent、同一个任务，跑 8 次可能 4 次成功、4 次失败。随机性来自模型采样的不确定性、网络波动，还有外部 API 响应上的差异。单次运行的成功率因此几乎没有统计意义，要多次采样才能得出可靠结论。

最后是归因模糊。Agent 表现一变，很难说清是换了底层模型、调了提示词（Prompt），还是改了工具定义的 Schema。A/B 测试时同时动几个变量，分数变化就没法归因。严谨的做法是：一次只改一个变量。

五大代表性 Benchmark 的能力光谱

眼下主流的基准测试有好几个，各自侧重不同的能力维度。弄清它们各自考什么，才选得对评估工具。

GAIA：通用助手的广度测试

GAIA 考的是 Agent 当通用助手的能力，覆盖推理、多模态处理、网页浏览和工具使用。题目共 466 道，其中 300 道用于留测。它有个明显特点：不少对人类来说简单的综合任务，Agent 做起来却极难。GPT-4 配合插件在 GAIA 上只拿到 15% 左右，人类准确率能到 92%。跨模态、跨工具的复杂协调，Agent 在这上面还有很大提升空间。

SWE-bench：代码修复的深度测试

SWE-bench 盯的是软件工程，要求 Agent 修复真实的 GitHub Issue。Verified 子集里有 500 道经过严格验证的题目。评分口径常见两种：一种是官方统一 Harness（如 mini-SWE-agent）下的成绩，另一种是厂商自报的成绩。2026 年初，官方榜单榜首约 79%，部分厂商声称专用 Agent 能到 96%-97%。两个数都是真的，但不能直接比。前者量的是标准框架下的通用能力，后者往往带着针对特定任务的深度优化。选型时务必看清评测口径。

WebArena：真实环境的长程执行

WebArena 在自托管的真实网站环境里测，含 812 个长程任务，模拟用户在真实网页上的操作，比如订机票、管邮箱。GPT-4 在这个基准上只有 14.41%，人类是 78.24%。它的核心价值在于测 Agent 在长上下文、多步骤交互中的稳定性，还有应对真实网页结构变化的能力。

τ-bench：可靠性与规则遵从

τ-bench 把工具、Agent 和用户三方交互引入场景，格外强调政策遵从和可靠性，测试落在零售和航空两个领域。数据显示，gpt-4o 在零售领域的 pass^1（一次尝试成功率）约 61%，pass^8（八次尝试全部成功的概率）却不到 25%。落差这么大，暴露的正是 Agent 稳定性上的短板：偶尔能完成任务，但很难保证每次都正确。

APEX-Agents：职业级生产力

APEX-Agents 的题由投行、咨询和法律专家出，480 道跨应用任务，每题平均 4 条判据，且限制在 250 步内完成，是目前最接近真实职业场景的基准。截至 2026 年初，榜首模型 Gemini 3 Flash 的 Pass@1 只有 24.0%，开源模型普遍低于 5%。在高度专业化、长链条的任务里，Agent 的生产力要替代人类专家，还有相当长的路要走。

成功率之外的三根支柱：成本、鲁棒性与安全

光看成功率（Success Rate），在生产环境里显然撑不起评估。ACL 2026 综述提到，眼下评估体系还留着三块空白：成本效率、鲁棒性、安全性，这三样恰恰是工程落地绕不开的。

成本效率

Agent 的运行成本不光是 Token 消耗，还有执行步数、时延和外部 API 调用费用。一个任务能完成但耗时太长、成本太高的 Agent，商业上不可行。APEX-Agents 等基准已开始把基础设施成本纳入考量，这提醒我们设计 Agent 时要建立成本核算机制，盯住每一步的资源消耗。

鲁棒性：pass^k 与 pass@k 的区别

这个概念最值得强调。HumanEval 等代码基准里常用 pass@k，即 k 次尝试中至少成功一次的概率，量的是 Agent “碰得上”的能力。生产系统要的是 pass^k，即 k 次尝试全部成功的概率，量的是 Agent “靠得住”的能力。

举个例子。假设两个 Agent，在 10 个任务上各跑 8 次：

• 拿两个 Agent 举例，同样 10 个任务各跑 8 次。Agent A 的表现是：8 个任务回回都成，剩下 2 个任务一次没成，平均分因此偏高，pass^8 为 0.6，也就是 60% 的任务能稳定成功。Agent B 则是另一种情况：每个任务都能成 5-6 次，可没有哪个任务能做到 8 次全对。它的 pass@8 可能达到 1.0——机会给够，总能碰对一次——但 pass^8 是 0.0。

放到生产环境里看，Agent B 其实没法用，因为没有一个任务算得上绝对可靠，每次都得靠人兜底。Agent A 虽有短板，可在自己擅长的领域是稳的。τ-bench 里 gpt-4o 从 pass^1 的 61% 掉到 pass^8 的 25% 以下，说的就是这回事。所以说，生产环境真正该盯的核心指标是 pass^k。

安全性

Agent 权限越大，越狱、注入攻击、权限滥用带来的风险就越重。眼下评测体系在安全这块还只是刚起步。落到工程上，得先把最小权限原则立起来，再在关键操作前加一道 Human-in-the-loop（人工确认）闸门。

前沿方向：终身学习与 Skills 生态

Agent 技术正从静态模型转向能动态进化的系统。

终身学习要解的，是持续适应和灾难性遗忘之间的那道矛盾：学新任务的同时，旧能力不能丢。这需要感知、记忆、行动几个模块一起优化，也是记忆管理理论往深处走的一步。

自我进化指向的是 Agentic RL（强化学习）。Agent 已经能自己生成训练数据、自己评估、自己修正，这种“自产数据”的路子，有机会绕开人类标注数据的瓶颈。

Agent Skills 生态是另一条重要趋势。Anthropic 推出的 Agent Skills 标准，把能力封成一个个文件夹——里面放描述文件、脚本和资源，运行时挂载即可。能力分发的方式由此从“训练进参数”变成“运行时加载”，和 MCP 协议的标准化路径有点像。往后，参数化训练与运行时技能挂载会并行推进，Agent 的灵活性和可扩展性都会更强。

个人项目路线建议

想深入实践 Agent 评估，可以照这条路线走：

1. 基础巩固：不借助大型框架，从零手写一个最小 Agent Loop，接上 2-3 个真实工具（比如邮件摘要、文件整理），把工具调用、终止条件和失败处理的手感练出来。
2. 全流程实战：挑一个垂直领域（文献调研或运维都行），从框架选型、MCP 接入、Tracing 监控、权限控制一路走到部署，重点把生产化环节的知识补齐。
3. 构建私有评测集：这一步是进阶的关键。给自己的 Agent 建一个 50 道题的私有评测集，题目要涵盖真实任务，终态判据要明确。每题跑 4-8 次，算 pass^4 或 pass^8。在决定微调还是 RL 之前，先用这套评测集把基线立起来。
4. 持续跟踪：GAIA、τ-bench、APEX 这些榜单的变化要定期看，感受技术边界往哪移。要记住，全对的评测集没有价值——难度得加到 Agent 会失败，评估才开始给出有意义的信号。

评估先行，训练在后。Agent 到底哪里不行还没搞清楚，盲目微调多半是白费功夫。靠 pass^k 这类严谨指标，才能看清 Agent 真实的能力边界，进而做出真正可靠的生产级应用。