Anthropic 在 2025 年 1 月推出的升级版 Claude 3.5 Sonnet，在软件工程评估基准 SWE-bench Verified 上取得了 49% 的得分——这一成绩直接将此前最先进模型的 45% 抛在身后。不过，分数只是冰山一角，真正值得深入探讨的是隐藏在它背后的“智能体”系统。本文将拆解这套系统的设计思路，帮助开发者明确如何充分利用这套模型，将其能力发挥到极致。

什么是 SWE-bench

SWE-bench 到底是什么？简单来说，它是一个用于测试 AI 能否完成“真正软件工程任务”的评估基准。它不会抛出面试题或竞赛题，而是直接从 GitHub 上热门的 Python 开源项目中筛选出真实的 Issue，让模型去解决。

每次任务，模型都会获得一个配置好的 Python 环境，以及问题发生之前整个仓库的本地副本。模型需要理解问题、动手修改代码、运行测试验证，最终提交一个解决方案。随后，系统会使用该方案对应的真实 Pull Request 中的单元测试来打分——这些测试并非虚构，正是人类开发者当初提交 PR 时所用的那套。因此，AI 能否像人一样高效完成任务，SWE-bench 能够清晰判断。

还有一个关键点：SWE-bench 评估的并非 AI 模型本身，而是完整的“智能体”系统。这里的“智能体”不仅包括底层语言模型，还涵盖了围绕它的软件脚手架——脚手架负责生成提示词、解析模型输出、管理整个交互循环（即把模型上一步的操作结果反馈到下一步的输入中）。同一模型搭配不同的脚手架，表现可能天差地别。

SWE-bench 的独特优势

市面上评估大模型编码能力的基准众多，为什么 SWE-bench 近年来越来越受关注？背后的原因值得仔细分析。

• 真实工程任务：它不搞虚的，采用的都是实际项目中的真实问题。不是面试题或竞赛题，而是开发者每天都会遇到、需要翻阅 GitHub Issue 才能解决的真问题。好比评估一位厨师的厨艺，不是看他颠勺有多花哨，而是看他能否为一桌子客人做出一顿可口的饭菜。
• 远未饱和：到目前为止，没有任何模型能在 SWE-bench Verified 上突破 50% 的门槛。即使升级版 Claude 3.5 Sonnet 达到了 49%，依然未能跨过那条线。这说明该领域仍有巨大的改进空间，还有许多潜力可挖。
• 整体评估：它考察的不是单独作战的模型，而是“模型+脚手架”这一组合拳。开源社区和初创公司已经证明，通过优化脚手架，可以将同一模型的性能显著提升一大截。

SWE-bench Verified 数据集说明

有一个需要注意的细节：原始的 SWE-bench 数据集中，部分任务在缺乏额外上下文（比如提示应返回特定错误信息）时根本无法解决。为了让测试更公平、更干净，Anthropic 构建了一个名为“SWE-bench Verified”的子集，从原始数据集中挑选了 500 个人工审核过、确认可解决的问题。本文讨论的成绩均基于这 500 个问题。因此，当你看到 49% 这个数字时，它衡量的是实打实的能力，而非掺水虚高。

实现最先进性能的方法

工具使用智能体架构

在为升级版 Claude 3.5 Sonnet 优化智能体脚手架时，核心设计理念其实只有一句话：信任模型，赋予自主权。凡是能让模型自行判断的事情，绝不越俎代庖。脚手架本身极其简洁，仅包含三样东西：一个提示词、一个执行 Bash 命令的工具、一个查看和编辑文件的工具。

任务开始后，模型会反复调用工具，直到自己认为搞定，或者将 20 万 token 的上下文窗口撑爆为止。这种设计的精妙之处在于，它允许模型按照自己的节奏和方式解题，而非被硬塞进一套预设的固定流程中。提示词只提供大方向，具体如何迈步，全由模型自行判断。

如果你的 token 预算比较宽裕，在提示词中明确鼓励模型多输出、进行长思考，效果会更出色。

智能体提示词

以下是这套脚手架所使用的提示词。它虽然不长，但关键指令一应俱全。

（此处插入原文中的提示词代码块）

Bash 工具规范

第一个 Bash 工具设计得非常干净。本质上它是一个可以运行环境命令的沙盒。但真正的精髓不在于工具本身，而在于工具描述——它告诉模型哪些事情不能做（比如无法联网）、哪些事情可以做（比如使用 apt 或 pip 安装包）、以及如何提高效率（比如用 sed -n 指定行数查看文件）。

以下是 Bash 工具的规格说明：

（此处插入原文中 Bash 工具规范的代码块）

编辑工具规范

第二个编辑工具则复杂得多，它集查看、创建、编辑文件于一身。在设计该工具时，团队投入了大量精力打磨其描述和规范——不仅写清楚它能做什么，还要预判模型可能在哪里出错，并用描述提前规避风险。这实际上与设计人机交互界面的道理相同：为人类设计的界面要尽善尽美，那么为模型设计的工具界面就更值得倾注心血。

（此处插入原文中编辑工具描述的代码块）

编辑工具的完整输入规范如下：

（此处插入原文中编辑工具完整输入规范的代码块）

工具改进：错误防护

提升性能的另一个关键策略是让工具变得“防错”。例如，模型有时会在切换工作目录后搞混相对路径。解决办法很简单——工具强制要求使用绝对路径，从根源上杜绝此问题。再比如编辑时，我们尝试了多种方案，最终发现字符串替换最可靠：模型指定一段 old_str（必须且只能匹配一处），然后用 new_str 替换它。如果匹配过多或过少，模型会看到明确的错误消息，然后自行重试。这就像为工具加了一层保险丝——小问题当场提醒，大错误直接规避。

性能结果

总体而言，升级版 Claude 3.5 Sonnet 在推理、编码和数学能力上均较之前的模型有了明显提升。更重要的是，它在智能体能力上的进步——工具和脚手架的存在——恰好将这些能力发挥到了极致。

性能对比表

所有模型均使用此智能体脚手架在 SWE-bench Verified 上的得分

智能体行为示例

理论说得再多，不如看一个真实案例。我们以 SWE-Agent 框架作为智能体代码的基础来运行基准测试。在下面的日志中，我们将模型的文本输出、工具调用和工具响应分别标注为思考（THOUGHT）、行动（ACTION）和观察（OBSERVATION）——请注意，模型并不需要按照固定顺序执行这三个步骤。

步骤 1：初始提示和问题描述

你看到的第一段代码是模型收到的初始提示。其中 {pr_description} 已被填入 SWE-bench 任务中的真实描述。这个任务的好处是，连重现问题的步骤都已写好——相当于给模型提供了一个不错的起点。

（此处插入原文中步骤1的代码块）

步骤 2：探索仓库结构

模型第一步使用编辑工具快速浏览仓库，了解其结构。

（此处插入原文中步骤2的代码块）

步骤 3：创建重现脚本

接着，模型用编辑工具创建了一个重现问题的脚本。

（此处插入原文中步骤3的代码块）

步骤 4：执行脚本确认错误

然后调用 Bash 工具执行脚本，错误被完美复现。

（此处插入原文中步骤4的代码块）

步骤 5：修复源代码

模型定位到问题根因后，使用编辑工具的字符串替换功能，直接修改了 RidgeClassifierCV 的构造方法。

（此处插入原文中步骤5的代码块）

任务完成

在这个例子中，模型总共用了 12 步就完成了任务。但在实际情况中，有些任务需要上百个回合才能解决，甚至有些模型直到上下文耗尽也未能提交。相比旧版模型，升级版 Claude 3.5 Sonnet 有一个明显的进步：它更擅长自我纠正，并且愿意尝试不同方案，而不是在同一个错误上反复跌倒。

面临的挑战

SWE-bench Verified 是一个非常有说服力的评估基准，但运行起来比那些一轮问答式的测试复杂得多。我们在使用过程中也踩了不少坑——这些坑，其他 AI 开发者大概率也会遇到。

1. 持续时间和高令牌成本

前面那个 12 步完成的例子算是相当顺利的。但很多成功的任务需要跑几百个回合，消耗超过 10 万个 token。升级版 Claude 3.5 Sonnet 的韧性确实很强——给它时间，它总能找到办法——但这背后是实打实的计算成本。

2. 评分问题

在排查失败任务时，我们发现有些情况模型行为明明是正确的，但要么是环境配置有问题，要么是补丁被重复打了两次。要准确评估 AI 智能体的真实水平，这些系统性问题必须先解决。

3. 隐藏测试

模型在运行任务时看不到最终的评分测试，所以它经常以为自己成功了，但实际上并未通过。部分失败是因为模型在错误的抽象层级上做了修改（比如打补丁而非进行更深层的重构）。但另一些失败则令人略感无奈：模型确实解决了问题，但解决方式与原始任务中单元测试的要求对不上。

4. 多模态能力未充分利用

升级版 Claude 3.5 Sonnet 的视觉和多模态能力非常突出，但我们的脚手架目前并未让它能够查看保存到文件系统或作为 URL 引用的图片。这在调试某些任务时尤其吃亏——例如 Matplotlib 相关的任务，看不到图表就只能靠猜，幻觉率直线上升。这其实是一个很容易摘取的低垂果实，而且 SWE-bench 也已经推出了专门针对多模态任务的新评估。相信在不久的将来，开发者们就能用 Claude 在这个新评估上打出更高的分数。

总结与展望

升级版 Claude 3.5 Sonnet 在 SWE-bench Verified 上取得了 49% 的成绩，超越了之前最先进的 45%，而且仅靠一个简单的提示词和两个通用工具。我们有理由相信，随着越来越多的开发者上手这套模型，很快就会出现更聪明、更高效的方法，将 SWE-bench 的分数推得更高——甚至超过我们现在展示的水平。