Dockerless：面向编码代理的环境无关程序验证器

无环境的代理代码验证器，实现完全环境无关的编码代理后训练

前置知识

程序验证器

程序验证器是用于评估代码补丁是否正确解决软件问题的自动化工具。在编码代理训练中，验证器的作用是判断代理生成的代码是否真正修复了 bug 或实现了需求。传统验证器通过执行单元测试来验证，需要在隔离的 per-repository 环境中运行测试用例，如 Docker 镜像，但这带来了巨大的环境设置成本。验证器的输出通常是二元正确性信号（通过/失败）或连续分数，用于监督微调（SFT）的轨迹筛选或强化学习（RL）的奖励计算。

验证器的质量直接决定了编码代理训练数据的筛选标准和 RL 奖励信号的可靠性，是本文提出的 Dockerless 方法的核心应用场景。

监督微调（SFT）

监督微调是训练大语言模型的两个阶段之一，专门用于提升模型在特定任务上的性能。对于编码代理，SFT 通常在高质量的代理执行轨迹上进行，这些轨迹展示了模型如何从初始问题分析到最终代码修复的完整过程。Rejection Fine-tuning（RFT）是 SFT 的一种变体，它通过验证器筛选出通过测试的高质量轨迹，然后在这些轨迹上微调模型。传统方法需要执行测试来验证轨迹质量，这要求为每个仓库构建独立的 Docker 环境。

本文使用 Dockerless 作为环境无关的 RFT 轨迹筛选器，替代昂贵的测试执行，实现了在最小基础镜像上收集和筛选轨迹。

强化学习（RL）

强化学习是大语言模型训练的第二阶段，通过奖励信号引导模型生成更好的输出。对于编码代理，RL 通常在 SFT 模型基础上进行，代理在多个 issue 上执行，每个 rollout 的最终补丁通过测试执行得到奖励。常用算法包括 GRPO（Group Relative Policy Optimization），它通过组内优势归一化来稳定训练。奖励信号可以是二元测试结果或连续分数，多个独立奖励评估会被平均以提高稳定性。RL 需要大量 rollout 和可靠的奖励信号，计算成本远高于 SFT。

本文使用 Dockerless 作为环境无关的 RL 奖励模型，实现了无需 per-repository 环境的 RL 训练，是完全环境无关后训练流水线的关键组成部分。

拒绝采样

拒绝采样是一种数据筛选技术，用于保留符合特定标准的样本，丢弃不符合的样本。在 Dockerless 的训练中，使用 teacher 模型生成问题-答案-判断轨迹，然后只保留那些预测 verdict 与执行标签匹配的轨迹。此外，还通过参数限制负样本与正样本的比例，以缓解类别不平衡问题。拒绝采样确保了训练信号的一致性，使验证器学习如何逐步推理并得出最终判断，而不是依赖偶然匹配。

本文使用拒绝采样在执行标注的候选补丁上训练验证器，这是 Dockerless 训练的核心技术。

研究动机

传统的基于执行的代码验证需要在每个仓库的独立环境中运行单元测试，这带来了巨大的工程开销。构建这些环境需要构建定制的 Docker 镜像、解析每个仓库的依赖关系、识别相关测试、编写测试执行脚本和结果解析器。即使是最先进的自动化流水线也只能在有限的候选仓库中成功运行。更根本的是，许多现实世界的仓库，特别是私有企业或遗留代码库，缺乏可重现的环境或全面的测试套件，使得基于执行的验证不可靠或不可行。论文数据显示，在 SWE-bench 等基准测试中，需要为数千个仓库构建独立的 Docker 环境，这在实际应用中成本极高且难以扩展。

本文的目标是本文的目标是提出一个环境无关的代理验证器，能够在不执行代码的情况下评估生成的代码补丁。这个验证器应该能够替代传统的执行验证，用于监督微调（SFT）的轨迹筛选和强化学习（RL）的奖励计算，从而实现一个完全环境无关的后训练流水线。具体来说，验证器应该在最小的基础镜像上运行，无需 per-repository 的依赖、测试运行器或对环境的访问，同时保持与基于执行验证相当的性能。

与已有工作不同的是，现有的环境无关验证器只使用表面信息对补丁进行评分，从未检查过仓库本身。这种浅层方法对于复杂的软件工程任务来说是不够的，因为确定功能等价性需要深入的仓库上下文：例如，修改后的函数是否真的被失败的行为调用，或者替代实现是否正确集成了周围的模块。Dockerless 的独特切入点是将验证器本身设计为一个主动探索仓库的代理，通过并行子代理收集证据来对补丁进行判断，而不是简单地比较候选补丁与参考补丁的文本差异。这种代理式的、证据驱动的验证方法是首次被应用于 SWE 补丁结果评分场景。

核心方法

Dockerless 的整体思路是将验证过程建模为一个两阶段的代理任务。首先，给定问题描述和参考补丁，验证器生成一组验证问题，这些问题询问修复应该在仓库的哪些位置生效、修补后的代码应该做什么、什么测试或断言能确认正确性，以及仓库的其他部分是否会损坏。然后，为每个问题派发一个子代理，通过只读 shell 工具（如 find、grep、rg）探索仓库，返回简短的、有证据支持的答案。最后，验证器聚合收集到的证据来判断候选补丁是否解决了问题。这个方法的核心直觉是，真正的代码验证需要深入理解代码库的上下文，而不是表面的文本匹配，而代理式的仓库探索能够提供这种上下文。

Dockerless 的核心创新点是将验证器本身设计为一个代理，它主动探索仓库来收集证据，而不是依赖表面的文本比较或执行测试。与现有的环境无关验证器不同，Dockerless 通过并行子代理从代码库中收集多个维度的证据，然后将这些证据聚合为最终的正确性判断。这种方法在不需要 per-repository 环境的情况下，实现了对代码库的深入理解。另一个关键创新是使用拒绝采样在执行标注的候选补丁上训练验证器，确保训练信号的一致性和推理的可解释性。训练过程中，一个共享的主干网络被用于问题生成、子代理探索和最终判断阶段，实现了端到端的联合训练。

方法步骤详情

Dockerless 的操作分为两个阶段。第一阶段：问题生成和探索。给定问题 x 和参考补丁 y_ref，模型提出一组验证问题。这些问题询问修复应该在代码库中的哪些位置生效、修补后的代码应该做什么、什么测试或断言能确认正确性，以及代码库的其他部分是否会损坏。对于每个问题，一个子代理通过只读 shell 工具（如 find、grep、rg）探索仓库，并返回简短的、有证据支持的答案 Ak。K 个子代理并行运行以提高效率。第二阶段：判断。给定问题和收集到的证据对，判断模型输出一个二元 token 0 或 1，其中 1 表示正确的补丁。在推理时，我们将两个 verdict token 的 logits 转换为连续分数，通过 softmax 公式计算。完整的提示词在附录 G 中列出。

技术新颖性

Dockerless 的技术新颖性体现在多个方面。首先，它是首个将代理式仓库探索应用于 SWE 补丁结果评分的验证器，在评分时调用工具并检查代码库本身，而不是从固定提示生成分数。其次，它使用拒绝采样在执行标注的候选补丁上训练，只保留那些预测 verdict 与执行标签匹配的轨迹，确保训练信号的一致性。第三，它在推理时生成 2-4 个验证问题并派发并行子代理，通过多维度证据探查来实现仓库基础的判断，这在之前的验证器中从未出现过。最后，它在 SWE-Gym 和 Multi-SWE-RL 的 3.7K issue 上训练，使用 2-4 个验证问题，实现了在无需 per-repository 环境的情况下达到与基于执行的验证相当的性能。

**Figure 2**: Architecture of Dockerless

**Figure 3**: Training pipeline for Dockerless

**Figure 4**: Env-free post-training pipeline for Dockerless

实验结果

论文的核心发现是 Dockerless 实现了一个完全环境无关的后训练流水线，其性能与标准的基于环境的后训练相当。作为独立验证器，Dockerless 在轨迹级验证器评估基准上达到了 81.0 AUC（SWE-bench Veriﬁed）和 72.1 AUC（Multi-SWE-bench Flash），比最强的开源基线高 14.3 和 9.2 AUC 点。对于 SFT，在 Dockerless 筛选的 top 25% 轨迹（16K 中的 4K）上训练，比在全部环境无关数据池上训练在三个基准上分别提高了 1.8、6.4 和 3.4 点。对于 RL，使用 Dockerless 作为环境无关奖励比使用 DeepSWE Veriﬁer 的 RL 在相同三个基准上提高了 1.4、2.7 和 1.1 点。端到端来看，完全环境无关的后训练流水线产生的模型在 SWE-bench Veriﬁed、Multilingual 和 Pro 上分别达到 62.0%、50.0% 和 35.2% 的解决率，比 Qwen3.5-9B 基线提高 2.4、8.7 和 2.9 点。此外，验证问题的数量 K 从 0 增加到 4 时，AUC 从 78.3 提升到 81.0，但超过 4 个问题后性能不再单调改善（K=6 时 79.6，K=8 时 80.3），表明额外问题经常引入冗余或噪声证据。延迟分析显示，在 RL 设置中，Dockerless 的奖励计算只占总时间的 7.2%，代理 rollout 的 2308s 是主要成本。

**Table 1**: Resolve rate (%) on SWE-bench Veriﬁed, Multilingual, and Pro under env-based evaluation

**Table 2**: Verifier AUC on the trajectory-level veriﬁer evaluation benchmark

**Table 3**: Effect of the SFT data ﬁlter on downstream resolve rate (%) under env-based evaluation

**Figure 5**: Verifier AUC vs. number of veriﬁcation questions

**Figure 6**: Per-rollout wall-clock breakdown during RL under three reward sources

**Figure 7**: Representative case where the candidate patch resolves the issue but uses a different surface form from the reference patch

查看结构化数据

任务	指标	本文	基线	提升
SWE-bench Veriﬁed - Resolve Rate	Resolve Rate (%)	62.0	Qwen3.5-9B: 59.6	+2.4
SWE-bench Multilingual - Resolve Rate	Resolve Rate (%)	50.0	Qwen3.5-9B: 41.3	+8.7
SWE-bench Pro - Resolve Rate	Resolve Rate (%)	35.2	Qwen3.5-9B: 32.3	+2.9
Verifier Evaluation - SWE-bench Veriﬁed	AUC	81.0	DeepSWE Veriﬁer: 66.7	+14.3
Verifier Evaluation - Multi-SWE-bench Flash	AUC	72.1	DeepSWE Veriﬁer: 62.9	+9.2

局限与改进

论文承认的局限性包括：验证问题的数量需要仔细调优，实验表明 K=2-4 是最佳范围，更多问题可能引入冗余或噪声证据；Dockerless 的奖励计算需要多步仓库探索，增加了奖励评估的时间（虽然只占总时间的 7.2%）；训练需要执行标注的候选补丁，这意味着仍然需要一定量的基于执行的数据来训练验证器；对于某些需要复杂运行时行为的验证场景，静态仓库探索可能仍然不够充分。我自己观察到，Dockerless 的性能依赖于问题生成和证据收集的质量，如果生成的问题不相关或子代理探索的路径不准确，判断可能会出错。此外，该方法假设代码库是可读的，对于混淆或加密的代码可能效果不佳。最后，论文主要在开源代码库上评估，对于私有企业代码库的适用性还需要进一步验证。

独立分析的弱点

Dockerless 的主要弱点之一是对问题生成质量的依赖。如果生成的验证问题不相关或不全面，子代理收集的证据可能无法支持正确的判断。改进方向可以是开发更智能的问题生成策略，例如从参考补丁中自动提取关键验证点，或使用 reinforcement learning 来优化问题选择。另一个弱点是子代理探索的效率问题，虽然并行运行，但大规模代码库的探索仍然耗时。改进方向可以是学习探索策略，优先访问最相关的代码区域，或使用代码索引技术加速搜索。第三个弱点是训练数据仍然需要执行标注，这限制了完全环境无关训练的可扩展性。改进方向可以是开发自训练或半监督学习方法，减少对执行标注的依赖。最后，Dockerless 主要处理代码级别的验证，对于需要运行时行为的验证场景可能不够充分，可以结合轻量级执行或符号执行来增强验证能力。

未来方向

作者提出的未来工作方向包括扩展 Dockerless 到更多的验证场景，如安全漏洞检测、性能回归分析和跨语言代码理解。基于成果可延伸的方向包括：将代理式验证应用到其他代码质量评估任务，如代码审查建议、重构建议和测试用例生成；开发自适应的问题生成策略，根据具体 issue 和代码库特征动态调整验证问题的数量和类型；研究如何将 Dockerless 与轻量级执行或符号执行结合，在保持环境无关性的同时增强对运行时行为的验证能力；探索在更多样化的代码库上训练和验证，包括私有企业代码库和遗留系统；研究如何将验证器的证据和推理过程可视化，提高可解释性和用户信任度；最后，可以探索将 Dockerless 集成到实际的软件开发流水线中，作为持续集成和持续交付（CI/CD）的一部分。

复现评估

论文没有明确说明代码和数据是否开源，这是复现性的一个重要限制。训练数据来自 SWE-Gym（3.7K issue）和 Multi-SWE-RL，这些数据集应该是公开的。论文提到使用 Qwen3.5-9B 作为主干网络，训练细节在附录 D.1 中，但具体的超参数设置、训练时间和算力需求没有明确说明。验证器评估基准从 SWE-bench Veriﬁed（500 样本）和 Multi-SWE-bench Flash（276 样本）构建，总共 776 个样本，这个数据集的大小对于充分评估验证器性能来说可能偏小。下游后训练使用 SWE-Rebench-v2，收集了 env-free 轨迹用于 SFT 和 RL rollouts，但具体的数据量和收集过程在附录中。复现难度主要在于需要访问原始数据集、复制训练配置和设置评估环境，尤其是论文没有提供开箱即用的代码或配置文件。论文的实验设计相对完整，包括多个基准和消融实验，但缺乏开源代码和详细的训练脚本会增加复现的难度。

Dockerless：面向编码代理的环境无关程序验证器 Dockerless: Environment-Free Program Verifier for Coding Agents