WideSWE：编码智能体能跨仓库协调变更吗？

TL;DR WideSWE 是首个跨仓库编码代理基准，从 103 个生态系统中挖掘 120 个真实任务，最佳配置成功率仅 42.50%，揭示代理在多仓库协调更改上的显著挑战。

问题

问题背景

编码代理评估已从解决单个 issue 演进到执行长期开发任务，但主流基准（如 SWE-bench）仍将任务限定在单一代码库内。

现有方法局限

真实软件生态中，功能开发与缺陷修复经常需要跨多个仓库协调变更，例如修改库的 API 后必须同步适配所有下游消费者。现有基准无法暴露代理在这种分布式场景中的能力缺口：

• 代理可能只修改了核心仓库，遗漏依赖方的适配；
• 或在不同仓库间引入了不一致的契约（如类型、序列化格式）；
• 隐藏测试若设计不当，会错误惩罚符合意图但实现方式不同的补丁。

为什么难且重要

跨仓库任务要求代理同时管理多个工作区、理解仓库间的接口契约，并在缺少单一集成测试的情况下验证全局正确性。这比单仓库任务多出依赖发现、变更传播、跨仓库验证三重负担。业界对 polyrepo 与 monorepo 的争论、微服务治理、库维护等场景，都直接依赖这类能力。若编码代理无法可靠协调跨仓库修改，其实际落地价值将严重受限。

行业类比

类似在微服务架构中升级一个共享库的接口，代理必须同时更新所有下游服务的调用代码，并确保端到端 CI 通过，否则部署即中断。

核心洞察

• 跨仓库协调任务暴露单仓库基准无法捕捉的工程协作复杂性。**WideSWE** 从 103 个真实软件生态挖掘 120 个跨仓库变更（bug/feature 各半），提示来自关联 issue/PR，隐藏测试经人工审查放宽实现特定约束。与 SWE-bench 等单仓库 benchmark 相比，代理必须理解多仓库间 **API 契约**、版本兼容与变更传播。实验显示最佳配置 `Codex CLI + GPT-5.6-sol` 仅 42.50% 完全成功率，且大量失败是“改了仓库但未满足契约”，说明跨仓库契约验证是当前代理的关键短板。
• 联合执行与独立执行的对比证实跨仓库上下文对实现与验证均有增益，但独立执行可恢复遗漏工作。该实验用相同提示比较两种模式，发现独立执行能补全联合执行中遗漏的仓库修改，却难以修正已尝试但未成功的实现；联合执行则能利用关联仓库信息指导实现（如 Ansible 案例）和验证下游状态。这为设计多仓库编码代理架构提供证据：应支持 **跨仓库上下文共享**，同时引入轻量 **工作区隔离** 以降低认知负载。

方法

WideSWE 的输入是真实跨仓库任务，从 103 个软件生态系统中挖掘并审查跨多个代码库的变更，筛选出 120 个任务（60 个 bug 修复 + 60 个功能实现）。每个任务提供关联 issue 和 pull request 作为提示，以及历史工作区快照。

关键模块包括：

1. 生态系统与变更挖掘：扫描软件生态，识别需要协调修改多个仓库的提交序列，确保任务真实性。
2. 提示构建：从相关 issue/PR 提取自然语言描述，明确需要改动的仓库和期望行为。
3. 隐藏测试构建与审查：继承上游测试，人为审查并放宽实现特定约束，同时保留回归检查，以支持不同但正确的实现；测试隔离避免补丁冲突。
4. 评估协议：将 agent 置于多仓库工作区，可采取 joint（同时处理）或 independent（逐个仓库）执行模式，最终用隐藏测试判定 full task success。

输出为 WideSWE 基准，包含任务、初始快照、测试和评估脚本，用于量化 coding agents 的跨仓库协调能力。实验显示，最先进配置（Codex CLI + GPT-5.6-sol）仅达 42.50% 成功率。

与 SWE-bench 等单仓库基准的差异在于：WideSWE 要求 agent 在多个相关仓库间保持变更一致，任务成功依赖于所有涉及仓库的正确修改，而不仅是单个代码库内的 issue 解决。

实验

实验设计

WideSWE 基准包含 120 个真实跨仓库任务，来源于 103 个软件生态系统，其中 60 个 bug 修复 与 60 个功能开发 平衡。任务 prompt 从相关 issue 和 PR 派生，隐藏测试经人工审查适配，既保留必要行为与回归检查，又允许多样化正确实现。评估指标为 完整任务成功率，同时对比 联合执行（单次处理所有相关仓库）与 按仓库独立执行 两种模式。共评测 7 种 agent 配置，包括不同 CLI 与模型组合。

关键发现

完整任务成功率介于 10.83% 至 42.50%，最优配置为 Codex CLI + GPT-5.6-sol。轨迹分析揭示三类典型失败模式：

1. 未能识别所需的跨仓库变更；
2. 识别到变更但未完成实现；
3. 修改了必需仓库但未完全满足请求。

独立执行主要能补偿联合执行中遗漏的工作，但对修正之前尝试过但不成功的实现效果较差；联合执行则能利用相关仓库的信息来指导实现与验证，尤其在需要跨仓库接口对齐时表现更好。

与基线对比解读

这里没有传统意义上的单一 baseline，而是配置间横向对比。最高配置比最低配置高出约 32 个百分点，说明模型与工具链选择对跨仓库任务影响显著。但即便最优也只有 42.50%，远低于单仓库任务上常见的高成功率，凸显跨仓库协调的核心难点：agent 必须在多个代码库之间维护一致的接口契约、依赖关系与状态传播。联合执行在需要信息共享时胜出，但单次工作区过大也会引入上下文噪声；独立执行降低单次负载，却缺乏跨仓库验证能力。工程上提示：未来 agent 设计需平衡全局上下文与局部聚焦，并强化依赖图谱感知与跨仓库验证循环。

行业影响

落地场景

WideSWE 直接适用于 多仓库 / 微服务 / SDK-插件生态 下的 AI coding agent 评测与研发。典型场景包括：

• 电商平台：新增支付方式需同时改 checkout 服务、风控服务、订单状态同步；
• 内容平台：上线新 DRM 策略要改播放器 SDK、后端授权接口、数据上报管道。 对 GitHub Copilot / Codex CLI / Claude Code / Cursor 等工具，WideSWE 能作为跨仓库任务的补充基准，暴露“只改单仓”类 agent 的盲区。

商业价值

• 降本：减少跨仓库集成失败与人工补漏，加速 feature / bugfix 交付；
• 增收：提升 AI coding 助手在复杂企业级任务中的成功率，推动订阅 / 席位采购；
• 体验提升：让 agent 在真实软件生态中从“能写单仓 PR”进化到“能协调跨仓变更”，降低开发者 review 负担。 论文数据显示最佳配置 Codex CLI + GPT-5.6-sol 也只有 42.50% 成功率，说明仍有明确优化空间和商业壁垒。

与现有工作流接口

• 可把 WideSWE 评测集接入 agent 开发的 CI / eval harness，与 SWE-bench 类单仓基准并列运行；
• 使用其 hidden tests 与 prompt 构造流程，作为企业内多仓库项目的回归测试模板；
• 参考论文 joint vs independent execution 结论，在 agent 编排层加入跨仓库上下文共享 / 任务拆分策略，而不是简单逐仓执行。

局限

• **任务规模与生态覆盖有限**：WideSWE 仅包含 120 个任务，来自 103 个软件生态系统，相比 SWE-bench 系列数千个单仓库任务，样本量较小。虽然经过人工筛选保证质量，但对跨仓库协调这一长尾场景，覆盖的编程语言、仓库类型和协调模式可能仍不够全面，模型的失败模式可能受限于所选生态，泛化到其他真实跨仓库场景时结论可能偏差。
• **评测配置与模型选择偏窄**：实验仅评估了 7 种 agent 配置，且最佳结果来自 Codex CLI 搭配 GPT-5.6-sol，其他流行 agent 框架（如开源 Devin、SWE-agent 等）未纳入。此外，隐蔽测试的构建依赖人工审核和修改，虽有系统化流程，但仍可能引入主观偏差，且对多样正确实现的覆盖未必完备。在评估 open-ended 跨仓库任务时，单一测试集可能低估 agent 的能力。
• **独立性 vs 联合执行的分析尚不充分**：论文比较了独立执行和联合执行，但仅基于相同 prompt 的粗略对比，未系统探索不同协调策略（如显式规划、增量提交等）对结果的影响。独立执行下每个代理对单个仓库的上下文仍可能遗漏跨仓库约束，而联合执行的长上下文与多仓库信息混杂也可能引入新困难。该权衡缺乏更精细的控制变量实验，对实际工程中如何组织多仓库改动指导有限。