仅凭行为重建一个程序
程序复现不同于多数智能体被训练去做的编码任务。在问题修复类基准中，智能体拿到的是一个代码仓库和一份缺陷报告；在仓库生成类基准中，它拿到的是一份需求文档。而在 ProgramBench 所定义的程序复现任务中，智能体得到的是一个参考程序和它的使用文档，但没有源代码，也不能联网。它必须通过运行参考程序去发现其余行为，然后从零设计实现。
这一设定抽掉了智能体通常依赖的两根拐杖：可供修补的现成代码库，以及可以照做的明确规格。论文指出，在最初的 ProgramBench 评测中，没有任何模型完整解决过一个任务，因此训练需要能提供可靠行为监督的交互式环境。SWE-Gym 和 SWE-smith 这类问题修复资源并不提供这种监督；论文还指出，MindForge 只支持命令行程序，且其监督无法验证。
环境与工作流为何同时失效
论文把问题拆成两个不同的瓶颈。第一个是可验证训练环境的规模化。构建参考可执行文件和运行时沙箱，需要适配各仓库特有的工具链和依赖；黑盒测试既要覆盖多样功能，又要拒绝错误的复现。单次测试生成可能漏掉重要行为，或写出过弱的断言。
第二个是维持长程开发。通用智能体框架支持工具调用，但本身并不能让探索与实现保持协调。智能体可能在充分探索参考程序之前就开始写实现，也可能随着上下文增长而忘记先前观察到的需求。论文的应对办法是一套明确的工作流，用来保存行为证据，并协调实现、审查与修订。
这两个瓶颈解释了为什么论文的贡献被拆成 Program-Env 和 Program-Agent，而不是单一的模型改动。环境质量决定存在什么样的监督；工作流决定智能体能否在长任务中利用这些监督。
修复构建与测试的反馈回路
Program-Env 通过一个反馈驱动的回路，从代码仓库构建训练环境。对于可执行文件和沙箱，它把在线依赖准备与离线编译分开，并把构建诊断信息返回给智能体以指导修复。论文的案例研究具体展示了这个回路：第一次尝试安装了 libopenimageio-dev，却没有安装 OpenEXR 开发包，于是 CMake 找不到 OpenEXRConfig.cmake，离线构建失败。反馈把脚本、错误日志和修复指令打包返回；智能体读后把失败归因于缺少 libopenexr-dev 包，将其加入 apt-get install 列表，修改后的脚本便通过了在线准备、离线编译和动态链接检查。
测试构建按功能模块并行推进。一个调度器按基于复杂度的预算把仓库拆成模块，为可执行文件插桩以收集覆盖率，并抽取文档。每个模块交给各自工作区中的子智能体，多个工作区并行运行。覆盖率插桩采用“规则优先、智能体兜底”的策略：先用语言特定规则生成一个候选插桩，再由校验器检查构建产物和覆盖率元数据是否存在，只有校验失败时才调用大模型智能体去诊断并修复插桩。
测试质量由一组 linter 规则把关，用来拒绝弱断言。这些规则会标记诸如以下模式：成员断言只使用 success 或 error 这类泛化关键词；唯一断言只检查 len(x) > n；测试导入了源码模块；测试在运行时引用源码目录；测试依赖网络、时间或未设种子的随机数。每轮之后的反馈被组织成回答三个问题：哪些已有测试需要修复，下一轮应针对哪些未覆盖代码，以及可以通过哪些公开入口到达这些代码。
这条流水线的产出是 1,648 个训练环境，覆盖 C、C++、Go 和 Rust。每个环境提供参考可执行文件、运行时沙箱、文档，以及用于训练监督的黑盒行为测试套件。
把分析、实现与审查分开
Program-Agent 用一套角色隔离的迭代工作流来应对长程问题，流程分为分析、实现和审查，并配合修订管理来处理编译检查和失败恢复。隔离之所以重要，是因为论文指出的失效模式是过早实现：智能体在记录足够行为证据之前就开始写代码，随后随着上下文增长而丢失这些证据。
工作流先记录证据，再依据证据实现，然后审查。修订管理负责编译检查和失败恢复，使一次失败的构建成为下一轮修订的输入，而不是尝试的终点。论文报告说，增加 Program-Agent 的迭代次数可以继续恢复程序行为，并且是 Program-Agent 而非仅靠监督微调，把智能体引向探索与修订。
环境增益与工作流增益彼此独立
实验使用 ProgramBench。用 Program-Env 收集的轨迹微调 Qwen3.8-27B，把它的成绩从 34.87% 提升到 42.84%。这一比较隔离出了所构建环境的价值：同一基础模型、同一基准，只是增加了监督。
随后 Program-Agent 把基础模型和 SFT 模型分别提升到 55.71% 和 56.25%。按论文说法，这两个数字都超过了一些旗舰模型。这两个数字不应合并成一个标题数字：42.84% 衡量的是基于环境的微调给基础模型带来了多少增益，而 55.71% 和 56.25% 衡量的是工作流在基础模型和微调模型之上又带来了多少增益。把 42.84% 与 56.25% 相比，是在拿微调结果对比工作流结果，而不是同一干预的两个版本。
微调数字背后的训练设置值得注意其规模。论文对全部 1,648 个 Program-Env 任务发起任务级 rollout；由于 Claude Code 在一次 rollout 中会重置或切换对话上下文，一次任务级 rollout 可能产生多个上下文独立的交互片段。每个片段被当作一条独立训练轨迹，合计得到 64,505 条训练轨迹。论文明确指出，这个轨迹数并不对应 64,505 次独立的环境 rollout。
已报告的增益未能确立什么
这些标题百分比是 Qwen3.8-27B 及其微调版和工作流增强版在 ProgramBench 上的结果。论文没有报告这些增益能迁移到其他基础模型、其他基准，或 ProgramBench 设定之外的程序复现任务；而“增强后的模型超过一些旗舰模型”这一说法，在现有证据中并未给出完整的逐模型对比。
环境流水线对测试覆盖也有明确上限。测试生成以 80% 的功能覆盖率为目标，根据仓库难度运行 5 到 20 轮，并在三轮窗口内核心覆盖率增益低于 0.25%、linter 通过率增益低于 20% 时提前停止，最早可在第 5 轮停止。论文承认有些目标无法通过黑盒测试到达，这正是设置提前停止的原因。因此覆盖率低于阈值是环境本身的属性，未必是在其中训练的智能体的失败。
轨迹数也是容易被误读的规模指标。64,505 条训练轨迹来自 1,648 个任务上 rollout 的片段，而不是独立的环境 rollout，因此训练经验的实际多样性比单看轨迹数所暗示的要小。
应归功于工作流而非仅微调
论文自身的拆解为评估这条研究路线的读者指出了一个具体优先级。仅构建环境就把 Qwen3.8-27B 从 34.87% 提升到 42.84%，约提高八个百分点。再加上角色隔离工作流后，基础模型达到 55.71%，微调模型达到 56.25%，都高于仅微调的结果。工作流贡献了最终报告性能中更大的份额，论文也指出是 Program-Agent 而非仅靠 SFT 把智能体引向探索与修订。
这一排序对决定投入方向的人很重要。如果目标是更好的程序复现智能体，这里的证据表明，对分析、实现和审查的协调并不是微调模型外面的装饰性包装，基准增益的很大一部分正出现在这里。环境流水线仍是前提，因为它提供行为监督和训练轨迹，但最终比较更支持把工作流当作一等组件，而不是附加项。
本文引用的文献
ProgramGym：为长程程序复现智能体扩展训练环境
用 Program-Env 轨迹微调 Qwen3.8-27B，把 ProgramBench 成绩从 34.87% 提升到 42.84%；Program-Agent 又把基础模型和 SFT 模型分别提升到 55.71% 和 56.25%。