BeyondSWE 论文解读当前代码智能体能否超越单仓库修 Bug论文标题BeyondSWE: Can Current Code Agent Survive Beyond Single-Repo Bug Fixing?论文链接https://arxiv.org/abs/2603.03194作者Guoxin Chen*, Fanzhe Meng*, Jiale Zhao*共同一作, Minghao Li, Daixuan Cheng, Huatong Song, Jie Chen, Yuzhi Lin, Hui Chen, Xin Zhao†, Ruihua Song†, Chang Liu, Cheng Chen, Kai Jia†, Ji-Rong Wen机构中国人民大学高瓴人工智能学院、Independent Researcher、AweAI Team日期2026年3月一、引言SWE-bench 之后代码智能体的下一站在哪过去一年代码智能体Code Agent领域可谓高歌猛进。以 SWE-bench 为代表的基准测试推动了一波又一波的模型刷榜热潮——GPT-5.2 在 SWE-bench Verified 上已经突破了 80% 的解决率似乎代码智能体距离替代程序员的目标又近了一步。然而如果我们冷静下来思考一个问题SWE-bench 到底在测什么答案很明确SWE-bench 及其变体SWE-bench Verified、SWE-bench Live、SWE-bench Pro测试的核心场景是单仓库内的局部 Bug 修复——给定一个 GitHub 仓库和一个 Issue让智能体在这个仓库内定位问题并生成修复补丁。这些任务平均只需要修改 1.3 个文件、11.6 行代码。但真实的软件工程远比这复杂得多。在日常开发中开发者需要跨仓库推理参考上游库的 Issue 和 PR 来排查本项目的 Bug领域专业知识在量子计算框架中调试哈密顿算子在生物信息学库中处理序列比对大规模迁移重构将整个代码库从 Pydantic v1 迁移到 v2从 NumPy 1.x 升级到 2.x从零构建项目根据设计文档和 API 规范从头搭建一个完整的仓库这些场景在现有基准测试中几乎完全缺失。来自中国人民大学高瓴人工智能学院和 AweAI Team 的研究团队正是抓住了这一关键缺口提出了BeyondSWE——一个沿解决范围Resolution Scope和知识范围Knowledge Scope两个维度全面扩展的综合性代码智能体评估基准。同时他们还开发了SearchSWE框架将深度搜索能力集成到代码智能体中系统性地探究外部知识对编码任务的影响。实验结果令人清醒**即使是最先进的前沿模型在 BeyondSWE 上的成功率也不到 45%**与 SWE-bench Verified 上 80% 的表现形成了鲜明对比。更出人意料的是给智能体加上搜索能力并不总是有帮助——在某些情况下搜索反而会降低性能。BeyondSWE 概览图1BeyondSWE 基准概览。沿知识范围和解决范围两个维度扩展构建了四种评估任务CrossRepo跨仓库和 DomainFix领域知识扩展了知识范围DepMigrate依赖迁移和 Doc2Repo文档到仓库扩展了解决范围。二、BeyondSWE 基准设计四维度全面评估2.1 设计哲学两轴四象限BeyondSWE 的核心设计思想是沿两个正交维度扩展现有评估框架解决范围Resolution Scope从局部函数级修复到仓库级全局重构知识范围Knowledge Scope从仓库内信息到外部知识跨仓库代码、领域专业知识、官方文档、人类规格说明由此形成了四种截然不同的评估设置共包含500 个真实世界实例涉及246 个 GitHub 仓库基准测试解决范围知识范围仓库数平均修改文件数平均修改行数SWE-bench Verified局部函数仓库内121.311.6SWE-bench Live局部函数仓库内2232.765.1SWE-bench Pro局部函数仓库内414.1107.4CrossRepo局部函数跨仓库674.1190.7DomainFix局部函数领域知识124.2157.6DepMigrate全局仓库官方文档1208.4281.6Doc2Repo全局仓库人类规格50全部全部BeyondSWE (总计)混合混合2465.6209.9对比数据一目了然BeyondSWE 的平均修改文件数5.6和修改行数209.9远超 SWE-bench 系列且在知识维度上实现了质的突破。2.2 四种任务详解任务一跨仓库问题解决CrossRepo— 200 个实例动机在实际开发中开发者很少在真空中解决问题。遇到 Bug 时他们会查阅相关项目的类似实现、参考上游库的解决方案、或追溯源自外部依赖的问题。这种跨仓库推理是现实开发的基本能力却完全缺失于现有基准。构建方式研究团队扫描 GitHub 上以 Python 为主的仓库收集包含外部链接的 Pull Request约 3000 个候选经过自动化环境构建和稳定性检验后约 800 个实例通过检查。再经人工验证最终得到200 个高质量实例跨越 67 个仓库平均每个 Issue 包含 1.3 个外部链接。举例一个项目的 Issue 可能引用了上游库的一个 PR 说这个 Bug 已经在那边修了智能体需要理解外部 PR 的修复方案并将其适配到当前项目的代码结构中。任务二领域特定问题解决DomainFix— 72 个实例动机许多真实世界的软件项目服务于专业科学领域。修复量子计算框架中的 Bug 可能需要理解量子算子的物理含义调试分子动力学包可能需要化学键的专业知识。对人类开发者而言这需要多年的专业训练对代码智能体而言这探测的是其领域知识的边界。构建方式研究团队与11 个科学学科的领域专家合作涵盖量子计算、分子动力学、材料科学、天文学、生物信息学等。从 21 个高质量仓库中收集约 800 个候选 PR经环境构建后约 200 个通过检查。每个实例由3 位领域专家独立审核验证1环境正确性2确实需要领域知识3解决方案不能从错误信息中直接推断。只有三人一致通过才保留最终得到72 个实例跨越 12 个仓库。涵盖的研究领域和对应仓库如下领域分类研究方向仓库科学计算天文学astroplan生物信息学biotite, Biopython计算化学cclib等离子体物理PlasmaPy量子物理qutip地震学obspy工程凸优化cvxpy地理空间geopandas材料科学pymatgen分子动力学mdanalysis光子IC设计gdsfactory任务三依赖驱动迁移DepMigrate— 178 个实例动机前两个任务扩展了知识范围但解决范围仍停留在局部修复。而依赖迁移则在另一个轴上提升了挑战——从修补单个 Issue 到编排整个代码库级别的变换。现代软件生态系统持续演进Pydantic v1→v2、Django 4.x→5.0、NumPy 1.x→2.x 等重大版本更新给下游项目带来了巨大的迁移负担开发者必须映射上游 API 变更定位代码库中每一个受影响的调用点并实施跨越数十个文件的更新。这种系统性重构既耗时又容易出错。构建方式首先识别 23 个广泛使用的包及其重大版本升级然后收集 PR 描述或提交信息中提及这些包和相关版本号的 Pull Request经过 LLM 过滤后约 7000 个候选。环境构建后约 1000 个通过检查再由 4 位软件工程专家人工验证迁移有效性最终得到178 个实例跨越 120 个仓库。关键设计Docker 环境配置了升级后的依赖版本而代码库检出为迁移前的提交。智能体必须修改代码以适应破坏性 API 变更。任务四文档到仓库生成Doc2Repo— 50 个实例动机这是最具挑战性的任务——评估智能体从零构建功能性仓库的能力。在实践中软件项目通常不是从现有代码开始而是从规格说明设计文档、API 描述、架构蓝图出发。将高层规格翻译为可运行的代码库需要一系列连贯的设计决策构建模块、定义抽象、正确实现所有指定行为。构建方式为避免数据污染研究团队收集 2025 年 1 月至 11 月间创建的高质量仓库要求 2025 年 8 月后仍有持续活动、至少 3 位贡献者、超过 20 个 Star。对每个仓库使用 Gemini 3 Pro 探索代码库并生成规格文档描述仓库用途、使用示例和 API 细节包括函数和类签名、参数、返回类型、行为描述但不透露实现细节或目录结构。与并行工作 NL2Repo 不同BeyondSWE 用target_repo掩码替换仓库名称要求智能体从上下文线索中推断项目结构例如from target_repo.reader.parquet import ParquetReader暗示存在reader/parquet.py模块。最终得到50 个高质量实例。仓库代码量从约 1000 行到超过 16000 行不等大多数40/50超过 1500 行——这绝非玩具级别的挑战。2.3 基准基础设施环境构建流水线这是 BeyondSWE 的一大技术亮点。由于历史提交的执行环境复现极其困难依赖衰退、废弃 API、不可用版本研究团队设计了一套基于智能体的自动化环境构建流水线环境构建流水线图2BeyondSWE 的自动化环境构建流水线。包含三个阶段1针对各任务的候选收集策略2基于智能体的 Docker 构建LLM 智能体在容器内迭代解决依赖直至所有测试通过3严格的环境检验要求一致的 P2P/F2P 行为以确保可重现性。候选收集针对每种任务采用定制策略智能体驱动的 Docker 构建在 Ubuntu Docker 容器内实例化 Gemini 3 Pro 智能体通过运行-错误-修复循环迭代地解决依赖问题。关键在于智能体拥有 Shell 访问权限可以执行系统级命令如apt-get这超越了静态安装脚本的能力严格的环境检验每个生成的 Dockerfile 被构建并执行全部测试套件5 次验证 P2P 测试通过、F2P 测试失败打补丁前以及两者都通过打补丁后。不确定性行为的实例直接丢弃评估协议环境隔离智能体生成的补丁通过git diff提取应用到一个全新的、与智能体工作环境完全独立的 Docker 容器中完整性保障移除目标提交之后的所有 git 历史应用补丁后恢复所有测试文件到原始状态防止智能体篡改测试评估指标CrossRepo/DomainFix/DepMigrate 报告解决率Resolved RateDoc2Repo 报告通过率Pass Rate和几乎正确数#(Almost) Correct三、SearchSWE 框架当搜索遇上编码3.1 框架设计当前主流的开源代码智能体如 SWE-agent、OpenHands在隔离的执行环境中交互——通常是 Docker 容器——探索仓库结构、执行代码、运行测试。虽然本地上下文提供了代码操作所需的基本反馈但它将智能体限制在封闭循环工作流中当解决问题需要代码库之外的知识时智能体无从获取外部信息。为此研究团队提出了SearchSWE一个扩展的编码智能体框架将深度研究能力集成到智能体的工作流中。SearchSWE 框架图3SearchSWE 框架概览。左侧智能体通过迭代访问外部资源搜索、浏览器和本地上下文Docker 容器来解决编码任务并有一个封锁列表防止作弊。右侧评估流程将补丁应用到全新容器并运行 P2P/F2P 测试进行验证。SearchSWE 跨两个互补上下文运作本地上下文Local ContextDocker 容器智能体在其中探索仓库结构、执行命令、运行测试——与现有代码智能体框架类似全局上下文Global Context通过两个工具访问外部环境搜索工具Search Tool查询网络搜索引擎获取相关资源基于 Google Search via SerpAPI浏览器工具Browser Tool给定 URL 和特定目标检索并总结网页内容使用 Jina Reader 提取内容DeepSeek-V3.2 做摘要智能体根据自身推理过程自主决定何时利用外部信息。3.2 防作弊机制为确保智能体通过真实推理而非检索现有解决方案来完成任务SearchSWE 实现了封锁列表机制使用正则表达式过滤搜索结果和 Bash 命令阻止访问目标仓库——涵盖 GitHub、GitLab 和原始内容源上的仓库页面、API 端点和 Git 操作。3.3 设计哲学SearchSWE 的核心目标不是刷榜而是系统性地考察搜索如何影响智能体的编码能力。研究团队明确表示其实现优先考虑通用性和简洁性主要目的是严格检验外部搜索如何塑造智能体能力——使用标准化的实例化避免过度复杂的任务特定设计。四、实验结果令人清醒的现实4.1 实验设置研究团队使用两个框架进行评估OpenHands当前最先进的代码智能体框架不含搜索能力SearchSWE本文提出的搜索增强框架测试了 9 个模型涵盖前沿通用模型和代码专用模型Gemini 3 Pro、GPT-5.2、DeepSeek-V3.2、Kimi-K2、GLM-4.7、MiniMax-M2.1、Seed-Coder、Qwen3-Coder-Plus 和 Qwen3-235B-Instruct。最大交互轮数设为 200。4.2 OpenHands 基线结果模型CrossRepo (%)DomainFix (%)DepMigrate (%)Doc2Repo Pass Rate (%)Doc2Repo #正确平均 (%)Gemini 3 Pro41.5031.9441.8152.03(8)/241.82GPT-5.233.0023.6134.2753.89(6)/236.19GLM-4.740.2036.1139.8948.40(3)/141.20DeepSeek-V3.238.0030.5636.5254.99(3)/040.01MiniMax-M2.137.5029.1737.6448.38(3)/138.17Kimi-K237.0027.7839.5354.91(6)/239.81Seed-Coder44.7225.0035.3942.55(1)/136.90Qwen3-Coder-Plus19.195.5615.431.87(1)/010.51Qwen3-235B-Inst15.505.7113.564.03(0)/09.70核心发现一BeyondSWE 暴露了巨大的能力差距最佳配置Gemini 3 Pro仅达到 41.82% 的平均解决率与 SWE-bench Verified 上 80% 的表现形成鲜明对比。这一差距清楚表明超越单仓库 Bug 修复会暴露当前 LLM 的根本局限性。值得注意的是没有任何模型在所有任务上都占主导地位Gemini 3 Pro 在 DepMigrate 上领先Seed-Coder 在 CrossRepo 上表现最佳44.72%DeepSeek-V3.2 在 Doc2Repo 通过率上最高GLM-4.7 在 DomainFix 上排名第一36.11%核心发现二不同任务维度暴露了不同的弱点DomainFix一致性地最具挑战所有模型的解决率几乎都不超过 36%确认了量子物理、生物信息学等领域的专业推理仍是当前 LLM 的重大瓶颈Doc2Repo呈现独特的失败模式通过率看似不错45-55%但完全正确的仓库数量惊人地低最多 2 个。这表明智能体能实现个别组件但难以从规格说明架构出连贯、完整的系统CrossRepo和DepMigrate性能相对较高35-45%但仍远低于 SWE-bench 水平4.3 SearchSWE 结果搜索是双刃剑模型CrossRepo (%)DomainFix (%)DepMigrate (%)Doc2Repo Pass Rate (%)平均 (%)Gemini 3 Pro41.12 (-0.4)39.44 (7.5)44.07 (2.3)50.73 (-1.3)43.84 (2.0)GPT-5.236.22 (3.2)22.22 (-1.4)33.90 (-0.4)55.85 (2.0)37.05 (0.9)GLM-4.745.40 (5.2)32.39 (-3.7)39.77 (-0.1)49.44 (1.0)41.75 (0.6)DeepSeek-V3.239.49 (1.5)31.88 (1.3)34.09 (-2.4)53.64 (-1.4)39.77 (-0.2)MiniMax-M2.141.00 (3.5)32.39 (3.2)39.55 (1.9)46.45 (-1.9)39.84 (1.7)Kimi-K239.90 (2.9)33.33 (5.6)34.83 (-4.7)49.31 (-5.6)39.34 (-0.5)Seed-Coder38.89 (-5.8)22.22 (-2.8)29.78 (-5.6)45.17 (2.6)34.01 (-2.9)绿色/红色表示 SearchSWE 相对 OpenHands 的提升/下降核心发现三搜索与编码——两种独立成熟但尚未有效统一的能力结果揭示了一个深层洞察搜索增强带来的收益高度不一致有时甚至会降低性能。任务层面的模式CrossRepo受益最广泛——从其他仓库和文档中检索信息确实有助于跨仓库推理Doc2Repo受损最一致——从零构建仓库需要连贯的架构决策而搜索带来的碎片化信息似乎破坏了这种连贯性DomainFix方差最大Gemini 3 Pro 提升 7.5%而 GLM-4.7 下降 -3.7%。当相关领域知识能被检索到时帮助很大但检索失败引入的噪声会主动误导生成模型层面的模式代码专用模型受搜索集成影响最大Seed-Coder 在四个任务中的三个上出现下降尽管其基线性能很强。这种分歧暗示代码专用训练可能以牺牲外部知识集成为代价优化了仓库本地推理通用前沿模型表现更稳定Gemini 3 Pro 和 MiniMax-M2.1 展示了更一致的增益4.4 智能体行为分析工具调用次数对比图4每个实例的平均工具调用次数。搜索调用次数对比图5每个实例的平均搜索调用次数。发现一高效智能体用更少的交互实现更多Gemini 3 Pro 需要最少的工具调用却达到了最高的整体性能。SearchSWE 尽管增加了搜索能力但总工具调用次数与 OpenHands 持平甚至略低——例如 GLM-4.7 从 105.4 下降到 102.0 轮。这表明有效的搜索可以减少本地环境中的试错探索。发现二搜索质量比搜索频率更重要这是一个引人注目的模式Gemini 3 Pro谨慎地使用搜索工具每实例 0.8-1.1 次却获得最一致的提升平均 2.0%DeepSeek-V3.2搜索最频繁每实例 4.2-5.4 次但收益不稳定平均 -0.2%这说明有效的搜索集成不仅仅是获取外部信息更需要精确判断何时需要搜索以及从结果中提取可执行的洞察。发现三任务特征塑造搜索效用DomainFix在大多数模型上引发最高的搜索频率与其对专业领域知识的需求一致Doc2Repo在所有模型上一致展示最低的搜索频率——智能体似乎认识到构建仓库主要依赖提供的文档而非外部资源这种任务感知行为表明模型确实具备一定程度判断搜索适当性的能力尽管这种判断并不总能转化为有效执行五、深度讨论编码搜索的三重挑战论文不仅给出了实验结果更深入分析了搜索在编码场景中失效的根本原因并提出了对未来代码智能体设计的深刻启示。5.1 软件知识的长尾效应当前 LLM 对高资源软件领域表现出强烈偏好。它们擅长通用 Web 开发任务如 Django 视图、Flask 路由因为这些模式在预训练数据中无处不在。然而DomainFix 的结果揭示了当智能体遇到软件的长尾——量子物理、生物信息学或地理空间分析中的专业库时性能显著崩溃。启示单纯扩大规模不是解决方案。未来系统可能需要超越隐式参数知识采用显式的**知识注入策略**——不仅仅是检索片段而是将库的完整核心文档或源代码读入上下文在尝试修复之前构建对该领域的临时心智模型——模拟人类专家即时学习新领域的方式。5.2 从检索到综合上下文污染问题实验揭示了一个反直觉的发现获得信息并不保证理解。对于较弱的模型深度研究模块反而成为了干扰因素。研究团队将此定义为**上下文污染Context Pollution**问题。没有强大的过滤机制智能体经常检索到错误版本的库文档或与目标仓库的架构约束相矛盾的通用教程。失败模式很少是找到了错误的页面而是**未能将外部概念映射到本地代码**。例如智能体可能正确找到了 NumPy 2.0 的迁移指南但无法将抽象规则如用float替换np.float应用到被装饰器包裹的具体复杂调用点。启示这表明检索找到 X和综合理解 X 如何约束 Y之间存在鸿沟。未来工作必须专注于训练智能体掌握研究驱动编码的完整工作流假设生成→严格的证据过滤→上下文感知的应用。5.3 重构的全有或全无本质依赖迁移任务呈现了独特的挑战它是二值的。不像功能添加那样基本可用往往是可接受的一个遗漏了单个文件或单个函数调用的迁移重构可能会破坏整个构建。实验表明智能体擅长识别变更模式但在全局一致性方面举步维艰——经常修复 90% 的出现位置但遗漏隐藏在工具文件、不起眼的测试或动态生成字符串中的边缘情况。启示这凸显了当前以文件为中心的智能体架构的局限性。未来的智能体需要一种**仓库感知的记忆架构**如使用代码知识图谱能够在整个项目图中跟踪变更状态确保依赖中的破坏性变更被传播到代码库的每一个受影响的叶节点。5.4 生成中的架构远见Doc2Repo 任务暴露了**架构远见**的关键缺陷。当被要求从零构建仓库时智能体往往表现得像没有计划的初级开发者它们正确地实现了个别函数但未能合理构建模块层次结构导致循环导入、臃肿文件或不可维护的目录结构。智能体倾向于线性地编写代码只有当测试套件崩溃时才发现架构缺陷——此时重构的成本已经太高。启示真正的软件工程需要设计和实现的明确分离。未来的智能体应该明确采用架构链Chain-of-Architect方法——先生成目录树和接口定义验证设计然后再进行实现。六、编码搜索的深层挑战论文进一步剖析了编码场景中信息检索与传统 Web 搜索的本质差异这构成了搜索增强编码智能体的核心技术挑战挑战一信息景观差异传统文档代表了人类精心策划的高信息密度知识搜索引擎对此有数十年的优化经验。然而代码任务所需的知识往往嵌入在原始工件中——分散在仓库中的源文件、Issue 跟踪器中的讨论线程或内联注释——搜索引擎难以有效索引这些内容。挑战二版本一致性搜索通常呈现最新库版本的文档而本地环境经常锁定较旧版本。模型难以检测和调和这些不匹配导致看似合理但实际不正确的解决方案。挑战三检索噪声的放大效应当相关信息难以检索时搜索引入的噪声会主动损害代码生成。研究团队观察到当模型无法找到精确答案时会纳入切题但最终具有误导性的信息导致性能低于无搜索基线。七、个人解读与评价7.1 论文的核心价值BeyondSWE 最大的贡献不在于提出了一个新的基准测试而在于它重新定义了代码智能体评估的维度。通过将评估从单一的能不能修 Bug扩展到能不能像真正的开发者那样工作它迫使我们正视一个现实当前在 SWE-bench 上的高分很大程度上是考试型能力——在特定、受限的场景下表现出色但面对真实世界的多样性时迅速崩溃。7.2 SearchSWE 的启示SearchSWE 的实验结果是本文最具价值的部分之一。它揭示了一个重要的事实人类开发者那种编码-搜索-编码的无缝切换工作流在当前 AI 系统中还远未被实现。更重要的是搜索质量 搜索频率的发现为未来代码智能体的设计提供了明确方向——与其让模型频繁搜索不如训练模型精准判断何时需要搜索以及如何高效利用搜索结果。7.3 对行业的影响这篇论文对于那些过度依赖 SWE-bench 分数来衡量代码智能体实用性的做法敲响了警钟。在实际的软件开发场景中代码智能体还需要走很长的路。特别是依赖迁移是一个巨大的实际痛点BeyondSWE 首次将其纳入系统评估从文档到代码库的生成代表了代码智能体的终极目标目前离实用还很远领域知识的缺失是一个难以通过简单 Scale up 解决的问题7.4 局限性思考当然BeyondSWE 也有一些局限性当前仅覆盖 Python 语言而多语言跨仓库的场景在实际开发中同样常见500 个实例的规模虽然不小但在某些子任务如 DomainFix 的 72 个和 Doc2Repo 的 50 个上可能不够充分SearchSWE 的搜索工具基于 Google Search而在实际场景中开发者可能使用更多元的信息源如 Stack Overflow 站内搜索、GitHub Code Search 等八、总结BeyondSWE 向我们展示了一幅令人谦逊的图景在单仓库修 Bug 之外当前代码智能体面临着陡峭的能力悬崖。跨仓库推理、领域专业知识、全局重构和从零构建——这些真实世界的核心工程挑战暴露了当前模型在架构理解、知识集成和全局一致性方面的根本不足。更值得深思的是SearchSWE 的实验揭示了搜索与编码能力之间的鸿沟——这两种能力沿着各自的轨迹独立成熟但它们的有效整合不会自动涌现可能需要在模型开发过程中给予明确的关注。对于整个代码智能体领域而言BeyondSWE 传递的信息很明确是时候从考试型评估走向实战型评估了。只有在更贴近真实软件工程的维度上系统地检验和推动智能体能力我们才能真正接近AI 软件工程师的愿景。参考资源论文https://arxiv.org/abs/2603.03194基准数据集https://huggingface.co/datasets/AweAI-Team/BeyondSWE代码仓库https://github.com/AweAI-Team/BeyondSWE智能体框架https://github.com/AweAI-Team/AweAgent项目主页https://aweai-team.github.io/BeyondSWE/