BeyondSWE：当前代码智能体能否超越单仓库缺陷修复？ BeyondSWE: Can Current Code Agent Survive Beyond Single-Repo Bug Fixing?
500实例基准测试，评估代码智能体在跨仓库、领域知识、依赖迁移等复杂场景的能力
前置知识
SWE-bench
SWE-bench 是一个基于真实 GitHub Issue 的代码智能体评估基准，由 Jimenez 等人在 2024 年提出。该基准收集了来自真实开源项目的缺陷报告，要求智能体在给定 Issue 描述的情况下自动生成代码补丁。评估方式是通过运行项目测试套件来验证补丁的正确性，包括 P2P（pass-to-pass，应继续通过的测试）和 F2P（fail-to-pass，修复后应通过的测试）两类测试。SWE-bench Verified 是其经过人工验证的子集，已成为代码智能体领域的标准评估范式。
BeyondSWE 直接扩展了 SWE-bench 的评估范式，理解 SWE-bench 的设计理念和评估方式是理解本文贡献的基础。本文的核心论点正是 SWE-bench 只覆盖了单仓库局部修复场景，而 BeyondSWE 将评估扩展到更广泛的知识和修复范围。
代码智能体（Code Agent）
代码智能体是能够自主执行软件工程任务的 AI 系统，通常由大语言模型驱动，配备文件读写、命令执行、代码搜索等工具。代表性系统包括 OpenHands（开源代码智能体框架）、Codex（OpenAI 的代码智能体）、Claude Code（Anthropic 的代码智能体）等。这些系统能够理解 Issue 描述，分析代码库，生成修复补丁，并通过执行测试来验证结果。
本文评估了多种代码智能体在 BeyondSWE 基准上的表现，包括 OpenHands 框架和 Codex 框架，理解代码智能体的工作方式有助于理解评估结果的含义和局限性。
搜索增强编程（Search-Augmented Coding）
搜索增强编程是指在代码智能体的工作流程中集成网络搜索和信息获取能力，使智能体能够访问仓库外部的信息资源。这种能力对于需要跨仓库知识、领域专业知识或 API 文档的任务尤为重要。SearchSWE 是本文提出的受控诊断基线，通过最小化地扩展标准代码智能体工作流来研究搜索访问对编程性能的影响。
本文的一个核心贡献是研究搜索增强编程的有效性。通过 SearchSWE 的受控实验，作者发现搜索访问确实有用，但收益有限且不均匀，这表明深度搜索编程仍然是一个开放问题。
Docker 环境构建
为了实现可复现的评估，BeyondSWE 为每个实例构建独立的 Docker 容器环境。这些环境包含目标仓库、依赖项、测试命令等完整运行时配置。构建过程采用智能体辅助方式：从基础 Ubuntu 容器开始，克隆仓库，检出 PR 前的提交，迭代解决设置失败直到现有测试可以执行。每个环境都经过严格的稳定性检查，要求测试在 5 次运行中表现出稳定的通过/失败行为。
可靠的环境构建是基准测试质量的关键。许多真实仓库存在依赖衰减、包不可用、API 弃用等问题，BeyondSWE 的智能体辅助环境构建流程解决了这些问题，确保评估结果的可靠性和可复现性。
研究动机
当前代码智能体的评估主要集中在单仓库内的局部缺陷修复任务上。以 SWE-bench Verified 为代表的主流基准假设相关上下文可以从 Issue 和代码库中恢复，目标解决方案通常只影响少量文件和代码行。然而，实际软件工程中的许多任务需要超出仓库范围的知识或更广泛的代码修改。开发者可能需要查阅上游项目、文档或领域知识；可能需要跨代码库迁移 API；或者需要从规范文档构建完整的仓库。这些场景对代码智能体的能力提出了更高的要求，但在现有基准中严重不足。具体来说，SWE-bench Verified 只包含 12 个仓库，平均每个实例影响 1.3 个文件和 11.6 行代码；即使是更难的 SWE-bench Pro 也只涉及 41 个仓库、4.1 个文件和 107.4 行代码。这种评估范围的局限性导致我们对代码智能体在真实软件工程场景中的能力缺乏全面了解。
本文的目标是本文的目标是回答一个简单但重要的问题：当前代码智能体在超越单仓库缺陷修复的场景中表现如何？为了研究这个问题，作者引入了 BeyondSWE 基准，旨在评估代码智能体在更广泛知识范围和更广泛修复范围下的能力。BeyondSWE 包含 500 个实例，来自 246 个真实 GitHub 仓库，覆盖四种代表性场景：跨仓库缺陷修复（CrossRepo）、领域特定缺陷修复（DomainFix）、依赖驱动迁移（DepMigrate）和文档到仓库生成（Doc2Repo）。这些任务的平均修改规模为 10.9 个文件和 1039.6 行代码，远超现有基准。同时，作者还引入 SearchSWE 作为受控诊断基线，研究搜索增强编程的有效性。
与已有工作不同的是，本文的独特切入角度在于两个实用维度的设计：知识范围（knowledge scope）和修复范围（resolution scope）。知识范围区分了只需仓库内部信息的任务和需要外部软件制品、科学领域知识、API 文档或规范文档的任务。修复范围区分了局部修复、仓库级变换和完整仓库构建。这两个维度的组合使得 BeyondSWE 能够压力测试现有基准中代表性不足的能力，同时保持可执行的、基于测试的评估方式。这种设计视角既保留了 SWE-bench 式评估的严格性（通过 Docker 环境和测试套件），又扩展了评估范围到更接近真实软件工程的场景。此外，SearchSWE 的引入使得作者能够隔离搜索增强对编程性能的影响，这是之前无法做到的，因为生产系统将搜索与专有提示、工具策略、模型选择和脚手架耦合在一起。
核心方法
BeyondSWE 的方法论建立在两个实用维度的设计之上：知识范围和修复范围。知识范围从'仅需仓库内部信息'到'需要外部软件制品、科学领域知识、API 文档或人类规范'；修复范围从'局部修复'到'仓库级变换'和'完整仓库构建'。基于这两个维度，作者定义了四个代表性压力测试：CrossRepo 保持熟悉的缺陷修复格式但需要使用外部仓库信息；DomainFix 测试智能体结合代码推理与专业知识的能力；DepMigrate 评估在上游依赖破坏性变更下的仓库级协调；Doc2Repo 要求智能体从自然语言规范构建功能仓库。整个方法还包括智能体辅助的 Docker 环境构建流程、严格的稳定性检查、搜索增强的诊断基线 SearchSWE，以及分离智能体执行与最终验证的评估协议。
本文的核心创新点在于将代码智能体的评估从'单仓库局部修复'扩展到'跨仓库、跨领域、跨版本'的综合评估。与 SWE-bench 系列基准假设'问题解决的上下文可从目标仓库中恢复'不同，BeyondSWE 明确设计了需要外部信息的任务。另一个关键创新是 SearchSWE 作为受控诊断基线的设计。之前的研究无法隔离搜索增强对编程性能的影响，因为生产系统将搜索与专有组件耦合。SearchSWE 最小化地扩展标准工作流，添加网络搜索和获取工具，同时通过 URL 阻止列表防止直接访问目标仓库的解决方案。这种设计使得作者能够进行受控比较：相同的模型和脚手架，有搜索和无搜索，从而准确量化搜索访问的边际收益。
方法步骤详情
BeyondSWE 的构建流程包括多个精心设计的步骤。首先，针对每个子集收集候选实例：CrossRepo 扫描包含外部链接的合并 PR，收集约 3000 个候选；DomainFix 与领域专家合作识别 21 个高质量仓库，收集约 800 个候选 PR；DepMigrate 识别 23 个有重大版本升级的广泛使用包，LLM 过滤后产生约 7000 个候选；Doc2Repo 收集 2025 年 1-11 月创建的 Python 仓库。其次，智能体辅助的环境构建流程：从基础 Ubuntu 容器开始，克隆仓库，检出 PR 前的提交，迭代解决设置失败，直到现有测试可以执行，然后将成功的命令历史蒸馏为可复现的 Dockerfile。第三，严格的稳定性检查：构建 Docker 镜像并执行相关测试 5 次，对于 CrossRepo/DomainFix/DepMigrate，要求 P2P 测试通过且 F2P 测试在应用参考补丁前失败、应用后都通过；对于 Doc2Repo，通过运行适配的测试套件和人工审计来验证。第四，分离评估：智能体在自己的 Docker 环境中工作并产生补丁或生成的仓库，然后将结果提取并应用到独立的新容器中，防止环境副作用影响最终分数。最后，完整性保护：移除目标提交后的 git 提交、日志和元数据，在运行评估前恢复所有测试文件到原始状态。
技术新颖性
BeyondSWE 的技术新颖性体现在多个方面。首先，在基准设计上，这是第一个系统性地从知识范围和修复范围两个维度评估代码智能体的工作，覆盖了跨仓库推理、领域特定修复、依赖迁移和仓库构建四个代表性场景。其次，在环境构建上，采用智能体辅助的流程来解决真实仓库的依赖衰减问题，这比手动配置更可扩展，比简单安装更可靠。第三，在评估协议上，分离智能体执行与最终验证，防止环境副作用影响分数；实施完整性保护，防止智能体通过访问未来仓库历史或编辑测试文件来'作弊'。第四，SearchSWE 的受控诊断设计是首创的，通过最小化地扩展工作流并使用阻止列表，实现了搜索增强效果的隔离研究。最后，在任务规模上，平均修改 10.9 个文件和 1039.6 行代码，远超 SWE-bench 系列的修改规模，更接近真实软件工程的复杂度。
实验结果
本文的核心发现揭示了当前代码智能体在超越单仓库缺陷修复场景中的显著局限性。在 OpenHands 脚手架下，表现最好的模型 DeepSeek-V4-Pro (Max) 仅达到 46.12 的平均分，远未饱和基准。使用 Codex 脚手架的 GPT-5.4 (xhigh) 在默认提示下达到 48.48，在 SearchSWE 风格提示下提升到 56.65，但仍有很大提升空间。任务级别的分析显示，不同任务的难度来源不同：CrossRepo 应力测试外部软件知识，DomainFix 需要领域特定推理，DepMigrate 要求协调的仓库级编辑，Doc2Repo 暴露了不同的局限性——即使最好的配置也只产生 2 个完全正确的仓库（50 个中）。搜索增强的分析表明，SearchSWE 改进了 8 个评估模型中的 7 个，32 个配对比较中有 20 个改进，但 31.2% 回退，表明搜索访问有用但不均匀可靠。DomainFix 受益最大（+19.4），而 Doc2Repo 收益最弱。成本和 token 预算分析表明，更高的 API 成本并不可靠地对应更高性能，更长的轨迹也不可靠地转化为更好的任务解决。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| CrossRepo（跨仓库缺陷修复） | %Resolved（解决率） | GPT-5.4 (xhigh) + SearchSWE Prompt: 55.17% | GPT-5.4 (xhigh) + Default Prompt: 46.23% | +8.94%（搜索增强提升） |
| DomainFix（领域特定缺陷修复） | %Resolved（解决率） | GPT-5.4 (xhigh) + SearchSWE Prompt: 61.11% | GPT-5.4 (xhigh) + Default Prompt: 41.67% | +19.44%（搜索增强提升最大） |
| DepMigrate（依赖驱动迁移） | %Resolved（解决率） | GPT-5.4 (xhigh) + SearchSWE Prompt: 48.59% | GPT-5.4 (xhigh) + Default Prompt: 44.38% | +4.21%（搜索增强提升） |
| Doc2Repo（文档到仓库生成） | Pass Rate（通过率） | GPT-5.4 (xhigh) + SearchSWE Prompt: 61.74% | GPT-5.4 (xhigh) + Default Prompt: 61.64% | +0.10%（搜索增强提升微弱） |
| 整体（AVG 平均分） | AVG（四任务平均分） | GPT-5.4 (xhigh) + SearchSWE Prompt: 56.65 | DeepSeek-V4-Pro (Max) OpenHands: 46.12 | +10.53（Codex vs OpenHands 最佳） |
局限与改进
本文存在多方面的局限性。首先，作者承认 BeyondSWE 只覆盖了 Python 生态系统，可能无法代表其他编程语言的软件工程挑战。其次，环境构建虽然采用智能体辅助流程，但仍需要大量人工验证，特别是 DomainFix 需要领域专家的独立审查，这限制了基准的可扩展性。第三，SearchSWE 的阻止列表虽然防止了直接访问目标仓库的解决方案，但无法完全防止智能体通过间接方式获取泄露信息。第四，评估只测试了有限的模型和脚手架组合，可能无法代表所有代码智能体的能力。从我的观察来看，Doc2Repo 任务的评估指标（Pass Rate）可能高估了成功，因为即使通过率很高，也可能无法产生功能完整的仓库（只有 2 个完全正确）；此外，搜索增强的收益在不同任务间差异很大，这可能反映了任务特性而非方法本身的局限性；最后，成本分析只考虑了 API 成本，没有考虑开发时间和调试成本，这在实际应用中可能同样重要。
独立分析的弱点
本文存在几个值得独立分析的弱点。首先，CrossRepo 的'外部知识'定义相对宽泛，包括上游仓库的 PR、Issue、官方文档等，但没有区分不同类型外部知识的难度和价值，这可能导致任务难度分布不均匀。改进方向是更细粒度地分类外部知识类型，并分析智能体对不同类型知识的利用效率。其次，DomainFix 的领域专家验证虽然提高了质量，但 21 个仓库和 72 个实例的规模相对较小，可能无法充分代表科学计算领域的多样性。改进方向是扩大领域覆盖范围，包括更多小众但重要的科学计算库。第三，DepMigrate 只考虑了 Python 包的版本升级，没有覆盖跨语言的依赖迁移（如从 Python 调用 C 库的 API 变更）。改进方向是扩展到多语言依赖迁移场景。第四，SearchSWE 的搜索工具设计相对简单（网络搜索和网页获取），没有考虑更复杂的检索策略（如语义搜索、代码搜索、文档搜索等）。改进方向是研究不同检索策略对搜索增强编程的影响。最后，评估指标主要基于测试通过率，没有考虑代码质量、可维护性、安全性等软件工程的其他重要维度。改进方向是引入多维度的评估指标。
未来方向
作者提出了几个未来研究方向。首先，深度搜索编程仍然是一个开放问题：搜索和编程都在快速发展，但当前智能体还不能可靠地将它们合成为稳健的搜索增强编程工作流。未来的进步需要智能体不仅能检索信息，还能决定何时信任信息、何时忽略信息，以及如何将信息转化为精确的、可执行的代码变更。其次，需要更好的源辨别、版本定位和本地验证机制，使得检索到的证据能够转化为正确的代码变更。第三，需要研究不同搜索策略（如语义搜索、代码搜索、文档搜索）对不同类型任务的影响。基于本文成果，可以延伸的研究方向包括：将 BeyondSWE 扩展到多语言编程场景；研究搜索增强编程中的'信息过载'问题（智能体如何从大量检索结果中筛选有用信息）；开发专门针对跨仓库推理和领域特定修复的训练方法；以及将 SearchSWE 的受控诊断方法应用到其他 AI 任务中。
复现评估
本文在可复现性方面做了大量工作，但仍存在一些挑战。开源情况方面，论文提到 BeyondSWE 包含 500 个实例，但没有明确说明是否完全开源数据集和评估代码。环境构建方面，每个实例都有独立的 Docker 环境，理论上可以完全复现评估过程，但构建过程需要访问历史版本的仓库和依赖，可能受到包管理器变化的影响。算力要求方面，评估涉及多种模型和脚手架的组合，包括 Codex（需要 OpenAI API 访问）和 OpenHands（开源），需要大量 API 调用和计算资源。具体来说，GPT-5.4 (xhigh) 的完整评估可能需要数百美元的 API 成本。复现难度方面，环境构建流程虽然文档化，但需要智能体辅助，这引入了不确定性；稳定性检查要求测试在 5 次运行中表现一致，这需要仔细的环境配置。总体而言，如果作者开源数据集和评估代码，复现主要结果应该是可行的，但完全复现所有实验配置需要显著的计算资源和 API 访问权限。
论文图表
