本文系统梳理 coding agent 评测领域的主流基准、评测指标与框架，覆盖 2021–2026 年的学术论文与工业界实践，适合希望了解或搭建 agent 评测体系的研究者和工程师参考。
一、背景：从代码补全到软件工程 Agent
Coding agent 的评测体系随模型能力演进经历了三次范式转变：
- 2021–2022：函数级代码生成时代。HumanEval、MBPP 等基准以单函数合成为核心，
pass@k为唯一指标，题目简单、数据集静态。 - 2023–2024：仓库级真实任务时代。SWE-bench 将评测对象从函数提升为真实 GitHub issue，要求 agent 理解 bug 报告、导航大型代码库并生成正确补丁。
- 2024–2026：多维度 agent 评测时代。随着 SWE-bench Verified 被顶级 agent 超过 70% 解决率（OpenAI 于 2025 年宣布将其退役），业界转向更难的 SWE-bench Pro、多模态、多语言基准，以及专门衡量 tool use 和多步规划能力的 agent 评测框架。同时，Claude Opus 4、Sonnet 4 等新一代模型的发布进一步加速了基准饱和。
当前评测体系面临三大核心挑战：基准饱和、数据污染（训练集泄露与搜索时污染）、指标局限（pass@k 无法度量推理过程）。
二、核心评测基准
2.1 第一代：函数级代码生成
HumanEval
| 项目 | 内容 |
|---|---|
| 来源 | OpenAI，2021 年随 Codex 模型发布 |
| 规模 | 164 道手写 Python 题 |
| 机制 | 给定函数签名+docstring，生成函数体，在隐藏测试用例上执行验证 |
| 核心指标 | pass@k，pass@1 最常用 |
| 当前水平 | Claude Sonnet 4 达 95.1% pass@1（2025） |
| 论文 | arXiv:2107.03374 |
局限： 164 题规模极小、静态数据集、已被广泛记忆，现已近乎饱和。HumanEval+ 通过扩增测试用例提供了略高的区分度，但本质局限未变——该基准已从"能力鉴别器"退化为"入门资格检验"。
MBPP（Mostly Basic Python Problems）
| 项目 | 内容 |
|---|---|
| 来源 | Google Research，2021 |
| 规模 | 974 道众包 Python 入门题 |
| 机制 | 自然语言描述 → 代码生成，每题 3 条 assert 测试 |
| 核心指标 | pass@1 / pass@k |
| 当前水平 | 前沿模型 95%+，已几乎饱和 |
| 论文 | arXiv:2108.07732 |
2.2 第二代：仓库级真实任务
SWE-bench（当前核心基准）
| 项目 | 内容 |
|---|---|
| 来源 | Princeton NLP，2023 |
| 规模 | 2,294 个实例；Verified 子集 500 个（人工验证） |
| 机制 | 给定真实 GitHub issue + 完整仓库，agent 需修改代码使"Fail-to-Pass"测试通过 |
| 数据来源 | 12 个知名 Python 开源项目（Django、scikit-learn、Flask 等） |
| 核心指标 | % Resolved：补丁通过所有关联单元测试的比例 |
| 难度演变 | 2023 年最强模型（Claude 2）仅解决 1.96%；2025 年顶级 agent 超过 70% |
| 论文 | arXiv:2310.06770 |
变体：
- SWE-bench Lite：300 个相对独立的 issue，适合快速评测
- SWE-bench Verified：OpenAI 联合推出，500 个人工核验实例，2024 年成为主流标准
- SWE-bench Pro：2025 年 9 月推出（arXiv:2509.16941），1,865 个任务覆盖 41 个活跃维护的仓库，顶级模型得分约 20–25%（标准化评测），是目前最难的版本
- SWE-bench Multimodal：包含图片（截图、UI 设计稿、架构图）的 issue，最佳系统仅解决约 12–15%，暴露了当前 agent 在视觉上下文理解上的短板
- SWE-PolyBench：2,110 个实例，覆盖 Java、JavaScript、TypeScript、Python；部分模型从 Python 切换到其他语言后性能下降 20–40%
2025 年排行榜现状： Claude Sonnet 4 / Opus 4 是得分最高 agent 的主流底座；AIR 在 SWE-bench Verified 上达到 87.1%，GitHub Copilot 约 56%，OpenAI Codex（agent）约 51.7%。OpenAI 已宣布 SWE-bench Verified 不再衡量前沿能力，建议迁移到 SWE-bench Pro。
BigCodeBench
| 项目 | 内容 |
|---|---|
| 来源 | BigCode 社区，2024 |
| 规模 | 1,140 个函数级任务，覆盖 139 个库、7 个领域 |
| 机制 | 每题需综合调用多个真实库（如 os + requests + pandas），执行测试验证 |
| 核心指标 | pass@1（执行验证，非字符串匹配） |
| 变体 | Complete（完整签名）/ Instruct（仅自然语言描述）/ Hard（高难子集） |
| 论文 | arXiv:2406.15877 |
定位： 被称为"下一代 HumanEval"，专注多库组合调用能力，更贴近真实开发场景。
2.3 第三代：污染对抗与持续更新基准
LiveCodeBench
| 项目 | 内容 |
|---|---|
| 来源 | UC Berkeley / MIT / Cornell，2024，ICLR 2025 收录 |
| 规模 | 800+ 题（持续增长），来自 LeetCode、AtCoder、Codeforces |
| 机制 | 按模型训练截止日期过滤题目，仅在"训练后发布"的题上评测 |
| 评测任务 | 代码生成、自修复（self-repair）、代码执行理解、测试输出预测 |
| 核心指标 | pass@1 + 各子任务准确率 |
| 污染防护 | 严格时间窗口过滤，已在 GPT-4o、Claude、DeepSeek 等模型上检测到污染 |
| 论文 | arXiv:2403.07974 |
Commit0
| 项目 | 内容 |
|---|---|
| 来源 | 2024 年 12 月 |
| 机制 | 要求 agent 从零重建 57 个核心 Python 库，仅给自然语言规范，通过库自身单元测试 |
| 难度 | 多阶段迭代 + 复杂依赖，远难于静态补丁生成 |
| 论文 | arXiv:2412.01769 |
定位： 目前最接近真实软件工程交付物的基准之一。
RE-Bench
| 项目 | 内容 |
|---|---|
| 来源 | METR，2025 |
| 规模 | 7 个 AI 研发环境，每题限时 8 小时 |
| 机制 | 在受控容器中执行真实 ML 研发任务（训练优化、数据增强、模型改进等），按改进幅度评分 |
| 定位 | 唯一聚焦"AI 做 AI 研发"的基准，评估 agent 在长周期复杂任务中的规划与迭代能力 |
| 论文 | arXiv:2503.04474 |
发现： METR 时间跨度分析表明，agent 可靠性在超过数小时的任务后急剧下降，RE-Bench 正是为检测这一衰减设计。
SciCode
| 项目 | 内容 |
|---|---|
| 来源 | NeurIPS 2024 Datasets & Benchmarks |
| 规模 | 65 道主题题 → 338 道子题，覆盖数学、物理、化学、生物、材料、力学 |
| 机制 | 由领域科学家出题，同时考察编程能力和专业知识 |
| 定位 | 前沿模型上限测试；前沿模型仍有显著差距 |
| 论文 | arXiv:2407.13168 |
三、评测指标体系
3.1 pass@k 及其局限
pass@k 是最广泛使用的代码评测指标，定义为：在 k 次独立采样中，至少一次通过所有测试用例的概率。
计算方式：
$$ pass@k = 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}} $$其中 n 为总采样次数，c 为通过的样本数。
主要局限：
- 奖励"暴力采样"而非真正的推理能力，算力预算掩盖模型质量
- 静态测试用例可被记忆，排名不稳定
- 无法区分推理深度与运气
- 纯结果指标，无法诊断失败原因
3.2 超越 pass@k 的新指标
| 指标/方法 | 核心思想 | 来源 |
|---|---|---|
| Breadth-Depth Metrics | 分别度量覆盖广度（能解决多少类问题）和深度（对每类问题的可靠性） | arXiv:2510.08325 |
| Bayesian pass@k | 在采样量少时稳定排名，减少假结论 | arXiv:2510.04265 |
| pass@o | 面向 OOP 场景，评估类级别与封装正确性 | ACL 2024 Findings |
| CodeJudge（LLM-as-Judge） | 用 LLM 评估器替代手写测试用例判定正确性 | arXiv:2505.20854 |
| SWE-Effi | 在 SWE-bench 解决率基础上加权 token 成本与执行时间 | SWE-agent 扩展工作 |
| 三维评测框架 | 效果（任务成功率）× 效率（执行步骤）× 开销（token 消耗） | OpenHands/PULSE |
| pass^k（Tau2-bench） | 度量 agent 在 k 次重复尝试中的一致性，区分"能做到"和"稳定做到" | Sierra Research / Princeton |
| HAL 成本联合评测 | 强制要求 score 与 cost 联合报告；发现同一基准上每次运行成本跨 4 个数量级 | Princeton HAL，ICLR 2026 |
3.3 多语言与多模态扩展指标
- MultiPL-E：将 HumanEval/MBPP 翻译为 20 种编程语言，揭示 Python-only 评测高估通用能力（IEEE TSE 2023）
- CRUXEval：800 道短 Python 函数，分输入预测和输出预测两个方向，测试代码推理而非代码生成（arXiv:2401.03065）
- CRUXEval-X：多语言扩展至 19 种语言，ACL 2025 收录；仅在 Python 上训练的模型在其他语言只有约 34.4%
四、Agent 评测框架
4.1 AgentBench
论文： arXiv:2308.03688，2023 年
首个系统性评测 LLM 作为自主 agent 的多环境基准，包含 8 个交互环境（OS 命令行、数据库、网页浏览、卡牌游戏、家庭任务等），测试 29 个模型。
核心发现： 商业 LLM（GPT-4、Claude）远超开源模型；主要失败模式为长期推理能力弱、指令遵循差。
4.2 SWE-agent（Scaffold 框架）
论文： arXiv:2405.15793，2024 年
SWE-agent 是一个 agent 脚手架（中间件层），为 LLM 提供结构化的仓库导航、文件编辑、Shell 执行等工具接口。
关键洞察： Scaffold 设计本身是性能的重要决定因素——相同的 LLM 底座在更强的 scaffold 下可解决更多 issue。这一发现推动了 scaffold 架构分类研究的兴起。
原始得分： SWE-agent + GPT-4 在 SWE-bench 全集达 12.47%，HumanEvalFix 达 87.7%。
后续发展： Live-SWE-agent（2025 年 11 月，arXiv:2511.13646）是首个在运行时自我改写工具的 agent scaffold——“自进化脚手架”。Claude Sonnet 4.5 + Live-SWE-agent 在 SWE-bench Pro 上达 45.8%（当时开源 scaffold 最高），Gemini 3 Pro + Live-SWE-agent 在 SWE-bench Verified 上达 77.4%。与之形成对照的是 mini-swe-agent：仅用 subprocess.run 的极简 scaffold 也能在 SWE-bench Verified 上超过 74%，说明瓶颈更多在于模型推理能力而非 scaffold 复杂度。
4.3 OpenHands（原 OpenDevin）
论文： arXiv:2407.16741
开放的 AI 软件开发 agent 平台，支持插入任意 LLM 和 agent 进行对比评测。
评测方法论：
- 支持 13+ 基准（SWE-bench、WebArena、SkillsBench 等）
- PULSE 框架：用户反馈 + ML 模型预测满意度 + 伪标签，实现以人为中心的评测
- OpenHands Index（2026 年 1 月）：跨五个维度的综合评测——SWE-bench Verified（issue 修复）、Commit0（从零构建）、SWE-bench Multimodal（前端）、SWT-bench（测试）、GAIA（信息获取），取宏观平均分
4.4 Agentless
论文： arXiv:2407.01489
反直觉的发现：无 agent 循环的简单两阶段流水线（故障定位 → 补丁生成与筛选）在 SWE-bench 上超越复杂 agent 框架。
性能： SWE-bench Lite 解决率 32%，成本约 $0.70/次，发布时超越所有开源 agent。
核心启示： 故障定位质量（函数级 > 文件级 > 行级）是代码修复的关键瓶颈，而非 agent 架构的复杂度。
4.5 InterCode
论文： arXiv:2306.14898，NeurIPS 2023
将交互式编程建模为强化学习问题：动作 = 代码，观测 = 执行反馈。支持 Bash、SQL、Python、CTF 四种环境，使用 Docker 保证安全可复现执行。
五、工具调用与多步规划的评测前沿
最终答案正确率对 agent 质量而言是个糟糕的信号——步骤级轨迹指标才能揭示 pass@k 看不到的失败模式。
5.1 轨迹级评测框架
| 框架 | 核心贡献 | 来源 |
|---|---|---|
| TRAJECT-Bench | 5,870 条查询（简单/困难/顺序），评估工具选择准确率、参数构造正确性、调用顺序依赖满足度；揭示"相似工具混淆"等失败模式 | arXiv:2510.04550，ICLR 2026 |
| MCP-Radar | 五维评测：答案准确性、工具选择效率、资源效率、参数构造准确性、执行速度 | arXiv:2505.16700 |
| DeepPlanning | 长视野规划中的可验证约束；发现前沿 LLM 在并行工具调用和显式多步推理链上显著退化 | arXiv:2601.18137 |
| ToolBench | 真实场景下规划、创建、使用工具的全流程基准 | ACL 2024 Findings |
MCP 评测生态的扩展： 2025–2026 年涌现了大量 MCP 专项基准：MCP-Bench（arXiv:2508.20453）、MCPToolBench++（1,500 查询覆盖 40+ 工具类别）、MCP-Universe（真实 MCP 服务器）、MCPWorld（混合 API+GUI）、LiveMCPBench（“Agent 能否导航 MCP 工具海洋？"）、MCP-AgentBench（AAAI 2025，33 个 MCP 服务器）。
5.2 LLM-as-Judge 方法
当测试用例难以穷举时，用 LLM 评估器代替手写测试判定代码正确性正在兴起。CodeJudge（基于 Llama-3-8B）在无需执行环境的情况下，评测性能超过基于 GPT-3.5 的方案。
六、数据污染问题与应对策略
这是目前评测体系中最重要的方法论争议。
6.1 污染类型
- 训练集泄露：基准题目出现在训练数据中，模型"背题"而非"解题”
- 问题上下文泄露：相关讨论、题解被间接纳入训练
- 搜索时污染（2025 年新问题）：具备搜索能力的 deep research agent 在评测时直接检索基准答案，人为抬高得分（arXiv:2606.05241）
6.2 五种主流污染检测方法
| 方法 | 原理 |
|---|---|
| 时间分区法 | 对比模型在训练截止日期前后题目上的表现差异（“Codeforces 断崖"效应） |
| Min-K% 概率 | 检查模型对基准题目 token 的预测概率是否异常高 |
| Time Travel 攻击 | 仅给模型任务 ID（无代码/描述），观察是否能复现答案 |
| ConStat | 对比模型在原始题目与改写题目上的表现差距 |
| BIG-Bench Canary | 在训练数据中嵌入 GUID，检查模型是否记忆 |
已被污染实质性影响的基准包括：MMLU、HumanEval、HellaSwag、原始 GSM8K，均已出现 90%+ 的天花板分数。
6.3 为什么 SWE-bench Verified 被退役
OpenAI 明确指出设计缺陷和污染是退役原因：“该基准不再能衡量前沿编程能力”，建议转向 LiveCodeBench 和 SWE-bench Pro。关键证据：在 138 个任务的抽样审计中，59.4% 存在测试缺陷（35.5% 的测试强制执行未在 issue 中描述的实现细节，18.8% 检查的功能来自其他 PR）。更具决定性的是，OpenAI 仅给 GPT-5.2、Claude Opus 4.5 和 Gemini 3 Flash 一个任务 ID（如 django__django-11099），不提供任何代码或描述，三个模型均能从记忆中逐字复现金标准补丁——精确到文件路径、行号和字符级修改。参见 OpenAI 博客。
6.4 主流反污染策略
| 策略 | 代表工作 | 原理 |
|---|---|---|
| 时间窗口过滤 | LiveCodeBench | 仅评测训练截止日期后发布的题目 |
| 动态生成 | EvoEval、EvoCodeBench | 用 LLM 演化现有题目，使记忆的答案失效 |
| 多智能体博弈 | arXiv:2605.04312 | agent 相互对抗，静态记忆无效 |
| 分发感知构造 | arXiv:2607.20911 | 跨领域（代码、Web、安全）构建污染抵抗基准 |
| NIST CAISI 定义 | NIST 官方框架 | 将"解题污染”（访问超出部署约束的信息）定义为核心作弊向量 |
七、工业界评测实践
7.1 主流 Coding Agent 评测方式对比
| 工具 | SWE-bench Verified（2025） | 评测特点 |
|---|---|---|
| Claude Code（Opus 4/Sonnet 4） | 72.5–80.2% | 按任务类型细分（文档 92.3%，功能 72.6%）；commit message 质量领先；1M token 上下文 |
| GitHub Copilot | ~56–68% | 公开基准 + 微软/GitHub 内部私有基准；同时评测 token 效率与速度 |
| OpenAI Codex（agent） | GPT-5.5 报告 88.7% | 沙箱环境运行；SWE-bench Pro 上 GPT-5.3 约 56.8% |
| Cursor | ~51.7–75% | 分数取决于底座模型选择；全仓库索引比仅聊天历史提升约 25% 准确率 |
| Devin（Cognition AI） | ~65%（2026 估算） | 首发时 13.86%（2024 年初），是当时最强无辅助基线的 7 倍 |
关键发现：
- 没有单一 agent 在所有任务类型上占优——Claude Code 领跑文档和功能类任务，其他工具在特定任务类型上各有优势。
- Vendor 报告分数与标准化评测差距巨大：vendor scaffold 分数通常比 Scale SEAL 标准化分数高 15–30 个百分点，直接比较无意义。
- 多工具组合使用已成主流：开发者普遍采用 Cursor（行内补全）+ Claude Code（重型 agent 任务）的双工具栈。
- 成本必须联合报告：HAL（Princeton，ICLR 2026）在 21,730 次运行中发现，同一基准上的单次运行成本跨越 4 个数量级。
7.2 多维度评测框架趋势
工业界正从单一准确率指标转向多维评测：
- 效果（任务成功率）
- 效率（执行步骤数 / 时间）
- 成本（token 消耗 / 美元成本）
- 质量（代码可读性、commit message 质量）
八、评测体系全景总结
8.1 基准选择参考
| 评测目标 | 推荐基准 | 原因 |
|---|---|---|
| 基础代码生成能力 | HumanEval + MBPP | 经典对照，仅作为入门资格检验；前沿区分请用 LiveCodeBench |
| 真实软件工程能力 | SWE-bench Pro | 仓库级 issue 修复，1,865 个任务覆盖 41 个仓库；Verified 已接近饱和 |
| 污染对抗评测 | LiveCodeBench | 持续更新，时间窗口过滤，800+ 题 |
| 多库 API 综合调用 | BigCodeBench | 真实库依赖，执行验证，Hard 子集仍有区分度 |
| 多语言能力 | MultiPL-E / SWE-PolyBench / Aider Polyglot | 暴露 Python-only 训练的泛化缺陷（3–23 倍性能差距） |
| 推理上限测试 | SciCode / Commit0 / RE-Bench | 前沿模型仍有大量提升空间；RE-Bench 专测长周期任务衰减 |
| Tool use / 规划能力 | TRAJECT-Bench / MCP-Radar | 步骤级诊断，超越最终结果 |
| CLI / 系统级能力 | Terminal-Bench | 命令行操作、环境配置、系统调试 |
| 多模态软件工程 | SWE-bench Multimodal | 包含 UI 截图、架构图的 issue |
8.2 核心洞察
- Scaffold 与底座同样重要：相同 LLM 在不同 agent scaffold 下的解决率差异可达 30–50 个百分点（HAL/GAIA 实证数据），scaffold 设计已成为独立研究方向。Meta 以约 $2B 收购 Manus（2025 年 12 月）被业界解读为收购 harness 架构而非底座模型。
- 简单不一定输：Agentless 的无循环两阶段流水线在 SWE-bench 上超越复杂 agent，故障定位质量是真正瓶颈。mini-swe-agent 仅用
subprocess.run也能超过 74%。 - 基准生命周期在压缩：从 HumanEval 饱和到 SWE-bench Verified 退役（2026 年 2 月），前沿模型刷爆主流基准的周期越来越短。HumanEval、MMLU、HellaSwag、GSM8K 均已实质失效。持续更新的基准（LiveCodeBench）和更难的任务（SWE-bench Pro、Commit0）是趋势。
- 指标需要升维：pass@k → 三维评测（效果 × 效率 × 成本）→ 轨迹级评测（工具调用准确性、规划依赖满足度）是演进路径。HAL 的核心主张是"不报告成本的分数无意义"。
- 搜索时污染是新威胁：2025 年才被系统研究，具备搜索能力的 agent 可在评测时直接检索答案。OpenAI 的 Time Travel 实验（仅给任务 ID 即复现金标准补丁）证明了污染的严重程度。
- Python 偏见是系统性盲区：SWE-PolyBench 和 Multi-SWE-bench 均发现，模型在 Python 上的表现是其他语言的 3–23 倍。仅在 Python 上评测会严重高估模型的通用编程能力。
参考文献与资源
核心论文
- SWE-bench: arXiv:2310.06770
- SWE-bench Pro: arXiv:2509.16941
- HumanEval / Codex: arXiv:2107.03374
- MBPP: arXiv:2108.07732
- LiveCodeBench: arXiv:2403.07974
- BigCodeBench: arXiv:2406.15877
- SWE-agent (Scaffold): arXiv:2405.15793
- Live-SWE-agent: arXiv:2511.13646
- Agentless: arXiv:2407.01489
- AgentBench: arXiv:2308.03688
- OpenHands: arXiv:2407.16741
- InterCode: arXiv:2306.14898
- SciCode: arXiv:2407.13168
- Commit0: arXiv:2412.01769
- RE-Bench: arXiv:2503.04474
- SWE-PolyBench: arXiv:2504.08703
- EvoEval: arXiv:2403.19114
- EvoCodeBench: arXiv:2602.10171
- MultiPL-E: IEEE TSE 2023
- CRUXEval: arXiv:2401.03065
- Search-Time Contamination: arXiv:2606.05241
- TRAJECT-Bench: arXiv:2510.04550
- MCP-Radar: arXiv:2505.16700
- LLM Code Gen Evaluation Survey: arXiv:2408.16498
- LLM-based Agent Evaluation Survey: arXiv:2503.16416
- Agentic SE Benchmark 反思: arXiv:2606.17799
排行榜与工具