在过去的两年时间当中，SWE - bench差不多是用以衡量Code Agent能力的单一把尺。

起步时，解决率不到30%，然而现在，Gemini 3 Pro、GPT-5.2等前沿模型超过了80%，社区里好像已然达成了一个共识，那就是：AI正迅猛地靠近人类程序员的水准。

但若回过头去审视这张“考卷”自身，一些数字让人心里不踏实，SWE-bench Verified仅仅覆盖了12个仓库，每一道题目平均下来只需修改1.3个文件，还有11.6行代码，而所有答案全都能够在仓库内部进行查找。就算是后续的SWE-bench Pro以及SWE-bench Live，尽管扩展了仓库数量，还有修改规模，然而在“知识来源”这个层面上依旧没有跨越单一仓库的界限。

这意味着什么？

Code Agent所面临的现有benchmark考察，从某个角度来说，类似于给予一个学生一场开卷考试的情境，这场考试里要做的是填空题，即答案就在学生手边的情况下，仅需去定位并且将其填写进去，然而，真实的软件工程所涵盖的全部情况远远不止是如此这般的状况。

最近，OpenAI也宣告放弃把SWE-bench Verified当作内部评测的标准，明确表示它已经没办法区分前沿模型的能力差别了。当成卷的人都不再相信自己出的试卷时，那就该换一张试卷了。

看一个Code Agent是不是「真的会写代码」，能从两个方面去考量，可以从这样两个维度来审视：

问题解决所涉及的范围（即分辨率范围），究竟需要变动多大的代码范畴？是仅仅改动一个函数，还是要对整个仓库实施改造？

知识来源（Knowledge Scope）：要从哪儿去获取信息，仓库内部是不是就足够了，还是说同样需要外部知识？

此刻，把这两把尺子放置于现有的benchmark跟前，两者之间的差距清晰得一眼就能看出来——每一个SWE - bench变体都汇聚在同一个象限里：是处于局部函数层面的解决范畴，亦或是源自仓库内部的知识发源地。在切实的软件工程当中，那些最为常见且最为棘手的情形，却正好是评测时所缺失的区域。

中国人民大学高瓴人工智能学院提出了BeyondSWE，在这两个维度上首次同时实现突破，借助四类任务系统性地对真实软件工程的多个象限进行了覆盖。

该项目 ，其主页为：https://aweai-team.github.io/BeyondSWE/。标点符号正确的话，这就是你要项目主页的网址。句号。

有一个关于论文的链接，其具体是这个链接：http://arxiv.org/abs/2603.03194。

存在这么一根纽带，它是代码的引导链，其具体指向的地方是这样一个链接，这个链接呈现的形式是https://github.com/AweAI-Team/BeyondSWE。

脚手架链接为，https://github.com/AweAI-Team/AweAgent。

这是一个网址链接，是关于领先者排行榜的链接，具体的链接内容是https://aweai-team.github.io/BeyondSWE_leaderboard/ ，它被称为Leadboarder链接。

CrossRepo：答案不在这个仓库里（200条）

在实质的开发进程当中，数量众多的Bug的根源或者是修复的思路并非处于当下的仓库范围之内，开发者时常需要去翻看上一级仓库的问题记录，抑或是Stack Overflow上的讨论帖子，甚至于要钻研另一个项目的源代码才能够确定问题所在。

BeyondSWE，从3000个有着外部链接的GitHub PR里，一层一层地进行筛选，最后，得到了来自67个仓库的200条高质量样例，这些样例平均包含1.3个外部链接。

Agent依旧仅于单个仓库之内对代码作出修改，然而修复所需要的关键资讯是存在于外部的。这所考察的并非是「多仓库协同开发」的能力，而是对于开源生态的广泛认知，这种认知既能够源自模型自身对生态的深度理解，也能够借助搜索外部资源来予以获取。

DomainFix：代码之外的知识壁垒（72条）

致使一名并不曾学过量子力学的后端工程师去修复量子计算库所呈现的Bug，然而，这正是当下Code Agent于领域专业任务层面遭遇的窘迫状况。

该任务是同来自11个学科方向的领域专家一起合作开展构建的工程，它含括了量子物理领域中的QuTiP，生物信息学领域下的Biotite，凸优化领域涵盖的cvxpy这一内容，天文学中astroplan所涉及的范畴，以及在等离子体物理领域牵扯到的PlasmaPy等这些属于高门槛领域范畴的项目要点，要点，要点。

每项题目历经三位领域专家予以独立审核，唯有同时达成环境正确性 ，以及领域知识必要性 ，还有解法非平凡性此项要求的样例才能够被选入。Bug进行正确修复不止亟有需要读懂代码 ，更甚要有之理解背后相应的物理公式 ，或者数学概念 ，又或者生物学原理才行——写妥当对应语法 ，却算了不正确物理 ，依旧是零分。

DepMigrate：整个仓库的系统性改造（178条）

从NumPy 1.x升级至2.0，从Pydantic v1升级到v2，从Django 4.x升级到5.0，在现代软件生态里，具有破坏性的依赖升级并非小概率之事，而是每个项目维护者都会反复遭遇的日常情形。这类任务的改动规模以及思维复杂程度远远超越普通Bug的修复，它需要Agent精准把握新旧API的差异之处，并且要在可能纵深数十个文件的代码库当中达成一致、无误的全局迁移。

BeyondSWE辨认出二十三个有着重大版本更新包含于其中的核心依赖包，自七千个候选项当中挑选出一百七十八条样例，这些样例覆盖了一百二十个仓库。那些所选样例各自的Docker环境已设定好了按照依赖进行更新后的版本，然而仓库代码却依旧停留在升级之前的状态——Agent所面临的恰恰是一个“依赖已经升级、代码却没有适配”的实实在在的困境。

Doc2Repo：从白纸到系统（50条）

真正实际的软件工程通常并非起始于Bug，而是源于一份设计文档或者PRD，Agent所面对的并非是「修什么」，而是「造什么」，架构究竟该如何设计，模块要怎样拆分，接口又该如何实现，这是一种跟Bug修复有着显著不同的工程能力。

50条样例，全都收集自2025年新建的高质量仓库，仓库持续活跃，至少有3位贡献者，Star超过20 ，代码量从1000行至超过16000行不等，近四成样例超过4000行。

在评测期间，为了避免Agent将已有仓库内的代码背诵出来，特意把仓库名称以及目录结构都隐瞒掉，Agent仅仅得到了一份纯粹以文字形式呈现的功能说明文档，还有一个空目录，什么都得从起始状态开始去做。

数据质量：多轮校验保底线

超越软工工程师软件总计包含二百四十六个真实的GitHub仓库，以及五百条样例。平均每一道题目涉及五点六个文件，还有二百零九点九行代码。

对于数据构建而言，存有这样的情况每条样例历经三个阶段经过如此这般的严格筛选，先是候选爬取，接着是基于Agent的自动化阶段来构建Docker环境，然后是进行严格的环境一致性验证，要注意的是每条样例需要5次独立运行，且P2P和F2P测试结果必定得完全一致。

另外，有3位专门领域的专家，5位经验丰富的软件工程师，以及5位一心专注于Code Agent研究的博士生，参与了整个流程的人工校验活动。

实验结果

近乎腰斩

基于OpenHands框架，BeyondSWE针对Gemini 3 Pro、GPT-5.2、DeepSeek-V3.2、GLM-4.7、Kimi-K2、Seed-Coder等一众位于前沿的模型开展了全方位的测试。所获得的核心发现简洁明了：

不存在任何一个模型，其整个展现出来的状况能够突破百分之四十五。在SWE-bench那里是百分之八十，到了BeyondSWE这里变为百分之四十五，其间的差异并非是那种微小幅度的起伏变动，相反是几乎减少了一半。

深入各任务来看，失败模式各不相同：

不存在全能的选手，Seed - Coder在CrossRepo中处于领先位置（占比44.72%），DeepSeek - V3.2获得Doc2Repo的最高通过率（占比54.99%），Gemini 3 Pro在DepMigrate方面表现最强（占比41.81%），没有一个模型能够在各个维度上同时独占鳌头，四类任务考核的的确是不一样的能力。

DomainFix堪称最为难啃的硬骨头，几乎不存在模型能够突破36%，领域方面的专业知识并非依靠多进行几轮代码数据训练就可以弥补的，它构建起了一道切实的认知壁垒。

Doc2Repo之中暗藏着「虚高陷阱」，其通过率看起来好像是有45至55%的区间范围，然而能够使得所有测试达成100%通过的完整程度的仓库数量非常稀少还寥寥无几。Agent擅长于达成那些零散的功能模块，可是却很难构建架构出一个具备连贯自洽特性的完整系统，另外，这两者之间存在着本质性的鸿沟。

SearchSWE：联网搜索是银弹吗？

一个自然而然会出现的问题是，要是Agent自身内部所具备的知识不足以满足需求，那么赋予它通过网络进行搜索的能力，这种状况究竟能够改善到何种程度呢？

该工作同期提出SearchSWE框架来系统研究这个问题。

一种名为SearchSWE的事物，在OpenHands的基础之上，为Agent引入了两个工具，其中一个是SearchTool，也就是搜索引擎查询工具，另一个是BrowserTool，即网页内容浏览与理解工具。Agent呢，在编码过程当中，能够自主地决定什么时候跳出本地环境，去查阅文档，或者翻阅论坛，亦或是检索领域知识，这情形就如同真实的开发者随手把浏览器打开那般。

SearchSWE设计了双重拦截机制，目的是想防止Agent直接搜到目标仓库的现成答案，其中一种是在搜索结果侧进行过滤，要过滤掉所有指向目标仓库的URL，另一种是在执行命令侧进行拦截，拦截任何直接访问目标仓库的操作。并且在Docker环境中，已经清除了目标commit之后的全部git历史。Agent没有别的捷径可走，只能依靠真正的推理来解题。

搜索有用，但融合是真正的难点

实验给出了一个答案，这个答案微妙且真实，它既不是那种认为联网就什么都能办到的情况，也不是那种觉得搜索毫无用处的看法。

在9个模型里头，有6个在加入搜索之后，整体呈现出提升的态势，然而，另外3个却出现了下降的情况。搜索对于知识密集型任务而言，其帮助是最为直接明显的：Gemini 3 Pro在DomainFix方面提升了7.5%，外部文档的确对内部知识存在的不足起到了弥补的作用，可是，最具有反直觉特点的发现存在于搜索频率与效果之间的关系上：

Gemini 3 Pro，平均下来，每一项任务仅仅调用搜索零点八至一点一次，然而却取得了最为出色的整体增益，即正百分之二；DeepSeek-V3.2，平均搜索次数为四点二至五点四次，整体情况反倒略微下降了百分之零点二。搜索所具备的价值并非在于频率，而是在于对于“知晓什么时候应该进行搜索，在搜索到之后如何加以运用”的精准判断。

三类失败模式：为什么搜索+编码这么难融合

对Agent搜索行为的深入追踪，揭示了三类根本性的障碍：

信息景观存在着鸿沟，搜索引擎历经几十年的优化，在检索人类可读的高层文档方面表现擅长，然而代码任务所需的关键知识，常常隐匿于源文件、commit diff以及issue评论的只字片语里，对于这类“技术原始制品”，搜索引擎的索引能力在本质上存在不足。Agent拿到的是“概念上正确”的文档摘要，可它实际需要的却是“逻辑上精确”的源码细节。

版本存在时间错位情况，搜索引擎在展示文档时天然倾向于展示最新版本，然而SWE任务的本地环境常常锁定在了某个历史版本。更为麻烦的是，LLM自身的参数知识同样倾向于最新的代码模式。这两者相互叠加，Agent有可能就会“幻想”出一个并不存在的新版本环境来，接着用最新的API写法去修改老代码，如此一来，搜索不但没有起到纠错作用，反倒令错误更快地落实到实际中了。

语义出现漂移，伴随着噪声发生污染，技术方面的术语存有大量的歧义，当Agent去搜索一个小众库有的专有概念时，搜索引擎常常返回源自完全不一样领域的高权重结果，Agent缺少有效的噪声过滤能力，会把“看起来合理”然而完全不相关的信息纳入到推理链路，致使修复方案偏离正轨。

核心启示

Deep Research for Coding

这些实验，共同指向了一个清醒的判断，search能力，已然相当成熟，coding能力，同样已然相当成熟，然而，两者的有效融合，并不会自动涌现。

过去几年间，Deep Research（其功能为信息检索与知识整合），取得了显著的进步，Code Agent（具备代码生成与仓库级推理能力），同样有了长足的进展，然而，它们几乎是沿着两条相互平行的轨道，各自独立地发展着。

要是真实的软件工程天然就需要两种能力进行深度融合，而API会更新，依赖会变化，领域知识永远学不完，那么这种「各自为战」的发展路径就暴露出了其根本局限。

进行深度的编码研究，使得Code Agent切实拥有在编码进程当中能够顺畅地穿插搜索以及推理的能力，这是下一阶段进化的关键趋向。

BeyondSWE给出了一个评测框架，这个评测框架在「解决范围」维度上更全面，在「解决范围」维度上更全面，在在「知识来源」方面也更全面，SearchSWE为系统研究搜索与编程的融合供给了实验基础，在在「知识来源」方面也更全面。

存在着两者共同拥有的目标，这个目标是促使Code Agent，从仅仅是在单一仓库里进行刷题的存在，切实地朝着能够在开放世界之中独自承担重要职责的工程智能体这样一个方向发展。

参考资料：

该链接为http://arxiv.org/abs/2603.03194。