SoftwareGym × ProgramGym：Agent 训练环境合成双子星 精读

论文 1 链接：SoftwareGym: Scaling Computer-Use Agent Training with Diverse Synthesized Software Environments 论文 1 代码：github.com/MrKiing-Jin/SoftwareGym ｜ 模型 HuggingFace 论文 2 链接：ProgramGym: Scaling Training Environments for Long-Horizon Program Reproduction Agents 论文 2 资源：huggingface.co/ProgramGym ｜ programgym.github.io 发表时间：2026 年 10 月（arXiv 2610.12611v1 / 2610.13395v1） 机构：SoftwareGym = 上海交通大学 + 浙江大学（纯高校合作，共同一作 Tian Jin / Wenhao Wang，通讯 Siheng Chen，团队与 CUA-Universe 重叠）；ProgramGym = 厦门大学 + Washington University in St. Louis + 中科院自动化所 + 思必驰（Unisound）——高校主导方法设计，企业提供部分研究支持，论文未细分各方角色 领域标签：cs.MA / cs.SE；CUA 训练环境合成、编码智能体训练环境、后训练

一、论文背景：当"环境"成为 Agent 训练的第一瓶颈

两句行话可以概括 2026 年 Agent 训练的现状：模型不缺算力，缺的是可交互、可验证的环境。

一条线是计算机使用智能体（CUA, Computer-Use Agent）。CUA 要像人一样看屏幕、点鼠标、敲键盘完成真实软件里的任务。OSWorld（NeurIPS 2024）为这类智能体提供了首个真实桌面评测环境：369 个 Ubuntu 真实任务，人类能完成 72.36%，而当时最好的模型只有 12.24%。两年过去，前沿模型的分数已大幅提高，但训练数据成了新瓶颈——高质量轨迹只能从真实应用里采集，而把一个真实桌面应用改造成可复现的训练环境，需要快照、初始化脚本、评测器三件套，OSWorld 团队自己统计：9 名学生 3 个月、约 1800 人时才做出 369 个任务。按这个成本，CUA 训练数据的规模化没有出路。

另一条线是编码智能体。SWE-bench 系列的"issue 修复"任务假设仓库已经给你了，agent 只需打补丁。但真实软件工程师更常见的工作是从零构建：先搞清楚程序该做什么，再决定怎么设计。ProgramBench（Meta FAIR 等，2026）把这个设定推向极端——只给一个可执行二进制和文档，agent 必须从黑盒探索中推断行为并重建整个程序。原版评测中 200 个任务没有任何模型能完整解决任何一个（最好的 Opus 4.7 也只有 3% 的任务通过 95% 的测试）。同样的瓶颈出现了：这一类任务几乎不存在可验证的训练环境，SWE-Gym/SWE-smith 这类 issue 修复环境没法提供"整程序行为级"的监督信号。

两篇论文就是在这两条线上分别给出的答案，而且答案的形状惊人地一致：

• SoftwareGym：自动合成多样化的独立桌面 GUI 应用环境，用 GUI 交互验证功能可靠性，产出 182 个应用/12 类软件，训练 9B 模型在严格 OOD 的 OSWorld 上 Pass@3 从 41.39% 提到 56.97%。
• ProgramGym：从开源仓库自动构建可验证的"程序复现"训练环境（参考可执行程序 + 运行时沙箱 + 文档 + 黑盒测试套件），产出 1,648 个环境/665,512 个测试，训练 27B 模型在 ProgramBench 上从 34.87% 提到 42.84%，再配合作业流革新推到 56.25%，超过 Claude Opus 4.7 的 50.90%。

读者可以把它们理解为一对"环境合成双子星"：一个合成交互的界面，一个合成可验证的行为；一个教 agent 学会用软件，一个教 agent 学会写软件。

二、论文定位和关联工作：环境合成谱系的两条支脉

2.1 GUI 侧：从"复用真实应用"到"合成新应用"

第一代：真实应用做成环境。OSWorld、Windows Agent Arena、AndroidWorld 把真实桌面/移动应用装进虚拟机，保证真实性但受限于集成成本。后续工作（OS-Genesis 的反向任务合成、EvoCUA 的可扩展合成经验、ProcCUA-SFT、AgentSynth 等）在既有应用内部合成任务和轨迹；CUA-Universe、Gym-Anything 则把任意软件配置成可复现环境。这条路线的覆盖面永远受制于"哪些应用已经被人工集成过"，且在固定应用池上反复训练容易过拟合到特定应用。

第二代：合成浏览器环境。InfiniteWeb 合成多页面网站（约 $1.93/站），AutoWebWorld 用有限状态机生成无限 Web 世界，GUI-GENESIS 把真实应用重建为无后端网页，ScaleWoB 让编码智能体大规模合成环境。浏览器基座部署方便、状态可控，但共享的 HTML/DOM 底层限制了交互深度与工作流复杂度——SoftwareGym 论文的批评是：网页点不出桌面应用的持久工作流。

SoftwareGym 的卡位：首次做独立桌面应用的规模化合成。它不复用既有应用（vs 第一代）、不用浏览器基座（vs 第二代），而是从功能规范直接生成 Avalonia 跨平台桌面应用，通过结构化风格设计控制多样性、GUI 引导修复保证可靠性。

2.2 代码侧：从"issue 修复环境"到"整程序复现环境"

Issue 修复一脉：SWE-Gym（ICML 2025）是首个开源 SWE 训练环境，2,438 个真实 Python 任务，仅用 491 条拒绝采样轨迹微调就把 SWE-bench Verified 从 7.0% 提到 20.6%，加验证器推理时扩展达 32.0%——证明了"少量高质量可执行环境 + 可验证信号"的数据效率。SWE-smith（NeurIPS 2025）把环境构建工业化：对任意 Python 代码库自动合成破坏测试的 bug 任务，5 万实例/128 仓库，训练 SWE-agent-LM-32B 达 40.2%。后续 SWE-rebench、R2E-Gym、SWE-Universe 等继续扩规模。

从零构建一脉：Commit0/NL2Repo-Bench 给需求文档让 agent 实现仓库——但需求文档规定了功能规范，任务退化为"实现"，没有需求发现空间。ProgramBench 与 MirrorCode 定义了更极端的"程序复现"：只给二进制+文档，行为必须靠探索发现。这一设定长期缺训练环境：MindForge 局限于命令行程序且不过滤行为正确性（功能错误的复现也会被当作成功监督）。

ProgramGym 的卡位：把"程序复现"任务的环境构建自动化、可验证化。承接 SWE-Gym/SWE-smith 的"环境即数据"范式，但验证对象从"补丁是否修复单测"升级为"重建程序的黑盒行为是否匹配参考实现"，为此设计了一套四重测试校验管线。

2.3 定位对比表

定位结论：两篇论文在各自赛道里都不是"首个做环境合成"，但都是首个把某一类此前不可验证的环境变成可验证的：SoftwareGym 让"新桌面应用"可验证（GUI 执行证据），ProgramGym 让"整程序行为复现"可验证（四重测试校验）。它们的新颖性都属于"中偏高"——范式承接既有谱系，机制创新在验证门控。

三、问题定义：同一个母题的两种形式化

两篇论文面对的具体场景不同，抽象出的本质问题却同构。

3.1 SoftwareGym：环境合成 = 多样性 × 可靠性 × 规模的三元悖论

CUA 训练环境要同时满足三个要求：(1) 界面与交互多样性——支撑泛化；(2) 功能可靠性——每个功能在完整 GUI 工作流中可用，否则轨迹是错的；(3) 规模化——有限工程投入扩展环境池。难点在于三者互相牵制：无约束生成会趋同（同一类软件生成十次得到十个相似布局）；可靠性检查若靠人工无法规模化。形式化地说：给定软件类型集合与资源，设计流水线 Φ，使输出应用集 {A_i} 在结构多样性 D_struct（归一化树编辑距离，门控阈值 0.60）、GUI 任务通过率 P_func、单位成本三个维度同时达标。

3.2 ProgramGym：环境构建 = 把仓库变成五元组

程序复现环境定义为 e_i = Φ(P_i) = (Bᵢ, Dᵢ, Tᵢ, Sᵢ)：参考可执行程序 Bᵢ（execute-only）、使用文档 Dᵢ、黑盒行为测试套件 Tᵢ、网络隔离沙箱 Sᵢ。两个核心挑战：(1) 仓库千差万别的工具链/依赖如何统一重建成可执行程序；(2) 黑盒测试如何既覆盖行为又能拒绝错误复现——单次生成会漏行为或写出弱断言。注意一个精妙之处：Tᵢ 只覆盖有限输入，通过它只证明"被测行为一致"而非语义等价，所以测试套件的质量就是监督信号的质量。

3.3 同构性

两篇论文的共同洞察：合成环境的价值不在生成端，而在验证端——只有被运行时证据验证过的部分才允许进入训练信号。

四、问题解法：两条流水线的解剖

4.1 SoftwareGym：设计—实现—评估三阶段多智能体流水线

阶段 A：软件设计（多样性从哪来）

• FunctionDesigner 把最小人类输入扩展为功能规范：先建立成熟产品的功能基线（目标用户/核心对象/增删改查操作），再扩展领域专业功能（多条件检索、批量操作、历史管理），连接成覆盖跨模块状态变化的完整工作流，最后把每个功能写成"实现与评估契约"（用户入口/动作/期望状态更新/GUI 响应/验收 checkpoint）。
• StyleDesigner 生成多个风格规范：每个规范遵循一个布局原型（navigation/spatial organization/object browsing/action placement 四维），任意两个变体必须至少在两个维度上不同。每个风格规范交给独立的 SubStyleDesigner 产出 Avalonia UI 蓝图，编译验证 XAML 有效性。
• 结构多样性硬门控：蓝图转成归一化布局树（窗口/区域/面板/控件，剥离文字颜色），计算两两树编辑距离，最小成对距离 < 0.60 就重新生成最不独特的蓝图。
• IconDesigner/SubIconDesigner 生成语义一致但结构不同的 SVG 图标资产，平台侧校验完整性。

阶段 B：实现（可靠性怎么保证）

• Coder 按 Verified Design Package 实现完整应用，每个功能是完整 GUI 工作流（入口/命令绑定/状态更新/持久化/可见反馈），并记录功能手册；DevCoder 对照手册审计命令绑定、持久化、启动行为、文件接口，修复缺失实现。
• GUI 引导修复回路：EvalTaskGenerateAgent 从功能手册生成测试用例（覆盖控件可达性、导航、对象创建编辑、持久化、检索、对话框、文件工作流），用例集在首轮实现后冻结、跨修复轮复用；GUIAgent（Seed 2.1 Pro）以鼠标键盘在 Ubuntu 虚拟机里执行（每用例最多 50 步），记录交互轨迹/checkpoint 证据/失败位置/修复建议。失败轨迹回传给 Coder 做定位修复，直到全部通过或版本预算（v1–v3 三轮）耗尽。
• 设计保真度门控：每轮修复后计算实现应用与 UI 蓝图的视觉保真分 F_vis（调色板 Jaccard 0.40 + 主色 0.15 + 圆角 0.20 + 字体 0.10 + 资源绑定 0.15），F_vis < 0.80 触发针对性修复——防止功能修复把界面改得面目全非。

阶段 C：任务合成（监督信号怎么来）

• 只用 GUI 验证过的功能建功能树：每个能力必须引用通过的用例/checkpoint/交互步骤才标记 supported，未测试/失败/被阻塞的路径全部排除（证据门控）。
• 难度分级靠能力依赖：easy=单功能短视野，normal=跨功能依赖组合，hard=多阶段工作流（每阶段建立下一阶段所需状态）；每级含文件型/空白态两类任务。
• 任务生成为自然语言请求 + 内部确定性评测规范（初始状态/结果准则/过程准则），用户请求不暴露坐标、路径、能力标识。

4.2 ProgramGym：Program-Env 构建环境 + Program-Agent 解决任务

Program-Env 之仓库收集：GitHub Search API 按语言×星数桶（6 桶递归二分绕开 1000 条限制）分层搜索，41,833 → 元数据校验（去重、SPDX 许可、排除已有 benchmark 仓库）→ commit 锁定 → 构建配置检测（Cargo.toml/go.mod/CMakeLists.txt 等），得 30,459 个候选库。

Program-Env 之可执行程序与沙箱：

• 构建代理（Claude Code + 语言技能包）生成双脚本：download.sh 在线装依赖（编译器/构建工具/第三方库/环境变量），compile.sh 离线编译。
• 构建验证三重奏：静态 linter 拒绝失败掩盖（|| true）、错误抑制（2>/dev/null）、占位内容，要求把可接受的失败显式分支处理；在线跑 download.sh（只给脚本不给源码，逼它自带依赖清单）；从冻结容器中无网启动跑 compile.sh，检查退出码、可执行文件存在与格式，ldd 链接检查确认无缺失动态库。失败诊断结构化回传，4 次尝试上限。
• Dispatcher 按复杂度 ξ（代码行数+运行时依赖的对数，clip 到 [0,10]）分配模块预算：easy(<2)=4、medium(2–4)=6、hard(≥4)=8 个模块；对可执行程序做覆盖率插桩（rule-first, agent-fallback：语言规则先试，验证失败才上插桩代理）；提取 README/LICENSE 与测试输入资产作为文档 Dᵢ（规则性排除源码目录，防止泄漏实现）。

Program-Env 之黑盒测试构建（本文最精彩的部分）：每个模块一个子智能体（共 5,918 个）在测试沙箱里迭代写测试，每轮反馈三类结构化文档：

• Summary：上轮做了什么、还剩什么、为什么（跨轮记忆）。
• Program analysis：动态分析（覆盖率）定位未覆盖功能——优先选部分覆盖文件（有执行证据、只需补分支输入），按覆盖率升序给目标（每轮至多 min(|G|, 10%, 300) 个防过度声称）；静态分析（Joern/CodeQL 代码属性图）从未覆盖行映射到外层函数、反向遍历调用图找黑盒可达的公共入口。
• Validation：四重独立校验——(1) pass check：在参考程序上必须通过（忠实性）；(2) double check：隔离文件状态跑两遍结果必须一致（稳定性，防随机通过）；(3) dummy check：把被测程序换成无意义输出的哑实现，测试必须失败（有效性，剔除"空实现也能过"的假测试）；(4) weak-assert check：37 条规则的静态 linter 拒绝弱断言（只查退出码、恒真断言、被条件分支掩盖的断言、吞异常、网络/时间/未播种随机依赖）。四项全过才进最终套件。
• 终止条件：模块覆盖率达 80%、轮数上限（5–20 随复杂度）或早停（连续 3 轮覆盖增益 <0.25% 且 linter 通过率增益 <20%）。

Program-Agent 之角色隔离工作流：分析（读文档+探索参考程序，产出冻结的 analysis.md）→ 实现（不可访问参考程序，只依据 Handoff 工件开发；首迭代先交付可编译基线）→ 审查（对照参考程序与不可变候选程序，把验证过的行为差异转成下轮修订需求）三阶段各自独立会话，Handoff 工件传递证据而非完整对话史。修订管理：每轮实现以独立编译为门（导出干净 git 快照，在开发工作区外编译，300 秒超时），通过则归档为 Revisions 并作为恢复检查点；失败/超时在新鲜会话有界重试（默认 2 次），仍失败则回滚到最后验证版本。固定预算 K=5（1 次分析 + K 次实现 + K-1 次审查）。

4.3 训练配置

• SoftwareGym：Qwen3.5-9B 多模态 SFT，只用 SoftwareGym 应用轨迹；双 GPT-5.5 裁判（结果裁判看最后 5 条消息+截图、过程裁判看全部消息+10 张采样截图）打分，双分 ≥0.8 才保留；16×A800、lr 5e-6、序列长 16,384、1 epoch，最终 49,445 条样本。
• ProgramGym：DeepSeek-V4-Flash-0731 + Claude Code 拒绝采样收集轨迹（按测试通过率过滤），得 64,505 条轨迹段（Claude Code 上下文重置会产生多段）；Qwen3.8-27B 全参数 SFT，ms-swift、2 epochs、序列长 262,144（bin packing）、loss 只算 assistant 有效 token（环境里不可用的工具调用置零掩码）。

五、评估指标与实验证据

5.1 SoftwareGym：OOD 泛化是主战场

指标体系：主指标 OSWorld Pass@3（244 任务/8 域，严格 OOD——训练不含任何 OSWorld 应用/任务/轨迹）；域内指标 SoftwareGym-Bench Pass@3（120 任务/12 类，含干扰物与保护对象的状态锚定设计）；环境质量指标 GUI 任务通过率；消融指标结构多样性（0–100）与修复增益。

核心数字：

关键消融：

• GUI 引导 vs 仅源码修复：同起点 50.4%，GUI 引导 v2 70.5% / v3 83.1%，仅源码 50.5% / 48.8%（甚至低于起点）。最终差距 34.3 分（95% CI 28.2–41.0），36 个应用全部胜出。
• 结构化风格设计 vs 简单设计：结构多样性宏平均 4.9 → 83.6，12 类全胜；简单设计的 12 组蓝图没有一组通过 0.60 多样性门控。
• 训练数据来源（同规模 3,715 轨迹对齐）：OSWorld-only 在 OSWorld 得 61.48%（域内占优），SoftwareGym-only 56.97%（域外逼近）；混合训练 OSWorld 58.61% / Bench 47.5% 双升——合成环境与真实数据互补。

5.2 ProgramGym：验证器可靠性决定 SFT 上限

指标体系：ProgramBench 的 Tests Passed（每任务测试通过率宏平均，主指标）、Almost Resolved（≥95% 测试通过）、Resolved（全通过且无作弊标志）；环境质量指标覆盖率/测试数/校验通过率。

核心数字：

关键消融/分析：

• 校验反馈的动态效果（案例级）：violet 仓库 linter 通过率 0%→98.3%、dummy 假通过率 1.41%→0%；kubesess 覆盖率 4.88%→85.77%；COLMAP 案例中覆盖反馈把 ply.cc 从 37.08% 提到 80.03%（模块 29.92%→42.86%），调用图发现 agent 误以为"太重而跳过"的轻量入口（模块 36.41%→45.47%）。
• token 效率反转：Program-Agent 各预算（K=1/3/5）的 token 消耗都低于基模型配 Claude Code 的单会话长轨迹——分轨修订代替单条长轨迹，花在结构化修订而非无限探索。
• 行为分布重塑：Program-Agent 使 read/git 操作显著增多（探索-修订型智能体）；≥50% 测试通过的任务占比从 40.5%→62.0%（基模型）、≥75% 从 18.0%→34.0%。而 SFT 的作用集中于分布中段：SFT 后 Almost Resolved 反而从 3.50% 降到 1.50%——SFT 拉不动高保真上尾。
• 实现紧凑性：通过 ≥75% 测试的解中，生成代码/参考代码行数比中位 0.64；Program-Agent 把中位比从 0.58→0.75（基模型）、0.49→0.67（SFT）——迭代把实现做得更完整而非更短。

六、效果优势的根源解释

6.1 SoftwareGym：三条因果链

因果链 1：独立应用合成 → 扩大软件分布 → OOD 泛化

• 方法差异：不复用固定应用池、不用浏览器 DOM，而是从功能规范生成全新的独立桌面应用（新布局结构、新交互模式、新视觉风格）。
• 机制变化：训练分布从"N 个已集成应用的轨迹"扩展到"软件类别级的功能×风格组合空间"，模型被迫学习跨界面结构迁移的通用 GUI 交互而非应用特定流程。
• 指标提升：零 OSWorld 数据 +15.58 分；且与 OSWorld 数据混合后 Bench 从 40.0→47.5（分布互补的直接证据）。
• 【论文实验已支持】训练来源消融（Table 3）严格控制了规模与协议。

因果链 2：GUI 运行时证据 → 修复有靶点 → 可靠性 +34.3 分

• 方法差异：修复回路喂给 Coder 的不是源码审计报告，而是 GUIAgent 真实点出来的失败轨迹（失败位置+checkpoint 证据+修复建议）。
• 机制变化：源码级自修复只能看到静态代码——事件绑定丢失、状态更新失败、持久化残缺这类只在交互中暴露的缺陷，源码审计既发现不了也验证不了修复；更糟的是盲目改代码会引入新缺陷（source-only v3 从 50.4 跌到 48.8，低于起点）。GUI 证据把修复从"猜测式重写"变成"定位式修补"。
• 指标提升：50.4→83.1 vs 48.8，36/36 应用全胜，95% CI [28.2, 41.0]。
• 【论文实验已支持】配对消融（共享 v1 起点、同修复轮数、同评估）。

因果链 3：结构化风格设计 → 结构多样性 4.9→83.6 → 防趋同

• 机制变化：无约束生成的"多样性"只是表面不同（文字/颜色），归一化布局树层面是同一个结构（Simple Design 12 组全部含相同布局树的成对蓝图）。布局原型四维距离≥2 + 树编辑距离 0.60 门控把多样性从装饰级提升到组件层级结构级。
• 【论文实验已支持】+【阅读者推测】多样性提升本身有实验支撑；但"结构多样性→OOD 泛化"的传导本文未直接消融（没有"高多样性 vs 低多样性环境训练对比"），是合理推测。

6.2 ProgramGym：三条因果链

因果链 1：四重校验 → 监督信号可靠 → SFT 有效

• 方法差异：测试套件不是"生成即用"，每条测试要过 pass/double/dummy/weak-assert 四关。
• 机制变化：SFT 的监督信号 = 测试筛选出的"成功"轨迹。若测试有假（哑实现也能过、随机也能过、断言恒真），错误实现会被标为成功进入训练集，直接污染梯度。dummy check 特判"空实现也能过"的测试、weak-assert 特判"只查退出码"的弱断言，从机制上保证正样本是真阳性。
• 指标提升：+7.97 分（同 scaffold 只换数据）；案例级证据：假通过率 1.41%→0%、linter 0%→98.3%。
• 【论文实验已支持】+【对照】MindForge 不过滤行为正确轨迹，监督不可验证——正是本文批评的对照面。

因果链 2：覆盖率+调用图反馈 → 测试写作有靶点 → 规模化覆盖

• 机制变化：无反馈时测试写作是盲目探索；覆盖率回答"哪里没测到"，调用图回答"从哪个黑盒入口能到达"。COLMAP 案例最典型：agent 主观跳过"太重"的 SfM 全流程路径，调用图揭示 standalone rotation averaging 这个轻量入口——把猜测变成可达目标。优先部分覆盖文件的策略（有执行证据、只需补输入）进一步把预算花在刀刃上。
• 指标提升：665K 测试、平均覆盖 72.99%；案例 ply.cc +42.95 分。
• 【论文实验已支持】（案例级；论文如实说明因终止轮数不同无法画平均覆盖曲线）。

因果链 3：角色隔离+快照回滚 → 消除上下文污染 → 作业流增益 +20 分且 token 更少

• 方法差异：单会话 Claude Code vs 分析/实现/审查三阶段独立会话+Handoff 工件+独立编译门。
• 机制变化：长时程任务（超 256K 上下文）单会话必然压缩历史，早期观察到的行为需求被遗忘、错误编辑累积到编译失败。角色隔离让每个会话上下文干净（分析阶段无实现噪声、实现阶段无参考程序可作弊性比对、审查阶段只看不可变候选）；独立编译快照保证"进展"永远是可构建的，回滚机制防错误累积。token 反而更少，因为探索/实现/修订分轨进行，不把预算耗在单条越滚越长的轨迹上。
• 指标提升：34.87→55.71 / 42.84→56.25；行为分布整体上移；token 成本下降。
• 【论文实验已支持】+【边界条件】DS-V4-Flash-0731 仅 +1.29——模型越强、单会话自我管理越好，作业流增益越小。

6.3 外部检索对照表

相反/限定性结论检索：围绕"GUI/运行时反馈是否总是有益"“SFT 是否普遍提升长时程任务”，本次检索范围内未发现直接否定 SoftwareGym/ProgramGym 结论的工作；但存在三类边界证据：(1) VF-Coder 发现视觉反馈在修复阶段的边际收益小（限定反馈的作用位置）；(2) ProgramGym 自己报告 SFT 后 Almost Resolved 下降、强模型作业流增益仅 +1.29（限定增益的分布位置与模型强度依赖）；(3) SoftwareGym 自己报告合成数据在 OSWorld 域内仍不敌真实数据 61.48 vs 56.97（限定合成数据的定位是互补而非替代）。

6.4 综合判断与未决问题

多研究共同支持的机制：(1) 可执行验证信号是训练环境价值的来源（SWE-Gym/SWE-smith/ProgramGym 三代同向证据）；(2) 运行时/交互证据能暴露源码静态信息不可见的缺陷（SoftwareGym 消融 + VF-Coder + CUA-SWE 三方一致）。

仍属合理推测的机制：结构多样性→OOD 泛化的传导链（缺直接消融）；dummy/weak-assert 校验的边际贡献分解（四重校验作为整体出现，未逐项消融——这是两篇论文共同的实验缺口）。

失效条件：当模型足够强（DS-V4-Flash 仅 +1.29）或任务上尾足够难（Resolved ≈ 0%、Almost Resolved 被 SFT 拉低）时，环境侧与作业流侧的增益都会衰减；合成环境在纯域内评测仍不敌等量真实数据。双子星解决的是"从 0 到 50 分"的规模化问题，“从 56 到 100"的最后一英里（OSWorld 2.0 显示长时程任务上最强 agent 完成率仅 20.6%）仍是开放问题。

七、必要知识反推：做这两篇论文最少要知道什么

假设一个零基础的人要复现这两条流水线，按层次反推：

领域知识层

• 桌面 GUI 应用的解剖学：什么是布局原型、信息架构、命令绑定、持久化、事件驱动——不知道这些就写不出 FunctionDesigner 的"功能契约”（入口/动作/状态更新/GUI 响应/checkpoint 五元组）。
• 编译型语言的构建生态：Cargo/go.mod/CMake/autotools 的版本兼容陷阱（CMake 4.0 拒绝旧 policy、Rust nightly 特性移除）、动态链接原理（为什么要 ldd 检查）——Program-Env 的双脚本设计与 linter 规则每一条都对应真实的构建失败模式。
• 测试理论：什么是弱断言/恒真断言/非确定性依赖、覆盖率的语义（行覆盖 vs 语句加权基本块）——四重校验与覆盖率反馈的理论底座。

方法论知识层

• 环境合成谱系：知道 OSWorld 的 1800 人时成本、SWE-Gym 的数据效率、InfiniteWeb 的浏览器路线——才能定位"独立桌面应用"与"整程序复现"两个空档。
• 树编辑距离/树结构度量（Zhang-Shasha 算法）、Jaccard 相似度——多样性门控与视觉保真度门控的数学工具。
• 程序分析工具链：Joern 代码属性图/调用图、CodeQL、llvm-cov/gcovr/go tool covdata——“成熟工具+查询裁剪"而不是自研分析器。
• SFT 数据工程：拒绝采样、loss 掩码（无效工具调用置零）、轨迹评分裁判设计。

工程知识层

• 容器化与沙箱：网络隔离、copy-on-write 层、并发写竞争（覆盖率计数器的 lease 协调）。
• 多智能体编排：会话隔离、工件冻结（root 所有权+去写权限）、有界重试、回滚检查点——Program-Agent 的修订管理本质是一套分布式系统的事务协议。
• 评估协议设计：Pass@3 三次独立 rollout、宏平均 vs 任务级通过率的区别、防作弊（execute-only 二进制、无网、禁包管理器）。

知识融合的关键节点

1. “验证即门控"的洞察：把软件工程的验收测试思想（功能契约/checkpoint）与 GUI 执行证据融合，产生"只有 GUI 验证过的功能才能变成任务"的证据门控——这是 SoftwareGym 区别于一切"生成了再说"路线的核心。
2. “哑实现"测试思想：把"对照实验"的方法论（换掉被测对象看测试是否仍通过）引入测试质量校验，dummy check 一条规则就击中了合成测试最致命的失败模式。
3. “反常识的 token 经济学”：直觉是"多阶段=多开销”，但角色隔离+分轨修订反而省 token——因为单会话长轨迹的大部分预算花在上下文膨胀后的重复探索上。这个洞见只有在实测 token 分布后才能获得。

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

灵感 1：合成数据的价值在验证器，不在生成器

• 核心思想：生成模型人人有，差异化在"怎么证明生成的东西是对的”——验证器质量决定监督信号质量。
• 论文证据：SoftwareGym 用冻结用例集跨轮 GUI 评估驱动修复（54.9→91.5%）；ProgramGym 四重校验使 665K 测试全部可信赖，SFT 因此 +7.97。
• 推广场景：RLHF 奖励模型的数据质检（dummy check 思想可迁移为"给随机策略也打高分就剔除该样本”）；工具调用轨迹过滤；自动评测器校准；合成课程数据的难度验证。

灵感 2：运行时证据 > 静态证据，适用于一切"行为型” artifact

• 核心思想：对于交互式/行为式产物，源码级或规格级的静态检查永远无法覆盖"运行起来才暴露"的缺陷面；修复回路必须接入真实执行反馈。
• 论文证据：source-only 修复 48.8% 甚至低于起点 50.4%；GUI 引导 83.1%。
• 推广场景：前端代码评审（截图/DOM 执行证据）；API 契约测试（真实调用 vs mock）；机器人策略验证（仿真执行 vs 静态规划）；配置变更（灰度执行 vs lint）。

灵感 3：用"对照实现"给验证器做证伪测试

• 核心思想：判断一个验证器是否有效，最直接的办法是喂给它一个"已知错误"的实现——若验证器仍通过，验证器本身失效。
• 论文证据：dummy check 把被测程序替换为无意义输出的哑实现；double check 用两次独立执行互为对照。
• 推广场景：评测基准的防作弊审计（灌入随机作答看是否得分）；LLM 裁判的对抗校准；安全规则的回归测试；招聘笔试题的质量筛查。

灵感 4：显式多样性门控，防"伪多样化"坍缩

• 核心思想：让生成器"自由发挥"会得到表面不同、结构相同的输出；必须在表示层（布局树/调用图/语义结构）度量距离并硬性门控。
• 论文证据：简单设计多样性 4.9 分且 12 组全部门控不通过；结构化设计 83.6。
• 推广场景：prompt 扰动数据增强（语义嵌入距离门控）；模型蒸馏的教师样本多样性；红队攻击样本生成；课程学习任务分布控制。

灵感 5：角色隔离+工件冻结是长时程任务的上下文经济学

• 核心思想：与其在单会话里压缩历史，不如把不同认知角色拆到独立会话、用不可变工件传证据——信息密度更高、token 更少、进展永远可构建。
• 论文证据：Program-Agent 用更少 token 把 27B 模型从 34.87 推到 55.71；行为分布转向探索-修订型（read/git 增加）。
• 推广场景：长文档分析流水线（读取/综合/写作分离）；多轮谈判 agent（立场轮换会话隔离）；科研 agent 的文献综述-实验-写作分轨；任何超上下文窗口的工作流。

灵感 6：SFT 提升"及格率"而非"优秀率”——训练信号设计要对准分布位置

• 核心思想：可验证信号筛选的 SFT 数据把大量任务从 0 分拉到部分通过，但对高保真上尾无能为力（甚至挤出效应）——数据工程要知道自己的增益落在分布的哪一段。
• 论文证据：SFT 后 Almost Resolved 从 3.50% 降到 1.50%；≥75% 通过率任务占比 SFT 只从 9.5%（配 Claude Code）改善有限，而作业流从 18.0→34.0%。
• 推广场景：竞赛模型训练（部分分 vs 满分策略）；分级奖励设计；课程难度调度；评测集分层报告。

灵感 7：成本透明是规模化主张的一部分

• 核心思想：声称"可扩展"的工作必须披露单位成本与成本分解，否则无法被社区复现与检验。
• 论文证据：SoftwareGym 给出 $70.76/237 分钟/14.8M tokens/1,718 调用的分阶段分解；ProgramGym 给出 136.77B tokens 的三阶段拆分（可执行 4.66B/dispatcher 1.29B/测试 130.83B）与 per-repo 均值——测试构建占 95.6% 的成本，这个数字本身就指明了后续优化方向。
• 推广场景：数据集构建论文的成本表；agent 服务定价；内部 AI 平台的单位经济学核算。

附录：两篇论文的开放资源

• SoftwareGym：182 应用库 + SoftwareGym-Bench（120 任务）+ 训练模型（Qwen3.5-9B SFT）开源于 GitHub 与 HuggingFace。
• ProgramGym：1,648 环境 + 665K 测试 + 构建代码 + 训练工件承诺开源（HuggingFace / 官网）；30,459 候选库中未处理的部分，流水线全自动，社区可继续扩产。
• 两篇均为 v1 预印本（2026-10-08/09 提交），数字以当前版本为准。