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

TL;DR Dockerless 提出一种**无需执行环境**的补丁验证器，通过**代理式仓库探索**判断代码正确性，实现了完全环境自由的 SFT+RL 训练管线，性能与依赖 Docker 的验证器持平。

问题

问题背景

在训练代码智能体 (coding agents) 的过程中，程序验证器 (program verifier) 是核心组件，它负责判断生成的代码补丁是否正确，从而为监督微调 (SFT) 筛选轨迹、为强化学习 (RL) 提供奖励信号。

现有方法的局限

当前主流的验证方式依赖基于执行的评估，即必须在每个仓库特定的环境（如 Docker 镜像）中运行单元测试。这带来三方面严重局限：

• 环境获取与构建开销巨大：每个仓库需维护独立的 Dockerfile、依赖库和硬件配置，在大规模后训练中成为瓶颈；
• 可扩展性差：在多语言、大规模代码仓库场景下，环境异构性急剧上升，管理和并行化困难；
• 替代方案精度不足：现有无环境方法多采用与参考补丁的文本匹配或静态分析，缺乏对代码语义和仓库上下文的深入理解，容易误判。

为什么该问题既难又重要

技术挑战：不执行代码而判断补丁正确性，需要模型具备多步推理和证据收集能力，能够像人类开发者一样探索仓库、理解调用关系、推断行为——这对模型的理解与规划能力是严格的考验。 业界关注度：随着代码智能体向自动化软件工程演进，环境管理成本已成为规模化部署的障碍。若能实现完全无环境的验证与后训练流水线，可大幅降低基础设施成本，并加速迭代周期，因此各大 AI 实验室均将其视为关键突破方向。

行业类比：这类似于 CI/CD 领域中从每次全量构建到基于缓存和依赖分析的增量测试的转变，核心都是在不损失可靠性的前提下消除繁重的环境准备环节。

核心洞察

• Dockerless 将代码补丁验证从传统的执行依赖转向了基于仓库探索的证据驱动判断。与现有基于单元测试或参考补丁匹配的验证器不同，Dockerless 不运行代码，而是让 agent 自主探索代码仓库来收集证据，从而评估补丁的正确性。这种范式类似于人类代码评审，能够捕捉语法匹配无法发现的语义错误，同时大幅降低了因环境搭建带来的计算和工程成本。
• 该工作首次证明完全环境无关的后训练流水线可以匹配甚至超越基于环境的训练效果。通过在 SFT 阶段用 Dockerless 过滤高质量轨迹、在 RL 阶段用其提供奖励信号，模型在 SWE-bench 等基准上的表现与使用 Docker 执行环境训练的模型相当。这为大规模训练 coding agent 扫清了基础设施障碍，使得训练不再受限于为每个仓库维护独立环境的昂贵开销。

方法

问题设定

给定一个代码仓库、一个问题描述和候选补丁，Dockerless 作为验证器输出一个连续的正确性评分（0-1），而不是简单的二元判断。目标是完全脱离执行环境（如 Docker）完成验证，从而消除环境准备成本。

核心架构：智能体仓库探索

Dockerless 的核心是一个多步智能体验证器，它将验证拆分为两个关键阶段：

1. 问题生成与子智能体探索
   主模型首先生成一系列验证问题（verification questions），每个问题针对补丁的某个潜在风险点（例如："这个函数调用是否匹配参数类型？"）。然后派发子智能体在仓库中进行探索，通过搜索文件、读取代码片段、检查函数签名等操作收集证据。整个过程模拟了人类开发者 review 代码时的信息检索行为。

2. 证据合成与最终评分
   收集到的证据与原始补丁、问题描述一同被送入评分模块。评分模块基于语言模型的深层语义理解，综合证据对补丁正确性给出一个标量分数。训练时使用监督学习，损失函数鼓励模型对正确补丁打出高分、对错误补丁打出低分，同时优化子智能体探索轨迹的生成。

训练与后训练集成

验证器本身通过细调大语言模型（如 Qwen）得到，训练数据包含仓库级上下文、人工构造的正误补丁对及标注标签。训练后，Dockerless 被无缝嵌入环境无关的后训练管线：

• SFT 过滤：用其评分筛选高质量轨迹作为拒绝采样微调（RFT）的训练数据。
• RL 奖励：直接作为强化学习的奖励信号，替代传统的执行通过率。

与同类方法的差异

• 相比执行验证（需完整 Docker 环境），Dockerless 节省了环境构建开销，并在 SWE-bench 验证指标上接近执行级精度。
• 相比零样本 LLM-as-judge，它通过主动式仓库探索收集证据，AUC 提升 14.3 点，验证更可靠。
• 相比基于参考匹配的方法，它不依赖预先存在的参考补丁，适用于开放式的代码修复任务。

实验

实验设计

论文提出 Dockerless 一种环境无关的 agentic 补丁验证器，通过 agentic 仓库探索收集证据来判断代码补丁的正确性，无需实际执行。实验作用于两个方面：

• 验证器评估：在专门构建的 Verifier Evaluation Benchmark 上，对比 Dockerless 与现有开源验证器的 AUC 分数。
• 后训练管线验证：将 Dockerless 同时用作 SFT 轨迹过滤器 和 RL 奖励信号，构建完全无需执行环境的 post-training 管线。在三个 SWE-bench 子集（Verified、Multilingual、Pro）上评估最终模型的 resolve rate。基线包括：原始 Qwen3.5-9B 模型、基于环境执行的 SFT 与 RL 训练结果。

关键发现

• 验证精度大幅领先：Dockerless 的 AUC 超出最强开源验证器 14.3 点，表明环境无关验证器能够通过搜索仓库上下文达到高精度判断。
• 完全环境无关的后训练效果匹配环境依赖方案：使用 Dockerless 进行 SFT 过滤（env-free RFT）的模型，在 SWE-bench Verified 上达到与 env-based SFT 相当的性能；进一步引入 env-free RL 后，整体 resolve rate 在 Verified 上达到 62.0%，在 Multilingual 上达到 50.0%，在 Pro 上达到 35.2%，全面匹配环境依赖的训练结果。
• 多语言扩展优势显著：在 Multilingual 子集上，Dockerless 后训练模型较 Qwen3.5-9B 提升 8.7 点，远高于 Verified 的 2.4 点，说明环境无关验证降低了对各语言特化执行环境的依赖，天然适应多语言场景。
• 环境无关 RL 逼近环境依赖 RL：单独使用 env-free RL 的效果已接近 env-based RL，证明 Dockerless 的奖励信号质量可与真实执行反馈相媲美。

与基线对比解读

环境无关后训练管线彻底移除了每个 repository 都需构建 Docker 镜像的高成本，而性能损失微乎其微。与 Qwen3.5-9B 基线的对比说明，新管线在无执行验证的条件下仍能有效筛选高质量轨迹和提供 RL 指导。与 env-based post-training 相比，性能持平，但大幅降低了基础设施开销；特别是在 Pro 子集上仅落后 0.5 点，这种接近无代价的转换对工程落地意义重大。Dockerless 验证器本身的 14.3 AUC 点提升源自 agentic 探索架构，其深层启示是：未来代码验证器应当主动挖掘仓库结构与上下文，而非被动比对输出字符串。

行业影响

落地场景

Dockerless 可以直接嵌入各类代码生成与修复产品的工作流。在 代码托管平台（如 GitHub、GitLab）中，它可以替代基于单元测试的 CI 验证步骤，对 Pull Request 进行即时、低成本的正误判断；在 IDE 智能编程插件（如 Copilot、Cursor）里，能快速筛选模型生成的候选补丁，仅保留高置信度结果推荐给开发者；在 自动化安全修复 或 代码迁移服务 中，可以直接对批量仓库应用补丁并验证，避免逐项目构建 Docker 环境。

商业价值

主要体现为 显著降低基础设施成本：传统执行验证需要在每个仓库的专属 Docker 镜像中运行测试，计算与存储开销巨大；Dockerless 仅需 LLM 推理，单次验证成本下降 1-2 个数量级。同时，它使 训练迭代速度大幅提升：在 SFT 数据筛选和 RL 奖励计算环节省去笨重的环境准备，后训练流程全自动化。对于提供代码修复 SaaS 的厂商，可借此降低服务单价，并支持对大量仓库的快速适配，从而扩大潜在市场。

与现有产品/工作流接口

Dockerless 设计为 无状态代理验证器，可通过 API 集成。训练侧，它直接替换基于执行的轨迹过滤器和奖励模型，与现有 SFT/RL 管线无缝对接（论文已证明可与环境依赖的训练结果匹敌）。部署侧，可以封装为轻量微服务，输入 <仓库快照, 补丁> 并输出评分，方便 CI 系统、代码审查工具调用。对于已有 LLM-as-judge 流程的团队，可直接替换为零样本验证器获得更高精度，或采用其多轮代理探索模式强化效果。

具体落地案例

1. 企业级代码审查平台：某托管平台的 PR 自动审查功能，原本需为每个提交拉起 Docker 执行测试，耗时且极易因环境不一致而失败。采用 Dockerless 后，可对非关键的风格修复、依赖升级类 PR 进行快速预审，仅将可疑或低分补丁交由人工详细核查，审查效率提升 40% 以上。
2. 在线编程评测系统：如 LeetCode 类平台，接收用户提交的解题代码时，先用 Dockerless 判断语义正确性，快速筛除明显错误提交，减少后端判题沙箱的负载，同时降低整体评测延迟。

Dockerless 为代码验证提供了环境无关、低延迟、可扩展的新范式，将在日益依赖自动化代码智能的行业产生广泛影响。

局限

• **依赖 LLM 的静态判断能力**：Dockerless 通过 agentic repository exploration 搜集证据，再交由 LLM 进行补丁正确性判决，整个过程仍是基于模型对代码和上下文的语义理解，不具备执行环境的**确定性反馈**。对于涉及动态行为、竞态条件、外部 API 依赖或需要通过运行时 assertion 才能暴露的错误，验证器可能产生误判。尽管在 SWE-bench 系列基准上表现接近环境执行，但在需要复杂全局状态或精确输出的任务上，其可靠性仍缺乏理论保证。
• **验证延迟与资源开销**：代理式探索需要多轮工具调用和子代理交互，导致单次验证耗时显著高于直接运行单元测试。论文中分析在 SWE-bench Pro 上平均耗时可达 120 秒，且消耗 token 数量较大。这对大规模训练管线（如 RL 中需要高频 reward 信号）可能构成效率瓶颈，限制了其在成本敏感或实时反馈要求高的场景下的应用。
• **跨仓库泛化与多语言覆盖**：训练数据主要来自 SWE-bench 相关的 Python 仓库，尽管在 Multilingual 子集上有所提升，但模型对非 Python 语言（如 Java、TypeScript）或高度定制化构建系统的项目仍可能存在适应性不足。agentic exploration 策略也依赖于仓库结构的规整性，面对非标准构建流程或复杂依赖网络时，探索效果可能下降，导致验证质量不稳定。