21. Benchmark 全景：SWE-bench、AgentBench、τ-bench 怎么读

你一定见过这类新闻："XX Agent 在 SWE-bench 上达到 65%，超越人类水平。"然后你去试，Agent 在你自己的任务上一塌糊涂。

这不是 benchmark 骗人，是你在用错误的方式读数字。这一篇把主流 Agent benchmark 逐一拆开：测的是什么、怎么测、数字意味着什么、又有什么它测不到的。

为什么 Agent 的 eval 比一般 LLM 难得多

一般 LLM eval 很简单——给一个 prompt，比较输出和 gold answer，准确率搞定。Agent eval 复杂在：

路径不唯一。完成同一个任务，Agent 可以走不同路径，中间步骤完全不同，但最终结果一样好。只评最终结果会漏掉效率差异；评中间步骤又太死板。

任务有副作用。Agent 可以真的修改文件、发 PR、点按钮。eval 环境必须隔离，不然 Agent "成功通过测试"的方式可能是作弊——比如直接修改测试文件让它 pass。

非确定性。同一个 Agent 跑两次，结果可能不同。benchmark 数字是多次采样的平均，但单次部署的方差可能很大。

分布外泛化。benchmark 的任务分布和你真实任务的分布很可能不一样。在 benchmark 上 70% 的 Agent，在你的业务场景上可能 30%。

带着这四个问题，去读每一个 benchmark 数字。

SWE-bench：Agent 能修复真实 GitHub issue 吗

SWE-bench 是目前最有影响力的编程 Agent benchmark，也是 Agent 领域里工程质量最高的评测。

它测什么：从 GitHub 上爬取 2294 个已修复的 bug issue（主要来自 Django、Flask、Scikit-learn 等知名 Python 项目）。给 Agent 看 issue 描述和仓库代码，让 Agent 生成 patch，然后跑官方测试套件，用测试通过来判断 patch 是否正确。

为什么这个设计好：

任务来自真实项目，不是人工构造的
用测试通过作为判断标准，客观、可重复
有人工 patch 对比，可以验证 Agent 的方法

SWE-bench Verified 是精选的 500 个子集，经过人工核验任务描述清晰、测试覆盖充分。看这 500 个的数字比看全量更有参考价值——全量里有相当比例任务本身就描述不清楚。

怎么读数字：截至 2025 年底，顶级系统（Claude + 专门工程）在 Verified 上达到 65% 左右，开源系统大约 30~50%。这个数字是"所有 issue 中能正确修复的比例"。

数字背后的假设：

测试套件是诚实的。如果测试覆盖不全，Agent 可以生成一个通过测试但破坏其他功能的 patch。
任务有完整的仓库上下文。实际项目里你可能还要先找到哪个文件、哪个函数，这步的难度没有在数字里体现。
Harness 把很多工程细节处理好了。生产 Agent 没有这么干净的环境。

SWE-bench Pro 是 2025 年发布的更难版本，任务来自更近的时间，刻意选了那些当前最强系统都解决不了的 issue，用来测试 Agent 的真实上限。

AgentBench：跨任务类型的通用 Agent 测试

AgentBench（清华 KEG Lab）的定位是"在一批不同任务上测 Agent 的通用能力"，而不只是编程。

包含的任务：

OS（命令行任务，操作虚拟 Linux 环境）
DB（SQL 操作，完成数据库任务）
KG（知识图谱查询和推理）
WebArena 子集（网页操作）
Card（卡牌游戏策略）
ALFWorld（家庭环境文本游戏）
Mind2Web（网页导航任务）

评分方式：每类任务有自己的 success metric，综合得一个总分。

怎么读：AgentBench 的价值在于横向对比——同一模型在 OS 任务上很强但在 WebArena 上很弱，说明什么？对你的任务类型有启示。

局限：任务设计年代稍早（2023），顶级模型现在大多数任务都能到很高准确率，区分度下降。2024 年后更关注 SWE-bench 的原因之一就是这个。

τ-bench：工具调用的现实压力测试

τ-bench（tau-bench，Princeton）专门测 Agent 在真实工具调用场景下的表现，更贴近实际业务 Agent。

核心设计：模拟用户和 Agent 多轮对话 + 工具调用。任务来自两个领域：零售（处理订单、退款、查询）和航空（改签、升舱、查航班）。Agent 必须调用一批 API 完成任务，同时不能做出错误操作（比如给不该退款的订单退款）。

评测重点：

工具调用准确率（参数正确吗）
业务逻辑遵从（不违反规定）
多轮对话一致性（前面说了不改的不能后来改）

为什么这个视角重要：大多数业务 Agent 不是写代码，是通过 API 完成任务。τ-bench 比 SWE-bench 更接近这类场景。

数字参考：当前顶级模型在 τ-bench 上的通过率约 40~60%，说明真实业务 Agent 还有很大提升空间。

WebArena 和 OSWorld：UI 交互的基准

这两个 benchmark 测的是"让 Agent 操作 UI 完成任务"。

WebArena：在真实网站（GitLab、Reddit、Wikipedia、商城）上完成自然语言任务。"在 GitLab 上创建一个新 issue，标题 XX，标签 YY"之类的。成功标准是检查网页状态是否符合预期。

OSWorld：让 Agent 控制桌面操作系统（Ubuntu、Windows、macOS），完成跨应用任务。"用 LibreOffice 打开 XX 文件，把第三列的总和填入 Cell B5"。难点在于需要看截图、操作真实 GUI，测视觉 Agent 能力。

数字参考：

WebArena：顶级系统约 40~55% 成功率
OSWorld：较难，约 20~40%，说明桌面 GUI 操作还远未解决

局限：两者的任务都相对简单、独立，不反映真实工作流里的跨任务依赖和长序列操作。

这些 benchmark 都测不到什么

这是读 benchmark 时最该注意的部分：

鲁棒性。benchmark 任务通常描述清晰，而真实用户输入模糊、歧义、甚至语法错误。在 benchmark 上 70% 的 Agent，面对真实用户输入可能只有 40%。

长任务稳定性。多数 benchmark 任务 10~30 步就结束。真实业务 Agent 可能要跑几百步。长任务里的目标漂移、上下文累积、错误放大，这些 benchmark 看不到。

分布外泛化。benchmark 任务是固定的。Agent 可能通过"记住"某类任务特征来提升分数，而不是真正会推理。换一批任务就掉一大截。

成本和延迟。benchmark 不管你花了多少钱跑出来。同样 70% 的两个 Agent，一个花 $0.05/task，另一个花 $5/task，实用性天差地别。

工具真实性。很多 benchmark 的工具是 mock 的，不会真的失败、超时、返回脏数据。真实工具更难对付。

如何建自己的 eval

Benchmark 的数字有参考价值，但最重要的是你自己任务分布上的数字。

最小可行 eval 的构建方法：

# 1. 从线上失败日志里挖 50 个真实任务
eval_set = load_from_traces(status="failed", limit=50) + \
            load_from_traces(status="success", limit=50)

# 2. 每个任务定义 success_fn
def success_fn(task, agent_output, trace):
    # 对于不同任务类型用不同判断逻辑
    if task.type == "data_query":
        return task.expected_answer in agent_output
    elif task.type == "file_edit":
        return file_matches_expected(task.expected_file)
    else:
        return llm_judge(task, agent_output)  # fallback 到 LLM judge

# 3. 跑评测
results = []
for task in eval_set:
    output, trace = run_agent(task)
    results.append({
        "task_id": task.id,
        "success": success_fn(task, output, trace),
        "steps": len(trace.spans),
        "cost": trace.total_cost,
        "latency": trace.total_time,
    })

# 4. 聚合
success_rate = mean([r["success"] for r in results])
avg_cost = mean([r["cost"] for r in results])
print(f"Success: {success_rate:.1%}, Avg cost: ${avg_cost:.4f}")

几个实操经验：

50~100 个任务就够开始。不需要千级。先有一个能跑的数字，比数字准确更重要。
从失败案例补充。每次 Agent 出 bug，把那个任务加进测试集。测试集越来越接近真实痛点。
分类聚合。按任务类型、用户类型、工具类型分别看成功率。"总体 60%"可能掩盖了某类任务 20% 的严重问题。
跑两遍取平均。Agent 非确定，单次跑结果不稳。重要决策前跑 3~5 次取中位数。

小结

读 benchmark 的正确姿势：看方法论，不只看数字。SWE-bench 测编程 Agent 修 bug 的能力，AgentBench 测跨任务泛化，τ-bench 测业务工具调用，WebArena/OSWorld 测 UI 操作。每个都有它覆盖的范围和覆盖不到的角落。

最实用的 eval 永远是你自己的任务分布上的数字。公开 benchmark 用来横向对比模型和系统选型，自己的 eval 用来驱动迭代。两个都要有。

这篇是 Agent 工程篇的收官之一。下一篇深入安全边界——Prompt Injection、权限最小化、沙箱逃逸，这是第 17 篇生产化章节点到为止、但值得专门展开的话题。