Artificial Analysis Coding Agent Index 深度剖析：三大基准的测评哲学与工程意义

三个基准，三个维度

Artificial Analysis 做了一件被很多人忽视的事：他们评测的是 "Agent 完整系统"，而不只是裸模型。同一个模型（例如 Claude Opus 4.5）在不同 agent harness 下（Cursor CLI vs Claude Code vs Codex）得分可以相差 15 个百分点以上。传统的 MMLU、HumanEval、SWE-Bench Verified 只看模型能力，而这个指数把 harness × model 组合作为一个整体来评测——这才接近工程选型的真实决策场景。

指数由三个基准等权（各 1/3）简单平均构成，每基准跑 3 次取 pass@1 均值。总任务量 358 道。

① SWE-Bench-Pro-Hard-AA（150 题）—— 交付可用代码

来源链路：SWE-Bench → SWE-Bench Verified（500 题，去噪）→ SWE-Bench Pro（Scale AI SEAL，731 题，抗污染）→ Hard-AA 子集（150 题精选）。

这个演进链路本身就说明问题：SWE-Bench Verified 已经被污染。同一个 Claude Opus 4.5，Verified 上 80.9%，Pro 上直接腰斩到 45.9%。Pro 上的 46% 比 Verified 上的 81% 更接近真实能力。而 Hard-AA 是 Pro 的困难子集，分数会进一步压低。

测什么：Agent 收到 GitHub issue + 代码仓库 → 浏览文件 → 编辑代码 → 跑测试 → 生成 patch → 必须通过原仓库的 test suite。二元评分，全过得 1，不过得 0。这是三个基准中最接近真实 "修 Bug / 写 feature" 场景的。

隐含挑战：Hard-AA 的 150 道题从 731 道 Pro 中如何筛选？这个筛选逻辑没有完全公开。如果筛选策略是 "当前模型表现差的题"，就引入了选择偏差——相当于专门挑了模型的短板来测。

② Terminal-Bench v2（84 题 / 原 89）—— 在终端里办事

来源：Stanford + Laude Institute 联合项目，Snorkel AI 为主要贡献者。开源（GitHub: harbor-framework/terminal-bench），在 Docker 沙箱中执行。

测什么：不是写代码，而是 "在 shell 里办事"——检视文件、运行命令、debug 失败、跟踪多步状态。考验的是 Agent 对终端环境的理解和操作能力，这在 infra / DevOps / 调试场景中至关重要。

被排除的 5 道题：AA 声明因 "环境兼容性问题" 排除。这值得追问——如果排除的是依赖特定系统环境（如特定 OS 版本、网络条件）的任务，可能系统性低估 Agent 的终端操作上限。不过反过来看，在标准化评测中排除环境依赖题也是合理的做法。

二元评分，测试套件判定 pass/fail。与 SWE-Bench 相同，没有 partial credit。

③ SWE-Atlas-QnA（124 题）—— 读懂代码并回答

来源：Scale AI 的 SWE-Atlas 基准套件（arXiv: 2605.08366）。注意：SWE-Atlas 完整版包含三个子任务——Codebase Q&A（124 题）、Test Writing（90 题）、Refactoring（70 题）——但 AA 只用了 Q&A 部分。

测什么：Agent 需要阅读代码库、理解架构和行为，然后给出文字答案。不要求修改代码。这是纯 "阅读理解" 维度。

唯一支持 partial credit 的基准：Rubric-based grading，每题得分 0–1 连续分布。答案可以部分正确——答对一半的 rubric 检查项拿 0.5 分。这意味着 SWE-Atlas-QnA 的 per-task 平均分通常高于另外两个二元基准，在等权平均中实际权重可能更大。

缺少的维度：SWE-Atlas 的 Test Writing 和 Refactoring 被跳过。这两个在实际工程中占比很高——写测试是 TDD 的基础，重构是日常维护的核心。跳过它们意味着指数缺失了两个重要的工程能力维度。

设计逻辑：为什么是这三个？

AA 的官方说法很直白："不同 Agent 在 repository Q&A、implementation / bug-fix tasks、terminal-heavy workflows 上表现差异巨大。指数的意义不是把所有编码工作坍缩成一个任务类型，而是把不同 benchmark 家族聚合到一个顶层视图，同时保留底层分类明细。"

三个基准的维度正交性确实不错：

• 写代码（SWE-Bench-Pro-Hard-AA）：实现可靠性，产出可验证的 patch
• 终端操作（Terminal-Bench v2）：工具使用能力，shell 环境中的多步工作流
• 读代码（SWE-Atlas-QnA）：仓库理解深度，不需要产出可执行代码

一个 Agent 可能读代码很强但修不好 Bug（理解正确但实现出错），也可能修 Bug 强但终端操作弱（编码厉害但不会用命令行工具）。三者组合才能反映全栈 coding agent 能力。

亮点与创新

✓ Harness-aware 是真正的进步

2026 年的 coding agent 市场已经从 "哪个模型最强" 变成了 "哪个 agent 组合最好用"。同一模型在不同 harness 下表现差异巨大。AA 把 harness 作为一等评测维度（每个榜单行是 "模型 + harness + 设置" 的组合），这比单纯报模型分数实用得多。

✓ 效率指标并重

除了 pass@1 分数，AA 还报告：

• Cost per task：基于 API token 定价的实际费用（非订阅价格）
• Token 消耗：区分 input / cache / cache-write / reasoning / output
• Wall-clock 执行时间：完整任务耗时

这在工程选型中极其重要。一个 Agent 拿 60 分但每次花 $15，另一个拿 55 分但每次 $2，后者性价比高出 6 倍。没有效率指标，你无法做出理性决策。

✓ 抗污染设计

三个基准都不是老旧的 SWE-Bench Verified。SWE-Bench Pro 是专门为抗污染设计的（新题、未公开答案），Terminal-Bench v2 是 v2 升级版，SWE-Atlas 是全新基准。这避免了 "模型在训练数据中见过题目" 的虚高分数问题。

✓ 统计稳定性

每基准跑 3 次取平均。虽然 3 次仍然偏少（尤其对二元评分的高方差任务），但好过只跑 1 次。

局限与改进空间

✗ 等权平均过于粗暴

三个基准的难度、区分度、评分分布完全不同：

• SWE-Bench-Pro-Hard-AA：二元 0/1，极难（Pro 上最好模型才 ~46%）
• Terminal-Bench v2：二元 0/1，难度未知
• SWE-Atlas-QnA：连续 0–1，有 partial credit，均值通常更高

等权 1/3 意味着 SWE-Atlas-QnA 的连续分（因为有 partial credit，均值系统性偏高）在指数中的实际贡献可能大于 1/3。更合理的做法是按难度归一化或使用 z-score。

✗ Hard-AA 子集不透明

150 道从 731 道中筛选的逻辑未完全公开。任何 "精选 harder subset" 的操作都可能引入主观偏差。如果筛选准则是 "当前最强模型也做不对"，那这个 subset 更多反映的是 "模型的当前盲区" 而非 "通用的工程难度"。

✗ 缺少可靠性维度

3 次重复只取均值，不报告方差。同一个 Agent 可能 3 次得分 (80, 20, 50)，均值 50 看起来还行，但实际极不可靠。对于生产环境，可靠性（方差）往往比均值更重要——一个稳定拿 45 分的 Agent 比一个波动在 20–70 之间的 Agent 可预测得多。

✗ 缺少自修正能力评测

pass@1 只测一次尝试，不测 Agent 看到测试失败后能否自我修复。现实中的 Agent 工作流几乎总是迭代式的：写 patch → 跑测试 → 看错误 → 修复 → 再跑。pass@1 丢掉了这个最重要的反馈循环。

✗ 题目总量偏小

三基准加起来 358 道独立任务（且有 3 次重复），对比 SWE-Bench Full 的 2,294 题，统计效力有限。尤其当模型之间差距在 3–5 分时，这可能没有统计显著性。

✗ 缺少多模态 & 测试/重构维度

三个基准全是纯文本/代码任务，不涉及 UI 截图、设计稿、API 文档截图等多模态输入。同时跳过了 SWE-Atlas 的 Test Writing 和 Refactoring 子任务——这两个在实际工程中占比很高。

与其他主流 Benchmark 体系的对比

维度	AA Coding Agent Index	SWE-Bench Verified	Aider Polyglot
评测对象	Agent 系统（model + harness）	裸模型（通常）	Agent 系统
任务类型	3 种异构	单一（修 Bug）	单一（编辑代码）
抗污染	高（Pro-based）	低（已明显被污染）	中
效率指标	✓（cost / token / time）	✗	✗
Partial credit	仅 Atlas-QnA	✗	✗
题目透明度	中（Hard-AA 子集不透明）	高	高
Harness 差异可见	✓	✗	✓（有限）

实用建议：什么时候用它，什么时候不够

适合的场景：

• 选型 coding agent 全栈方案（Cursor vs Claude Code vs Codex vs Copilot）
• 需要同时考虑质量、成本、速度的决策
• 对比同一模型在不同 harness 下的表现差异
• 跟踪 coding agent 领域的能力演进趋势

不够用的场景：

• 你的主要工作是单一类型任务（如只修 Bug、只做 code review）——看对应子基准即可
• 需要评测 Agent 的自修正 / 迭代能力——需要补充 pass@k（k ≥ 2）
• 需要多模态能力（处理设计稿 → 写前端，或 UI bug 截图 → 定位代码）
• 需要评测特定语言 / 框架——三个基准主要是 Python 仓库
• 团队预算极度敏感——需要结合自己的 API 订阅计划重新算实际成本

底线判断

AA Coding Agent Index 是目前最好的 Agent 系统级评测框架之一。核心价值在于三点：harness-aware 设计（把 harness 作为一等变量）、效率并报（不止报分数）、抗污染（三个基准都比较新）。

但它更适合做 相对排名 而非 绝对能力测量。等权平均、358 题总量、缺少方差报告——这些意味着指数上 3–5 分的差距可能没有统计显著性。选型时建议：看子基准分类得分 + 效率指标，而不是只看总指数排名。

2026 年的 coding agent 评测正在从 "排行榜竞赛" 走向 "工程决策工具"。AA 这个指数是正确方向上的关键一步——但还远不是终点。

发布日期：May 14, 2026