用 Claude Sonnet 4.5 在 SWE-bench Verified 上立标杆

导读

本文围绕 Claude Sonnet 4.5 在 SWE-bench Verified 上的表现，分析 agentic coding benchmark 如何衡量真实代码修复能力、harness 和验证流程。

说明：本文按 Agent Learning 的中文阅读页格式，对原文结构与关键技术细节做逐节中文转述与解读；为避免整篇镜像转载，正文保留原文章节脉络、关键数字和术语，但不做逐字复刻。

核心观点

• SWE-bench Verified 用真实开源项目 issue 测试模型修复代码的能力。
• 高分依赖模型、harness、工具、测试执行和错误恢复共同作用。
• agentic coding 不只是写 patch，还包括理解 repo、定位 bug、运行测试和迭代修复。
• Verified 子集提高了题目质量和判分可信度，但仍受环境噪声影响。
• Sonnet 4.5 的意义在于更强长程代码理解和更稳工具使用。
• benchmark 报告应披露是否使用 test-time compute、重试、工具和人工筛选。
• SWE-bench 不能覆盖所有软件工程，但能作为回归基准。
• 产品中的 coding agents 还需要用户意图、scope 控制和安全边界。

正文

原文主线

本文围绕 Claude Sonnet 4.5 在 SWE-bench Verified 上的表现，分析 agentic coding benchmark 如何衡量真实代码修复能力、harness 和验证流程。

SWE-bench Verified 测什么

SWE-bench Verified 来自真实开源项目 issue，要求模型修改代码，让相关测试通过。相比人工构造题，它更接近真实维护工作：代码库大、依赖复杂、错误信息不完整、修复路径不唯一。

Verified 子集通过人工筛选提高题目质量，减少 ambiguous issue 和不稳定判分。但它仍然是 benchmark，不等同于全部软件工程能力。

为什么是 agentic coding

在 SWE-bench 上取得好成绩，需要模型像 agent 一样工作：阅读 issue、搜索代码、定位相关文件、理解测试、写 patch、运行测试、分析失败、再迭代。单次补全很难完成完整闭环。

因此分数同时反映模型能力和 harness 设计。工具选择、context 管理、测试命令、重试策略、timeout 和 patch 提交流程都会影响结果。

Sonnet 4.5 的能力信号

如果 Sonnet 4.5 在该基准上提升，最重要的能力信号通常包括长代码上下文理解、更好的 bug localization、更少无关改动、更可靠测试反馈利用，以及更稳的指令遵循。

这些能力对产品很关键。用户不只想要通过 benchmark 的 patch，还希望 agent 理解项目风格、控制修改范围、解释原因，并在测试不可用时诚实说明不确定性。

如何解读 leaderboard

SWE-bench 分数应结合实验设置解读：是否允许多次尝试、使用多少 token、是否运行隐藏测试、是否有人工过滤、是否使用额外检索、执行环境如何控制。不同 harness 之间的分数并不总是直接比较。

对团队来说，SWE-bench 更适合作为回归测试和能力方向指示，而不是唯一产品指标。真实 coding agent 还需要测新功能开发、重构、代码审查、迁移和长期项目维护。

深度解读

SWE-bench Verified 的价值，在于把 coding agent 从 demo 带到可比较评估。它迫使模型面对真实代码库的不整洁：依赖、测试、历史设计和错误线索。但它也提醒我们，agentic coding 是系统能力。模型变强是一部分，harness 如何给它文件、命令、反馈和回滚机制同样关键。产品团队应该用 SWE-bench 建立基线，再用自己的真实工单评估业务效果。

落地启示

• 用 SWE-bench 建立通用基线，但不要当唯一产品指标。
• 披露 retry、token、工具和执行环境设置。
• 在内部补充真实工单 eval。
• 同时评估修改范围控制、解释质量和测试策略。
• 记录失败归因，区分模型问题和环境问题。