返回评测
代码生成 代码-仓库级 未饱和 模态 · 代码 任务 · 代码生成

CrossSWE v1

arXiv:2611.01484,上海交大等,171 个真实跨仓库实例 / 165 仓库 / 20 技术域 / 13 语言,要求 Agent 在多个相互依赖的仓库里做出「缺一不可」的协同修改;最强模型 GPT-6.1 Sol 仅 58.48% Pass@1,跨仓库不一致以 44.2% 占比成为全部五款模型的第一失败模式

Shanghai Jiao Tong University / Xidian University / Singapore Management University ·

考察能力

跨仓库依赖推理 变更传播 接口一致性维护 仓库级代码修改 多语言工程

构建信息

数据规模
171 实例 / 165 仓库 / 20 技术域 / 13 编程语言
构建方式
多阶段流水线:候选发现 → 源头验证(issue/PR/review 历史重建)→ Docker 环境构建 + 联合必要性验证(单独改任一仓库必须不足以完成任务,否则丢弃)
评测方式
每个实例预配置包含两个以上参与仓库的执行环境,各仓库锁定在已验证的 base commit;可执行验证器判分,Pass@1
核心指标
Pass@1(%),附平均输入/输出 token、平均步数、平均成本(美元)

模型效果排行

🥇 GPT-6.1 Sol (闭源第一; 单语 60.34 / 跨语 54.55, 0.97M 输入 token, 32.9 步, $0.3496/实例)
58.48% 2026-11
🥈 DeepSeek V4.1 Flash (开源第一, 总榜第二; 跨语 52.73 几乎追平单语 52.59; 但 17.54M 输入 token 是 Sol 的 18 倍, 152.7 步)
52.63% 2026-11
🥉 Claude Sonnet 5.5 (闭源第二; 单语 52.59 / 跨语 43.64——跨语落差 8.95pp 为闭源最大)
50.29% 2026-11
4. Qwen3.8-Flash-Next (开源, 13.31M token, 182.1 步)
45.03% 2026-11
5. GLM-5.3 Flash (开源, 9.74M token, 141.7 步)
43.86% 2026-11

为什么重要

当 SWE-bench Verified 头名越过 97%、SWE-bench Pro 过 80% 之后,编码基准的难度军备竞赛集中在两个方向:更长的时间跨度、更大的单仓库改动量。但真实软件开发有一条这两条路都没碰过的难度轴:一个变更本身就要横跨多个相互依赖的仓库——改共享 API 要连着改它的服务端与客户端,改认证协议要同步改身份与遥测,升级依赖要一路传播到下游。这恰是开源生态里每天都在发生、而任何单仓库基准都无法测量的工作形态。

CrossSWE 把这条轴变成了 171 个可执行验证的真实实例,并且做了一件比「出题」更关键的事:联合必要性验证——每个实例都验证过「只改其中任何一个仓库都不足以完成任务」。这堵住了「Agent 只把容易的那半个仓库改对也能拿分」的漏洞,保证分数测的是协同修改能力而非单仓库能力的简单叠加。

构建方式

流水线三阶段,逐级收紧:

  1. 候选发现:从 GitHub 公开仓库的开发历史里挖掘涉及多仓库协同修改的真实变更(issue、PR、review 记录)。
  2. 源头验证:重建任务意图与参考补丁,确认变更确实需要跨仓库协同。
  3. 环境构建 + 联合必要性验证:为每个实例构建专用 Docker 镜像,所有参与仓库锁定在已验证的 base commit;若单独修改任一仓库就能让测试通过,该候选被丢弃。剩余实例构成正式评测集。

每个实例含四部分:预配置执行环境(≥2 个参与仓库)、任务描述、验证器(测试套件)、参考补丁。任务意图分八个互斥类别:功能开发(54)、API/模式/协议演进(43)、缺陷修复(22)、安全/身份/可观测性协同(21)、部署/平台/运行时协同(14)、迁移/升级/重构(9)、测试/基准/一致性适配(7)、传递性变更传播(1)——功能开发与 API 演进合计 97/171,说明基准重心在「演进型工程」而非「修 bug」。作者用 oauth2-proxy 与 Higress 的真实案例说明任务形态:oauth2-proxy 需把 cookie 保持为列表,Higress 需逐条处理输出 cookie,只改一边接口就不一致,两边协同改才能恢复预期行为。

数据以 CC BY 4.0(基准材料)+ 上游许可(源码引用)双许可发布在 HuggingFace,patch 溯源保留。

关键发现

  • 联合修改比单侧修改系统性更难,且弱模型掉得更多。GPT-6.1 Sol 联合 58.48% vs 单侧 64.55%(−6.07pp);DeepSeek V4.1 Flash 联合 52.63% vs 单侧 61.81%(−9.18pp)。步数同步膨胀:Sol 联合 32.9 步 vs 单侧 18.5 步,DeepSeek 联合 152.7 步 vs 单侧 126.9 步。「跨仓库协同」对弱模型的边际惩罚更大,这本身就是该难度轴存在的直接证据。
  • 跨仓库不一致是全部五款模型的第一失败模式:占 GPT 失败轨迹的 44.2%、Claude 的 41.2%、GLM 的 40.7%、DeepSeek 的 29.2%。每个仓库的补丁单独看都「正确」,拼在一起却接口不兼容——这正是人类工程师做跨仓库变更时最怕的那类错误,现在被定量证明同样是 Agent 的头号坑。
  • 第二失败模式是「不完整实现」:Claude 29.4%、DeepSeek 25.0%、GLM 25.4%。DeepSeek 的失败谱最分散,兼容性回归占 18.8%。
  • 开源模型靠 token 暴力换分:DeepSeek 单实例平均 17.54M 输入 token、88.73K 输出 token、152.7 步,对 GPT-6.1 Sol 的 0.97M / 12.5K / 32.9 步——输入量 18 倍、步数 4.6 倍,换来总分低 5.85pp 但成本反而最低(0.2881 美元 vs 0.3496 美元/实例)。在 CrossSWE 上,「每分成本」与「绝对能力」的排序完全相反。
  • 闭源模型内部也分化:Sonnet 5.5 的跨语/单语落差(52.59 → 43.64,−8.95pp)远大于 Sol 的 −5.79pp 与 DeepSeek 的 +0.14pp,说明跨语言一致性是独立于总能力的第二条轴。

关联基准与展望

关联:SWE-bench Pro(单仓库长程工程)、SWE-Marathon(小时级项目全周期)、SWE-bench Multimodal(单仓库多模态)。同期还有两个相邻工作:Switch-SWE(arXiv:2611.02017,多任务切换后恢复未完成任务,7 款 Agent 平均 11.5pp 的焦点任务落差)与 THReD(arXiv:2611.02484,EHR 数据预处理 Agent),两者尚未建卡。CrossSWE 与 Switch-SWE 分别占领「空间维度的跨仓库」与「时间维度的多任务」两块单仓库基准覆盖不到的疆域。局限:传递性变更传播仅 1 例、部分类别样本极少;模型阵容五款且以 Flash 档开源模型为主,头部闭源(Opus 5.5 / Astra)未测——58.48% 的「最强模型」只是这个阵容里的最强。

代码生成 跨仓库 联合开发 依赖推理 变更传播 接口一致性