WideSWE：跨仓库协调改动才是 Coding Agent 真正的硬骨头

  • 关联论文：2609.33382
  • 作者：flyP
  • 更新：2026-09-29

一句话结论

本文（ZJU-ACES-ISE，cs.SE）提出 WideSWE——第一个针对"跨仓库协调改动"的 coding agent 评测基准：从 103 个软件生态里挖出 120 个真实跨仓库任务（60 bug fixes + 60 features），七种 agent 配置下全任务成功率仅 10.83%~42.50%，最强组合 Codex CLI + GPT-5.6-sol 拿下 42.50%；实验同时证明 联合执行（joint execution）比单仓依次执行更能利用跨仓库信息纠错，而单仓模式只会"补漏"不会"翻案"。

解决的真问题

Coding agent 评测自 2024 年起已经历两波迭代：

  1. 单 issue 修复：SWE-bench / SWE-bench Verified 起步，盯单仓单 PR；
  2. 长视野开发：跨多轮 / 多文件 / 多 PR，但仍在单仓。

但现实软件生态里，一个 feature 或一个 bug fix 往往要跨多个仓库协同改动：

  • 例：客户端 SDK + 服务端 API + 文档仓库同时改；
  • 例：上游依赖 patch + 下游使用方适配补丁同步发版；
  • 例：核心库 deprecate API + 周边插件 + 迁移工具同时更新。

这种跨仓库任务在 SWE-bench 这类单仓基准里几乎完全缺位，原因有三个：

  1. 数据采集难——跨仓库 PR / issue 的因果对齐需要人工审核；
  2. 评测难——hidden tests 跨仓库要保持"等效正确实现"；
  3. 失败模式分层难——agent 是"漏改"还是"改错"还是"改了但没满足需求"难以区分。

WideSWE 把这三件事一次性做了。

核心方法

1. 任务构建 pipeline

四步构造 120 个真实跨仓库任务：

  1. 生态筛选：从 103 个软件生态（含 monorepo 拆分、多仓协同、企业 OSS 等）采样；
  2. change mining：从 GitHub 历史里挖"涉及 ≥2 个 repo 的协同 PR / commit"；
  3. 人工 review：每个候选任务由研究者审核，确认跨仓必要性 + 改动的最小集；
  4. hidden tests 适配：为每个任务写隐藏测试，要求"支持多种正确实现"且"回归测试必须通过"。

任务配比：

类型 数量 说明
Bug fixes 60 修复类，需跨仓库
Features 60 新功能类，需跨仓库
合计 120 平衡配比

prompt 来自相关 issue / PR 描述（经过脱敏与适配）。

2. Agent 配置

abstract 提到"seven agent configurations"，覆盖主流闭源 / 开源 + 工具链组合：

  • Codex CLI + GPT-5.6-sol：42.50%（最强）；
  • 其余六组散布在 10.83%~略低于 42.50% 区间；
  • 最低 10.83%——意味着哪怕有 SOTA 基座，跨仓库任务仍是少数能完成的事。

3. 失败模式分类

通过对失败 trajectory 做归类，作者识别三类失败：

  1. 未识别必要改动：根本没发现该改的跨仓文件；
  2. 识别但未完成：看到了要改，但没把改动 commit 完；
  3. 改了但未满足需求：动了相关仓库，但 hidden tests 没全过——> 错误实现 / 不完整实现。

4. 关键对照实验：单仓 vs 联合执行

动机：跨仓库任务失败，是因为 agent 不会"跨仓推理"，还是单纯因为"提示里信息太多处理不过来"？

实验：同一组 prompt，分别让 agent "一次一个仓跑" vs "一次性跨多仓跑"。

关键发现：

执行模式 行为特征
单仓依次（Independent execution） 主要"补漏"——把前一轮漏掉的改动补上；但对"已尝试但失败"的实现缺乏纠错能力，会反复重蹈覆辙。
联合执行（Joint execution） 能利用其他仓库的信息来指引当前仓库的实现与验证——实现细节可跨仓参考，回归测试可跨仓对齐。

直觉解读——独立模式像"分头干最后拼"，联合模式像"边对齐边干"。联合模式才能纠错，独立模式只会补漏——这是对 agent 工程实践有直接指导意义的结论。

关键实验与数据

配置 全任务成功率（abstract）
Codex CLI + GPT-5.6-sol 42.50%（最强）
其余六组 10.83% 起
任务总数 120（60 bug fixes + 60 features）
任务来源 103 个软件生态

诚实标注：abstract 未公开： - 其余六组配置的具体模型与工具链组合（仅说 "seven configurations"）； - 任务难度分层后的成功率（按仓库数 / commit 数 / LOC 切分）； - 三类失败模式的占比（仅定性给出，未给百分比）； - 单仓 vs 联合实验的对照配置名称与提示构造细节； - 评测时每个任务的 token 消耗 / 工具调用次数 / 时间分布。

这些只能在 PDF §5 拿到，本文不臆测。

亮点

  1. 首个跨仓库 coding agent 基准：补 SWE-bench 系列"只看单仓"的盲区。
  2. 真实任务而非合成：从 103 个生态挖出的 120 个任务，最小化"为 benchmark 而 benchmark"的人为偏差。
  3. 双轨任务配比：bug fix 与 feature 各 60，避免"全是修 bug"或"全是加 feature"的能力偏向。
  4. hidden tests 支持多解：测试设计允许"等价正确实现"共存，比 SWE-bench Verified 的"必须字符串完全匹配"更贴近真实软件生态。
  5. 执行模式对照实验：单仓 vs 联合的二分对照是工程级洞察，不是单纯跑分数。
  6. GitHub 已开放：仓库 ZJU-ACS-ISE/WideSWE（⚠️ abstract 给出链接，需到 README 核实任务 / 评分脚本完整性）。

局限

  1. 120 个任务对小模型 / 长尾研究不足：跨仓任务天然少，统计 power 偏弱，可能让"差距 1-2 个任务"的小幅领先难以分辨。
  2. 任务偏 PR-level 而非 release-level：跨仓发布协调（semver / changelog / 同步发版）这种"运维"维度没覆盖——这是真实软件生态的高频痛点。
  3. 三类失败模式定性：没有给出可量化的失败 taxonomy（如每类失败的 PR / token / 时间分布），后续若要做"agent 升级前后失败模式迁移"，本文的对照粒度不够。
  4. 仅七种 agent 配置：开源 agent（如 SWE-Agent + open models + 自带工具链）覆盖偏少，对"非 GPT/Claude 阵营"的可推广性需 PDF §5 补充。
  5. 回归测试覆盖度未量化：hidden tests 数量 / 覆盖率 / 跨仓一致性需要 PDF 实验节披露。
  6. GitHub 仓库状态：abstract 给了 https://github.com/ZJU-ACES-ISE/WideSWE 链接（⚠️ 落地前需 fetch README 核实任务 release / scoring script 是否完整）。
  7. 执行模式对照的"提示构造差异"：单仓 vs 联合的提示是否等长 / 等信息密度未提，对照公平性需 PDF 补充。

对工程落地的启发

  • 真业务场景里跨仓改动是常态：评估自家 coding agent 时只跑 SWE-bench 是远远不够的——必须加 WideSWE 这一档。
  • 联合执行是默认选项：单仓依次执行看上去"更可控"，但 abstract 已证它只能补漏不会翻案；生产 agent 必须支持"跨仓 context 共享"。
  • 多解兼容测试比字符串匹配更接近业务：内部 SWE 基准建设应抛弃"必须 diff 完全一致"，改为"行为等效"测试。
  • 失败模式必须分类监控：未识别 / 未完成 / 不满足三类是三种不同的工程问题，对应"检索能力 / 工具稳定性 / 需求理解"三种修复方向。

五个落地坑点（现象 / 影响 / 修复）

  1. 只跑 SWE-bench 不跑跨仓 - 现象：团队把 SWE-bench Verified 当 coding agent 唯一 KPI。 - 影响：上线后遇到跨仓需求直接崩，benchmark 与生产严重脱节。 - 修复：内部 CI 加 WideSWE 这一档 + 真业务跨仓任务，至少 30 个 / 月。
  2. 单仓依次模式被默认为"安全模式" - 现象：为了"可控"，把 agent 限制为"一次一个仓跑"。 - 影响：仅能补漏，遇到已失败实现无法纠错（abstract 实证）。 - 修复：默认走联合执行，仅在"仓间无信息耦合"时切单仓；切换前必须有数据支持。
  3. 失败模式混在一起统计 - 现象：失败率只看"是否成功"，未拆"未识别 / 未完成 / 不满足"三类。 - 影响：agent 升级可能把一类失败迁移到另一类，整体失败率不变但工程含义变了。 - 修复：每类失败独立计分 + 趋势图，回归测试必须有跨类分布对比。
  4. hidden tests 必须字符串 diff - 现象：内部评测只看"diff 是否完全匹配参考 patch"。 - 影响：把"实现风格不同但等价"的正确答案判为失败，挫伤模型。 - 修复：测试改为"行为等效"——给定输入序列断言输出与不变量。
  5. 跨仓任务数据收集一次性投入 - 现象：花一个月挖 120 个任务就完事。 - 影响：基准静态化，半年后与真实生态脱节。 - 修复：建立季度数据回流机制，把新出现的跨仓 PR 持续纳入；同时标注难度档位变化。

与同方向工作的关系

  • SWE-bench / SWE-bench Verified：单仓基线，本文在"跨仓"维度做正交扩展，不替代。
  • SWE-bench Multimodal / SWE-Gym：训练用 + agent loop 优化，与本文"跨仓"互补。
  • RepoBench / RepoCoder：跨文件但仍单仓，本文跨仓库维度更高。
  • Long-horizon agent 评测（如 GAIA / HumanEval-Plus）：跨任务但跨工具链而非跨仓库，与本文互补。
  • RAG for code（如 GraphCoder / RAGAS-Code）：提升检索能力可缓解"未识别必要改动"类失败，与本文失败模式分类有直接耦合。
  • Multi-agent code collaboration（如 ChatDev 编程版 / MetaGPT）：理论上联合执行能借鉴，但 WideSWE 给出的是对照证据而非新方法。
  • Software ecosystem research：与"开源软件依赖网络 / coordination cost"研究有交集，但本文是首次把它量化为 agent benchmark。

适合谁读

  • Coding agent 框架作者：想让自家框架在跨仓场景下不被"补漏模式"卡死。
  • 企业 DevOps / SRE 负责人：关心"AI 自动跨仓升级"能不能上生产。
  • Agent evaluation 研究者：跨仓基准的开创性工作，值得做正交扩展。
  • AI + 软件工程研究者：把"软件生态学"和"agent 评测"嫁接的新方向。
  • 不适合：只想看 SWE-bench 涨几个百分点的"刷榜型"读者——本文结论偏系统性洞察，不是单点涨分。

诚实标注与待核

  • ❓ GitHub 仓库 ZJU-ACES-ISE/WideSWE：abstract 给了链接，需 fetch README 核实任务 release / scoring script 完整性。
  • ❓ 其余六组 agent 配置的具体模型与工具链：abstract 仅说 "seven configurations"，需 PDF §5。
  • ❓ 任务难度分层（按仓库数 / commit 数 / LOC）下的成功率分布：abstract 未给。
  • ❓ 三类失败模式的占比：abstract 仅定性，需 PDF。
  • ❓ 单仓 vs 联合的对照提示构造：是否等长 / 等信息密度 / 等 token 上限——需 PDF 核实对照公平性。
  • ❓ hidden tests 数量 / 覆盖率 / 跨仓一致性：abstract 未披露。
  • ❓ 评测 token / 工具调用次数 / 时间分布：未披露，部署侧成本估算需自测。