当需求相互交织：以相互依赖的规格扩展长程编码 When Requirements Interact: Scaling Long-Horizon Coding via Interdependent Specifications
合成相互依赖规格的真实仓库编码任务并用RL训练，大幅提升智能体长程编码能力
前置知识
任务规格（Specification）
软件开发任务中对期望行为的具体约束，如接口兼容、输入校验、事务回滚、错误处理、状态一致性等。论文用 $s_i(\Delta)=1$ 表示补丁 $\Delta$ 满足第 $i$ 条规格，任务请求 $Q$ 中嵌入规格集 $S=\{s_1,\dots,s_m\}$，它是判定补丁合格与否的最小单元。
本文的研究对象就是规格的数量、类别与相互依赖结构，理解规格语义是读懂任务形式化 $T=(R,Q,S,E)$ 与数据合成流程的前提。
强化学习与可验证奖励（RLVR）
让模型在环境中交互、用可执行测试作为奖励信号更新策略的训练范式。本文把合成任务作为 RL 环境：补丁通过验证器 $V$ 即获得奖励，训练中跟踪任务组均分、策略熵（稳定在 0.29–0.40）、响应长度与智能体轮数等动态指标。
论文的核心实验是用合成数据做 RL 训练，所有效果结论（如 DeepSWE-v1.1 提升）都来自 RL 对比，不熟悉 RLVR 无法理解 Table 2 与 Figure 5–7。
假阳性与假阴性（FP/FN）
测试对齐错误的两种形态：假阳性指验证器放过了违反规格的不完整实现（漏检缺陷），假阴性指测试假定了特定实现方式而拒绝满足全部规格的合法替代方案（误杀）。两者都会污染奖励信号，使 RL 学到错误行为。
论文发现 73.9% 的候选任务存在此类缺陷（Table 1），多模型轨迹审查与修复阶段正是为系统性解决它们而设计，是理解框架第二阶段的钥匙。
MoE 混合专家模型
稀疏激活架构：总参数规模很大，但每个 token 只路由到少数专家计算，推理成本只与激活参数相关。本文两个训练骨干 MiMo-V2.5 与 MiMo-V2.6-Flash-SFT 均为 310B 总参数、15B 激活参数的 MoE 模型。
所有 RL 训练实验都在这两个模型上进行，理解其规模有助于判断结论的适用范围与复现所需的算力级别。
SWE-bench 系列基准
基于真实 GitHub issue 的仓库级编码评测家族：Verified 含 500 条人工校验的 Python 任务，Pro 含 731 条多语言公开任务，DeepSWE-v1.1 提供 113 条长程编码任务；模型需产出能通过隐藏测试的补丁。
论文所有训练收益都在这四个基准上度量，知道各基准的定位才能正确解读 Table 2 中不同训练数据集对比的含义。
研究动机
现有 SWE 训练数据在规格的数量与多样性上严重不足。作者对主流数据集做了规格抽取统计（Figure 1）：Scale-SWE 平均每任务仅 4.38 条规格、1.83 个行为类别，SWE-rebench V2 只有 1.44 条/1.41 类，SWE-Lego 1.33 条/1.28 类，R2E-Gym 2.15 条/1.49 类；而真实工程要求智能体同时满足接口兼容、状态一致性、错误处理等多维约束且不破坏既有依赖，在这些低密度数据上训练的智能体遇到多约束交互的真实仓库时非常脆弱。同时任务合成面临两难：单纯堆叠规格会把任务退化成可逐条贪心完成的清单，甚至泄露解题路径；而一旦规格相互耦合，测试又极易出错——试点生成中 3,067 个候选任务里 2,267 个（73.9%）存在查询-测试对齐缺陷，其中仅假阳性占 50.5%、仅假阴性 13.9%、两者兼有 9.6%（Table 1）。
本文的目标是本文的目标是构建一个可扩展的合成框架 CodeSpecWeave，自动产出带有丰富且相互依赖规格、验证器可靠的真实仓库编码任务。具体而言：任务中的规格不应是彼此独立的检查项，而要共享执行上下文与生命周期约束，使得为满足某条规格做出的实现选择会约束其余规格的可行解，逼使智能体进行联合推理与全局协调；同时测试必须与规格严格对齐——既不放过违反规格的不完整实现（假阳性），也不拒绝满足全部规格的合法替代实现（假阴性）。在此之上，用合成数据对大模型做强化学习，显著提升智能体在 DeepSWE-v1.1 等长程编码基准上的成功率，并配套构建一个人工精审、能清晰区分前沿模型并揭示共同失败模式的基准 CodeSpecWeave-Bench。
与已有工作不同的是，已有编码数据合成工作（R2E-Gym 从 commit 生成、SWE-smith 修改可用代码造修复任务、SWE-Flow 用单测与运行时依赖构造增量任务、SWE-Mirror 跨仓库迁移 issue 语义、ADR 重组种子问题语义元素、TaskPilot 用求解器反馈精化任务-补丁-测试三元组）都聚焦于任务来源或内容生成方式，没有把「规格的覆盖面与交互结构」本身当作合成目标；规格研究线（ArchCode、SpecRover、REAgent、CodeSpec）则侧重需求抽取、根因分析或用可执行规格对齐功能链实现，而非用耦合规格构造需要联合推理的任务。本文的独特切入是给出「可加规格 vs 相互依赖规格」的数学刻画：设设计变量 $d=(d_1,\dots,d_k)$，若可行域可分解为 $\mathcal{F}_d=\prod_j \mathcal{F}_j$ 则任务退化为清单，而相互依赖对应 $\mathcal{F}_d\subsetneq\prod_j \mathcal{F}_j$，并以此原则驱动整个数据合成管线。
核心方法
CodeSpecWeave 把任务形式化为四元组 $T=(R,Q,S,E)$：代码仓库 $R$、给求解器的自然语言请求 $Q$、嵌入 $Q$ 的规格集 $S=\{s_1,\dots,s_m\}$、带验证器 $V$ 的执行环境 $E$；合法补丁集合为 $\mathcal{F}(T)=\{\Delta : s_i(\Delta)=1,\ \forall i\}$。整体思路先有直觉：真实工程约束天然相互牵制，例如输入校验、事务回滚、向后兼容往往锚定在同一状态转换上，把它们编织进同一任务后，逐条局部编辑无法解耦，必须联合推理。技术路线分两阶段（Figure 2）：任务合成阶段由合成智能体依据真实开发者规格种子，在仓库中迭代起草请求、规格与测试并执行反馈；验证与修复阶段收集多个独立模型的求解轨迹 $\tau$ 与补丁 $\Delta$，审查智能体检视完整元组 $(Q,A,\Delta,\tau)$ 识别假阳性/假阴性，修复智能体改写请求或验证器后再复审。最终产出 4,670 个训练任务（覆盖 2,865 个仓库）与含 100 任务、1,044 条规格的 CodeSpecWeave-Bench。
核心创新是把「规格间的依赖结构」形式化为设计空间可行域的可分解性，并让它成为任务合成的显式目标。设规格集合允许的工程选择为设计变量 $d=(d_1,\dots,d_k)$、可行空间为 $\mathcal{F}_d$：可加规格对应 $\mathcal{F}_d=\prod_j \mathcal{F}_j$，每个选择可独立贪心确定，任务只是分步清单，语言模型逐条满足即可得高分；相互依赖规格则破坏这一分解（$\mathcal{F}_d\subsetneq\prod_j \mathcal{F}_j$），为满足某条规格做的选择严格收窄其余规格的可行替代，局部编辑解耦失败，必须全局协调。合成智能体据此刻意把互补需求锚定到同一状态转换或核心组件——论文示例任务把消息去重、并发预占、失败重试、保留期、遗留 API 兼容、取消清理等 13 条规格耦合到共享的消息声明（claim）生命周期上。这与以往只追求数量、或仅验证单条需求的数据集有本质区别：作者初始实验发现只堆规格数量时任务仍然平凡，才引出这一设计原则。
方法步骤详情
第一步，规格种子挖掘：从开源仓库的 commit 历史、issue 讨论与 PR 中抽取规格单元，过滤对话噪声与裸代码，归一化去重后得到覆盖六种自然语言的 104,182 条候选规格。第二步，任务合成：给定仓库与种子，合成智能体探索代码库，将互补需求锚定到同一状态转换或核心组件，迭代起草任务请求 $Q$、规格 $S$ 与测试用例 $A$；测试与规格是多对多映射，智能体直接在仓库中执行测试并依据运行时反馈精化。第三步，难度过滤：对 14,905 个初始任务用多个独立编码模型多次求解，保留成功率混合的 3,275 个候选。第四步，验证与修复：试点显示 73.9% 候选存在对齐缺陷（Table 1：仅假阳性占 50.5%、仅假阴性 13.9%、兼有 9.6%）；审查智能体检视 $(Q,A,\Delta,\tau)$ 找出漏检与误杀，修复智能体改写请求或验证器，再经执行检查、全新求解试验与对齐复审，单批最终批准 766 个。第五步，产物构建：得到 4,670 个训练任务，并人工精审出 Bench（100 任务、1,044 条规格，均值 10.44 条/任务、中位数 9、范围 3–31）。
技术新颖性
技术新颖性体现在三点。其一，首次把规格交互结构作为任务合成的显式优化目标，并用可行域分解性给出可操作定义（$\mathcal{F}_d\subsetneq\prod_j \mathcal{F}_j$），区别于 CodeSpec 用可执行规格维持功能链设计与实现的一致性、DevAI 把需求组织成依赖图做评测——本文是用耦合规格「构造」训练任务本身。其二，验证可靠性不依赖静态审查而依赖执行时证据：只有当代码真正在多约束交互下运行，漏检（放走违反多条规格的补丁）与过严（拒绝合法实现）才会暴露，因此用多个独立模型的轨迹与补丁交叉审计，形成假阳性/假阴性的发现-修复-复审闭环，每批 14,905 个初始任务经难度过滤（3,275）与审查（766）层层把关。其三，规模与质量兼顾：平均每任务 8.36 条规格、4.08 个行为类别，远超 Scale-SWE 的 4.38/1.83 等现有数据集，同时以多模型混合成功率过滤，把任务保持在「有挑战但可解」的难度区间。
实验结果
Bench 横评（Figure 4）：11 个前沿智能体通过率 44.0%–74.0%，最强的 GPT-6 Astra 达 74.0% 且平均输出 token 最少（17.2k）；Claude Opus 5 比 Qwen3.8-Max 高 6.1 个百分点且输出少约 47%。失败集中于边界/路径处理不完整，以及满足一条规格却违反共享同一状态的另一条规格。RL 训练（Table 2）：MiMo-V2.5 平均分 50.15%（Vanilla 44.69%，SWE-PI 42.05% 负迁移），DeepSWE-v1.1 从 12.39% 提到 25.30%；Flash-SFT 平均 67.60%，DeepSWE 54.42%→62.98%，Verified 77.40%、Pro 59.37% 均最优。行为变化（Table 3）：V2.5 思考 token 29.7k→141.6k、编辑-测试循环 3.48→4.34；Flash-SFT 循环 2.96→4.90、≥2 循环轨迹占 78.3%。按规格数与七类规格分组均提升 9.5 个点以上（Figure 6），且训练全程策略熵稳定。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| CodeSpecWeave-Bench（100 任务，RL 训练后） | 通过率 % | 52.00（MiMo-V2.5）/ 70.67（Flash-SFT） | Vanilla 47.00 / 59.00；MiMo Coding 50.00 / 69.00 | 较 Vanilla +5.00 / +11.67 个百分点 |
| DeepSWE-v1.1（113 条长程编码任务） | 通过率 % | 25.30（MiMo-V2.5）/ 62.98（Flash-SFT） | Vanilla 12.39 / 54.42；SWE-PI 仅 6.78（V2.5，负迁移） | 较 Vanilla +12.91 / +8.56 个百分点 |
| SWE-bench Verified（500 条人工校验任务） | 通过率 % | 72.00（MiMo-V2.5）/ 77.40（Flash-SFT） | Vanilla 69.27 / 74.20 | +2.73 / +3.20 个百分点 |
| SWE-bench Pro（731 条多语言任务） | 通过率 % | 51.30（MiMo-V2.5）/ 59.37（Flash-SFT） | Vanilla 50.11 / 54.54 | +1.19 / +4.83 个百分点 |
| 前沿模型横评（CodeSpecWeave-Bench） | 通过率 %（11 个智能体） | 最高 GPT-6 Astra 74.0（17.2k 输出 tokens） | 最低 44.0；Claude Opus 5 高出 Qwen3.8-Max 6.1 个百分点且输出少约 47% | 区间跨度 30 个百分点，区分度显著且留有 26% 失败空间 |
局限与改进
作者承认三点局限：RL 训练本身需要大量算力；每个任务携带容器镜像并在 Kubernetes pod 中运行，训练与评测都需要并发管理大量容器的基础设施；高质量任务依赖强模型与多轮过滤，会丢弃大量候选。我的补充观察：其一，数据合成与审查使用小米 MiMo 系模型，而 Bench 上 MimoAgent 系智能体分数垫底（44.0%–55.0%），生成/审查模型与被评模型的同源关系可能引入隐性偏置；其二，「相互依赖」虽有数学定义（$\mathcal{F}_d\subsetneq\prod_j \mathcal{F}_j$）但缺少可计算的耦合度估计，实际耦合强度依赖 LLM 审查的主观判断；其三，轨迹审查只能覆盖采样到的实现路径，修复后残余的假阳性/假阴性率未量化；其四，训练只在 310B 总参/15B 激活的两个 MoE 模型上验证，对更小模型是否成立未知；其五，Bench 仅 100 任务且与训练集出自同一合成管线，存在分布耦合风险，需更长时间的第三方检验。
独立分析的弱点
第一，合成漏斗效率极低：单批 14,905 个初始任务经难度过滤剩 3,275 个、审查通过仅 766 个，通过率约 5%，且每个候选都需要多个前沿模型反复 rollout 与容器化执行，算力与基础设施成本高昂；改进方向是用变异测试或静态规格-测试一致性检查做廉价预筛，只把疑难候选送入昂贵的多模型轨迹审查。第二，对强模型的依赖形成质量瓶颈：合成、求解、审查全部依赖前沿模型，资源有限的团队难以复制同等质量；可把审查规则蒸馏进小型判别模型以降低边际成本。第三，相互依赖度缺乏度量与课程设计：所有任务一次性强耦合，没有从可加规格到强耦合规格的难度梯度，可定义耦合度谱系用于课程学习以稳定 RL 早期训练。第四，失败分析是定性的：测试与规格的多对多映射使规格级归因困难，缺少每条规格通过率的自动度量，难以精确定位模型在哪些约束交互上最薄弱。第五，每任务需独立容器镜像，存储与分发开销随数据集线性增长。
未来方向
作者提出的方向集中在降本增效：减少对容器化基础设施的依赖、提升合成吞吐、降低对强模型与多轮过滤的依赖。基于成果可延伸的方向包括：其一，量化规格耦合度并构建课程学习，从可加规格渐进过渡到强耦合规格，改善 RL 早期稳定性；其二，把整体通过/失败的稀疏奖励改为规格级过程奖励模型（PRM），为每条规格给出中间信号，缓解长程任务的奖励稀疏与信用分配难题；其三，将管线推广到多语言与更多领域（规格种子已覆盖六种自然语言），检验在 DevOps、数据工程等场景的泛化；其四，与形式化方法结合，用契约式设计或性质测试（property-based testing）自动生成更严格的约束交互测试，替代部分人工审查；其五，研究相互依赖规格训练能否迁移提升模型的规格理解与自审查能力，例如在规格遵循、需求消解类基准上验证正迁移；其六，探索耦合度与推理时计算（更长思考、更多交互轮）之间的量化关系，指导测试时扩展策略。
复现评估
论文正文未给出代码或数据的开源链接，复现需分层评估。评测侧门槛中等：若 100 个任务的 Bench 与容器镜像开源，只需一个智能体框架加容器环境即可复跑榜单；附录 A.1 列出数据构建所用模型与 harness、A.2 说明人工审查流程、B.1 给出 RL 超参、B.2 给出评测设置，信息相对完整。训练侧门槛极高：任务数据需走完整合成管线，从 14,905 个初始任务漏斗到 4,670 个训练任务，每个候选都要多个独立前沿模型反复 rollout 并收集执行轨迹，外加每任务容器镜像与 Kubernetes 编排；RL 训练对象是 310B 总参/15B 激活的 MoE 模型，算力估计在数千 GPU 卡天量级，远超一般学术实验室预算。可行的降级路径：先用开源数据集（如 SWE-PI）验证训练框架，再小规模合成数百个任务验证质量过滤环节的有效性，最后视资源决定是否扩展。综合评级：训练全流程复现非常困难，仅 Bench 评测复现为中等难度。
论文图表
上半部分柱状图对比各 SWE 训练数据集的每任务平均规格数与行为类别数（含 95% bootstrap 置信区间）：Scale-SWE 4.38/1.83、SWE-rebench V2 1.44/1.41、SWE-Lego 1.33/1.28、R2E-Gym 2.15/1.49，而 CodeSpecWeave 达 8.36/4.08。下半部分示例对比：先前数据集任务只有 2 条独立规则（按消息 ID 过滤、空批返回空），CodeSpecWeave 任务含 13 条相互耦合的规格（去重、并发预占、失败重试、保留期、遗留 API 兼容、取消清理等），共享同一消息声明状态与生命周期约束。
这张图同时给出了问题的量化证据（现有数据集规格密度低）与解决方案的直观样例（耦合规格长什么样），是理解全文动机与设计原则的入口。