快照日期:2026-05-23。

追踪编程智能体最先进水平的有效方式不是”哪个模型最擅长编程?“,而是:

  • 能否修改真实代码仓库并通过测试?
  • 能否在终端中独立操作而无需手把手指导?
  • 能否处理不熟悉的语言和框架?
  • 能否构建产品级应用而不仅仅是玩具式补丁?
  • 分数能否经受更严格的测试、隐藏评估或新任务的考验?

基准评测概览

SWE-bench 系列

SWE-bench 仍然是自主代码修复的默认参考点。官方网站跟踪多个排行榜:Full、Verified、Lite、Multilingual 和 Multimodal。

适用场景:

  • 真实 GitHub issue 的解决
  • 针对现有代码仓库生成补丁
  • 比较智能体框架和基础模型

重要提示:SWE-bench Verified 是一个经过人工筛选的 500 实例子集,官方指标是问题解决百分比。这使其易于理解,但也随着流行度的增加而容易过拟合。

Terminal-Bench

Terminal-Bench 测试智能体是否真正会使用 shell。Terminal-Bench 2.0 包含 89 个任务,涵盖软件工程、机器学习、安全、数据科学和系统运维。

适用场景:

  • CLI 能力
  • 调试和构建工作流
  • 文件系统和系统管理任务
  • “这东西能像真正的终端编程智能体一样工作吗?”

这更接近 Claude Code、Codex CLI、OpenCode 等智能体的真实使用体验。

Aider Polyglot

Aider 的多语言基准测试 测试基于模型的代码编辑能力,涵盖 C++、Go、Java、JavaScript、Python 和 Rust 共 225 个 Exercism 任务。

适用场景:

  • 编辑准确率
  • 多语言代码修改
  • 模型是否可靠地遵循补丁/编辑格式

它的智能体程度低于 SWE-bench 或 Terminal-Bench,因为它专注于代码编辑而非长周期仓库工作,但对于衡量原始编辑可靠性仍然有用。

SWE-PolyBench

SWE-PolyBench 将仓库级别评估扩展到 Python 之外。它包含来自 21 个代码仓库的 2,110 个实例,涵盖 Java、JavaScript、TypeScript 和 Python,涉及 bug 修复、功能添加和重构。

当模型在 Python 为主的基准测试上表现良好,但你关心实际产品技术栈时使用。

SWE-Bench Mobile

SWE-Bench Mobile 测试智能体在工业级 iOS 代码库上的表现,涉及 Swift/Objective-C、产品需求文档、Figma 设计和全面的测试。论文报告称,最佳配置的任务成功率仅为 12%。

这很重要,因为它显示了前沿技术距离产品级移动端工程仍有很大差距。

关键启示:智能体设计与模型选择同样重要。同一个模型在不同编程智能体框架、上下文系统、工具和提示词下可能表现迥异。

SWE-WebDevBench

SWE-WebDevBench 将”氛围编程(vibe coding)“和应用构建平台作为虚拟软件机构进行评估。它不止关注代码正确性,还考察需求、架构、生产就绪度、安全、运维和应用修改。

适用场景:

  • 全栈应用构建器
  • 产品就绪度声称
  • 前后端集成
  • 安全和部署真实性

重要的信号不仅仅是”它是否创建了一个应用?“,而是该应用是否真正可维护、安全且具备业务就绪性。

可信度分级

高可信度信号:

  • SWE-bench Full/Verified 用于代码仓库 issue 修复
  • Terminal-Bench 用于真实终端自主能力
  • SWE-PolyBench 用于非 Python 和产品技术栈广度
  • SWE-Bench Mobile 用于艰难的工业级移动端任务
  • 在自有代码仓库上运行的实际内部评估

低可信度信号:

  • HumanEval 风格的玩具函数
  • 供应商提供的孤立演示截图
  • 没有成本、重试策略、工具框架或通过/失败日志的单一基准测试声称
  • 未区分模型能力与智能体工具链能力的排名

当前结论

编程智能体现已相当强大,但基准测试的图景仍然碎片化:

  • SWE-bench 告诉你智能体能否修复真实的 GitHub issue。
  • Terminal-Bench 告诉你它能否在 shell 中存活。
  • Aider Polyglot 告诉你模型能否跨语言进行干净的编辑。
  • SWE-PolyBench 告诉你 Python 分数能否迁移到实际产品技术栈。
  • SWE-Bench Mobile 和 SWE-WebDevBench 表明前沿在完整产品工程上仍然薄弱。

实际的最先进水平问题是:

哪种智能体 + 模型 + 上下文系统 + 工具框架能以低回归风险解决我的代码仓库任务?

这就是为什么生产环境评估不仅应追踪通过率,还应追踪:

  • 每个被接受补丁的成本
  • 运行的测试和失败恢复
  • 回归率
  • 工具调用次数
  • 人工审查时间
  • 智能体能否解释和撤销其更改

来源