BeyondSWE | 评测

为什么重要

BeyondSWE 首次在**解决范围（Resolution Scope）和知识来源（Knowledge Scope）**两个维度上同时突破现有代码基准的局限。所有 SWE-bench 变体（Verified/Pro/Live）都集中在同一个象限：局部函数级别的解决范围 + 仓库内部的知识来源。而真实软件工程中，开发者经常需要跨仓库检索信息、理解领域专业知识、执行全仓库级迁移、或从零构建系统——这些恰恰是评测的空白地带。

核心发现：前沿模型在 SWE-bench 上达到 80%+ 的通过率，在 BeyondSWE 上却不超过 45%，差距近乎腰斩。

四类任务

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

Agent 仍只在单一仓库修改代码，但修复所需的关键信息存在于外部仓库/Stack Overflow/上游库
来自 67 个仓库，平均包含 1.3 个外部链接
考察对开源生态的广泛认知

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

修 Bug 不只需要读懂代码，更需要理解背后的物理公式、数学概念或生物学原理
覆盖 11 个学科：量子物理（QuTiP）、生物信息学（Biotite）、凸优化（cvxpy）、天文学（astroplan）、等离子体物理（PlasmaPy）
每道题经三位领域专家独立审核
最硬的骨头：几乎没有模型突破 36%

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

依赖升级是每个项目维护者反复面对的日常：NumPy 1.x→2.0、Pydantic v1→v2、Django 4.x→5.0
识别了 23 个核心依赖包的重大版本更新，从 7000 个候选项中筛选出 178 条
覆盖 120 个仓库，需要全局一致性迁移

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

Agent 只拿到一份纯文字功能说明文档和一个空目录，一切从零开始
50 条样例来自 2025 年新建的高质量仓库，代码量 1000-16000+ 行
为防止记忆化，刻意隐去仓库名称和目录结构

构建方式

候选爬取：从 3000+ 包含外部链接的 GitHub PR 中筛选
Docker 环境自动构建：基于 Agent 的自动化构建
严格的环境一致性验证：每条样例 5 次独立运行，P2P 和 F2P 测试结果必须完全一致
三轮人工校验：3 位领域专家 + 5 位资深软件工程师 + 5 位 Code Agent 研究博士生

复杂度：平均每题涉及 5.6 个文件、209.9 行代码——是 SWE-bench Verified（1.3 文件/11.6 行）的 18 倍。

SearchSWE 框架

BeyondSWE 同期提出 SearchSWE，系统研究搜索与编码的融合：

SearchTool：搜索引擎查询
BrowserTool：网页内容浏览与理解
双重防作弊机制：搜索结果侧过滤目标仓库 URL + 执行命令侧拦截目标仓库访问

搜索增强的关键发现

6/9 模型搜索后提升，3 个反而下降
搜索质量 > 搜索数量：Gemini 3 Pro 平均每任务搜索 0.8-1.1 次却获最佳增益 (+2.0%)；DeepSeek-V3.2 平均搜索 4.2-5.4 次反而微降 (-0.2%)
三类失败模式：
- 信息景观的鸿沟：搜索引擎擅长人类可读文档，但代码任务需要”逻辑上精确”的源码细节
- 版本时间错位：搜索引擎偏向最新文档，而任务环境锁定在历史版本
- 语义漂移与噪声污染：技术术语歧义导致搜索结果偏离

关键发现

45% 天花板：Gemini 3 Pro、GPT-5.2、DeepSeek-V3.2 等前沿模型整体均不超过 45%
没有全能选手：不同任务领跑者不同——Seed-Coder (CrossRepo)、DeepSeek-V3.2 (Doc2Repo)、Gemini 3 Pro (DepMigrate)
DomainFix 最难：领域专业知识构成真实的认知壁垒，几乎无模型突破 36%
Doc2Repo 虚高陷阱：看似 45-55% 通过率，但完整仓库全测试通过率极低——Agent 善于零散功能模块，却难以架构连贯系统

局限性

目前仅支持 Python 语言
Doc2Repo 任务数量较少（50 条）
搜索增强实验仅基于 OpenHands 框架
部分任务的测试覆盖度可能不完整

关联基准

SWE-bench：单一仓库 Bug 修复
SWE-bench Pro：高难度多语言版
SWE-bench-Live：实时更新版
ProgramBench：从零构建软件系统
Web-Bench：前端代码基准

BeyondSWE v1

考察能力

构建信息

资源链接

模型效果排行