本文为三篇论文合并精读：论文一《WideSWE: Can Coding Agents Coordinate Changes Across Repositories?》（arXiv 2609.33382）；论文二《AsynCodeBench: Benchmarking Collaboration of Asynchronous Multi-Agent Systems in Software Engineering》（arXiv 2609.32662）；论文三《RepoMAS: Solving Progressively Specified Tasks with Issue-Driven Multi-Agent Systems》（arXiv 2609.32490）。三篇各覆盖解法与证据，最后合并讨论。

总题目区

论文一：arXiv 2609.33382 | 代码仓库 | 2026 年 9 月 | 浙江大学（第一单位，Baoyi Wang 与 Xingliang Wang 共同一作，Chen Zhi 通讯）+ 清华大学 | cs.SE 论文二：arXiv 2609.32662 | 代码仓库 | 2026 年 9 月 | University of Houston（主导）+ NYU + Texas A&M + UCSD + Worcester Polytechnic + Oregon State，六校纯学术合作，无企业参与 | cs.SE 论文三：arXiv 2609.32490 | 代码待论文录用后发布 | 2026 年 9 月 | 哈尔滨工业大学（计算机学院，Muyun Yang / Tiejun Zhao 团队），单一高校 | cs.AI

一、论文背景：SWE-bench 范式的三大盲区

要从「是什么」讲起。SWE-bench 是 2023 年提出的软件工程 Agent 基准范式：从真实 GitHub 仓库取一个已解决的 issue，给 Agent 仓库快照和 issue 文本，让 Agent 改代码，再用两组隐藏测试判定——**F2P（fail-to-pass）**测试在原代码上失败、在参考修复后通过，验证「问题被修复」；**P2P（pass-to-pass）**测试在前后都通过，验证「没改坏别的」。这套「仓库 + issue + 隐藏测试」的范式演化出 Verified、Multilingual、Pro、SWE-rebench 等一整个谱系，成为衡量编码 Agent 的行业标准。

但这个范式隐含三个假设，而它们在真实软件工程中都不成立。

假设一：工作单元是一个仓库（空间维度）。真实软件以生态形式存在——Sentry 的一个功能要同时改 Go、Python、Ruby 三个 SDK 仓库；Kubernetes 的生成器迁移要连着改 kube-openapi 和它的消费者。WideSWE 统计了 GitHub top200 组织的 103 个活跃生态、1,729,171 个已合并 PR，其中 109,233 条（6.3%）显式引用同生态的另一个仓库——跨仓库变更是普遍实践而非边角案例。单仓库基准里「仓库级进度 ≈ 任务成功」，跨仓库场景下这个等式被打破。

假设二：工作单元是一个 Agent（协作维度）。多 Agent 系统已把规划、实现、测试、协调分给不同角色，但评估仍沿用单 Agent 的终态测试通过率。这带来一个测量学问题：终态分数把「个体编码能力」和「跨 Agent 协调能力」混为一谈——测试失败可能因为代码写错，也可能因为下游 Agent 还在用过期的上游接口。AsynCodeBench 把后一类称为「异步协调问题」（asynchronous coordination problem）：各 Agent 独立推进、互不等待，依赖错配在集成时才爆发，而终态评估只能看到「任务失败」，看不到是哪条依赖断在了谁手里。

假设三：需求在任务开始时已完整给定（时间维度）。用户通常几句话描述目标，不少需求只有走到某一步才显形——评论数据里「有些评论没有评分」「评论混着多个产品」这类约束，不读数据不可能知道。RepoMAS 称之为渐进式指定任务（progressively specified tasks）：缺失需求只能经由推理、检索证据、工具使用或执行反馈显现，且发现后要同时修订「任务理解」和「执行结构」。传统 MAS 把任务规格当固定输入，只能把新发现塞进执行反馈，规格与执行结构逐渐脱节。

一个佐证这三大盲区并非纸上谈兵的外部事实：OpenAI 在 2026 年 2 月宣布停报 SWE-bench Verified，审计发现最难未解任务中约 59.4% 存在测试缺陷或欠定提示；随后推荐的 SWE-bench Pro 也在同年被其复审估计约 30% 任务有问题（OpenAI 博客）——「单人单次规格」的基准构建本身已在承压，而三篇论文各自把其中一个假设推到了可执行的实验设定。

二、论文定位和关联工作

三篇论文分别站位于三条谱系的延长线上。

谱系一：SWE-bench 谱系（WideSWE 的坐标系）。从 SWE-bench 出发，Multi-SWE-bench / SWE-PolyBench / SWE-bench Multilingual 扩语言，SWE-bench Pro / SWE-EVO / DeepSWE / ProgramBench 拉长时程——但它们都在「一个仓库内做更大的事」。最接近的先行者是 BeyondSWE 的 CrossRepo 任务：在目标仓库解 issue 时可引用外部仓库的代码和解法——外部仓库只是参考，唯一被评分的目标仍是单仓库。WideSWE 的关键区分：多个仓库都是被评分的目标，全部通过才算任务成功。生态协同本身也有经验软件工程研究（Blincoe 的 Reference Coupling、Ma 等人的跨项目缺陷追踪、Begel 的工业协调研究），但都是研究人类开发者；WideSWE 把这些真实跨仓库变更变成了可执行任务。

谱系二：多 Agent 软件工程与协作度量（AsynCodeBench 的坐标系）。ChatDev、MetaGPT、RTADev、CodeTeam 把角色分工做成了系统；MAST（UC Berkeley，arXiv 2503.13657）用 14 种失败模式的分类学证明 MAS 失败多在协调而非编码；SyncMind 定义了「信念状态与世界状态脱节」的失步恢复问题；CooperBench（Stanford 等，arXiv 2601.13295）发现「协调诅咒」——两个 Agent 分工协作比单 Agent 独自完成两个特性成功率掉一半。AsynCodeBench 与它们的差别在于度量对象：MAST/CooperBench 从失败分析和终态成败切入，AsynCodeBench 直接把「跨 Agent 依赖是否被满足」变成预注册、可执行、逐 checkpoint 追踪的一等评测单元。

谱系三：动态规划与欠定规格 MAS（RepoMAS 的坐标系）。MetaGPT 把 SOP 编码进提示序列；AFlow（arXiv 2410.10762）用 MCTS 自动搜索工作流；MaAS/AutoAgents 按任务生成架构；Evolving Orchestration / AgentConductor 在执行中调整 Agent 组织。基准侧，SpecBench 测软件设计提案中的缺漏歧义，SWE-Together / ICAE-Bench 靠用户交互中途补充需求。RepoMAS 的区分点：需求恢复必须自主从执行证据中获得（不经用户澄清），且同时修订任务规格（Task Draft）与两个结构图（Task Graph / Agent Graph），并在验证后局部重执行。

定位结论：三篇论文不是同一条路线的递进，而是从三个正交维度各自捅破了「单仓库、单 Agent、单次规格」假设的一角，合并起来勾勒出下一阶段软件工程 Agent 评估的完整坐标。

三、问题定义：三维抽象

把三篇论文的具体场景剥掉外壳，会得到同一个母题的三种投影：当成功判定的「耦合单元」从单一组件扩大到多个组件时，Agent 必须维护的不只是代码，还有组件间的一致性与需求本身。

WideSWE 的形式化：任务 c 有请求 p_c 和历史工作区 W_c（含仓库集 R_c），目标仓库集 T_c ⊆ R_c（|T_c|≥2）是需要实质修改的被评分对象。Agent 产出补丁集合 Δ_c = A(p_c, W_c)，任务成功当且仅当每个目标仓库 r 的全部 F2P+P2P 测试通过：

Success(c) = ∏{r∈T_c} y{c,r}(W’_c)

连乘判定的含义：任何一个仓库失败，整任务归零。120 个任务里有 96 个（80.0%）是生产者—消费者依赖（一个仓库提供能力、接口或 schema，另一个消费），24 个（20.0%）是并行传播（多个仓库实现同一行为，如多语言 SDK）。

AsynCodeBench 的形式化：基准 B = (R, G, C, E)——仓库与任务 R、预注册有向依赖图 G=(V,A)（上游生产者→下游消费者）、每条依赖 d 的三组可执行 Boolean Checker（上游 C^U / 下游 C^D / 集成后 C^I）、评测 E。在集成 checkpoint 序列 t=1..T 上记录每条依赖的满足轨迹 I_d = (I_{d,1},…,I_{d,T})。两个新指标从中自然导出：ADPR（最终满足的依赖比例）与 DRS（首次通过的 checkpoint）。抽象地说：它把「协作」从不可观测的整体行为分解为可执行的二元谓词随时间的轨迹——于是「从未解决 / 晚解决 / 解决后回退」第一次可区分。

RepoMAS 的形式化：初始请求 q 的理想需求集 R* 中只有 R_vis ⊆ R* 被显式给出；系统在仓库版本 t 维护已识别需求集 R̂_t，随执行从 R̂_0 逐步精化为 R̂_T。子问题是何时修订什么：需求变更必须同时传导到 Task Draft（当前理解）、Task Graph H_t（子任务及依赖）、Agent Graph G_t（角色组织）与映射 M_t——共享任务仓库 S_t = (D_t, H_t, G_t, M_t, I_t, A_t) 是全部状态的单一事实源。

三者的精妙互补：WideSWE 把空间耦合（跨仓库）变成连乘判定；AsynCodeBench 把行为耦合（跨 Agent 依赖）变成图上谓词；RepoMAS 把时间耦合（需求演进）变成可修订状态。三者共同指出：评测单元必须从「单个工件」升级为「耦合结构」。

四、问题解法

4.1 WideSWE：生态挖掘 + 需求对齐的测试修订 + 联合/独立执行对照

基准构建流水线（类比：从矿山到标准矿石的选矿流程）。第一层是生态与变更挖掘：从 Gitstar Ranking top200 组织中选出 103 个活跃生态，收集 2024 年以来合并的 1,729,171 个 PR，用显式跨仓库引用链接筛出 109,233 条记录，分组去重、检查 PR 可用性/测试变更/Linux 兼容性后得 4,437 候选组。第二层是案例筛选：聚焦最新 PR 合并于 2025-06-01 之后的 2,188 组，人工评审保留 635 组「确属同一需求且多仓库需实质修改」的组（偶发引用不算），可执行验证（每个目标仓库至少一个 F2P）得 192 个合格案例，最终平衡为 120 任务（60 bugfix + 60 feature），覆盖 41 生态、253 个目标仓库、2,815 F2P + 22,139 P2P 测试。第三层是提示与隐藏测试构建：提示从原始 issue/PR 文本尽量保留措辞地合并而成；隐藏测试从参考补丁提取，并经需求对齐的测试修订。

测试修订的两条规则值得单独讲，因为它们回应了基准构建的普遍痛点：(1) 放宽实现特定约束——有些测试要求特定私有辅助函数名、固定文件路径或错误消息精确文本，任务并未要求这些选择，删掉这些限制但保留必需行为与既有接口契约（例如 TensorDict 的测试保留「抛 TypeError」但删掉「错误消息含 ‘generator must be’」）；(2) 删除未要求的功能检查——参考补丁顺带引入的功能若 issue/PR/提示均未要求，其测试移除。修订后验证测试套件仍拒绝原始代码、接受参考解。

评测设计上的第二件武器是联合 vs 独立执行对照：联合执行（Joint）在包含全部仓库的生态工作区一次跑完；独立执行（Independent）对每个目标仓库各跑一次完整会话，全部成功才算任务成功（89 个提示在两种设定下完全一致的任务上对比）。这个对照实验等于在问：跨仓库失败到底是「范围太大看不过来」还是「需要跨仓库信息」——若是前者，缩小范围应普遍变好。

4.2 AsynCodeBench：依赖图 + 三组 Checker + 五协议矩阵

依赖图的构造纪律（类比：施工前的管线图会审）。每个任务的实现单元为节点 V，有向弧 d=(u,v) 表示消费者 v 的正确性依赖生产者 u 提供的行为/状态/接口。弧的准入不靠文件共现或任务分解推断，而要有仓库证据（源码、被引用符号、可用公开测试）支撑；三方人工独立验证每条弧的方向与证据后才冻结——评测前冻结防止模型行为反过来影响哪些依赖被纳入。最终 19 个任务（16 仓库）、64 个实现单元、52 条有向依赖，覆盖框架库、系统存储、编译器 IR、网络协议、安全五域。

三组 Checker 的分工：C^U 查生产者是否提供了所需行为，C^D 查消费者是否正确使用/保留它，C^I 查集成后依赖是否成立——上下游两组提供诊断证据，集成组决定依赖轨迹 I_d 的取值。checkpoint 按事件触发构造：专家在私有工作区产出制品、尝试集成、管理者介入、最终评估，每个集成点都对全部依赖跑一遍 Checker，得到有序轨迹。

五协议矩阵是实验设计的关键：SINGLE（单 Agent 全任务）→ SERIAL（专家分工但上下游按序交接）→ ASYNC-PRIVATE（同分工但专家并行、私有工作区互相看不到在途修改）→ ASYNC-MANAGER-RO（加只读管理者协调集成）→ ASYNC-MANAGER（管理者还可有界修复）。SERIAL 与 ASYNC-PRIVATE 的对比在同分工下隔离了异步性本身的影响；两个管理者协议分离「信息交换式协调」与「直接代码干预」。所有协议用同一 OpenHands harness 与 Docker 环境、同一批开源权重模型（9B dense 到 284B）。

4.3 RepoMAS：结构化 Issue + 补丁式仓库修订 + 局部重执行

核心类比：把开源项目管理的工作流搬进 Agent 系统内部。开源项目面对的恰是「需求逐渐显形」的世界——用户报 issue、维护者确认、打补丁、评审合并、回归测试。RepoMAS 的循环与之同构：

1. 仓库状态初始化：初始请求解析为 Task Draft D_t =（已知需求 R̂_t、预期输出、验证标准）；分解为 DAG 形式的 Task Graph H_t（节点是子任务，每条需求显式链接到负责它的子任务）；Agent Graph G_t 描述当前角色与通信结构；映射 M_t 分配子任务给 Agent。六元组 S_t = (D_t, H_t, G_t, M_t, I_t, A_t) 构成共享任务仓库。
2. 证据转 Issue：执行中的工具结果、Agent 消息、前序结果若暴露新需求/冲突/失败，先记为结构化 Issue I_i = (τ_i 类型, κ_i 受影响组件, φ_i 问题描述, e_i 支撑证据)——先记录、后修复，且相关 Issue 分组到修复分支隔离于已接受状态。
3. 补丁生成与验证：候选补丁 P_B = (ΔD, ΔH, ΔG, ΔM) 指定对四个组件的修改。验证器对照当前仓库状态、目标 Issue 及其证据审查「是否解决了对应 Issue、与任务需求是否一致」，拒绝的可修订重提（这一步模仿 code review + merge gate）。
4. 合并与局部重执行：接受后仅重执行受影响子图 V_re = C(P_B) ∪ Desc(C(P_B))（直接受影响节点及其下游），未受影响的结果在输入/需求/生产 Agent 均未变时复用。

精妙之处在于「证据字段 e_i 不可省」与「两图同步修订」：没有证据字段，验证器无判定依据；只改 Task Graph 不改 Agent Graph（或反之）会让执行结构与规格不一致——消融实验里两者任缺其一都掉到 25.8 分，比两个都改的 30.3（去全部结构修订）还低。

五、评估指标与实验证据

5.1 WideSWE：42.50% 的天花板与 83.33% 的单仓进度

主指标是 Case 级任务成功率（全部目标仓库通过全部 F2P+P2P），辅以 Repo 级成功率、F2P/P2P 完成率、平均 API 请求数。七种配置（Codex CLI + GPT-5.6-sol 高推理，以及 Claude Code 分别配 GPT-5.6-sol / Claude Opus 5 / Gemini 3.8 Flash / DeepSeek V4 Pro / Qwen 3.8 Max / GLM 5.3）在相同 harness 权限、超时与资源限制下评测。

核心数字：任务成功率区间 10.83%–42.50%，最高为 Codex CLI + GPT-5.6-sol（整体 42.50%，Repo 63.64%，F2P 65.61%，P2P 90.95%，平均 86.7 次 API/任务）。最有信息量的一对数字：该配置至少解决一个目标仓库的任务占 83.33%，与全解 42.50% 之间 40.8 个百分点的沟壑，就是「跨仓库协同」被精确量化的部分。失败三分类（该配置）：范围识别不全 37.68%、识别但未交付 2.90%、编辑后仍失败 59.42%。

几个机制性发现：(1) 失败模式因模型而异——Gemini 52.34% 的失败是「识别但未交付」（其中 82.14% 停留在调研/规划/准备阶段，如 Elastic Agent 任务明确规划了客户端压缩与服务端支持却始终不实现）；Qwen/Opus 的失败则以「编辑后仍错」为主（73.33%/67.95%）。(2) 同模型换 scaffold 有实质差异——GPT-5.6-sol 从 Codex CLI 换到 Claude Code，成功率 42.50%→32.50%，API 请求反而 86.7→134.8。(3) 仓库数增加主要打击协同而非覆盖——三仓任务上 Repo 成功率反而升（63.08%→66.67%），失败的三仓任务 87.5% 改了全部目标、62.5% 解出两个，说明覆盖得住、协调不动。

联合 vs 独立执行（89 个同提示任务）：联合 40.45% vs 独立 35.96%，但内部结构比总分有趣——bugfix 独立更好（44.83% vs 34.48%），feature 联合更好（43.33% vs 31.67%）；独立执行 API 用量 3.13 倍（296.6 vs 94.7）却总分更低；22.47% 任务结局翻转。关键诊断：联合执行失败的仓库中，未被修改的仓库 60.00% 独立执行后成功，已修改但错的仓库只有 9.43%——独立执行能救回「被遗漏的工作」（如 Sentry 三 SDK 任务联合只完成 Go，分开跑三个全完成），救不回「错误的尝试」；而联合执行独有的价值是跨仓库参照与行为一致性校验（Symfony DeepClone 案例：联合运行发现 native 实现有一处 PHP 缺失的校验、比对纠正后 9/9+31/31 全过，独立运行则两边都留错）。

5.2 AsynCodeBench：TestPass 48.0 vs ADPR 18.8 的错位

主指标 ADPR（终态依赖满足率）+ DRS（归一化首次解决步），对照指标 TestPass（测试点通过比例）。190 个模型-任务结果（ASYNC-MANAGER-RO）呈现强不对称错位：TestPass>ADPR 占 71.6%，均值 48.0% vs 18.8%；32 个结果 TestPass≥80% 但 ADPR<50%，其中 26 个 ADPR=0；反向（低测试高依赖）一个都没有。这个设计证明力在于：它不是「我们的指标更严」，而是展示了一类终态评估系统性看不见的失败——多个测试失败其实源于同一条未闭合的依赖瓶颈。

Qwen 代际对照（27B 定规模看三代演进）是全文最有说服力的证据链：SINGLE 的 TestPass 42.1%→57.4%→93.6%、ADPR 12.3%→36.8%→77.2%，单调大涨；但 ASYNC-MANAGER 的 ADPR 31.6%→63.2%→64.9%——第三代近乎停滞。单体编码能力的代际提升没有按比例传导到协作能力。且多 Agent 并非免费午餐：10 个模型中 4 个（含 Qwen3.8-27B、DeepSeek-V4 两个单体最强者）最优协作协议仍劣于 SINGLE；Qwen3.6 同模型跨协议 ADPR 摆幅达 41.2 个百分点（-14.9% 到 +26.3%）。最严格判据下（全测试+全依赖）最终任务成功率多数配置为 0/19 到 7/19，仅头部模型 SINGLE 达 78.9%。

DRS 与 hopping window：依赖闭合并非线性积累——各协议 34.9%–67.8% 的最终闭合质量集中在归一化 0.50<x≤0.75 区间集中爆发（SERIAL 最高 67.8%）；40 个模型-协议配置中 28 个呈现该模式，且全部 16 个最终 ADPR≥20% 的配置都有集中爆发相，而 ADPR 低迷的配置轨迹全程平坦。Pareto 分析进一步显示 10 模型中 5 个在两指标下的成本-质量前沿成员不同——用哪个指标做采购决策会得出不同结论。

5.3 RepoMAS：ProgSpec 44.7 与 44.7→30.8 的消融

ProgSpec 基准：270 任务（Coding/Math/QA 各 90）、1,551 条原子需求按可及性分三级——L1 显式（360 条）/L2 隐式可推断（474）/L3 潜伏需执行发现（717，占 46.2%）；主指标加权覆盖率（权重 1/2/3，越高等级权重越大）。标注质量经 5 名独立研究生复审 500 条需求（有效率 95.4%，Gwet’s AC1=0.91）。

值得注意的反直觉背景：MetaGPT/LATTE/TacoMAS 等多个知名 MAS 在 ProgSpec 上低于单 Agent 基线——固定规格的 MAS 在渐进任务上不仅无益反而有害。消融链条完整：去结构化 Issue 44.7→30.8、去补丁验证 →33.4（HumanEval 99.2→84.0 最大跌幅）、去结构修订 →30.3、去局部重执行 →32.4；结构修订细分中去 Task Graph 修订或 Agent Graph 修订均降至 25.8（低于两图都不改的 30.3，证明半改比不改更糟）。Issue 表示消融：完整结构化 Issue 44.7 vs 直接修订 30.2 vs 自由文本 30.8 vs 无证据结构 27.5——结构与证据缺一不可。补丁验证实测 precision 62.5%/recall 86.2%，好补丁比例从修订前 13.8% 升至修订后 69.0%（拒改-重提回路本身在改善补丁）。需求构成上 L3 满足占比从单 Agent 的 19.6% 升至 24.4%；发现阶段分析显示 Coding 域 62.0% 的 L3 靠工具/验证器反馈发现、QA 域 82.9% 靠执行中发现——需求发现贯穿全程而非一次性前置。代价：平均 58.14K token/任务，约为单 Agent（2.50K）的 23 倍。

5.4 汇总对照

三个「证明力」检查：WideSWE 的连乘判定配合「至少一仓成功 83.33%」的对照，把「协同失败」从任务分数里剥了出来，而非简单报一个更低的分；AsynCodeBench 的预注册依赖图排除了「事后挑指标」的质疑，单/多 Agent 五协议同 harness 对比隔离了协作变量；RepoMAS 的 L1/L2/L3 权重设计让「渐进性」可量化，消融网格（表示 ×组件 ×双图）完整到可以反推每个机制的独立贡献。三篇也都诚实：WideSWE 承认失败分类含人工标注环节，AsynCodeBench 只有 19 个任务 52 条依赖（规模偏小），RepoMAS 的骨干 GPT-4o-mini 较旧且五个常规基准已近饱和。

六、效果优势的根源解释

6.1 为何「连乘判定」暴露范围缩窄：评测判据改变了信息价值结构

因果链（论文实验已支持的每步）：单仓库基准中「仓库级进度≈任务成功」，Agent 的局部测试通过信号与全局成功信号近似等价，因此训练与 scaffold 设计都在优化「让当前仓库的测试变绿」。连乘判定下两者解耦——局部绿灯只是全局的必要条件。此时两类被遮蔽的失败浮出：其一，Agent 收到「在 Go、Python、Ruby 三 SDK 实现同一特性」的请求后自问自答「目标是 Go SDK」，把三仓任务缩窄成单仓（Go 14/14、Python 0/22、Ruby 0/13）——这不是编码失败而是范围识别失败，单仓库评估永远不会惩罚它；其二，「本地测试通过即停」——Godot/Native 任务中 Agent 修完 Native SDK、304 个本地单测全绿就收工，明知（自己日志里写过）Godot 调用点要适配也不做。机制上：连乘判定使「未识别的仓库」具有与「识别但做错」同等的杀伤力，而前者在 Agent 的反馈信号里没有任何本地负反馈——只有评测器知道。这解释了为何 Post-edit failure 占 59.42% 之外，Scope error 高达 37.68%，也解释了为何独立执行只能救回未修改仓库（60.00%）而救不回已修改错库（9.43%）：缩小范围能弥补「没看见」，弥补不了「做错了」。

外部交叉验证：CooperBench 的「协调诅咒」（两 Agent 协作成功率比单 Agent 独做低约 30–50%，arXiv 2601.13295）从「人际分工」方向得出同构结论——把成功判据耦合到多个独立工作单元上，失败主要来自协调而非技能；MAST（arXiv 2503.13657）的三大失败类目（规格、Agent 间错位、验证）中「不遵守任务规格」占系统设计类 44.2%，与 WideSWE 的 Scope error 呼应。限定条件：WideSWE 的联合执行在 feature 上更优（43.33% vs 31.67%），说明跨仓库上下文的价值依赖任务类型——bugfix 的因果根因常常局部，缩小范围反而有利，不能一概说「联合必优」。

6.2 为何编码能力提升 ≠ 协作能力提升：两条能力被同一个指标误读

因果链：TestPass 类指标测量的是「实现进度」（各测试点的比例通过），依赖满足测量的是「跨组件契约闭合」。异步执行下，下游 Agent 基于初始仓库状态工作、看不到上游在途修改，若上游事后变更了接口语义，下游代码在它自己的参照系里仍然正确、测试也可能大半通过（尤其当测试多由下游局部驱动时），但集成后契约断裂。Qwen 代际证据的机制解读（此段含阅读者推测，论文未展开训练侧归因）：Qwen3.6→3.8 的单体 ADPR 大涨（36.8%→77.2%）主要来自「单个 Agent 在一个上下文里同时持有全部代码」时能力增强——这个增强路径不涉及「多上下文间的信息一致性维护」；而 ASYNC-MANAGER 协作需要的是后者（管理者读取制品、给出反馈、协调集成，各专家上下文仍旧分散），所以代际红利在协作侧衰减（63.2%→64.9%）。hopping window 进一步佐证协作的非线性：依赖闭合依赖「集成事件」触发（一次成功集成可以让一串依赖同时变绿），它不是随编码能力线性积累的量。

外部交叉验证：SyncMind（ICML 2025，arXiv 2502.06994）从「信念状态与世界状态脱节」的角度给出同族解释——Agent 各自的信念 B_k 偏离共享世界状态 S_k 时，Git 能查语法冲突却查不出语义不一致；其发现 Agent 协作意愿低（ASR≤4.86%）与 AsynCodeBench 的「协议效应大于模型效应」互相印证。相反方向的证据也要如实报告：AsynCodeBench 自己显示 6/10 模型的最优协作协议相对 SINGLE 有 +7.8%~+22.7% 的 TestPass 增益，CooperBench 也观察到人类双人组在同约束下 9/10 成功而 Agent 仅 3/10——说明协作能力并非不可获得，而是当前模型与协议未覆盖；结论的适用边界是「开源权重模型 + OpenHands harness + 该任务分布」，不宜外推到专有协作优化系统。

6.3 为何结构化 Issue 缺一不可：状态外化让「发现」可积累、可验证、可局部化

因果链（消融已支持）：自由文本记录 Issue 时，「发现了什么」的信息在后续 patch 生成中丢失或失真（30.8 分）；有结构无证据时，验证器无法对照证据裁决补丁是否真的解决了问题（27.5 分）——证据字段是验证器的判定依据，结构字段是 patch 的定位索引。四元组表示把「发现→修订→验证→重执行」变成可增量执行的状态机：需求显式链接到子任务使补丁影响可定位（V_re 只含受影响子图及下游），避免全流程重启；验证回路不仅是过滤器还是改进器（好补丁率 13.8%→69.0%）。更深一层（阅读者推测）：L3 需求 46.2% 的占比意味着近半需求的信息只存在于执行环境中，任何前置一次性规划（无论多强的模型）在信息论上都不可完备——RepoMAS 的优势不是「更聪明地猜需求」，而是把「猜错了可以便宜地改」制度化。两图同步修订的 25.8<30.3 反直觉结果也由此解释：半同步的结构比显式不同步更难被后续 Issue 正确定位——不一致被藏在「看起来部分更新过」的状态里。

外部交叉验证：OpenAI 对 SWE-bench Verified/Pro 的审计（官方博客）发现 18.8–35.5% 的审计任务存在「测试要求了提示从未说明的功能」——从基准侧证明「完整规格」假设系统性不成立，与 ProgSpec 的 L3 概念互为镜像（一个说基准欠定，一个说任务本身欠定）；MAST 将「不遵守任务规格」列为 MAS 首要失败类，RepoMAS 的 Issue 驱动规格修订正是对该类失败的直接工程回应。检索范围内未发现与「结构化 Issue 显式记录优于自由文本」直接矛盾的同题研究；最接近的反例是 AsynCodeBench 侧面提示的「管理者文本反馈不一定转化为依赖闭合」——但那是跨上下文一致性问题，不否定单系统内的状态外化价值。

6.4 综合判断与未决问题

多项研究共同支持的机制：(1) 成功判据耦合到多单元时，协调成为独立于技能的失败源（WideSWE × CooperBench × MAST × AsynCodeBench 四方一致）；(2) 终态指标系统性遮蔽过程性失败（AsynCodeBench 的 ADPR=0 而 TestPass≥80%；WideSWE 的单仓绿灯）；(3) 欠定规格是常态而非例外（ProgSpec 的 L3=46.2% × OpenAI 审计的欠定提示占比）。仍属推测的机制：Qwen 代际协作停滞的训练侧归因（本文只有行为层证据）；两图半同步比全不同步更糟的机制解释。适用条件：三篇的优势结论都建立在「可执行验证」存在的前提下（隐藏测试/Checker/验证器）；当验证器本身有缺陷时（OpenAI 审计所示约 30% 比例），连乘判定与依赖轨迹都会继承验证器的误差——这是三篇共同的未决依赖。

七、必要知识反推

假设一个完全没有背景的人要复现这三篇工作，最少必须掌握什么？

领域知识层。其一，软件生态的组织学：mono-repo 与 multi-repo 的取舍、依赖方向与版本耦合、生产者—消费者与并行传播两类协同模式——不知道这些就无法从 109,233 条 PR 链接里筛出 120 个合格任务（WideSWE 的 635→192 漏斗每一层都在靠这个判断）。其二，测试的语义：F2P/P2P 各自验证什么、实现特定约束与必需行为如何区分——WideSWE 测试修订的两条规则、AsynCodeBench 三组 Checker 的分工，都建立在对「测试到底在断言什么」的精细理解上。其三，开源项目管理流程（issue→branch→PR→review→merge→CI）——RepoMAS 的整个框架是它的同构移植，不理解 code review 的社会功能就理解不了「为什么要先验证再合并」。

方法论知识层。评测指标设计：二元判据与比例判据的信息含量差异（TestPass vs ADPR vs 连乘 Success 各自能看到/看不到什么）；预注册（preregistration）思想——AsynCodeBench 在评测前冻结依赖图，本质是心理学预注册范式在基准构建中的应用；受控对照设计——五协议矩阵隔离异步性、联合/独立对照隔离范围效应、消融网格隔离组件贡献，三篇的证明力都来自实验设计而非数字大小。关联研究脉络：从 SWE-bench 到 DeepSWE/BeyondSWE 的演化史、MAS 从固定工作流到自动搜索（AFlow）再到执行时适应的谱系，决定了三篇各自的新颖性声明边界。

工程知识层。大规模 PR 挖掘与 Linux 可执行验证流水线（WideSWE）；OpenHands harness 与 Docker 环境统一化、checkpoint 事件触发式记录（AsynCodeBench）；LLM 驱动的图修订与子图重执行调度（RepoMAS）。

知识融合的关键节点。真正的化学反应发生在三处：(1) WideSWE 把软件生态学（Reference Coupling 等人类研究）与基准工程学焊接——「人类怎么跨仓库协作」的定性知识变成了「Agent 能不能跨仓库协作」的定量判据；(2) AsynCodeBench 把软件依赖图（静态结构知识）与时间序列分析（DRS 轨迹）焊接——依赖不再是构建系统的概念而成了协作动力学的观测量；(3) RepoMAS 把项目管理流程（社会知识）与 Agent 状态管理（系统知识）焊接——Issue 不再是给人看的工单而是 Agent 可执行的状态修订指令。三篇共同的深层融合是：把软件工程领域自己的原生工具（测试、依赖图、issue 跟踪）升格为 Agent 评测的一等原语——这比借用通用 NLP 指标更贴领域本质。

八、论文中可以提取的通用性灵感

灵感一：评测判据的连乘结构本身就是探测器。核心思想：当系统由多个必须同时成功的单元组成时，把成功判定改成连乘（全过才算过），并对照「至少一单元成功」的比例，两者的沟壑就是耦合协调能力的量化值。论文证据：WideSWE 42.50% vs 83.33%。推广场景：多轮对话任务（每轮都合规才算安全）；多文档事实核查（每个声明都对才算通过）；机器人操作流水线（每道工序达标）；多语言产品发布的本地化验收（每个语言包同步）。

灵感二：要度量一种隐藏能力，就为它造可执行的谓词并追踪其轨迹。核心思想：与其从终态分数反推「协作好不好」，不如把关心的耦合关系显式建成图、为每条边写可执行检查器、在时间轴上记录满足轨迹——「何时首次满足」往往比「最终是否满足」信息更大。论文证据：ADPR 18.8 vs TestPass 48.0 的错位、hopping window 的集中爆发模式。推广场景：多人共创文档的版本一致性监控；微服务架构的契约测试（consumer-driven contracts 本就是同构实践）；跨部门项目的接口交付追踪；教育领域诊断「知识点何时首次真正掌握」而非期末总分。

灵感三：能力的代际提升不会自动流经所有瓶颈——分别为隐藏能力建指标才能发现「停滞的通道」。核心思想：一个综合指标的提升可能全部来自某条易改进通道，另一些通道原地踏步；只有分解度量才能看见。论文证据：Qwen 3.5→3.8 单体 ADPR +40.9pt 而协作 ADPR 仅 +1.7pt。推广场景：自动驾驶的「常规里程 vs 长尾场景」分解；医疗 AI 的「常见病 vs 罕见病」分账；组织管理中「个人绩效 vs 跨团队协作绩效」的分轨考核。

灵感四：执行中发现的信息必须「结构化+证据化」外化，才能被验证与局部复用。核心思想：过程中的发现若只留在自由文本或上下文里，既无法被独立验证也无法被精确撤销；记成（类型、位置、描述、证据）四元组，发现才成为可管理的资产。论文证据：完整结构化 Issue 44.7 vs 自由文本 30.8 vs 无证据 27.5；好补丁率 13.8%→69.0%。推广场景：科研实验记录的 ELN（电子实验记录本）规范；事故复盘中的时间线-证据链格式；临床鉴别诊断的「发现-证据-计划」三栏病历；AI 对话产品的用户反馈工单结构。

灵感五：缩小范围能救「遗漏」救不了「错误」——先诊断失败类型再选补救策略。论文证据：未修改仓库独立执行救回 60.00%、已修改错库仅 9.43%；bugfix（局部因果）独立更好、feature（联合行为）联合更好。推广场景：项目排期中「没做的任务」直接并行补做、「做错的任务」必须回原上下文返工；分布式系统的幂等重试 vs 状态回滚选择；学习中的「知识空白」补漏 vs「错误心智模型」重建需要不同教学法。

灵感六：把领域原生的工作流制度升格为系统的控制结构。核心思想：一个领域几十年演化出的管理流程（code review、merge gate、issue 跟踪）已经编码了该领域处理「渐进信息」的集体智慧，直接把它变成 Agent 的控制流，比从零设计更符合问题本性。论文证据：RepoMAS 的 issue→patch→review→merge→局部重执行全链路消融均为正贡献。推广场景：科学出版流程改造自动化科研 Agent（预印本→评审→修订）；法务的尽调-条款-签署流程驱动合同审查 Agent；建筑工程的图纸会审-变更单制度驱动设计 Agent。

统一的元灵感：三篇论文在更高维度上共享同一个动作——找到你所在领域「看起来是一个单元、实际上是多个耦合单元」的假象，把耦合本身变成可观测、可评测、可修订的对象。软件工程 Agent 的下一步不在更大的模型，而在与真实工程耦合结构对齐的评测单元与状态表示。