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%+ 的表现形成了鲜明对比。更出人意料的是，给智能体加上搜索能力并不总是有帮助——在某些情况下，搜索反而会降低性能。

图1：BeyondSWE 基准概览。沿知识范围和解决范围两个维度扩展，构建了四种评估任务：CrossRepo（跨仓库）和 DomainFix（领域知识）扩展了知识范围；DepMigrate（依赖迁移）和 Doc2Repo（文档到仓库）扩展了解决范围。

二、BeyondSWE 基准设计：四维度全面评估

2.1 设计哲学：两轴四象限

BeyondSWE 的核心设计思想是沿两个正交维度扩展现有评估框架：

• 解决范围（Resolution Scope）：从局部函数级修复到仓库级全局重构
• 知识范围（Knowledge Scope）：从仓库内信息到外部知识（跨仓库代码、领域专业知识、官方文档、人类规格说明）

由此形成了四种截然不同的评估设置，共包含 500 个真实世界实例，涉及 246 个 GitHub 仓库：

基准测试	解决范围	知识范围	仓库数	平均修改文件数	平均修改行数
SWE-bench Verified	局部函数	仓库内	12	1.3	11.6
SWE-bench Live	局部函数	仓库内	223	2.7	65.1
SWE-bench Pro	局部函数	仓库内	41	4.1	107.4
CrossRepo	局部函数	跨仓库	67	4.1	190.7
DomainFix	局部函数	领域知识	12	4.2	157.6
DepMigrate	全局仓库	官方文档	120	8.4	281.6
Doc2Repo	全局仓库	人类规格	50	全部	全部
BeyondSWE (总计)	混合	混合	246	5.6	209.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、不可用版本），研究团队设计了一套基于智能体的自动化环境构建流水线：

图2：BeyondSWE 的自动化环境构建流水线。包含三个阶段：（1）针对各任务的候选收集策略；（2）基于智能体的 Docker 构建，LLM 智能体在容器内迭代解决依赖直至所有测试通过；（3）严格的环境检验，要求一致的 P2P/F2P 行为以确保可重现性。

1. 候选收集：针对每种任务采用定制策略
2. 智能体驱动的 Docker 构建：在 Ubuntu Docker 容器内实例化 Gemini 3 Pro 智能体，通过"运行-错误-修复"循环迭代地解决依赖问题。关键在于，智能体拥有 Shell 访问权限，可以执行系统级命令（如 apt-get），这超越了静态安装脚本的能力
3. 严格的环境检验：每个生成的 Dockerfile 被构建并执行全部测试套件 5 次，验证 P2P 测试通过、F2P 测试失败（打补丁前），以及两者都通过（打补丁后）。不确定性行为的实例直接丢弃

评估协议：

• 环境隔离：智能体生成的补丁通过 git diff 提取，应用到一个全新的、与智能体工作环境完全独立的 Docker 容器中
• 完整性保障：移除目标提交之后的所有 git 历史；应用补丁后恢复所有测试文件到原始状态，防止智能体篡改测试
• 评估指标：CrossRepo/DomainFix/DepMigrate 报告解决率（Resolved Rate）；Doc2Repo 报告通过率（Pass Rate）和（几乎）正确数（#(Almost) Correct）

三、SearchSWE 框架：当搜索遇上编码

3.1 框架设计

当前主流的开源代码智能体（如 SWE-agent、OpenHands）在隔离的执行环境中交互——通常是 Docker 容器——探索仓库结构、执行代码、运行测试。虽然本地上下文提供了代码操作所需的基本反馈，但它将智能体限制在封闭循环工作流中：当解决问题需要代码库之外的知识时，智能体无从获取外部信息。

为此，研究团队提出了 SearchSWE，一个扩展的编码智能体框架，将深度研究能力集成到智能体的工作流中。

图3：SearchSWE 框架概览。左侧：智能体通过迭代访问外部资源（搜索、浏览器）和本地上下文（Docker 容器）来解决编码任务，并有一个封锁列表防止作弊。右侧：评估流程将补丁应用到全新容器并运行 P2P/F2P 测试进行验证。

SearchSWE 跨两个互补上下文运作：

• 本地上下文（Local Context）：Docker 容器，智能体在其中探索仓库结构、执行命令、运行测试——与现有代码智能体框架类似
• 全局上下文（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 Pro	41.50	31.94	41.81	52.03	(8)/2	41.82
GPT-5.2	33.00	23.61	34.27	53.89	(6)/2	36.19
GLM-4.7	40.20	36.11	39.89	48.40	(3)/1	41.20
DeepSeek-V3.2	38.00	30.56	36.52	54.99	(3)/0	40.01
MiniMax-M2.1	37.50	29.17	37.64	48.38	(3)/1	38.17
Kimi-K2	37.00	27.78	39.53	54.91	(6)/2	39.81
Seed-Coder	44.72	25.00	35.39	42.55	(1)/1	36.90
Qwen3-Coder-Plus	19.19	5.56	15.43	1.87	(1)/0	10.51
Qwen3-235B-Inst	15.50	5.71	13.56	4.03	(0)/0	9.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 Pro	41.12 (-0.4)	39.44 (+7.5)	44.07 (+2.3)	50.73 (-1.3)	43.84 (+2.0)
GPT-5.2	36.22 (+3.2)	22.22 (-1.4)	33.90 (-0.4)	55.85 (+2.0)	37.05 (+0.9)
GLM-4.7	45.40 (+5.2)	32.39 (-3.7)	39.77 (-0.1)	49.44 (+1.0)	41.75 (+0.6)
DeepSeek-V3.2	39.49 (+1.5)	31.88 (+1.3)	34.09 (-2.4)	53.64 (-1.4)	39.77 (-0.2)
MiniMax-M2.1	41.00 (+3.5)	32.39 (+3.2)	39.55 (+1.9)	46.45 (-1.9)	39.84 (+1.7)
Kimi-K2	39.90 (+2.9)	33.33 (+5.6)	34.83 (-4.7)	49.31 (-5.6)	39.34 (-0.5)
Seed-Coder	38.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/