跳到正文
北京时间
原文
HuggingFace Daily Papers(社区热门论文)·· 2026-05-14精选AI 评分72

Orchard:一个开源智能体建模框架

Orchard: An Open-Source Agentic Modeling Framework

AI 导读

针对智能体建模领域因依赖闭源资源而受限的问题,研究团队推出了开源框架Orchard。其核心是轻量级环境服务Orchard Env,提供跨任务和流程的可复用沙箱管理基元。基于此构建了三个高效智能体方案:编码智能体Orchard-SWE在SWE-bench Verified上达到67.5%的准确率;视觉语言计算机使用智能体Orchard-GUI仅用少量数据便在多项基准测试中取得64.0%-74.1%的成功率;个人助理智能体Orchard-Claw仅用0.2K合成任务便在Claw-Eval上实现59.6%的pass@3成功率。该框架证明了其跨领域实现可复用数据、训练与评估的能力。

推荐理由

开源终于能打低数据量、高性能的 agent recipe 了,Orchard-SWE 在 SWE-bench 拿下 67.5%,只用了 107K 条蒸馏轨迹,小团队也能复现,做 coding agent 的必读。

正文 · AI 翻译

[Uncaptioned image]

摘要

智能体建模旨在将大语言模型(LLM)转变为能够通过规划、推理、工具使用以及与外部环境进行多轮交互来解决复杂任务的自主智能体。尽管投入巨大,但该领域的开放研究仍受限于基础设施和训练方面的差距。许多高性能的智能体系统依赖于专有代码库、模型或服务,而开源框架则主要关注智能体编排和工具设计,而非通过可扩展的模型训练来提升大语言模型的智能体能力。我们提出了 Orchard,一个用于可扩展智能体建模的开源框架。其核心是 Orchard Env,一个轻量级的、原生支持 Kubernetes 的环境服务,为沙箱生命周期管理提供可复用的原语。Orchard Env 旨在跨任务领域、智能体工具以及流水线阶段(包括轨迹蒸馏、在线强化学习(RL) rollout 和评估)运行。在 Orchard Env 之上,我们构建了三种智能体建模方案。Orchard-SWE 针对软件工程智能体:我们从 MiniMax-M2.5 和 Qwen3.5-397B 中蒸馏出 107K 条轨迹,引入信用分配监督微调(SFT)以从未解决轨迹的有效片段中学习,并应用平衡自适应 rollout 进行稀疏奖励强化学习。使用 Qwen3-30B-A3B-Thinking,Orchard-SWE 在 SWE-bench Verified 上经过 SFT 后达到 64.3%,经过 SFT+RL 后达到 67.5%,在同等规模的开源模型中树立了新的最优水平。Orchard-GUI 仅使用 0.4K 条蒸馏轨迹和 2.2K 个开放式训练任务,训练了一个 4B 参数的视觉语言计算机使用智能体。它在 WebVoyager、Online-Mind2Web 和 DeepShop 上分别取得了 74.1%、67.0% 和 64.0% 的成功率(平均 68.4%),成为最强的开源模型,同时与 OpenAI 和 Google Gemini 的专有系统相比也具备竞争力。Orchard-Claw 针对个人助手智能体,用于电子邮件、日历和日常工具使用任务等生产力工作流。仅使用 0.2K 个合成任务进行训练,它在 Claw-Eval 上达到了 59.6% 的 pass@3,当与更强的 ZeroClaw 工具配合使用时,pass@3 提升至 73.9%。这些结果共同表明,一个轻量级、开放且与工具无关的环境层能够实现跨领域和跨工具的智能体数据、训练方案和评估协议复用。我们发布 Orchard 以加速智能体建模研究,并推动开源 AI 社区的创新。

1 引言

Refer to caption

Refer to caption

图 1:性能对比。左图:Orchard-SWE(30B)在 SWE-bench Verified 上达到 67.5%,接近更大的前沿 MoE 系统。右图:Orchard-GUI(4B)在 WebVoyager、Online-Mind2web 和 DeepShop 上平均成功率达 68.4%,使其成为最强的开源 GUI 智能体,同时与 OpenAI 和 Google 的专有系统持平。

能够与环境进行多轮交互的大语言模型(LLM)智能体,已成为从软件工程(Jimenez 等人,2024;Yang 等人,2024)、网页导航(Zhou 等人,2024;Zhang 等人,2025;Ning 等人,2025)到通用计算机操作(Xie 等人,2024;Hu 等人,2025)等各类任务的核心范式。训练此类智能体——无论是通过专家轨迹的监督微调,还是基于环境奖励的强化学习——都需要生成大量 rollout 轨迹,每条轨迹涉及与沙盒执行环境的数十次顺序交互。

随着智能体训练和评估扩展到新的领域和更大的数据集,对开放、可扩展、经济实惠且利于研究的底层基础设施的需求日益迫切。例如,为单个软件工程任务生成一条轨迹,可能涉及克隆代码仓库、安装依赖项、应用代码编辑并运行测试套件——所有这些都必须在需要配置、管理和清理的隔离容器内完成。在大规模场景下,数千个此类环境必须同时运行,每个环境都有不同的基础镜像、资源需求和网络隔离约束。

我们将环境层识别为根本性的瓶颈。当环境层封闭或与特定训练栈紧密耦合时,其上的每一层——训练方案、评估流程、轨迹收集——都会继承这些约束,无法独立复现或复用。现有系统在环境管理部署位置上有不同选择,各有利弊。E2B(E2B, 2024)、Daytona(Daytona, 2025)和 Modal(Modal Labs, 2024)等托管沙箱平台提供了便捷的托管运行时,但研究人员对基础设施配置、成本和可复现性的控制有限。ProRL Agent(Zhang 等人, 2026a)和 MegaFlow(Zhang 等人, 2026b)等垂直集成训练栈将环境管理作为更大规模部署或训练系统的一部分,使其与推理调度、奖励计算和训练循环编排相耦合。ROCK(Wang 等人, 2026)等更广泛的环境框架提供了丰富的平台功能,但并未将环境层隔离为最小服务边界。其结果是,轨迹数据集、训练方案和评估流程往往与特定的框架或基础设施实现绑定,难以复现、比较或复用。

我们认为,环境层应成为一个轻量级、独立的服务,可在三个维度上复用:(i)跨任务领域,(ii)跨领域内的智能体框架,以及(iii)跨流程阶段,包括轨迹蒸馏、在线策略强化学习展开和评估。当这一边界清晰时,其上的各层也变得可复用:数据可以在一个框架下收集,在另一个框架下评估;监督微调和强化学习方案可以共享同一个执行后端;新领域可以复用同一套基础设施,而无需重建。

Refer to caption
图 2:Orchard 框架概览。Orchard 环境(中心)是一个轻量级的、基于 Kubernetes 的环境服务,它暴露了通用原语——沙箱生命周期、命令执行、文件输入输出、网络策略、REST API 以及轻量级智能体注入——并支持异构任务环境(底部一行)。开放训练配方(第二行)与该服务组合使用,但无需与其耦合,我们在三个领域(顶部一行)实例化了相同的技术栈:Orchard-SWE(软件工程)、Orchard-GUI(浏览器导航)和 Orchard-Claw(AI 个人助手);每个领域的核心数据汇总于各领域框内。

因此,我们提出了 Orchard(图 2),这是一个以轻量级、可复用的环境层为核心的可扩展智能体建模开放框架。其核心组件 Orchard 环境是一个基于 Kubernetes 的服务,它暴露了通用原语——沙箱生命周期管理、命令执行、文件输入输出、网络策略和 REST API——而不与任何智能体框架、训练器、推理后端或任务领域耦合。Orchard 环境通过两个关键选择实现扩展:运行时智能体注入,允许任意特定任务的 Docker 镜像独立运行;以及将执行和文件请求直接路由到沙箱 Pod IP,避免了 Kubernetes exec/WebSocket 的开销。结合网络隔离、异步生命周期管理、心跳清理和基于 watch 的就绪状态跟踪,这些机制使 Orchard 环境具有广泛的组合性,并适用于大规模环境交互。实验表明,其平均命令执行延迟为 0.28 秒,可承受 1000 个沙箱的压力测试且成功率为 100%,并且相较于其他方案,其沙箱成本显著降低。

在 Orchard 环境之上,我们开发了三种智能体建模(SFT+RL)方案,这些方案与环境服务组合使用,但无需紧密耦合。这些方案负责处理轨迹收集、数据整理、奖励计算和策略优化。我们使用从面向浏览器智能体的 Qwen3-VL-4B-Thinking 到面向软件工程和个人助理智能体的 Qwen3-30B-A3B-Thinking(30 亿活跃参数)等不同基座模型对它们进行了实例化。在三个领域中,相同的环境抽象支持了多种模态、工具接口、智能体框架和奖励机制。

Orchard-SWE。

在软件工程方面,Orchard-SWE 针对开放 SWE 智能体训练的两个关键瓶颈:监督信号有限和奖励稀疏。我们整理了 107K 条轨迹,这些轨迹来自使用 OpenHands(Wang 等人,2025b)和 mini-swe-agent(Yang 等人,2024)两种框架,对 MiniMax-M2.5 和 Qwen3.5-397B 在 SWE-rebench(Badertdinov 等人,2025)、SWE-rebench V2(Badertdinov 等人,2026)和 Scale-SWE(Zhao 等人,2026)上的表现进行知识蒸馏而得。与大多数现有方案不同,我们不仅保留了已解决的轨迹,也保留了未解决的轨迹。我们引入了信用分配 SFT,该方法利用回溯性价值估计从失败的轨迹中提取有效的进展片段,将部分进展转化为监督信号。我们进一步应用了平衡自适应展开(BAR),这是一种在线展开分配方法,能够自适应地组装奖励平衡的轨迹组,用于稀疏奖励的强化学习。使用 Qwen3-30B-A3B-Thinking,Orchard-SWE 在 mini-swe-agent 框架下,经过 SFT 后在 SWE-bench Verified 上达到了 64.3% 的解决率,经过 SFT+RL 后达到 67.5%,在同等规模的开源模型中树立了新的最先进水平,同时与规模大得多的模型相比也具备竞争力。

Orchard-GUI。

对于基于浏览器的图形用户界面智能体,Orchard-GUI 表明,相同的环境服务和方案可以迁移到纯文本计算机使用任务之外。我们训练了一个 4B 视觉语言骨干模型,并搭配通用的 ReAct 风格(Yao 等人,2023)浏览器框架,在 WebVoyager(He 等人,2024)、Online-Mind2Web(Deng 等人,2023)和 DeepShop(Lyu 等人,2025)上进行了评估。经过 SFT+RL 训练后,Orchard-GUI 在这三个基准测试上的成功率分别达到 74.1%、67.0% 和 64.0%,平均总体成功率为 68.4%,其中在长周期基准测试(即 Online-Mind2Web 和 DeepShop)上提升最为显著。尽管使用了 4B 骨干模型且仅基于 2.6K 训练任务,这仍是开源领域的新最优水平,同时与领先的专有计算机使用系统保持竞争力。值得注意的是,Orchard-GUI 大幅超越了之前的开源智能体及其 235B 教师模型,这表明基于环境强化的 RL 可以提升模型的智能体能力,使其超越教师模型。

Orchard-Claw。

对于个人助手智能体,Orchard-Claw 研究了机器学习得到的智能体技能是否可以在不同框架之间迁移。我们从 Claw-Eval(Ye 等人,2026)种子数据和 ClawHub(OpenClaw,2026)工作流中合成训练任务,蒸馏成功的 MiniMax-M2.5 轨迹,在 Qwen3-30B-A3B-Thinking 上进行智能体训练(SFT+RL),并在多个框架上评估,包括 ReAct 风格框架和 ZeroClaw(ZeroClaw Labs,2026)框架。Orchard-Claw 在 Claw-Eval 上分别达到 31.7% 和 59.6%,尽管仅使用了 0.2K 合成任务,仍显著优于同等规模的开源基线。当在推理时搭配更强的 ZeroClaw 框架时,同一模型进一步提升至 41.0% 和 73.9%。

综合来看,三种智能体建模方案的结果支持了本研究的核心论点:环境层不仅仅是一个基础设施组件,更是决定智能体建模产物可复用性的基础。一个轻量、开放、与框架无关的环境服务,能够使轨迹数据、SFT 配方、RL 展开以及评估协议跨领域、跨智能体框架和流水线阶段进行迁移。Orchard 证明了,开源智能体建模可以在不将环境与任何单一训练栈耦合的情况下,以既经济高效又可复现的方式进行规模化。我们发布了完整的 Orchard 框架——包括环境服务、训练配方以及涵盖软件工程、GUI 导航和个人助手工具使用的轨迹数据集——以促进可扩展智能体建模领域的开放研究。

2 Orchard 环境

跨领域和跨任务扩展智能体训练对环境层提出了特定要求。我们确定了环境服务作为研究社区实用基础所需满足的三项核心需求:

  1. 1.

    轻量、独立的服务边界。环境管理应被隔离为一个精简的服务——与智能体框架、模型服务和训练编排解耦——以便任何训练器、智能体设计和任务领域的组合都能与同一服务协同工作。

  2. 2.

    低成本的镜像兼容性。该服务应以较低的适配成本支持异构任务环境和任意 Docker 镜像。

  3. 3.

    可访问且规模化后成本可控。该服务应能部署在任何标准云基础设施上,使大规模智能体训练变得经济实惠且易于采用。

本节描述了 Orchard 环境如何实现这些需求,介绍了其架构和关键设计选择,并将其与现有系统进行了比较。更多细节可参见附录 A。

2.1 架构概览

Orchard Env 采用三层架构,如图 3 所示:一个提供同步和异步 Python 接口的客户端 SDK,一个管理沙箱生命周期和调度的编排器,以及一个注入到每个沙箱容器中的轻量级 Pod 内智能体。

Refer to caption
图 3:Orchard Env 架构。Python 客户端 SDK(同步或异步)向 FastAPI 编排器发起 REST 调用,编排器在 Kubernetes 集群中管理沙箱生命周期。Pod 的创建和删除(冷路径)通过 Kubernetes API 服务器进行,而所有执行、文件和健康检查请求(热路径)则通过 Pod IP 直接分发到每个沙箱 Pod 的 Pod 内智能体,绕过了 API 服务器,避免了 kubectl exec/WebSocket 建立连接的开销。

这种三层分离体现了三个经过深思熟虑的设计选择。首先,编排器和 Pod 内智能体独立部署和扩展:生命周期决策(创建、删除、就绪状态)通过中央编排器流转,而每条命令的执行流量则直接分发到每个沙箱的 Pod 内智能体,将控制平面操作与延迟敏感的热路径隔离开来。其次,Pod 内智能体在运行时注入到用户提供的镜像中,而非在构建时固化,因此任意任务镜像无需逐个修改即可集成。第三,整个技术栈运行在标准 Kubernetes 原语(Pod、NetworkPolicy、Watch)之上,继承了开放生态系统的工具、多云可移植性以及集群自动扩缩容和竞价实例等成本优化方案。我们依次描述每一层。

客户端 SDK。

Orchard Env 提供同步(SandboxClient)和异步(AsyncSandboxClient)两种 Python 客户端。沙箱根据用户指定的 Docker 镜像创建,并提供用于命令执行、文件上传/下载和应用补丁的方法。上下文管理器提供自动清理功能,SDK 还公开了心跳工具,用于在需要时保持长期运行的沙箱处于活动状态。SDK 还包含可配置的重试逻辑,针对瞬时连接错误和服务不可用错误采用指数退避策略。

编排器。

编排器是一个 FastAPI 服务,以 Kubernetes Deployment 形式部署,并运行多个副本。它对外暴露 REST API 用于沙箱生命周期管理,并可跨副本将沙箱元数据追踪委托给可选的 Redis 后端。其关键职责包括:沙箱预配——将 `POST /sandboxes` 请求转换为 Kubernetes Pod 规格,包括初始化容器配置、资源限制、网络策略和就绪探针;就绪状态追踪——PodWatcher 组件维护一个持久的 Kubernetes LIST+WATCH 流,缓存 Pod 状态转换,并在 Pod 就绪时唤醒被阻塞的客户端;执行调度——ExecManager 通过直接向 Pod IP 发起 HTTP 调用,将执行请求路由到目标沙箱的 Pod 内智能体,并通过每个沙箱的锁对发往同一沙箱的并发请求进行序列化;生命周期管理——后台协调循环检测并清理孤儿沙箱(即心跳已过期或其底层 Pod 已被驱逐的沙箱)。

Pod 内智能体。

Pod 内智能体¹¹(此处“智能体”指沙箱侧的执行服务,而非本文其他部分研究的基于大语言模型的智能体)是一个轻量级 FastAPI 服务器,运行在每个沙箱容器内部。它对外暴露命令执行(`/exec`)、文件上传、下载、列表查看及健康检查等端点。命令作为子进程执行,并带有可配置的超时时间;超时后,通过进程组信号终止整个进程树。该智能体仅能通过沙箱 Pod 的内部集群网络端点访问,其健康检查端点同时用作 Kubernetes 的就绪探针。

2.2 与现有系统的对比

为了将 Orchard Env 与现有系统进行定位比较,表 1 根据上述需求,从四个维度对环境和训练基础设施进行了对比:是否存在可供研究人员自行部署的开源服务器栈;该系统是否主要作为托管服务运行;是否提供轻量级的独立环境服务;以及在研究规模下的相对成本。具体来说,当满足以下条件时,我们将一个系统视为轻量级环境服务:(i) 环境管理是该系统的主要范围,而非智能体工具、训练编排或大语言模型服务的副产品;(ii) 环境层提供稳定的 API——通常是一个用于沙箱生命周期和命令执行的小型 REST 接口——该接口不要求调用方采用该系统的训练器、调度器或 rollout 抽象层;(iii) 该 API 独立于智能体工具、强化学习训练器和推理后端的选择,因此同一服务可以互换地用于知识蒸馏、强化学习 rollout 和评估。我们重点介绍 Orchard Env 定位的三个方面的内容(该比较基于截至 2026 年 4 月的公开文档和代码仓库):

媒体内容 · 前往原文查看
表 1:用于智能体训练的环境和训练系统,基于截至 2026 年 4 月的公开文档。范围:系统的主要设计范围。自行部署:存在开源服务器/控制平面栈,研究人员可将其部署在自己的基础设施上。托管默认:系统的主要产品作为托管/托管服务提供。轻量级环境服务:环境管理作为一个狭窄、独立的服务边界暴露出来,独立于智能体工具、训练循环和推理后端(上述操作性定义)。相对成本:以 Daytona 为基准进行归一化,针对一个 2 vCPU、8 GiB 的沙箱;“—”表示没有公开可比的定价。方法详见附录 B。
系统 范围 自行部署 托管默认 轻量级环境服务 相对成本
E2B 托管沙箱 ✓† ✓ ✓ 1.0
Daytona 托管沙箱 ✓† ✓ ✓ 1.0
Modal 计算平台 ✗ ✓ ✗ 1.5
SkyPilot 计算编排 ✓ ✗ ✗ —
ROCK 环境框架 ✓ ✗ ✗ —
ProRL Agent rollout 基础设施 ✓ ✗ ✗ —
MegaFlow 训练编排 ✗ ✗ ✗ —
Orchard Env 环境服务 ✓ ✗ ✓ 0.47∗

∗0.10 使用竞价实例。†E2B 和 Daytona 提供了有限的开源服务端组件,但其主要产品是托管控制平面,Rel. cost 列反映的是该托管服务的价格。

轻量环境服务与集成式、广泛型系统的对比。

ProRL Agent(Zhang 等人,2026a)实现了一项重要的解耦——通过 HTTP 服务将 rollout 生命周期与 RL 训练器分离——但其环境层仍然与智能体框架(通过 AgentHandler 插件)、大语言模型推理路由以及评估逻辑耦合在同一个 rollout 服务器中。MegaFlow(Zhang 等人,2026b)同样将环境管理嵌入到一个更大的训练编排系统中。Modal(Modal Labs,2024)则完全是另一个类别:它是一个通用的无服务器计算平台,提供灵活的函数和容器执行能力,但并非专门作为用于智能体训练的轻量环境服务,其托管控制平面和按秒计费的模式难以在长期运行的 RL 训练任务中分摊成本。ROCK(Wang 等人,2026)提供了一个更广泛的环境框架,包含多种协议和更丰富的平台组件,其目标范围远超轻量服务边界。SkyPilot(Kim,2025)提供了开源的多云计算编排能力,可以作为 Orchard Env 部署的底层基础设施;两者是互补而非竞争关系。E2B(E2B,2024)和 Daytona(Daytona,2025)与 Orchard Env 类似,都将环境管理作为独立的沙箱服务提供,但它们是托管产品,拥有托管控制平面和由供应商决定的定价。Orchard Env 独特的技术选择在于智能体注入:一个 Kubernetes init 容器在 Pod 启动时将自包含的执行智能体复制到任何用户提供的 Docker 镜像中,从而避免了重建任务镜像的需要。这使得 Orchard Env 能够支持数百种异构任务环境——例如 SWE-bench 所需的各种镜像——而无需对每个镜像进行修改。

部署可移植性。

Orchard Env 的目标是研究者可控的基础设施:任何标准 Kubernetes 环境——无论是托管型(AKS、EKS、GKE)还是自托管型——都能运行完整技术栈,并对资源分配、网络策略和自动扩缩容拥有直接控制权。这与面向 HPC 的系统(如 ProRL Agent)形成对比,后者需要访问机构级 Slurm 集群和 Singularity 运行时,从而限制了其在特定机构研究者中的采用。

成本是设计选择的结果。

表 2 比较了 128 个并行沙箱(每个 2 vCPU、8 GiB)在 240 小时内的预估成本——这是一个典型的强化学习训练工作负载。由于 Orchard Env 在标准 Kubernetes 上自托管,它自然受益于云原生的成本优化:临时沙箱节点可运行在竞价实例上,集群自动扩缩容可根据实际需求调整容量。这使得使用竞价实例时的成本降至 673 美元——比 Daytona 和 E2B 等托管方案低 10 倍。即使按按需定价计算,Orchard Env(3,362 美元)的成本也不到 Daytona(7,078 美元)和 E2B(7,078 美元)的一半。详细分解见附录 B。

媒体内容 · 前往原文查看
表 2:128 个并行沙箱在 240 小时内的预估成本(30,720 沙箱小时)。目标配置:每个沙箱 2 vCPU、8 GiB 内存。成本已归一化至 Daytona。价格来自截至 2026 年 4 月的官方费率表;详见附录 B。
系统 美元/沙箱小时 成本(美元) 与 Daytona 对比
Daytona 0.230 7,078 —
E2B 0.230 7,078 0%
Modal 0.335 10,305 +46%
MegaFlow† 0.150(估算) 4,608(估算) 35%
Orchard Env(按需) 0.109 3,362 53%
Orchard Env(竞价) 0.022 673 90%

†MegaFlow 未公开定价;标记为(估算)的单元格是根据 Zhang 等人(2026b)中报告的基础设施使用情况估算得出的。

2.3 系统评估

对于智能体数据生成和强化学习训练而言,最关键的系统指标是环境交互延迟——它直接决定了推理吞吐量和 GPU 利用率。我们从三个维度评估 Orchard Env:(i) 与现有服务相比的执行延迟,(ii) 高并发下的可靠性,以及 (iii) 在下游智能体评估中与直接 Docker 基线的功能等价性。除非另有说明,所有测量均使用一个由 8 个节点(每个节点 32 vCPU、128 GiB 内存)组成的 Kubernetes 集群,部署在通用云虚拟机上,每个节点上预先拉取了沙箱镜像,每个沙箱配备 2 vCPU 和 8 GiB 内存。

执行延迟。

我们使用 SkyPilot Code Sandbox(Kim, 2025)的基准测试方法,在四个环境服务之间比较平均命令执行延迟,所有平台采用相同的基准测试设置。

媒体内容 · 前往原文查看
表 3:Orchard Env 的系统评估。左图:各环境服务的平均命令执行延迟(越低越好;基准测试方法遵循 Kim (2025))。右图:在 Terminal-Bench 2.0 上,使用 Orchard Env 与直接 Docker 基线的智能体通过率(%),每个单元格取 3 次运行的平均值,确认环境服务层未导致性能回退。
系统 平均延迟(秒)
Orchard Env 0.280
SkyPilot Code Sandbox 0.284
E2B 0.747
Modal 2.046
模型 Docker Orchard Env
GPT-4.1 34.1 35.1
MiniMax-M2.5 52.6 54.4
Qwen3-8B-thinking 7.0 8.8

如表 3 所示,Orchard Env 实现了 0.28 秒的平均执行延迟,基本与 SkyPilot Code Sandbox(0.284 秒)持平,并显著优于 E2B(0.747 秒,慢 2.7 倍)和 Modal(2.046 秒,慢 7.3 倍)。这验证了 Orchard Env 的直接 Pod-IP 通信设计:通过将执行请求直接路由到 Pod 内的智能体,并在热路径上绕过 Kubernetes API 服务器,Orchard Env 在保持基于 Kubernetes 部署的灵活性的同时,实现了与优化后的原生运行时相当的延迟。

并发下的可靠性。

为了对 Orchard Env 进行大规模压力测试,我们并行运行了 1,000 个沙箱,贯穿其完整生命周期:创建 → 执行 4 条命令 → 删除。

媒体内容 · 前往原文查看
表 4:1,000 个并行沙箱完整生命周期(创建 → 4 次执行 → 删除)的压力测试结果。
指标 值
并行沙箱 1,000
每个沙箱的命令数 4
成功率 100%
端到端耗时 26 秒
平均创建时间 11.75 秒
平均执行延迟 0.28 秒

如表 4 所示,Orchard Env 在全部 1,000 个会话中实现了 100% 的成功率——在创建、执行或清理环节均未出现失败——整个测试在 26 秒内端到端完成。换算这些端到端数据,Orchard Env 在整个创建-执行-删除生命周期中,每秒可维持约 154 条命令的处理量(26 秒内在 1,000 个沙箱中处理 4,000 条命令),远超典型智能体知识蒸馏和强化学习工作负载在此并发度下所需的吞吐量。这些结果证实,Orchard Env 的架构——基于就绪状态跟踪、每个沙箱的锁定机制以及基于心跳的清理策略——在大规模智能体训练所需的并发水平下依然保持可靠。

与 Docker 的功能等价性。

除了基础设施指标之外,我们还验证了 Orchard Env 在下游智能体评估中不会引入性能退化。我们使用三种不同能力的模型,将 Orchard Env 与直接的 Docker 基线在 Terminal-Bench 2.0(Merrill 等人,2026)上进行了对比;报告的数字是每个(模型,后端)组合在 3 次独立运行中的平均值。如表 3(右)所示,Orchard Env 在所有三种模型上的表现与 Docker 相当,差异在运行间的波动范围内,并且在每种情况下都略有优势(1–2 个百分点)。这证实了智能体注入机制和 Orchard Env 的执行路径在智能体-环境交互中不会引入可观测的开销或干扰。

3 Orchard-SWE

本节介绍 Orchard-SWE,即 Orchard 训练方案在软件工程领域的具体实现。我们将描述问题设定、轨迹收集流程、两阶段训练方案、在 SWE-bench Verified 上的主要结果,以及用于隔离关键设计选择的消融实验。

3.1 问题设定

任务与评估。

我们针对 SWE-bench 任务设定(Jimenez 等人,2024):给定一个 GitHub 问题描述以及问题提交时仓库的快照,智能体必须生成一个能解决该问题的代码补丁。只有当解决方案通过了与真实拉取请求关联的完整黄金测试套件时,才被判定为正确。我们使用 SWE-bench Verified(OpenAI,2024)——一个包含 500 个实例、经人工验证的子集——作为主要评估基准。我们还在 SWE-bench Multilingual(Yang 等人,2025a)和 Terminal-Bench 2.0(Merrill 等人,2026)上报告了辅助评估结果。

智能体框架与工具接口。

该智能体以多轮 ReAct 风格循环(Yao 等人,2023)运行:在每一步,它生成一个推理轨迹(思考)和一个工具调用(行动),然后在继续执行前观察环境响应。工具接口包括 shell 命令执行、文件查看与编辑以及补丁提交。所有环境交互都通过 Orchard Env 服务进行路由:每个任务实例在从特定任务 Docker 镜像配置的隔离沙箱(2 vCPU,8 GiB 内存)中运行,Orchard Env 的智能体注入机制透明地处理镜像异构性。Orchard-SWE 的一个独特之处在于,我们使用两种不同的智能体框架——功能完备的 OpenHands(Wang 等人,2025b)框架和轻量级的 mini-swe-agent(Yang 等人,2024)——来收集轨迹,并研究框架设计如何影响轨迹特征及下游训练结果(第 3.6 节)。

3.2 轨迹收集与整理

我们通过从强大的教师模型进行大规模轨迹蒸馏,并辅以系统性过滤和整理,构建了 Orchard-SWE 数据集。表 5 总结了最终数据集的构成。

任务来源。

我们从三个来源抽取任务实例:(1)SWE-rebench(Badertdinov 等人,2025),这是一个大规模的真实世界 GitHub 问题集合,配有可执行的基于 Docker 的测试环境。我们使用其经过过滤的子集,该子集应用了质量和难度过滤条件,以保留既具可解性又非平凡的任务实例,覆盖超过 1400 个 Python 仓库。(2)SWE-rebench V2(Badertdinov 等人,2026),这是 SWE-rebench 的语言无关扩展版本,收集了更多软件工程任务。它提供了超过 3.2 万个容器化可执行任务,涵盖 20 种编程语言333在我们的实验中,为与任务池其余部分保持一致,我们主要使用其 Python 任务。以及超过 3600 个仓库,并配有预构建镜像。我们将 SWE-rebench V2 全部保留用于强化学习训练。(3)Scale-SWE(Zhao 等人,2026),这是一个补充性任务来源,从 5200 个仓库的真实 GitHub 拉取请求中构建了 10 万个任务实例。每个实例都打包了 Docker 镜像、一个黄金补丁以及自动生成的测试脚本,显著扩展了可用于轨迹收集的仓库和问题类型的多样性。

多教师轨迹生成。

我们使用多个教师模型来增加成功轨迹的多样性,同时保持下游动作空间固定。对于每个任务实例,我们通过 Orchard 环境采样五条 rollout 轨迹,并保留所有成功解决任务的轨迹。我们的教师模型池包括 Qwen3.5-397B(Qwen 团队,2026)和 MiniMax-M2.5 230B(MiniMax,2026)。在 SWE-rebench 上,我们在 mini-swe-agent 和 OpenHands 两种框架下收集来自两个教师模型的轨迹。实验表明,MiniMax-M2.5 的任务通过率更高,而 Qwen3.5-397B 偶尔会发出 OpenHands 工具接口中未定义的工具调用。基于这些观察,我们在 Scale-SWE 上仅使用 MiniMax-M2.5 作为教师模型,因为该场景下实例数量更大,rollout 效率和稳定性变得更加重要。在所有情况下,教师模型都通过评估时使用的同一沙箱工具接口进行交互,从而确保收集到的轨迹与下游动作空间保持一致。

框架选择。

我们使用两种智能体框架收集轨迹:OpenHands(Wang 等人,2025b)和 mini-swe-agent(Yang 等人,2024)。在 SWE-rebench 上,我们同时使用两种框架,以便轨迹收集覆盖更广泛的交互风格和工具使用模式。对于 OpenHands 的运行,我们遵循其标准的 SWE-bench 工具配置。444https://github.com/OpenHands/benchmarks/tree/main/benchmarks/swebench 对于 Scale-SWE,我们仅使用 mini-swe-agent,这是一个轻量级框架,工具集极简(bash 执行、文件编辑、提交),因为我们未观察到该数据源上相对于 OpenHands 存在显著性能差距,且更轻量的框架更适合大规模 rollout 收集。这种双框架设置也让我们能够分析框架选择如何影响下游训练结果(第 3.6 节)。

过滤与整理。

与大多数仅保留成功(已解决)轨迹进行 SFT 的先前工作不同,我们在训练语料中同时保留了已解决和未解决的轨迹。已解决轨迹提供标准的模仿信号;未解决轨迹则通过时序差分信用分配进行筛选,以提取连续上升片段——即轨迹取得进展的区间——这些片段提供部分进展监督(在第 3.3 节中形式化)。我们还应用了以下质量过滤器:(1)超过 64K tokens 的轨迹被裁剪以确保训练稳定性;(2)包含工具接口中未定义的工具调用(主要在使用 Qwen3.5-397B 时观察到)的轨迹被丢弃;(3)包含语法无效或无法解析的动作的轨迹被移除。

媒体内容 · 前往原文查看
表 5:Orchard-SWE 训练数据集的构成。该语料同时保留了已解决和未解决的轨迹:已解决轨迹提供直接的模仿信号,而未解决轨迹则通过信用分配 SFT 提供部分进展信号。
来源 教师模型 已解决 未解决 总计 工具框架
Scale-SWE MiniMax-M2.5 33,527 20,591 54,118 mini-swe-agent
SWE-rebench MiniMax-M2.5 13,364 10,099 23,463 mini-swe-agent
SWE-rebench Qwen3.5-397B 15,545 1,846 17,391 mini-swe-agent
SWE-rebench MiniMax-M2.5 12,213 0 12,213 OpenHands
总计 74,649 32,536 107,185

经过过滤后,Orchard-SWE 数据集包含 107K 条轨迹(74.6K 条已解决,32.5K 条未解决),涵盖 19,287 个独特的任务实例,平均每条轨迹包含 47.5 次交互轮次和约 21K tokens。我们将包含已解决和未解决轨迹的完整数据集作为开源成果发布。

3.3 训练方案

我们的训练方案遵循两阶段流程:首先在教师模型蒸馏的轨迹上进行监督微调(SFT),然后结合环境反馈的奖励进行强化学习(RL)。两个阶段均使用 Orchard Env 作为执行后端。

3.3.1 第一阶段:基于信用分配的监督微调

我们从基础主干网络初始化,并在经过筛选的教师轨迹上进行微调。每个训练样本都将问题描述和仓库上下文与完整的多轮交互轨迹配对,序列化为一系列观察和行动。遵循长周期智能体训练的标准做法,我们应用多轮掩码机制,使得环境观察结果不参与损失计算,模型仅被训练来预测其推理轨迹和行动。

我们监督微调阶段的一个显著特征是使用了信用分配监督微调,它不仅包含了 74.6K 条已解决轨迹,还纳入了经过筛选的、可识别出部分进展的未解决轨迹子集。我们将信用分配实现为一种基于轻量级大语言模型的时序差分价值估计变体,其公式如下。

回顾性价值估计。

对于每条未解决轨迹,我们使用该轨迹自身的教师模型作为零样本回顾性价值函数。教师模型会看到完整的轨迹以及真实的测试结果,并被要求估计在每一步,智能体在给定历史的情况下解决该问题的概率:

(1)

教师模型会标注一组稀疏的关键步骤,其余步骤的价值通过插值得到,从而形成逐步骤的价值曲线。由于这种判断是回顾性的且以结果为条件,该价值曲线能够很好地校准实际进展:在我们标注的轨迹中,98.9% 的情况下曲线呈倒 U 形,在探索阶段达到峰值,并在接近失败的提交时衰减。确切的提示词格式如下所示。

上升段提取。

我们将逐步骤的信用定义为估计成功概率的时序差分偏移,

(2)

并提取上升段:即智能体取得正向进展的最大连续子序列,也就是说,对于所有步骤(使用一个小阈值来过滤标注噪声)。555我们使用;敏感性分析见附录。上升段通常较短(在合并周围上下文之前,中位数为 2 步),但捕捉了原本不成功轨迹中的有效部分——仓库导航、文件定位以及部分根因分析。

SFT 目标函数。

我们在动作 token 上使用标准的下一个 token 交叉熵损失进行训练,并掩蔽环境观测值以及任何不属于上升区段的动作 token:

其中, 是轨迹 中参与损失计算的 action token 集合。对于已解决轨迹, 包含所有 action token(相当于一个覆盖整个轨迹的单一区段,因为终止值为 1)。对于未解决轨迹, 被限制在提取出的上升区段内的 action token,而之前的历史记录则作为上下文保留。经过这样的构造后,32,536 条未解决轨迹提供了以探索为重点的监督信号,补充了来自已解决轨迹集的完整求解与提交轨迹。

我们使用 slime (Zhu et al., 2025) 对 Qwen3-30B-A3B-Thinking (Qwen Team, 2025) 进行训练,共训练五个 epoch,全局 batch size 为 128,上下文窗口为 64K,学习率采用余弦退火策略从 降至 。尽管训练时使用的最大序列长度为 64K,我们在推理时将上下文限制扩展到 128K,以容纳更长的仓库上下文和交互历史。

3.3.2 第二阶段:基于平衡自适应展开(BAR)的强化学习

从 SFT 检查点开始,我们应用强化学习来提升模型从错误中恢复以及探索替代解题路径的能力。奖励信号是二元的且基于环境:如果最终补丁在沙箱中通过了黄金测试套件,则轨迹获得奖励 ,否则为 。Orchard Env 的快速执行延迟(每条命令 0.28 秒;第 2.3 节)在此阶段至关重要,因为每次 RL 展开都需要数十次环境交互,而训练吞吐量直接取决于沙箱的响应速度。

系统设计与组件编排。

我们的强化学习系统构建于 slime (Zhu et al., 2025) 后训练框架之上,扩展了其基于 Ray、Megatron-LM 后端的训练架构以及基于 SGLang 的推理架构,以支持异步智能体强化学习。该系统由四个松散耦合的服务组成,这些服务通过 Ray actor 句柄和 HTTP 端点进行通信,使得每个组件都可以独立地进行扩展、替换或重启。

  • •

    策略训练器。一个基于 Megatron-LM 的分布式训练器,采用张量、流水线、专家和上下文并行分片,拥有可训练参数,并使用优势加权策略梯度执行优化步骤。

  • •

    推理服务。一个基于 SGLang 的推理服务,前端设有请求路由器,服务于最新的策略快照。它支持 KV 缓存复用、确定性采样种子以及每个模型 token 的对数概率提取。

  • •

    沙盒执行服务。一个从 Orchard Env 初始化的沙盒运行时。每个智能体轨迹都绑定到一个隔离的沙盒中,在该沙盒中,可以通过 Orchard Env 安全地执行 bash 命令和单元测试套件。

  • •

    智能体循环驱动器。一个按样本运行的异步协程,用于编排推理服务与执行沙盒之间的工具调用交互。在每一步中,它使用聊天模板和注册的 bash 工具模式对运行中的消息历史进行分词,查询推理服务,从助手消息中解析出结构化的工具调用,在沙盒内执行该调用,并将生成的观察结果作为工具消息追加。当智能体提交补丁、超出步数、挂钟时间或模型 token 预算,或因罕见的沙盒故障而中止时,循环终止。

编排是异步且流水线化的。当训练器正在为第 轮更新权重时,中央回滚管理器已经为第 轮分派了生成任务。中央回滚管理器还实现了对部分失败轨迹的稳健处理,因此单个沙盒故障不会导致优化器崩溃。

我们的智能体循环驱动引擎采用多层超时与重试层级(沙箱创建、大语言模型推理、观测执行、沙箱关闭、总奖励评估)进行加固,在保证端到端可靠性的同时约束尾部延迟。当沙箱崩溃归因于资源耗尽时,CPU和内存分配会在重试时自动升级,并在沙箱创建前注入少量随机抖动,以防止数百条并发轨迹同时启动时出现惊群效应。在模型token空间应用损失掩码,使得梯度仅通过助手生成的token流动;工具结果token被显式掩码,这使得多轮智能体强化学习在标准语言模型交叉熵目标下具有良好定义。

3.3.3 平衡自适应展开(BAR)

对于SWE等具有挑战性的智能体任务,GRPO(Shao等人,2024)使用的标准固定组展开存在两个主要问题:

  • •

    计算浪费。当策略在某个提示词上表现胜任时,所有轨迹往往都会成功;当策略不胜任时,所有轨迹往往都会失败。在这两种情况下,生成的组奖励方差为零,对每个token贡献的advantage为零,并被静默丢弃——然而我们已经为这些长耗时、与环境绑定的轨迹付出了计算成本。

  • •

    组不平衡噪声。当某个提示词的成功率远离平衡点时,即使是一个"非退化"的组也会被正面或负面样本主导,由此产生的GRPO advantage值带有噪声,并偏向于占比过高的那一类。

媒体内容 · 前往原文查看
算法1 针对单个提示词的平衡自适应展开(BAR)

1:提示词;策略;奖励函数;环境工厂

2:训练组大小;最大预算;步长(满足)

3:正样本比例区间;理想比率

4:一个训练组,其中

5:已完成轨迹池

6:当执行时

7:并行生成步长

8:对于每个

9:

10:

11:如果满足条件则

12:返回提前停止:已找到平衡组

13:结束条件判断

14:结束循环

15:宽松回退方案

16:如果满足条件则返回

17:结束条件判断

18:返回尽力而为回退方案

19:

20:过程TryAssemble()

21:将划分为、,并将剩余部分(中止/超时)放入回填堆。

22:按(状态、响应长度)升序排序和,优先选择已完成且简洁的轨迹

23: 如果 则 返回

24: 结束 如果

25: ; ;

26: 对于 按 排序 执行

27:

28: 如果 且 则

29: 返回

30: 结束 如果

31: 结束 循环

32: 返回

33: 结束 过程

我们通过平衡自适应展开(BAR)——一种渐进式、群体感知的展开算法——来解决这两个问题。与那些丢弃零方差提示词(Yu 等人,2025;Le 等人,2025)、使用历史成功率预过滤提示词(Bae 等人,2026;Zheng 等人,2025b),或事后对过大的展开集进行下采样(Xu 等人,2025;Shang 等人,2025;Zhang 等人,2026c)的动态采样和难度过滤方法不同,我们的方法在线执行、基于每个提示词、按步幅进行群体组装。它会自适应地持续生成,直到能够构建出一个固定大小的训练群体,该群体的正奖励比例落在目标区间内,同时还会考虑轨迹状态、截断、沙箱失败和长度等因素。这使得展开调度器能够与长周期智能体环境中的群体相对估计器直接兼容。

对于每个提示词,我们设定了三个数量:一个训练组大小(优化器实际将消耗的轨迹数量)、一个最大预算(我们愿意生成的轨迹数量上限)以及一个步长(增量生成批次的大小)。此外,我们还指定了一个目标正奖励分数区间,理想比例为 。算法流程如下:我们生成轨迹,用奖励模型对其进行评分,并将已完成轨迹池划分为正集(奖励为 的轨迹)和负集(其他轨迹),在此之前先将中止或截断的轨迹移至回填堆。然后,我们尝试组装一个恰好包含 条轨迹的训练组,其正分数位于 内,且最接近理想比例 。在每个类别内,轨迹按终止状态排序(已完成 > 截断 > 中止)666此处也可使用其他排序标准,例如按轨迹长度、模型似然度、多样性或估计不确定性等排序,以便优先选择简洁、正常终止的轨迹。如果存在可行的组,我们提前停止并返回该组;否则,生成另一个步长并重试。如果在 条轨迹后仍无法构建平衡组,则回退到宽松选择(正分数位于 内的任意值),并根据需要用最佳回填轨迹进行填充。

因此,BAR 表现为一种任意时刻、自定步调的展开调度策略:1)对于简单或已掌握的提示词(其中第一步的正面结果占绝对优势),不会触发进一步生成——该提示词要么被过滤掉,要么以满足下限所需的最小正面结果数量返回;2)对于困难提示词(正面结果稀少),会持续生成,直到发现足够多的正面结果或预算耗尽;3)对于平衡良好的提示词,在第一步附近即可完成,并产生信息量最大的梯度。其结果是提高了每个梯度批次的平均信息密度。重要的是,BAR 能够与 GRPO、GSPO(Zheng 等人,2025a)以及任何其他基于组相对优势的估计器无缝组合,因为它需要满足的契约仅仅是“为每个提示词返回一组轨迹列表”。

最终组级过滤。

由于奖励是由嘈杂的真实环境产生的(沙箱创建可能超时,容器可能被驱逐,大语言模型可能在步骤中途达到其 token 预算),即使在一个原本有效的组内,某些轨迹也可能不包含可用的学习信号。因此,我们在展开循环中插入了一个组级过滤器,在奖励计算之后、该组被纳入训练批次之前进行评估。被丢弃的组只需从过采样提示词中补充,这便将训练批次大小与生成批次大小解耦,并保持了梯度质量。

过滤与平衡自适应展开(BAR)被设计为协同工作:BAR 最大化生成组在首次尝试时即满足过滤条件的概率,而过滤则为 BAR 返回的任何结果提供硬性正确性保证。两者共同实现了一种奖励感知的课程学习机制,该机制在每个梯度步骤中在线执行。这些组件共同构成了一条容错、吞吐量优化的流水线,用于在长周期、沙盒约束的智能体任务上进行端到端强化学习,其中平衡自适应展开将固定批次的展开转变为一种自定进度的、信息密集型的展开。样本组内展开轨迹的最终估计优势值使用组奖励进行归一化,其中 表示分配给展开轨迹 的奖励。强化学习最多训练 150 步,全局批次大小为 128,上下文窗口为 64K,使用从 开始的余弦衰减学习率。我们采用展开批次大小 16,训练组大小为 ,最大预算和步幅以鼓励并行展开。使用的目标正奖励分数区间为 。

数据选择。
媒体内容 · 前往原文查看
表 6:SWE-rebench v2 上的性能。带有 † 的基线结果来自 Badertdinov 等人(2026),这些模型在包含 60 个任务的 Python 子集上进行了评估。Orchard-SWE 在完整的 Python 子集上进行了评估。所有模型均使用 mini-swe-agent 框架进行评估。
模型 pass@1 pass@3
Claude Opus-4.5† 36.11% 36.67%
GLM-4.7† 27.22% 31.67%
MiniMax-M2.1† 26.11% 31.67%
Gemini† 25.56% 33.33%
DeepSeek-V3.2† 23.33% 31.67%
GPT-5.2† 20.56% 23.33%
gpt-oss-120b† 8.89% 16.67%
Orchard-SWE 22.36% 27.94%

在强化学习训练中,我们使用 SWE-rebench V2 的所有 Python 子集数据以及 SFT 阶段未使用的 Scale-SWE 数据构建了一个任务池。我们首先在每项候选任务上对初始 SFT 模型进行 8 次 rollout 评估,以获取其初始通过率。表 6 报告了初始 Orchard-SWE SFT 检查点在 SWE-rebench V2 上的性能以及基线结果。Orchard-SWE SFT 在整个 Python 子集上达到了 22.36% 的 pass@1 和 27.94% 的 pass@3。随后,我们仅保留通过率处于特定范围内的任务,过滤掉那些要么难度过高无法提供可靠学习信号、要么对 SFT 模型来说已经过于简单的任务。这一筛选对于极具挑战性的 SWE-rebench V2 尤为重要:如表所示,即使是最先进的模型在该数据集上的通过率也仅为 20%-40%。经过筛选后,最终的强化学习训练集包含约 2000 个实例。我们采用 mini-swe-agent 作为强化学习训练的框架。

3.4 主要结果

表 7 按基础模型系列分类,将 Orchard-SWE 与开源 SWE-agent 方案在 SWE-bench Verified 上进行了比较。Orchard-SWE 在 SFT 后达到 64.3%,采用完整的 SFT+RL 方案后达到 67.5%,且仅使用 30 亿活跃参数:其 Qwen3-30B-A3B MoE 骨干网络在推理时从总共 300 亿参数中激活了 30 亿参数。在此活跃参数预算下,Orchard-SWE 与激活参数多一个数量级的密集开源基线模型相比具有竞争力甚至更优:它超越了表中所有 Qwen 2.5 32B 和 Qwen 3 32B 开源方案——包括 OpenSWE-32B(使用 SWE-Agent 达到 62.4%)、SWE-Master-32B-RL(61.4%)、CoderForge-32B(59.4%)和 SWE-Mirror-LM(52.2%)——并且超越了最强的密集 72B 系统(Kimi-Dev 60.6%,OpenSWE-72B 65.0–66.0%)。

媒体内容 · 前往原文查看
表 7:SWE-bench Verified 上的解决率(%)。我们将 Orchard-SWE 与按基础模型系列分类的开源 SWE-agent 方案进行了比较。在每个部分内,行按报告的解决率排序。Orchard-SWE 所在行以粗体显示。作为更广泛的背景参考,前沿专有系统(Claude Opus 4.5、GPT-5.2、Gemini 3 等)在该基准测试上达到了 71–77%。
系统 基础模型 框架 解决率(%)
开源方法:Qwen 2.5 32B Coder 系列
R2EGym-Agent(Jain 等人,2025) Qwen2.5-32B-Coder-Base R2E-Gym 34.4
Openhands-LM(Wang 等人,2025b) Qwen2.5-Coder-32B-Inst. OpenHands 37.2
Skywork-SWE(Zeng 等人,2025) Qwen2.5-Coder-32B-Inst. OpenHands 38.0
SWE-Agent-LM(Yang 等人,2025a) Qwen2.5-Coder-32B-Inst. SWE-Agent 40.2
SWE-Mirror-LM(Wang 等人,2025a) Qwen2.5-Coder-32B-Inst. MOpenHands 52.2
SWE-Compressor(Liu 等人,2025) Qwen2.5-32B-Base OpenHands 57.6
SWE-Master-32B(Song 等人,2026) Qwen2.5-Coder-32B-Inst. R2E-Gym 57.8
SWE-Master-32B-RL(Song 等人,2026) Qwen2.5-Coder-32B-Inst. R2E-Gym 61.4
开源方法:Qwen 3 32B 系列
FrogBoss(Sonwane 等人,2025) Qwen3-32B R2E-Gym 54.6
SWE-Lego-Qwen3-32B(Tao 等人,2026) Qwen3-32B OpenHands 52.6
CoderForge-32B(Ariyak 等人,2026) Qwen3-32B OpenHands 59.4
开源方法:Qwen 2.5 32B 系列
daVinci-Dev-32B(Zeng 等人,2026) Qwen2.5-32B-Base SWE-Agent 56.1
OpenSWE-32B(Fu 等人,2026) Qwen2.5-32B-Base OpenHands 59.8
OpenSWE-32B(Fu 等人,2026) Qwen2.5-32B-Base SWE-Agent 62.4
开源方法:Qwen 2.5 72B 系列
SWE-Fixer-72B(Xie 等人,2025) Qwen2.5-72B-Base Agentless 32.8
daVinci-Dev-72B(Zeng 等人,2026) Qwen2.5-72B-Base SWE-Agent 58.5
Kimi-Dev(Yang 等人,2025b) Qwen2.5-72B-Base Agentless 60.6
OpenSWE-72B(Fu 等人,2026) Qwen2.5-72B-Base OpenHands 65.0
OpenSWE-72B(Fu 等人,2026) Qwen2.5-72B-Base SWE-Agent 66.0
同尺寸基线模型与我们的模型(30B-A3B;约 3B 激活参数)
Qwen3-30B-A3B-Instruct — OpenHands 22.0
Qwen3-Coder-30B-A3B-Instruct — OpenHands 51.6
GLM-4.7-Flash-30A3B(Team 等人,2025) — — 59.2
Scale-SWE-Agent(Zhao 等人,2026) Qwen3-30B-A3B-Instruct OpenHands 64.0
Orchard-SWE(SFT) Qwen3-30B-A3B-Thinking mini-swe-agent 64.3
Orchard-SWE(SFT) Qwen3-30B-A3B-Thinking OpenHands 62.1
Orchard-SWE(SFT+RL) Qwen3-30B-A3B-Thinking mini-swe-agent 67.5
同尺寸家族性能提升

在 30B-A3B 系列内部进行同维度对比最为清晰。Orchard-SWE 在 SWE-bench Verified 上相比 Qwen3-30B-A3B-Instruct 实现了 45.5% 的绝对提升(SFT 后、SFT+RL 后),并且也大幅超越了代码专用模型 Qwen3-Coder-30B-A3B-Instruct(51.6%)以及通过更广泛蒸馏得到的 GLM-4.7-Flash-30A3B(59.2%)。在相近规模下最接近的竞品是基于相同骨干系列的 Scale-SWE-Agent(64.0%)。Orchard-SWE 在 SFT 条件下与其持平,并在 SFT+RL 条件下超越它。这隔离出了 Orchard-SWE 配方本身的效果——多教师蒸馏、多测试框架数据收集、信用分配 SFT 以及 RL——而非底层基础模型的任何优势。

同一个 Orchard-SWE(SFT)检查点在 mini-swe-agent 测试框架下达到 64.3%,但在 OpenHands 下为 62.1%,这表明单一条件下的排行榜分数对测试框架的选择很敏感。这种敏感性成为第 3.5 节的核心实证问题:当我们在多个测试框架和任务上将 Orchard-SWE 与最接近的开源方案(Scale-SWE、OpenSWE-32B)并列评估时,差异变得更加显著——Orchard-SWE 在未见过的测试框架和分布外任务上仍能保持能力,而其他模型则性能崩溃。

3.5 对未见测试框架和任务的泛化能力

在 SWE-bench Verified 上,Scale-SWE(64.0%)和 OpenSWE-32B(62.4%)报告的解决率相近。单一基准分数可能掩盖智能体泛化能力上的巨大差异。因此,我们在三个测试框架——OpenHands、mini-swe-agent 和 Kimi-CLI(月之暗面,2026)——以及三个不同任务上对每个模型进行评估:SWE-bench Verified、SWE-bench Multilingual(Yang 等人,2025a)和 Terminal-Bench 2.0(Merrill 等人,2026)。这三个系统在训练数据收集过程中均未使用 Kimi-CLI,使其成为本研究中的一个未见测试框架。

媒体内容 · 前往原文查看
表 8:跨测试框架与任务分布的泛化能力。在匹配条件下报告各系统的解决率(%)。SWE-V = SWE-bench Verified;SWE-M = SWE-bench Multilingual;T-Bench 2.0 = Terminal-Bench 2.0。* 表示原始论文中报告的数字;未标记的条目为我们自己在匹配条件下的评估;✗ 表示该系统在该测试框架下产生了格式错误的工具调用,无法得出有效的解决率。
OpenHands mini-swe-agent Kimi-CLI(未见过的)
系统 SWE-V SWE-V SWE-M SWE-V T-Bench 2.0
Scale-SWE 64.0∗ ✗ ✗ ✗ ✗
OpenSWE-32B 62.4∗ 54.9 28.7 3.6 0.0
Orchard-SWE 62.1 64.3 51.0 45.0 20.1
单一测试框架训练导致的框架锁定问题非常严重。

我们发现 Scale-SWE(Zhao 等人,2026)在其原生测试框架之外的任何框架下都会产生无效输出,无法得出可测量的解决率。OpenSWE-32B(Fu 等人,2026)在结构上仍然有效,但性能急剧下降:从其在原生 OpenHands 上的 62.4% 降至 mini-swe-agent 上的 54.9%(下降 7.5 个百分点),以及 Kimi-CLI 上的 3.6%(下降 58.8 个百分点)。相比之下,Orchard-SWE 在所有三个测试框架上的表现都保持在 45.0%–64.3% 的狭窄区间内,最差情况下的下降幅度相对于其自身最佳表现被限制在 19.3 个百分点以内。在 Scale-SWE 和 OpenSWE-32B 中观察到的两种失败模式(灾难性的格式失败和解决率下降)有着相同的根本原因——在单一测试框架下训练的模型并未学到与测试框架无关的软件工程技能。这种模式正是我们在受控实验中的跨测试框架消融研究所预测的(第 3.6 节,表 10);在这里,我们看到同样的失败模式在两个独立开发的开源方案中上演。

跨分布泛化。

在 mini-swe-agent 测试框架下的 SWE-bench Multilingual 上,Orchard-SWE 从 64.3%(Verified)降至 51.0%(绝对下降 13.3 个百分点,相对下降 20.7%)。OpenSWE-32B 从 54.9% 降至 28.7%(绝对下降 26.2 个百分点,相对下降 47.7%)。Orchard 的相对下降幅度大约只有一半,这表明跨 SWE-rebench 和 Scale-SWE 的多教师知识蒸馏提供了比任何单一来源更广泛的代码仓库和问题类型覆盖。

向 Terminal-Bench 2.0 的跨领域迁移。

Terminal-Bench 2.0 评估了比 GitHub Issue 解决更广泛的终端交互任务类别。在 Kimi-CLI 框架下,Orchard-SWE 保持了 20.1% 的解决率,而 OpenSWE-32B 则降至 0.0%。两个系统相对于它们在 SWE-bench Verified 上的得分均有大幅下降,但只有 Orchard-SWE 在这个领域外基准测试上保留了非微不足道的能力。我们假设,训练过程中更广泛的轨迹多样性——多个教师模型、多个框架和多个任务来源——相比更狭窄的训练语料库,提供了对更多样化的工具使用和终端交互模式的间接接触。

讨论。

表 8 中可见两个大体上独立的泛化改进:跨框架的鲁棒性和跨任务的鲁棒性。两者都归因于 Orchard-SWE 方案在三个层面的多样性选择。数据设计:轨迹跨越两个框架(mini-swe-agent、OpenHands)、两个教师模型(MiniMax-M2.5、Qwen3.5-397B)和三个互补的任务来源(SWE-rebench、SWE-rebench V2、Scale-SWE),产生了 107K 条在框架、仓库结构和 Issue 类型上各异的轨迹。Orchard Env:它使数据设计选择在大规模上变得可行,并且仅暴露沙箱生命周期、命令执行和文件 I/O——不对其之上的框架或工具模式施加任何假设——任何框架都可以在零适配成本下与同一环境层组合。学习设计:信用分配 SFT 从仅解决轨迹方案所丢弃的未解决轨迹中提取部分进度监督,从而拓宽了学生模型所看到的探索模式,而平衡自适应 rollout(BAR)通过在完整难度谱系内的每个提示组中强制平衡的正/负样本混合,使 RL 梯度保持信息量。然而,Orchard-SWE 有所改进但并未解决泛化问题:在 Kimi-CLI Verified 上的下降是显著的,而完全未见过的框架或领域条件仍然构成重大挑战。

3.6 消融实验与分析

我们对 Orchard-SWE 中的关键设计选择进行了消融实验,以了解它们对最终结果的贡献。四个问题指导了我们的分析:(i) 数据规模如何与选择策略相互作用?(ii) 训练后的模型与工具框架的耦合程度如何?(iii) 与仅使用已解决轨迹训练相比,信用分配 SFT 带来了什么贡献?(iv) 在大规模 SFT 基础上,强化学习又增加了什么?

数据规模与选择策略。

我们首先研究 SFT 性能如何依赖于训练数据规模和选择策略。我们保持配方不变——相同的基座模型、相同的 SFT 超参数、mini-swe-agent 工具框架、无 RL——仅改变训练轨迹数量()以及从已解决轨迹池中选择这些轨迹所使用的策略。选择策略分为两类:

1) 启发式基线(不使用黄金补丁信息):随机:从已解决池中均匀随机采样。多样化仓库:通过限制每个仓库的轨迹数量来最大化仓库多样性。集中仓库:将样本集中在已解决数量最多的“核心”仓库上。2) 基于属性的选择器(使用黄金补丁特征作为问题复杂度的信号):多文件:优先选择黄金补丁修改了多个文件的实例。大差异:优先选择黄金补丁差异较大的实例。复合:基于多个黄金补丁属性的复合评分。

媒体内容 · 前往原文查看
表 9:数据规模和选择策略对 SWE-bench Verified 上仅 SFT 解决率(%)的影响,在 mini-swe-agent 工具框架下评估。所有单元格使用相同的超参数;仅(轨迹数量)和选择策略不同。每行最大值以粗体显示。
启发式基线 基于属性的选择器
随机 多样化仓库 集中仓库 多文件 大差异 复合
512 45.8 44.0 47.9 47.5 49.5 48.1
1024 50.3 49.0 51.3 51.6 52.2 52.1
2048 52.8 52.2 53.4 54.2 52.9 53.7

表9报告了仅在SWE-bench Verified上进行SFT(监督微调)的解决率。该表呈现两个主导模式。首先,在测试的每一种数据规模下,数据量都压倒选择策略。在最差的方法(多样化代码库,44.0→52.2)上将数据量翻倍两次(512→2048),可获得+8.2个百分点的提升,这比所有选择策略在512数据量下5.5个百分点的全距还要大,更远大于2048数据量下2.0个百分点的全距。其次,不同选择策略之间的差距随数据量增加而单调缩小:512数据量下为5.5个百分点,1024数据量下为3.2个百分点,2048数据量下为2.0个百分点。在足够的数据规模下,选择策略本身的重要性远不如数据量。

有几个具体行为值得注意。大差异补丁在小数据量下取得了最强结果(512数据量下为49.5%),但饱和最早,从1024到2048数据量仅提升+0.7个百分点,这很可能是因为大差异黄金补丁的池子有限,额外样本来自更接近整体均值的分布。反直觉的是,集中代码库在小数据量下比多样化代码库高出3.9个百分点,在2048数据量下差距缩小至1.2个百分点:在小数据规模下,对少数几个代码库的深入接触比浅层覆盖多个代码库能产生更具迁移性的行为。基于属性的选择器在512数据量下略优于启发式基线,但到2048数据量时已与基线趋同,这表明黄金补丁启发式方法充当了一种样本高效的先验知识,在数据充足时随机采样也能达到相同效果。

即使表9中最差的(方法,数据量)组合(512数据量下为44.0%)也比底层基础模型(22.0%,表7)的解决率提升了22个绝对百分点,这证实即使少量高质量SFT轨迹也能提供相对于基础模型的大部分结构性提升。然而,在SFT-only条件下,整个消融网格在2048数据量下停滞在约54%,而完整的Orchard-SWE方案——使用全部107K条轨迹语料库并加入RL(强化学习)——在SWE-bench Verified上达到了67.5%。

使这种扩展变得实用的是 Orchard Env 本身。其薄层、与框架无关的服务边界让同一环境层能够服务于任何框架,从而在不增加额外基础设施成本的情况下实现多框架数据收集和训练。与图像无关的智能体注入机制允许将任意任务图像添加到语料库中,而无需针对每张图像进行重建。低命令执行延迟(0.28 秒;第 2.3 节)保证了高 rollout 吞吐量。而低廉的成本(比托管替代方案便宜一个数量级;表 2)使得大规模数据收集和 RL rollout 对学术研究团队而言成为可行。

跨框架泛化。

为了评估训练期间的框架选择是否会影响训练模型在评估时的泛化能力,我们进行了一项受控对比实验:使用从 MiniMax-M2.5 蒸馏得到的 SWE-rebench 上的 12K 条已解决轨迹,我们仅改变收集框架,并采用其他完全相同的方案训练两个 SFT 模型。然后,我们在 SWE-bench Verified 上对每个模型在两个框架下进行评估,结果如表 10 所示。

媒体内容 · 前往原文查看
表 10:SWE-bench Verified 上的跨框架泛化。行表示用于收集训练轨迹的框架,列表示评估时使用的框架。所有四个单元格均使用相同的训练数据(SWE-rebench 上的 12K 条已解决轨迹,MiniMax-M2.5 教师模型)和相同的 SFT 方案;仅框架配对不同。对角线上的条目(训练/评估框架匹配)以粗体显示。
评估框架
训练框架 mini-swe-agent OpenHands
mini-swe-agent 57.9 19.0
OpenHands 28.0 53.5

交叉测试框架矩阵揭示出明显的对角线与非对角线差距。在训练时使用的同一测试框架上评估的模型,其解决率达到 53.5%–57.9%,但在不匹配的测试框架下,性能骤降至 19.0%–28.0%。这种不对称性表明,OpenHands 轨迹(其暴露了更丰富的工具语义和更结构化的观测)向更简单的 mini-swe-agent 设置迁移的效果略优于反向迁移。然而,主导效应在于模型并未学习到与测试框架无关的 SWE 技能:工具调用格式、观测结构以及轮次级约定都与训练时所见到的测试框架紧密耦合。这一发现与 Qwen3-Next-Coder 报告(Cao 等人,2026 年)中关于测试框架耦合的同期观察结果一致。其含义是,没有任何单一测试框架的训练语料库能够产生一个在各类测试框架生态中都能良好泛化的智能体;多测试框架训练是必要的。

信用分配 SFT 的效果。

我们通过一项受控的、规模匹配的对比实验,分离出信用分配 SFT 的贡献。从完整的已解决轨迹池出发,我们子采样出 32K 条已解决轨迹,使得已解决基线在规模上与 32,536 条未解决轨迹的上升段相匹配,然后使用其他完全相同的配方训练两个 SFT 模型:(i) 仅已解决轨迹(32K 条轨迹),以及 (ii) 已解决轨迹 + 带有信用分配 SFT 的未解决轨迹(32K 条已解决轨迹 + 32K 条上升段轨迹)。在 SWE-bench Verified 上,仅已解决轨迹的基线达到了 59.3%,而添加信用分配 SFT 后,解决率提升至 61.2%——提升了 1.9 个百分点。这一增益验证了信用分配 SFT 能够从原本被丢弃的未解决轨迹中提取有用的监督信号,而非拟合噪声。在完整的 Orchard-SWE 配方中,同样的信号与更大的 74.6K 已解决语料库相结合,共同促成了在 SWE-bench Verified 上 64.3% 的显著成绩。

强化学习的效果。

一个自然的问题是,强化学习的收益在多大程度上取决于其所基于的监督微调检查点的强度——尤其是在分布外泛化方面,过度的监督微调可能会减少强化学习保留跨分布能力的空间。我们比较了从两个监督微调检查点初始化的强化学习,这两个检查点在监督量上相差约两个数量级:一个中等检查点(表9的Composite/单元格,在SWE-bench Verified上为48.1%)和一个重度检查点(完整的107K轨迹方案,64.3%)。我们在mini-swe-agent下,在SWE-bench Verified(分布内)和SWE-bench Multilingual(分布外)上进行了评估。这两个初始模型对强化学习的反应截然不同。从中等初始化开始,强化学习在两个维度上都有提升,其中分布外的增益大于分布内的增益:Verified(提升pt)和Multilingual(提升pt)。从重度初始化开始,强化学习仍然提升了Verified(提升pt),但Multilingual略有下降。我们将此解读为一种特化效应:重度监督微调将策略置于训练分布的一个更尖锐的模式上,因此基于策略的细化强化了分布内行为,但牺牲了分布外迁移能力;而中等基础保留了更多的行为多样性,因此相同的强化学习信号起到了广泛覆盖的细化作用,而非狭隘的优化。

4 Orchard-GUI

本节介绍Orchard-GUI,这是我们针对多模态图形用户界面智能体的Orchard训练方案的具体实现。我们将描述问题设定、轨迹收集流程、两阶段训练方案以及在评估基准上的主要结果。

4.1 问题设定

我们采用浏览器使用智能体的标准任务设定:每个任务由一个起始 URL 和一条自然语言描述的用户意图(例如,“在亚马逊上找一张可水洗且长度至少 30 英寸的狗床”)定义。智能体必须从提供的起始 URL 出发,在浏览器界面内导航,与实时网页交互,并通过生成自然语言的最终答案(或执行所请求的操作)来完成任务。任务成功与否通过大语言模型作为评判者进行评估,该评判者根据最终响应和截图序列,对照用户意图对执行轨迹进行评分。我们在三个基准上进行评估:i) WebVoyager (He 等人,2024);ii) Online-Mind2Web (Deng 等人,2023);以及 iii) DeepShop (Lyu 等人,2025)。我们使用与 FARA (Awadallah 等人,2025) 和 Molmo-Web (Gupta 等人,2026) 相同的评估协议,以确保公平比较。

4.2 通用工具调用智能体框架

我们没有采用诸如 Browser-Use777https://github.com/browser-use/browser-use 这类定制的浏览器智能体框架,而是有意使用通用的多轮 ReAct 风格循环 (Yao 等人,2023)。这种设计选择避免了将框架特定效果与数据或训练方法的差异混为一谈,更重要的是,它能够实现一种统一的智能体学习范式,该范式可以推广到图形用户界面导航之外的多个领域和任务。

具体来说,每个回合开始时都会有一个系统提示词,用于指定智能体的角色、高级操作指南以及以标准 OpenAI 工具格式定义的操作模式。遵循标准图形用户界面智能体的实践,我们使用 OpenAI 工具调用接口定义了一个包含 13 个原子工具的固定操作空间:click、write、press_keys、scroll、wait、drag、hover、goto_url、go_back、new_tab、switch_tab、close_tab 以及终端 done(response)。done(response) 操作是终止回合的唯一机制,也是最终面向用户输出的唯一载体。表 11 提供了每个工具的一行摘要,完整的参数说明见附录 C。

媒体内容 · 前往原文查看
表 11:浏览器操作空间:按类别分组的 13 个原子工具。完整的参数签名列于附录 C。
类别 工具 描述
指针管理 点击 在屏幕像素点处进行鼠标点击;支持单击/双击以及左键/右键/中键。
悬停 将光标移动至某个像素点,以显示工具提示或打开下拉菜单。
拖拽 从起始像素点拖放至结束像素点。
键盘管理 写入 清空当前聚焦的输入框并输入一段字符串。
按键 按下一个或多个按键,可顺序按下或作为快捷键组合按下。
页面导航 滚动 按视口的一定比例滚动页面或子元素。
跳转URL 将当前标签页导航至指定URL。
后退 在浏览器历史记录中向后导航。
等待 暂停若干秒,让页面稳定下来。
标签页管理 新建标签页 打开一个新的空白浏览器标签页。
切换标签页 切换到指定索引(从0开始)的标签页。
关闭标签页 关闭当前标签页。
终止 完成 结束本轮交互并输出最终面向用户的答案。

第一轮用户交互提供任务意图以及初始浏览器观察结果,包括最新的截图、视口尺寸以及从任务的起始URL获取的标签页摘要(每个打开标签页的URL和标题)。在后续每一步中,模型会在 `<think>...</think>` 标签内生成推理过程,随后跟一个或多个 `<tool_call>` 代码块。每个调用都会被解析并在 Orchard Env 沙箱中执行。得到的工具响应(例如,成功:点击 `<button>` "继续购物")会与更新后的观察结果合并,作为下一轮用户交互追加到上下文中,作为对先前操作的反馈。此循环重复进行,直到模型输出完成或预定义的步骤预算耗尽。

由于单张截图可能扩展为数千个视觉 token,简单地将全部截图历史拼接起来会迅速使上下文窗口膨胀到超出任何合理的训练时长度:一个30步的展开过程甚至会使64k token的上下文饱和。根据经验,早期截图中的可操作信息已经提炼到智能体先前的推理过程中,而这些推理过程本身在每一轮交互中仍保留在上下文中。因此,我们仅保留最后几张截图的原始内容,以大幅缩短上下文长度。此处展示了一个示例,即最后一轮交互中提供给VLM的输入(包含上下文图像)以及对应的VLM响应。完整轨迹请参见附录D。

所有交互均在 Orchard Env 沙箱内执行:每个任务都在一个由 Playwright 控制的隔离 Chromium 实例(2 个 vCPU,8 GiB 内存)中运行,并配有任务特定的配置。这种隔离不仅有助于在涉及身份验证、区域限制内容和速率受限 API 的场景中实现可复现性,还能支持可扩展的并行执行,从而显著提升训练和评估的吞吐量。

4.3 轨迹收集与整理

我们通过一个三阶段流程构建 Orchard-GUI 数据集:(i)筛选原始任务意图,将其整理为干净的种子池;(ii)在 Orchard Env 中针对这些任务采样教师轨迹;(iii)基于评判器的过滤与质量整理,生成最终的 SFT/RL 数据划分。表 12 总结了所收集数据集的构成以及用于 SFT/RL 的子集。

任务来源。

我们从 WebGym(Bai 等人,2026b)提供的任务集中获取任务实例,该任务集总共包含 292,092 个原始实例。为了生成一个干净、评估安全且多样化的训练提示词池,我们应用了一个五步过滤流程(图 4)。最终过滤后的池包含 15,601 个独特的任务意图,这些意图作为种子集,用于采样 SFT 和 RL 中使用的教师轨迹。其中,2,537 个来自 PAE-WebVoyager(Zhou 等人,2025),13,064 个来自 InSTA(Trabucco 等人,2025)。这些任务涵盖六个广泛领域类别中的 13,063 个独特主机(图 5,左)。它们覆盖了 MOZ 前 500 网站中的 425/500(85.0%)以及 SimilarWeb 前 100 网站中的 57/100(57.0%)。相应地,48.5%(7,566)的任务落在 MOZ 前 500 主机上,13.0%(2,030)的任务落在 SimilarWeb 前 100 主机上(图 5,右)。更多详细信息见附录 E。请注意,RL 阶段使用的任务来自同一个任务池,并经过相同的过滤流程处理,但采用了更严格的基于相似性的去重阈值 0.95,最终得到包含 2,198 个任务的任务集(表 12)。

Refer to caption
图 4:任务过滤流程。从原始任务出发,我们依次移除评测基准重叠任务、子任务、WebVoyager 意图、长尾网站以及近似重复意图(基于 Qwen3-Embedding-8B 的语义相似度),最终得到一组在热门网站上的去重种子任务池。

Refer to caption

Refer to caption

图 5:过滤后种子任务池的构成。左图:按顶级域名划分的任务占比(类别涵盖各类任务)。右图:种子任务池覆盖了 SimilarWeb 访问量前 100 名网站中的 80% 和 MOZ 最受欢迎前 100 名网站中的 75%,其中分别有 60% 和 50% 的任务落在这两个榜单的网站上。
轨迹生成。

我们使用 Qwen3-VL-235B-A22B-Thinking(Bai 等人,2025)作为轨迹蒸馏的唯一教师模型。对于每个过滤后的种子任务,我们在第 4.1 节所述的相同工具调用智能体框架下,通过 Orchard 环境采样独立的 rollout 轨迹,得到教师模型 rollout 的原始池(其中一小部分尝试因环境或 rollout 引擎错误而中止)。GPT-4.1 在数据收集过程中担任评判者:它对最终完成状态(响应)和智能体交互历史的判定,连同截图轨迹,被用作二元奖励信号。在该评判标准下,60% 的任务至少有一次成功的 rollout,30% 的任务在所有四次 rollout 中均成功,其余 10% 的任务在所有 rollout 中都失败(图 6 左图)。这些失败中有相当一部分是环境因素而非智能体能力问题:在所有 rollout 均失败的任务中,40%(即 4% 的任务,占完整任务池的 4%)在全部四次尝试中都被验证码拦截,剩下约 6% 的任务是教师模型确实无法解决的。各网站的成功率也差异很大(图 6 右图),反爬虫措施严格的网站(例如 dictionary.cambridge.org、bing.com)成功率集中在低端。每个任务采样四次 rollout 是有意为之:这种冗余设计一方面提供了基于成功率的难度估计和用于下游筛选的轨迹多样性,另一方面生成了一个比我们最终训练所用数据大得多的候选池,使我们能够通过在小规模、精心筛选的子集上训练(而非使用全部数据)来研究数据效率。

Refer to caption

Refer to caption

图 6:按网站和按任务的成功结果。左侧:各轮次中按结果划分的任务占比——全部通过、混合(部分通过部分失败)和全部失败。在全部失败的任务中,有(共 个任务;占全部 个任务池的)个任务在全部四次轮次中均被验证码拦截。右侧:按轮次数量排名前 的网站中,教师模型在各网站的成功率,分为两列显示;条形长度 = 轮次数量,颜色 = 成功率。
筛选与整理。

我们首先仅保留那些最终 done(response) 被 GPT-4.1(奖励模型)判定为成功的轮次,并按来源基准进行拆分,得到 4,826 个成功的 PAE-WebVoyager 轮次和 26,154 个成功的 InSTA-v3 轮次。对于 SFT,我们刻意避免使用全部成功数据池:在 RL 之前让学生模型过度饱和地学习模仿数据,往往会将其推向一个狭窄的模仿区间,使得在线策略梯度难以摆脱;因此,我们转而选取一个经过精心整理的小规模子集。我们进一步将 SFT 数据池限定为 PAE-WebVoyager:尽管 PAE-WebVoyager 仅贡献了种子任务的 (共 个),但其任务中有 落在 SimilarWeb 排名前 100 的网站上,而 InSTA-v3 的这一比例仅为 (表 12)——在更贴近日常用户浏览习惯的热门主机上,PAE-WebVoyager 具有密度优势。

在 PAE-WebVoyager 的成功数据池内,我们随后应用两项缩减措施以平衡质量与多样性。(i) 任务内质量:对于每个任务,我们仅保留一个轮次,即最短的成功轨迹(轮次最少,若相同则比较总响应长度),因为较短的教师轨迹通常更干净,包含更少的恢复噪声。(ii) 跨网站多样性:我们将每个网站的任务数量上限设为 个,防止高流量主机(如 amazon.com、coursera.org)主导 SFT 混合数据。最终得到的 SFT 语料库包含 412 个独特任务,覆盖 70 个网站;该子集及 RL 数据池的按来源细分和结果统计见表 12。

媒体内容 · 前往原文查看
表12:Orchard-GUI训练数据集的构成。完整集是我们收集模型运行轨迹的种子任务池。SFT轨迹是用于监督微调的、通过评判器筛选的运行轨迹,RL任务是用于引导基于运行轨迹优化的种子提示词。任务按以下类别划分:所有运行轨迹均成功、全部失败,或结果混合。最后一列报告了起始URL位于SimilarWeb前100名网站的任务数量(仅限至少有一条成功运行轨迹的任务)。
子集 来源 任务数 全部成功 全部失败 混合 前100名网站上的任务
完整集 PAE-WebVoyager
InSTA-v3
总计
SFT轨迹 PAE-WebVoyager
RL任务 PAE-WebVoyager
InSTA-v3
总计

4.4 训练方案

我们的训练方案遵循两阶段流程:首先在教师模型蒸馏得到的轨迹上进行监督微调,随后进行基于评判器奖励的强化学习。两个阶段均使用Orchard环境作为执行后端。

第一阶段:监督微调。

我们从 Qwen3-VL-4B-Thinking(Bai 等人,2025)初始化模型,并在整理好的教师轨迹数据上进行微调。对于每一条教师 rollout,我们为每个助手轮次生成一个训练样本:第 i 个样本携带经过聊天模板序列化的、截至第 i 轮的前缀,并仅对该轮次的助手回复进行监督。序列化前缀遵循 Qwen 聊天模板,其中包含一个携带智能体角色的系统轮次以及 OpenAI 格式的工具 schema;一个包含任务意图和 start_url 观测的初始用户轮次;随后是助手轮次(一段 `<think>...</think>` 推理轨迹,后接一个或多个 `<tool_call>` 块)与用户轮次(工具响应,其中包含更新后的浏览器观测,包括最新截图)的交替。遵循长程智能体训练的标准做法,损失仅计算在最终(目标)助手轮次上;系统提示、作为上下文历史保留的先前助手轮次以及所有环境观测均被掩码处理。视觉编码器和多模态投影仪保持冻结状态,仅更新语言模型权重,这保留了骨干网络的截图定位能力,并将 SFT 能力集中在智能体特定的推理和动作预测上。我们训练了 3 个 epoch,峰值学习率为 1e-5,采用余弦调度和线性预热。每个优化器步骤使用每设备 2 的批次大小,配合 8 步梯度累积,从而得到每个工作节点的有效批次大小为 16,并在 8 个数据并行工作节点上实现全局批次大小 128。

第二阶段:强化学习。

从 SFT 检查点开始,我们应用强化学习来提升模型在部分可观测条件下从错误中恢复并探索替代路径的能力。我们优化了 GRPO(Shao 等人,2024)的多轮变体:对于每个任务,我们从并行浏览器实例中采样一组轨迹,根据轨迹级奖励计算组相对优势,并将其广播到所有轮次中每个助手回复的 token;观测和环境反馈 token 在损失计算中被掩码掉。奖励结合了确定性格式检查与二元评判器:当每个助手轮次都能解析为有效的 `<think>`+工具调用,且最终的 `done(response)` 根据截图轨迹和用户意图被 GPT-4.1 判定为成功时,轨迹获得正奖励;当 rollout 因重复格式错误而终止时获得负奖励;其他情况获得零奖励。我们使用非对称 PPO 裁剪(, ),不采用 KL 或熵正则化,并有意省略每条轨迹的损失归一化,以便更长的、更困难的任务不会被降低权重。为去除无信息量的更新,我们应用了 DAPO 风格的轨迹级动态采样(Yu 等人,2025)——丢弃那些奖励全部为 或全部为 的组——并通过 `remove_sample` 机制额外将评判器 API 失败和验证码中止运行的损失掩码置零,从而确保基础设施噪声不会渗入策略更新。我们还在强化学习内部采用了步骤预算课程学习:首先,在每轮步骤预算上限为 15 的条件下运行强化学习,直到性能饱和;然后,从该检查点继续训练,并将预算提高到 30。短视界阶段能在策略已可在 15 步内解决的任务上廉价地产生密集奖励信号,而长视界阶段则将策略扩展到那些确实需要更多交互的更困难任务。

Refer to caption
图 7:Orchard-GUI 强化学习训练与评估曲线。红色曲线表示从我们的 SFT 检查点开始的强化学习训练,蓝色曲线表示从基础模型初始化的强化学习训练。与基础模型初始化相比,SFT 初始化的模型在整个训练过程中实现了持续更高的评估成功率以及更稳定的奖励提升。

4.5 主要结果

表 13 将 Orchard-GUI 与专有视觉语言模型、此前开源的 GUI 智能体以及同规模基线模型在 WebVoyager、Online-Mind2Web 和 DeepShop 上进行了对比。经过两阶段训练后,Orchard-GUI 在 WebVoyager / Online-Mind2Web / DeepShop 上分别达到 74.1% / 67.0% / 64.0%,平均 68.4%——这是开源模型中表现最强的结果,且大幅领先,同时与最佳专有系统(Gemini computer-use-preview,平均 69.3%)相比也具备竞争力,尽管其骨干模型仅为 4B 参数量,且仅使用 2.6k 训练任务。强化学习贡献了大部分性能提升,使 SFT 检查点在三个基准上的绝对分数分别提升了 +13.9 / +20.0 / +15.3(平均从 52.0% 提升至 68.4%)。

四项发现尤为突出。第一,在 WebVoyager 上,Orchard-GUI 与最强的开源基线模型表现相当(74.1% 对比 MolmoWeb-4B 的 75.2% 和 MolmoWeb-8B 的 78.2%),但消耗的训练任务数量大约少两个数量级(2.6k 对比 278.5k)。WebVoyager 仅覆盖 15 个热门网站,且任务跨度相对较短,因此与那些在此特定分布上经过大量蒸馏的基线模型相比,拉开差距的空间有限。

第二,在 Online-Mind2Web 和 DeepShop 上,Orchard-GUI 大幅超越了此前所有开源模型——比此前最强的开源基线 MolmoWeb-8B 分别高出 +31.7 和 +21.7 个绝对百分点——同时也超越了其自身的 235B 参数 Qwen3-VL 教师模型,高出 +3.3 / +7.3,这表明基于环境交互的强化学习能够提取出教师模型本身不具备的能力。

第三,图 7 中的训练动态显示,从 SFT 检查点初始化的强化学习,在评估成功率上始终高于直接从基座模型初始化的强化学习,且优化行为更稳定。虽然两种设置在训练奖励上表现相当,但 SFT 初始化的策略收敛到了显著更强的泛化性能,最终在评估集上达到超过 50% 的成功率,而基座模型初始化则低于 40%。这一差距表明,监督初始化提供了关键的行为先验,稳定了探索过程,并使强化学习能够更有效地将奖励优化转化为下游任务的成功。

媒体内容 · 前往原文查看
表 13:三个开放网页基准测试中 GUI 智能体的成功率(%)。* 标记的数字来自 FARA(Awadallah 等人,2025);† 标记的数字来自 MolmoWeb(Gupta 等人,2026)。
系统 步骤数 任务数 WebVoyager Online-M2W DeepShop \cellcoloravgblue平均
专有模型
GPT-5 (Axtree)† 30 – 70.6 41.9 40.7 \cellcoloravgblue51.1
Gemini-3-flash (Axtree)† 30 – 74.4 34.8 45.1 \cellcoloravgblue51.4
Gemini-3-flash (Axtree)† 100 – 85.6 44.8 55.3 \cellcoloravgblue61.9
GPT-4o (SoM)* 100 – 65.1 34.6 16.0 \cellcoloravgblue38.6
o3 (SoM)* 100 – 79.3 55.4 49.7 \cellcoloravgblue61.5
GPT-5 (SoM)* 100 – 90.6 57.7 49.1 \cellcoloravgblue65.8
OpenAI computer-use-preview* 100 – 70.9 58.3 24.7 \cellcoloravgblue51.3
Gemini computer-use-preview† 100 – 88.6 57.3 62.0 \cellcoloravgblue69.3
开源模型
Holo1-7B† 30 >15.6k 55.4 – – \cellcoloravgblue–
UI-TARS-1.5-7B* 100 – 66.4 31.3 11.6 \cellcoloravgblue36.4
GLM-4.1V-9B-Thinking* 100 – 66.8 33.9 32.0 \cellcoloravgblue44.2
Fara-7B* 100 >123.2k 73.5 34.1 26.2 \cellcoloravgblue44.6
MolmoWeb-4B† 100 >278.5k 75.2 31.3 35.6 \cellcoloravgblue47.4
MolmoWeb-8B† 100 >278.5K 78.2 35.3 42.3 \cellcoloravgblue51.9
Qwen3-VL-4B-Thinking 30 – 49.0 32.0 33.3 \cellcoloravgblue38.1
Qwen3-VL-235B-A22B-Thinking 30 – 63.1 63.7 56.7 \cellcoloravgblue61.2
Orchard-GUI-4B-SFT 30 0.4k 60.2 47.0 48.7 \cellcoloravgblue52.0
Orchard-GUI-4B (SFT + RL) 30 2.6k 74.1 67.0 64.0 \cellcoloravgblue68.4

最后,最大的提升出现在 Online-Mind2Web 上,该基准测试涵盖的网站分布范围远比 WebVoyager(15 个固定网站)或 DeepShop(单一购物垂直领域)更广泛、更多样化。因此,在该基准测试上取得成功需要对之前未见过的界面进行泛化,而非适应狭窄的网站集。Orchard-GUI 在此场景下提升最为显著,这表明,基于评判器的强化学习,利用相对较小但多样化的任务池,能够比在狭窄分布上进行大规模教师蒸馏更有效地在开放网页上进行泛化,而这最终才是可部署浏览器智能体在实际中相关的场景。

5 Orchard-Claw

本节介绍 Orchard-Claw,这是我们针对基于爪形(claw)的智能体所实现的 Orchard 训练方案。我们将描述问题设定、轨迹收集方法、两阶段训练方案、在 Claw-Eval(Ye 等人,2026)上的主要结果,以及用于隔离影响性能的关键设计选择的消融实验。

5.1 问题设定

任务与评估

我们针对 Claw-Eval(Ye 等人,2026)所定义的多步骤日常工作任务。给定一条任务指令,例如“整理我的收件箱——哪些邮件需要回复,哪些是通知,哪些是垃圾邮件?”,智能体需要与一系列日常工具(如“gmail_list_messages”、“gmail_get_message”等)进行交互,在确保安全且稳健的前提下完成任务。具体来说,在智能体完成任务后,评估过程会审计整个智能体轨迹,通过结合自动化脚本和 LLM-as-a-judge(Zheng 等人,2023;Xiong 等人,2026)来衡量智能体的完成度、安全性和稳健性。这三个维度被聚合为一个单一的任务得分,当得分达到某个阈值时,该任务即被视为通过。我们使用 Claw-Eval 作为主要评估基准。

智能体框架与工具接口

我们使用两种不同的智能体框架来收集轨迹:一种是由 Claw-Eval 基准定义的 ReAct 风格框架,以及 ZeroClaw(ZeroClaw Labs,2026)框架——它是流行的 OpenClaw(OpenClaw Team,2026)的一个更快、更轻量的 Rust 版本。所有环境和框架都在通过 Orchard Env 服务路由的 Docker 运行时中实现:每次任务运行(环境和框架)都在一个隔离的沙箱(2 vCPU,2 GiB 内存)中执行,该沙箱基于预装了 ClawEval 和 ZeroClaw 的 Python 镜像进行配置。在 SFT 和 RL 阶段,我们在这两种框架上训练 Orchard-Claw,并研究这种端到端训练是否有助于模型更好地利用诸如 ZeroClaw 之类的高级框架,从而达到更高的性能。

5.2 轨迹收集与整理

由于基于爪形(claw)的智能体相对较新,我们使用 Claude Opus 4.6(Anthropic,2026)进行了一项初步研究,以合成爪形智能体任务作为我们的训练集。

任务来源。

我们从两个来源抽取种子任务:(1)来自 Claw-Eval 的任务,以及(2)来自 ClawHub 上热门技能的流程。我们使用官方 OpenClaw CLI 访问 https://clawhub.ai/ 上的技能。从这些种子出发,我们通过 claude-agent-sdk 提示 Opus 4.6,在一个四步循环中合成新任务:(1)提出并筛选任务想法;(2)生成环境、文件、工具服务器和测试脚本;(3)运行 MiniMax-M2.5(MiniMax,2026)作为求解器生成运行轨迹;(4)根据运行轨迹优化任务,确保可行性和指令清晰度。每个任务平均合成成本为 4.9 美元,最终在 Claw-Eval 和 ZeroClaw 测试框架上共享 192 个任务。

轨迹生成。

为简化起见,我们从单一教师模型中蒸馏监督微调数据。我们选择 MiniMax-M2.5,因其性能强劲。对于每个合成任务,我们在 Orchard Env 环境下,通过相应的测试框架(ReAct 风格或 ZeroClaw)从 MiniMax-M2.5 中采样五次运行轨迹,仅保留完成任务的轨迹。为了从 ZeroClaw 等复杂测试框架中记录训练样本,我们实现了一个代理大语言模型服务器,在运行过程中记录每一次大语言模型调用(输入和输出)。下方展示了一个来自 ZeroClaw 测试框架的记录(输入和输出)对示例。运行结束后,每个记录的(输入和输出)对被重新组合成一条轨迹,用于训练(以及在强化学习阶段用于奖励计算)。这最终产生了 561 条轨迹,共 4537 个训练对,用于监督微调。

5.3 训练方案

我们的训练方案遵循两阶段流程:首先在教师蒸馏的轨迹上进行监督微调,随后进行强化学习。两个阶段均使用 Orchard Env 作为执行后端。我们采用 Qwen3-30B-A3B-Thinking-2507(Qwen 团队,2025)作为训练的骨干模型。

阶段 1:监督微调。

我们从基础骨干网络初始化,并在精心整理的教师轨迹上进行微调。每个训练样本都是我们的代理 LLM 服务器记录的一个(输入提示词,LLM 响应)对,按照第 3.3 节所述,我们对输入进行掩码处理,仅对响应部分进行训练。我们使用全局批次大小 16 和 64k 上下文窗口进行 1 个 epoch 的 SFT,采用从某值衰减至某值的余弦学习率,并对超出上下文窗口的序列应用左截断。在推理时,我们将上下文扩展到模型的最大值 256k。

第二阶段:强化学习。

从 SFT 检查点开始,我们应用 RL 来训练模型从错误中恢复并探索完成任务的其他路径。奖励是二元的且基于环境:如果一次 rollout 通过了所有测试脚本,则该 rollout 中的每个(输入,输出)对都获得正奖励;否则,每个(输入,输出)对都获得负奖励。我们使用标准 GRPO(Shao 等人,2024;Guo 等人,2025)进行优化,批次大小为 8,组大小为 8,共进行 150 个训练步骤。Orchard 的沙箱并行化在此阶段至关重要,它使我们能够轻松地为每个步骤运行 64 个异步 rollout 沙箱,这大大提高了训练吞吐量。此外,在 rollout 期间,我们不设置最大步骤限制,而是为每个任务设置 10 分钟的挂钟时间预算。我们发现这能更好地适应不同测试框架和不同工具调用在每步延迟上的差异,并且更贴合实际使用场景。超出预算的 rollout 将被中止,其所有轮次均从训练中排除。在图 8 中,我们绘制了 RL 训练过程中的训练和验证成功率以及轨迹长度。

Refer to caption

Refer to caption

图 8:Orchard-Claw RL 训练曲线。左图:训练和验证成功率随 RL 步骤的变化。右图:训练和验证回合长度(每次 rollout 中智能体的轮次数量)。验证任务从 ClawEval 基准中采样。两个指标在训练过程中都稳步上升,表明智能体学会了解决更多任务,同时也能进行更长的多轮交互。
媒体内容 · 前往原文查看
表 14:Claw-agent 在 Claw-Eval 上的性能。我们使用通用领域(0408)进行评估。标 * 的数字来自 Ye 等人(2026)的报告。
系统 #任务数 ClawEval() ClawEval()
SOTA 大语言模型
Claude Opus 4.6* – 70.8 80.8
GPT 5.4* – 60.2 75.8
Gemini 3.1 Pro* – 55.9 80.8
Qwen3.5 397A17B* – 57.8 70.8
GLM 5 Turbo* – 52.8 73.3
MiniMax M2.7* – 49.7 72.0
MiniMax M2.5 – 47.2 65.2
Kimi K2.5* – 36.6 67.1
相似规模基线模型与我们的模型(30B-A3B;约 3B 激活参数)
Nemotron-3-nano-30b-a3b – 26.1 57.8
Qwen3-30B-A3B-Thinking – 14.3 39.8
Qwen3-Coder-30B-A3B-Instruct – 30.4 49.7
Orchard-Claw (SFT) 0.2k 22.4 50.3
Orchard-Claw (SFT + RL) 0.2k 31.7 59.6

5.4 主要结果

表 14 将 Orchard-Claw 与大型闭源模型以及相似规模的开源模型在 Claw-Eval(Ye 等人,2026)上进行了比较,使用了该基准测试原生的 ReAct 风格测试框架。经过我们的两阶段训练后,Orchard-Claw 达到了 31.7% 和 59.6%,显著优于其基础模型,并且超越了专门针对代码和工具调用的模型,例如 Qwen3-Coder-30B-A3B-Instruct(Cao 等人,2026)和 Nemotron-3-nano-30b-a3b(NVIDIA,2025),尽管它仅基于 0.2k 个合成任务进行训练。RL 贡献了大部分性能提升,在 和 上分别比 SFT 检查点高出 9.3 个绝对百分点。这表明,即使使用有限的合成数据,RL 在优化智能体行为方面也极为有效,其效果超越了仅靠教师蒸馏所能达到的水平。

媒体内容 · 前往原文查看
表 15:跨测试框架评估。ReAct* 是 ClawEval 基准测试中的 ReAct 风格循环。ZeroClaw 是流行的 OpenClaw Harness 的一个轻量级 Rust 版本。
ClawEval() ClawEval()
模型 ReAct* ZeroClaw ReAct* ZeroClaw
Qwen3-30B-A3B-Thinking 14.3 20.5 (+6.2) 39.8 44.7 (+4.9)
Qwen3-Coder-30B-A3B-Instruct 30.4 29.8 (-0.6) 49.7 54.7 (+5.0)
Orchard-Claw (SFT) 22.4 25.5 (+3.1) 50.3 62.1 (+11.8)
Orchard-Claw (SFT+RL) 31.7 41.0 (+9.3) 59.6 73.9 (+14.3)

在表15中,我们进一步评估了Orchard-Claw在其原生ReAct风格框架以及更先进的ZeroClaw框架下的表现。将Orchard-Claw(SFT+RL)与ZeroClaw配对使用,性能提升至41.0%和73.9%,相比同一模型在ReAct风格框架下运行,分别实现了+9.3和+14.3的绝对提升。这一增益也是所有对比模型中最高的,包括Qwen3-Coder-30B-A3B-Instruct等基线模型,这些模型在切换到ZeroClaw时获益甚微甚至出现性能倒退。我们将此归功于在Orchard Env支持下,我们在模型部署过程中使用了目标框架进行端到端训练。通过在训练过程中让智能体接触这些框架,智能体学会了利用更强框架在推理时提供的特性——包括但不限于子智能体、自动压缩等功能。

6 相关工作

面向智能体训练的交互式环境编排。

与传统模型训练不同,智能体训练的基石在于交互式环境编排。它要求智能体在隔离的沙盒中执行动作、处理反馈,并通过多轮轨迹进行迭代。为了满足底层基础设施层的这一特殊需求,目前出现了两种不同的设计范式:集成训练栈与解耦环境服务。

在集成范式下,执行环境是嵌入在更大训练或编排系统中的一个子组件。这使得环境层能够与特定的训练框架或智能体框架进行协同设计,从而为特定任务流水线定制基础设施。MegaFlow(Zhang 等人,2026b)将智能体训练分解为三个协同设计的服务(模型、智能体、环境),协调了数万个并发智能体任务。虽然它认识到环境服务应具备独立扩展能力,但这三个服务是为通义千问训练流水线协同设计的,无法与任意外部训练器或第三方框架组合使用。ProRL Agent(Zhang 等人,2026a)在解耦方面迈出了重要的一步:它通过 HTTP 服务将 rollout 生成与训练器分离。然而,其环境层仍通过 AgentHandler 插件与智能体脚手架绑定,因此在不修改环境配置的情况下无法更换框架。相比之下,Orchard Env 的 REST API 明确地与训练循环、具体任务和智能体框架解耦。这种模块化设计使其特别适合开源开发和异构研究环境。通过将环境抽象为独立服务,我们的环境编排支持整个智能体开发生命周期:轨迹蒸馏、在线策略 rollout 和评估。

第二种范式是解耦环境服务,即将执行环境暴露为一个轻量、独立的服务,具有极简的 API 接口,可跨不同训练框架、智能体脚手架和任务领域复用。E2B(E2B, 2024)、Daytona(Daytona, 2025)和 Modal(Modal Labs, 2024)等商业平台为面向开发者的用例提供了范例:它们通过 REST API 或 SDK 暴露沙箱生命周期和代码执行功能。然而,这些平台普遍缺乏可扩展强化学习训练所需的细粒度环境控制,例如可调资源限制、与训练状态绑定的基于心跳的生命周期管理、以及按沙箱隔离的网络策略。此外,这些专有服务的运营成本通常远高于 Orchard Env——后者采用 Kubernetes 原生设计,以最大化资源效率并最小化开销。因此,Orchard Env 作为一个专为开源研究和智能体开发而设计的高性能、高性价比基础平台。

软件工程智能体。

自动化软件工程已收敛于一个规范的任务设定:给定一个真实的 GitHub issue 和仓库快照,生成一个能通过相关测试套件的补丁。SWE-bench(Jimenez 等人,2024)及其经人工验证的子集 SWE-bench Verified(OpenAI,2024)将这一设定付诸实践,并作为 Orchard-SWE 的主要评测基准。在这一领域内,相关工作沿着两个互补方向推进:设计更好的智能体脚手架和扩展训练数据。在脚手架方面,SWE-agent(Yang 等人,2024)引入了一种专门的智能体-计算机接口,支持结构化文件查看、编辑和代码库搜索。其轻量级衍生版本 mini-swe-agent 被用作 Orchard-SWE 的两个训练框架之一。此外,OpenHands(Wang 等人,2025b)提供了一个功能完备的多智能体平台,被用作 Orchard-SWE 的第二个训练框架。在数据扩展方面,SWE-smith(Yang 等人,2025a)通过自动化任务合成,从任意仓库生成新的训练实例,从而扩展任务多样性;BugPilot(Sonwane 等人,2025)通过指示智能体在仓库中实现新功能来生成“非刻意”的 bug。Orchard-SWE 则另辟蹊径:我们不合成新任务,而是通过从前沿模型进行多教师知识蒸馏,以及对失败轨迹进行部分正确性监督,来扩展轨迹质量,并以真实的 GitHub issue(Badertdinov 等人,2025;2026;Zhao 等人,2026)作为任务来源。

GUI 与浏览器导航智能体。

GUI 智能体的研究围绕一系列互补性基准展开,这些基准共同覆盖了真实网页与桌面任务的结构多样性。Mind2Web(Deng 等人,2023)引入了首个大规模人工标注跨网站任务数据集,涵盖 137 个站点,确立了主流的网页导航评估体系。OSWorld(Xie 等人,2024)将评估扩展至完整的桌面环境,包含 369 个涉及多应用工作流的真实计算机任务,要求智能体在无 DOM 访问权限的情况下仅通过截图进行操作。WebVoyager(He 等人,2024)利用 GPT-4V 在真实网站上建立了端到端网页任务基准,既作为评估基准,也作为纯提示词基线。近期,Online-Mind2Web 在完全实时的环境中重新审视了 Mind2Web 任务空间,移除了静态快照这一捷径;DeepShop(Lyu 等人,2025)则引入了一个交易型电商基准,要求在购物约束条件下进行多步推理——这两者均作为 Orchard-GUI 的留出评估目标。我们在 WebVoyager、Online-Mind2Web 和 DeepShop 上评估了 Orchard-GUI——之所以专门选择这三个基准,是因为它们代表了结构上截然不同的任务类型,使用实时环境而非静态快照,且其动作空间或奖励信号互不重叠,从而为单一统一模型(无需针对特定基准进行调优)构成了严苛的测试平台。

该领域的方法论演进,正从这些仅依赖提示词的基线方法,迈向高度依赖训练的复杂范式。早期的系统如 WebVoyager(He 等人,2024)建立了强大的提示词基线,但为经过训练的模型留下了巨大的提升空间。随后主导的范式聚焦于在人类或模型生成的示范数据上进行监督式微调(SFT)。Fara(Awadallah 等人,2025)引入了 FaraGen,这是一个可扩展的流水线,它提出多步骤的网页任务,并通过自动验证器筛选成功案例,以生成低成本的 SFT 数据,从而产出一个仅基于截图的 7B 智能体,其性能可与前沿模型媲美。更近期,MolmoWeb(Gupta 等人,2026)整合了 MolmoWebMix——一个由合成轨迹、人类示范和原子级网页技能数据组成的大型精选混合数据集——用于训练一个完全开源的智能体,该智能体在 WebVoyager、Online-Mind2Web 和 DeepShop 基准测试中,在开源权重模型中达到了最先进的水平。新一波的研究将强化学习(RL)整合进来,以增强推理能力和分布外(OOD)性能。UI-TARS(Qin 等人,2025)开创了用于 GUI 智能体的迭代式 RL 数据飞轮。近期的开源方法(Luo 等人,2025;Lu 等人,2025)则更侧重于通过 RL 提升接地(grounding)和推理质量。尽管取得了这些进展,但在统一的训练框架下,跨在线和离线环境的跨基准泛化能力仍然罕见。使用 Orchard Env 作为与框架无关的执行后端进行训练的 Orchard-GUI 证明,将单一的 SFT+RL 方案应用于 4B 模型即可实现跨领域泛化。这为所提出的开放开发系统的可扩展性和可复用性提供了具体证据。

通用型长时间运行的自主智能体(Claw-agent)。

爪式智能体代表了从片段式领域工具(SWE/GUI)向持久化、通用型伙伴的转变。领域智能体针对特定环境进行优化,并带有重置记忆,而爪式智能体则通过结构化工件维持持久化状态和身份。它们利用动态技能库(ClawHub),跨异构 API 执行多步骤工作流,并使用主动心跳来维持一种环境存在感。这种架构上的差异旨在面向开放式时间跨度实现对话对齐,因此随着智能体的工具面不断扩展,跨框架泛化成为一个核心挑战。

近期的一些基准测试(Ye 等人,2026;Li 等人,2026;Bai 等人,2026a)为爪式智能体建立了评估标准。Claw-Eval(Ye 等人,2026)提供了高质量、人工策划的场景,严格评估长期规划和工具调用稳定性。相比之下,ClawGym(Bai 等人,2026a)则依赖于对模拟工作空间的自动化数据合成,为训练和评估创建可扩展的数据管道。近期的训练创新聚焦于效率和快速适应。MetaClaw(Xia 等人,2026)能够从失败轨迹和空闲时段强化学习更新中实现持续技能合成,在 Claw 基准测试上展现出提升。此外,OpenClaw-RL(OpenClaw 团队,2026)将用户反馈等实时部署信号,通过事后引导的在线策略蒸馏,视为持续的训练来源。我们利用 Orchard-Env 实例化了一个端到端的训练管道 Orchard-Claw,通过统一的、与框架无关的执行后端,在 Claw-Eval 上实现持续改进。

7 结论

本文提出了 Orchard,这是一个围绕轻量级、Kubernetes 原生、与执行框架无关的环境服务构建的可扩展智能体建模开源框架。通过将沙箱管理与智能体执行框架、训练器和任务领域解耦,Orchard Env 使得轨迹收集、SFT、RL 展开和评估更具可复用性、可复现性和成本效益。在软件工程、GUI 导航和个人助手工作流中,Orchard 证明了共享环境层可以支持多样化的智能体和训练方案。Orchard-SWE、Orchard-GUI 和 Orchard-Claw 在取得强劲结果的同时,还展示了跨执行框架、领域和流水线阶段的迁移能力提升。总体而言,Orchard 表明,可扩展的智能体进展既依赖于基础设施,也依赖于训练设计。通过使环境服务、训练方案和数据收集能够在不同领域和执行框架间复用,Orchard 降低了在智能体 AI 领域开展开放、可复现且以能力为导向的研究的门槛。

参考文献

  • Anthropic (2026) 推出 Claude Opus 4.6。注:https://www.anthropic.com/news/claude-opus-4-6 访问日期:2026-05-03 引用自:§5.2。
  • A. Ariyak, J. Zhang, J. Wang, S. Zhu, F. Bianchi, S. Srivastava, A. Panda, S. Bharti, C. Xu, J. Heo, X. S. Wu, J. Zou, P. Liang, L. Song, C. Zhang, B. Athiwaratkun, Z. Zhou, 和 Q. Wu (2026) CoderForge-Preview:用于训练高效智能体的 SOTA 开放数据集。Together AI 博客。注:项目核心负责人:Alpay Ariyak;Zhongzhu Zhou;Qingyang Wu 外部链接:链接 引用自:表 7。
  • A. Awadallah, Y. Lara, R. Magazine, H. Mozannar, A. Nambi, Y. Pandya, A. Rajeswaran, C. Rosset, A. Taymanov, V. Vineet, S. Whitehead, 和 A. Zhao (2025) Fara-7b:一个用于计算机操作的高效智能体模型。arXiv:2511.19663。引用自:§4.1,表 13,§6。
  • I. Badertdinov, A. Golubev, M. Nekrashevich, A. Shevtsov, S. Karasik, A. Andriushchenko, M. Trofimova, D. Litvintseva, 和 B. Yangel (2025) Swe-rebench:一个用于软件工程智能体任务收集与去污染评估的自动化流水线。arXiv 预印本 arXiv:2505.20411。引用自:§1,§3.2,§6。
  • I. Badertdinov、M. Nekrashevich、A. Shevtsov 和 A. Golubev(2026 年)《SWE-rebench v2:大规模语言无关的 SWE 任务集合》。arXiv 预印本 arXiv:2602.23866。引用自:§1、§3.2、表 6、§6。
  • S. Bae、J. Hong、M. Y. Lee、H. Kim、J. Nam 和 D. Kwak(2026 年)《面向推理型强化学习的在线难度过滤》。载于《第 19 届欧洲计算语言学协会会议论文集(第 1 卷:长论文)》,摩洛哥拉巴特,第 700–719 页。外部链接:文献、链接。引用自:§3.3.3。
  • F. Bai、H. Song、S. Sun、D. Cheng、Y. Yang、C. Hao、R. Li、F. Chang、Y. Wei、R. Tao、B. Dai、J. Yang 和 W. X. Zhao(2026a 年)《ClawGym:构建高效 Claw 智能体的可扩展框架》。外部链接:2604.26904,链接。引用自:§6。
  • H. Bai、A. Taymanov、T. Zhang、A. Kumar 和 S. Whitehead(2026b 年)《WebGym:通过真实任务扩展视觉 Web 智能体训练环境》。arXiv 预印本 arXiv:2601.02439。引用自:附录 E、§4.3。
  • S. Bai、Y. Cai、R. Chen、K. Chen、X. Chen、Z. Cheng、L. Deng、W. Ding、C. Gao、C. Ge、W. Ge、Z. Guo、Q. Huang、J. Huang、F. Huang、B. Hui、S. Jiang、Z. Li、M. Li、M. Li、K. Li、Z. Lin、J. Lin、X. Liu、J. Liu、C. Liu、Y. Liu、D. Liu、S. Liu、D. Lu、R. Luo、C. Lv、R. Men、L. Meng、X. Ren、X. Ren、S. Song、Y. Sun、J. Tang、J. Tu、J. Wan、P. Wang、P. Wang、Q. Wang、Y. Wang、T. Xie、Y. Xu、H. Xu、J. Xu、Z. Yang、M. Yang、J. Yang、A. Yang、B. Yu、F. Zhang、H. Zhang、X. Zhang、B. Zheng、H. Zhong、J. Zhou、F. Zhou、J. Zhou、Y. Zhu 和 K. Zhu(2025 年)《Qwen3-VL 技术报告》。arXiv 预印本 arXiv:2511.21631。引用自:§4.3、§4.4。
  • R. Cao、M. Chen、J. Chen、Z. Cui、Y. Feng、B. Hui、Y. Jing、K. Li、M. Li、J. Lin、Z. Ma、K. Shum、X. Wang、J. Wei、J. Yang、J. Zhang、L. Zhang、Z. Zhang、W. Zhao 和 F. Zhou(2026 年)《Qwen3-Coder-Next 技术报告》。arXiv 预印本 arXiv:2603.00729。引用自:§3.6、§5.4。
  • Daytona(2025 年)《Daytona:用于运行 AI 生成代码的安全且弹性基础设施》。注释:https://www.daytona.io GitHub 仓库:https://github.com/daytonaio/daytona 引用自:§1、§2.2、§6。
  • X. Deng, Y. Gu, B. Zheng, S. Chen, S. Stevens, B. Wang, H. Sun, and Y. Su (2023) Mind2Web:迈向通用型网络智能体。收录于《神经信息处理系统进展》,A. Oh, T. Naumann, A. Globerson, K. Saenko, M. Hardt, and S. Levine 编,第36卷,第28091–28114页。外部链接:Link 被引用:第1项,§1,§4.1,§6。
  • E2B (2024) E2B:面向AI代码执行的开源安全沙箱。说明:https://e2b.dev GitHub仓库:https://github.com/e2b-dev/E2B 被引用:§1,§2.2,§6。
  • D. Fu, S. Wu, Y. Wu, Z. Peng, Y. Huang, J. Sun, J. Zeng, M. Jiang, L. Zhang, Y. Li, J. Hu, L. Liu, J. Hou, and P. Liu (2026) DaVinci-env:大规模开源软件工程环境合成。外部链接:2603.13023, Link 被引用:§3.5,表7,表7,表7,表7。
  • D. Guo, D. Yang, H. Zhang, J. Song, P. Wang, Q. Zhu, R. Xu, R. Zhang, S. Ma, X. Bi, X. Zhang, X. Yu, Y. Wu, Z. F. Wu, Z. Gou, Z. Shao, Z. Li, Z. Gao, A. Liu, B. Xue, B. Wang, B. Wu, B. Feng, C. Lu, C. Zhao, C. Deng, C. Ruan, D. Dai, D. Chen, D. Ji, E. Li, F. Lin, F. Dai, F. Luo, G. Hao, G. Chen, G. Li, H. Zhang, H. Xu, H. Ding, H. Gao, H. Qu, H. Li, J. Guo, J. Li, J. Chen, J. Yuan, J. Tu, J. Qiu, J. Li, J. L. Cai, J. Ni, J. Liang, J. Chen, K. Dong, K. Hu, K. You, K. Gao, K. Guan, K. Huang, K. Yu, L. Wang, L. Zhang, L. Zhao, L. Wang, L. Zhang, L. Xu, L. Xia, M. Zhang, M. Zhang, M. Tang, M. Zhou, M. Li, M. Wang, M. Li, N. Tian, P. Huang, P. Zhang, Q. Wang, Q. Chen, Q. Du, 等人 (2025) DeepSeek-R1:通过强化学习激励大语言模型中的推理能力。《自然》645 (8081),第633–638页。外部链接:ISSN 1476-4687, Link, Document 被引用:§5.3。
  • T. Gupta, P. Wolters, Z. Ma, P. Sushko, R. Y. Pang, D. Llanes, Y. Yang, T. Anderson, B. Zheng, Z. Ren, H. Trivedi, T. Blanton, C. Ouellette, W. Han, A. Farhadi, and R. Krishna (2026) MolmoWeb:面向开放网络的开放视觉网络智能体与开放数据。外部链接:2604.08516 被引用:§4.1,表13,§6。
  • H. He, W. Yao, K. Ma, W. Yu, Y. Dai, H. Zhang, Z. Lan, and D. Yu (2024) WebVoyager:构建基于大型多模态模型的端到端网络智能体。arXiv预印本 arXiv:2401.13919。被引用:第1项,§1,§4.1,§6,§6。
  • X. Hu, T. Xiong, B. Yi, Z. Wei, R. Xiao, Y. Chen, J. Ye, M. Tao, X. Zhou, Z. Zhao, Y. Li, S. Xu, S. Wang, X. Xu, S. Qiao, Z. Wang, K. Kuang, T. Zeng, L. Wang, J. Li, Y. E. Jiang, W. Zhou, G. Wang, K. Yin, Z. Zhao, H. Yang, F. Wu, S. Zhang, 和 F. Wu (2025) OS agents: a survey on MLLM-based agents for computer, phone and browser use. 收录于《第63届计算语言学协会年会论文集(第一卷:长文)》,奥地利维也纳,第7436–7465页。外部链接:文档,链接。引用自:§1。
  • N. Jain, J. Singh, M. Shetty, L. Zheng, K. Sen, 和 I. Stoica (2025) R2e-gym: procedural environments and hybrid verifiers for scaling open-weights swe agents. arXiv预印本 arXiv:2504.07164。引用自:表7。
  • C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, 和 K. R. Narasimhan (2024) SWE-bench: can language models resolve real-world github issues?. 收录于《第十二届国际学习表征会议 (ICLR)》,外部链接:链接。引用自:§1, §3.1, §6。
  • A. Kim (2025) Self-host open-source LLM agent sandbox on your own cloud. 注释:SkyPilot博客,https://blog.skypilot.co/skypilot-llm-sandbox/;SkyPilot Code Sandbox;GitHub:https://github.com/alex000kim/skypilot-code-sandbox。引用自:§2.2, §2.3, 表3。
  • T. V. Le, M. Jeon, K. Vu, V. Lai, 和 E. Yang (2025) No prompt left behind: exploiting zero-variance prompts in llm reinforcement learning via entropy-guided advantage shaping. arXiv预印本 arXiv:2509.21880。外部链接:链接。引用自:§3.3.3。
  • C. Li, Z. Tang, M. Huang, Y. Lin, S. Huang, S. Liu, B. Ye, R. Li, L. Li, B. Wang, 和 Y. Yuan (2026) Claw-eval-live: a live agent benchmark for evolving real-world workflows. 外部链接:2604.28139,链接。引用自:§6。
  • S. Liu, J. Yang, B. Jiang, Y. Li, J. Guo, X. Liu, 和 B. Dai (2025) Context as a tool: context management for long-horizon swe-agents. arXiv预印本 arXiv:2512.22087。引用自:表7。
  • Z. Lu, Y. Chai, Y. Guo, X. Yin, L. Liu, H. Wang, H. Xiao, S. Ren, G. Xiong, 和 H. Li (2025) UI-r1: enhancing efficient action prediction of gui agents by reinforcement learning. 外部链接:2503.21620,链接。引用自:§6。
  • R. Luo, L. Wang, W. He, L. Chen, J. Li, 和 X. Xia (2025) GUI-r1:一种面向 GUI 智能体的通用型 R1 风格视觉-语言-动作模型。外部链接:2504.10458,链接 引用自:§6。
  • Y. Lyu, X. Zhang, L. Yan, M. de Rijke, Z. Ren, 和 X. Chen (2025) DeepShop:面向深度研究购物智能体的基准测试。arXiv 预印本 arXiv:2506.02839。引用自:项目 1,§1,§4.1,§6。
  • M. A. Merrill, A. G. Shaw, N. Carlini, B. Li, H. Raj, I. Bercovich, L. Shi, J. Y. Shin, T. Walshe, E. K. Buchanan, J. Shen, G. Ye, H. Lin, J. Poulos, M. Wang, M. Nezhurina, J. Jitsev, D. Lu, O. M. Mastromichalakis, Z. Xu, Z. Chen, Y. Liu, R. Zhang, L. L. Chen, A. Kashyap, J. Uslu, J. Li, J. Wu, M. Yan, S. Bian, V. Sharma, K. Sun, S. Dillmann, A. Anand, A. Lanpouthakoun, B. Koopah, C. Hu, E. Guha, G. H. S. Dreiman, J. Zhu, K. Krauth, L. Zhong, N. Muennighoff, R. Amanfu, S. Tan, S. Pimpalgaonkar, T. Aggarwal, X. Lin, X. Lan, X. Zhao, Y. Liang, Y. Wang, Z. Wang, C. Zhou, D. Heineman, H. Liu, H. Trivedi, J. Yang, J. Lin, M. Shetty, M. Yang, N. Omi, N. Raoof, S. Li, T. Y. Zhuo, W. Lin, Y. Dai, Y. Wang, W. Chai, S. Zhou, D. Wahdany, Z. She, J. Hu, Z. Dong, Y. Zhu, S. Cui, A. Saiyed, A. Kolbeinsson, J. Hu, C. M. Rytting, R. Marten, Y. Wang, A. Dimakis, A. Konwinski, 和 L. Schmidt (2026) Terminal-Bench:在命令行界面中对智能体进行困难、真实任务的基准测试。外部链接:2601.11868,链接 引用自:§2.3,§3.1,§3.5。
  • MiniMax (2026) MiniMax M2.5:为真实世界生产力而生。注:https://www.minimax.io/news/minimax-m25 HuggingFace:https://huggingface.co/MiniMaxAI/MiniMax-M2.5 引用自:§3.2,§5.2。
  • Modal Labs (2024) Modal:高性能 AI 基础设施。注:https://modal.com 引用自:§1,§2.2,§6。
  • 月之暗面 (2026) Kimi Code CLI 注:用于软件开发和终端操作的 AI 智能体命令行工具。访问于 2026-05-06 外部链接:链接 引用自:§3.5。
  • L. Ning、Z. Liang、Z. Jiang、H. Qu、Y. Ding、W. Fan、X. Wei、S. Lin、H. Liu、P. S. Yu 和 Q. Li(2025)《WebAgents 综述:迈向基于大型基础模型的下一代 Web 自动化 AI 智能体》。载于《第 31 届 ACM SIGKDD 知识发现与数据挖掘会议论文集》V.2,第 6140–6150 页。外部链接:文献。被 §1 引用。
  • NVIDIA(2025)《Nemotron 3 Nano:面向智能体推理的开源高效混合专家 Mamba-Transformer 模型》。注:技术报告。外部链接:链接。被 §5.4 引用。
  • OpenAI(2024)《SWE-bench Verified 介绍》。注:https://openai.com/index/introducing-swe-bench-verified/ 从 SWE-bench 中经人工验证的 500 个实例子集,发布于 2024 年 8 月 13 日。被 §3.1、§6 引用。
  • OpenClaw 团队(2026)《OpenClaw》。外部链接:链接。被 §5.1、§6 引用。
  • OpenClaw(2026)《ClawHub:OpenClaw 技能目录》。外部链接:链接。被 §1 引用。
  • Y. Qin、Y. Ye、J. Fang、H. Wang、S. Liang、S. Tian、J. Zhang、J. Li、Y. Li、S. Huang、W. Zhong、K. Li、J. Yang、Y. Miao、W. Lin、L. Liu、X. Jiang、Q. Ma、J. Li、X. Xiao、K. Cai、C. Li、Y. Zheng、C. Jin、C. Li、X. Zhou、M. Wang、H. Chen、Z. Li、H. Yang、H. Liu、F. Lin、T. Peng、X. Liu 和 G. Shi(2025)《UI-TARS:开创基于原生智能体的自动化 GUI 交互》。外部链接:2501.12326,链接。被 §6 引用。
  • Qwen 团队(2025)《Qwen3 技术报告》。外部链接:2505.09388,链接。被 §3.3.1、§5.3 引用。
  • Qwen 团队(2026)《Qwen3.5:迈向原生多模态智能体》。注:https://qwen.ai/blog?id=qwen3.5 Qwen3.5-397B-A17B 的开源权重发布;HuggingFace:https://huggingface.co/Qwen/Qwen3.5-397B-A17B。被 §3.2 引用。
  • N. Shang、Y. Liu、Y. Zhu、L. L. Zhang、W. Xu、X. Guan、B. Zhang、B. Dong、X. Zhou、B. Zhang、Y. Xin、Z. Miao、S. Li、F. Yang 和 M. Yang(2025)《rStar2-Agent:智能体推理技术报告》。arXiv 预印本 arXiv:2508.20722。外部链接:链接。被 §3.3.3 引用。
  • Z. Shao、P. Wang、Q. Zhu、R. Xu、J. Song、X. Bi、H. Zhang、M. Zhang、Y. K. Li、Y. Wu 和 D. Guo(2024)《DeepSeekMath:突破开源语言模型的数学推理极限》。外部链接:2402.03300,链接。被 §3.3.3、§4.4、§5.3 引用。
  • H. Song、L. Huang、S. Sun、J. Jiang、R. Le、D. Cheng、G. Chen、Y. Hu、Z. Chen、W. X. Zhao、Y. Song、T. Zhang 和 J. Wen(2026)《SWE-Master:通过后训练释放软件工程智能体的潜力》。外部链接:2602.03411,文献。被引用于:表 7、表 7。
  • A. Sonwane、I. White、H. Lee、M. Pereira、L. Caccia、M. Kim、Z. Shi、C. Singh、A. Sordoni、M. Côté 和 X. Yuan(2025)《Bugpilot:为高效学习软件工程技能生成复杂缺陷》。arXiv 预印本 arXiv:2510.19898。被引用于:表 7、第 6 节。
  • C. Tao、J. Chen、Y. Jiang、K. Kou、S. Wang、R. Wang、X. Li、S. Yang、Y. Du、J. Dai、Z. Mao、X. Wang、L. Shang 和 H. Bai(2026)《SWE-Lego:突破监督微调在软件问题解决上的极限》。外部链接:2601.01426,文献。被引用于:表 7。
  • G. Team, A. Zeng, X. Lv, Q. Zheng, Z. Hou, B. Chen, C. Xie, C. Wang, D. Yin, H. Zeng, J. Zhang, K. Wang, L. Zhong, M. Liu, R. Lu, S. Cao, X. Zhang, X. Huang, Y. Wei, Y. Cheng, Y. An, Y. Niu, Y. Wen, Y. Bai, Z. Du, Z. Wang, Z. Zhu, B. Zhang, B. Wen, B. Wu, B. Xu, C. Huang, C. Zhao, C. Cai, C. Yu, C. Li, C. Ge, C. Huang, C. Zhang, C. Xu, C. Zhu, C. Li, C. Yin, D. Lin, D. Yang, D. Jiang, D. Ai, E. Zhu, F. Wang, G. Pan, G. Wang, H. Sun, H. Li, H. Li, H. Hu, H. Zhang, H. Peng, H. Tai, H. Zhang, H. Wang, H. Yang, H. Liu, H. Zhao, H. Liu, H. Yan, H. Liu, H. Chen, J. Li, J. Zhao, J. Ren, J. Jiao, J. Zhao, J. Yan, J. Wang, J. Gui, J. Zhao, J. Liu, J. Li, J. Li, J. Lu, J. Wang, J. Yuan, J. Li, J. Du, J. Du, J. Liu, J. Zhi, J. Gao, K. Wang, L. Yang, L. Xu, L. Fan, L. Wu, L. Ding, L. Wang, M. Zhang, M. Li, M. Xu, M. Zhao, M. Zhai, P. Du, Q. Dong, S. Lei, S. Tu, S. Yang, S. Lu, S. Li, S. Li, Shuang-Li, S. Yang, S. Yi, T. Yu, W. Tian, W. Wang, W. Yu, W. L. Tam, W. Liang, W. Liu, X. Wang, X. Jia, X. Gu, X. Ling, X. Wang, X. Fan, X. Pan, X. Zhang, X. Zhang, X. Fu, X. Zhang, Y. Xu, Y. Wu, Y. Lu, Y. Wang, Y. Zhou, Y. Pan, Y. Zhang, Y. Wang, Y. Li, Y. Su, Y. Geng, Y. Zhu, Y. Yang, Y. Li, Y. Wu, Y. Li, Y. Liu, Y. Wang, Y. Li, Y. Zhang, Z. Liu, Z. Yang, Z. Zhou, Z. Qiao, Z. Feng, Z. Liu, Z. Zhang, Z. Wang, Z. Yao, Z. Wang, Z. Liu, Z. Chai, Z. Li, Z. Zhao, W. Chen, J. Zhai, B. Xu, M. Huang, H. Wang, J. Li, Y. Dong, and J. Tang (2025) GLM-4.5: 智能体、推理与编码(ARC)基础模型。外部链接:2508.06471,链接 被表 7 引用。
  • B. Trabucco, G. Sigurdsson, R. Piramuthu, and R. Salakhutdinov (2025) InSTA:迈向互联网规模的智能体训练。外部链接:2502.06776 被第 1 项、第 4.3 节引用。
  • J. Wang, D. Zan, S. Xin, S. Liu, Y. Wu, and K. Shen (2025a) Swe-mirror:通过跨仓库镜像问题来扩展问题解决数据集。arXiv 预印本 arXiv:2509.08724。被表 7 引用。
  • W. Wang 等人 (2026) 《Let it flow: agentic crafting on rock and roll, building the ROME model within an open agentic learning ecosystem》。注:本文介绍了作为 ALE 生态系统一部分的 ROCK(强化学习开放构建套件)沙盒环境管理器;GitHub:https://github.com/alibaba/ROCK 外部链接:2512.24873,链接 引用自:§1, §2.2。
  • X. Wang, B. Li, Y. Song, F. F. Xu, X. Tang, M. Zhuge, J. Pan, Y. Song, B. Li, J. Singh, H. H. Tran, F. Li, R. Ma, M. Zheng, B. Qian, Y. Shao, N. Muennighoff, Y. Zhang, B. Hui, J. Lin, R. Brennan, H. Peng, H. Ji, 和 G. Neubig (2025b) 《OpenHands: an open platform for AI software developers as generalist agents》。收录于第十三届国际学习表征会议 (ICLR),外部链接:链接, 2407.16741 引用自:§1, §3.1, §3.2, 表7, §6。
  • P. Xia, J. Chen, X. Yang, H. Tu, J. Liu, K. Xiong, S. Han, S. Qiu, H. Ji, Y. Zhou, Z. Zheng, C. Xie, 和 H. Yao (2026) 《MetaClaw: just talk – an agent that meta-learns and evolves in the wild》。外部链接:2603.17187, 链接 引用自:§6。
  • C. Xie, B. Li, C. Gao, H. Du, W. Lam, D. Zou, 和 K. Chen (2025) 《SWE-Fixer: training open-source LLMs for effective and efficient GitHub issue resolution》。收录于计算语言学协会发现:ACL 2025,奥地利维也纳,第1123–1139页。外部链接:文献, 链接 引用自:表7。
  • T. Xie, D. Zhang, J. Chen, X. Li, S. Zhao, R. Cao, T. J. Hua, Z. Cheng, D. Shin, F. Lei, Y. Liu, Y. Xu, S. Zhou, S. Savarese, C. Xiong, V. Zhong, 和 T. Yu (2024) 《OSWorld: benchmarking multimodal agents for open-ended tasks in real computer environments》。收录于神经信息处理系统进展,第37卷,第52040–52094页。引用自:§1, §6。
  • T. Xiong, Y. Ge, M. Li, Z. Zhang, P. Kulkarni, K. Wang, Q. He, Z. Zhu, C. Liu, R. Chen, T. Zheng, Y. Chen, X. Wang, R. Zhang, W. Chen, 和 H. Huang (2026) 《Multi-crit: benchmarking multimodal judges on pluralistic criteria-following》。外部链接:2511.21662, 链接 引用自:§5.1。
  • Y. E. Xu, Y. Savani, F. Fang, 和 Z. Kolter (2025) 《Not all rollouts are useful: down-sampling rollouts in llm reinforcement learning》。arXiv 预印本 arXiv:2504.13818。外部链接:链接 引用自:§3.3.3。
  • J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. R. Narasimhan 和 O. Press (2024) 《SWE-agent:智能体-计算机接口实现自动化软件工程》。收录于第三十八届神经信息处理系统年度会议,外部链接:链接。引用自:§1, §1, §3.1, §3.2, §6。
  • J. Yang, K. Lieret, C. E. Jimenez, A. Wettig, K. Khandpur, Y. Zhang, B. Hui, O. Press, L. Schmidt 和 D. Yang (2025a) 《SWE-smith:为软件工程智能体扩展数据》。外部链接:2504.21798,链接。引用自:§3.1, §3.5, 表7, §6。
  • Z. Yang, S. Wang, K. Fu, W. He, W. Xiong, Y. Liu, Y. Miao, B. Gao, Y. Wang, Y. Ma, Y. Li, Y. Liu, Z. Hu, K. Zhang, S. Wang, H. Chen, F. Sung, Y. Liu, Y. Gao, Z. Yang 和 T. Liu (2025b) 《Kimi-Dev:将无智能体训练作为 SWE 智能体的技能先验》。外部链接:2509.23045,文献编号。引用自:表7。
  • S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan 和 Y. Cao (2023) 《ReAct:协同语言模型中的推理与行动》。收录于国际学习表征会议 (ICLR)。引用自:§1, §3.1, §4.2。
  • B. Ye, R. Li, Q. Yang, Y. Liu, L. Yao, H. Lv, Z. Xie, C. An, L. Li, L. Kong, Q. Liu, Z. Sui 和 T. Yang (2026) 《Claw-eval:迈向可信赖的自主智能体评估》。外部链接:2604.06132,链接。引用自:§1, §5.1, §5.4, 表14, §5, §6。
  • Q. Yu, Z. Zhang, R. Zhu, Y. Yuan, X. Zuo, Y. Yue, W. Dai, T. Fan, G. Liu, L. Liu, X. Liu, H. Lin, Z. Lin, B. Ma, G. Sheng, Y. Tong, C. Zhang, M. Zhang, W. Zhang, H. Zhu, J. Zhu, J. Chen, J. Chen, C. Wang, H. Yu, Y. Song, X. Wei, H. Zhou, J. Liu, W. Ma, Y. Zhang, L. Yan, M. Qiao, Y. Wu 和 M. Wang (2025) 《DAPO:一个大规模开源大语言模型强化学习系统》。arXiv 预印本 arXiv:2503.14476。引用自:§3.3.3, §4.4。
  • J. Zeng, D. Fu, T. Mi, Y. Zhuang, Y. Huang, X. Li, L. Ye, M. Xie, Q. Hua, Z. Huang, M. Jiang, H. Wang, J. Lin, Y. Xiao, J. Sun, Y. Wu 和 P. Liu (2026) 《daVinci-Dev:面向软件工程的智能体原生中期训练》。外部链接:2601.18418,文献编号。引用自:表7, 表7。
  • L. Zeng, Y. Li, Y. Xiao, C. Li, C. Y. Liu, R. Yan, T. Wei, J. He, X. Song, Y. Liu, 和 Y. Zhou (2025) 《Skywork-SWE:揭示大语言模型中软件工程的数据缩放定律》。外部链接:2506.19290,文献。被表 7 引用。
  • ZeroClaw Labs (2026) 《ZeroClaw》。外部链接:链接。被第 1 节、第 5.1 节引用。
  • C. Zhang, S. He, J. Qian, B. Li, L. Li, S. Qin, Y. Kang, M. Ma, G. Liu, Q. Lin, S. Rajmohan, D. Zhang, 和 Q. Zhang (2025) 《大语言模型驱动的图形用户界面智能体:综述》。机器学习研究汇刊。外部链接:ISSN 2835-8856,链接。被第 1 节引用。
  • H. Zhang, M. Liu, S. Zhang, S. Han, J. Hu, Z. Jin, Y. Zhang, S. Diao, X. Lu, B. Xu, Z. Yu, J. Kautz, 和 Y. Dong (2026a) 《ProRL Agent:面向多轮大语言模型智能体强化学习训练的即用式回滚服务》。外部链接:2603.18815,链接。被第 1 节、第 2.2 节、第 6 节引用。
  • L. Zhang, M. Chen, R. Cao, J. Chen, F. Zhou, Y. Xu, J. Yang, L. Chen, C. Luo, K. Zhang, F. Yan, K. Shum, J. Zhang, Z. Cui, H. Feng, J. Lin, B. Hui, 和 M. Yang (2026b) 《MegaFlow:面向智能体时代的大规模分布式编排系统》。外部链接:2601.07526,链接。被第 1 节、第 2.2 节、表 2、第 6 节引用。
  • Z. Zhang, Z. Han, C. Mavromatis, Q. Zhu, Y. Zhang, S. Guan, D. Wang, X. Zhou, S. Wang, S. Adeshina, V. Ioannidis, 和 H. Rangwala (2026c) 《训练更少,学习更多:基于分组的强化学习的自适应高效回滚优化》。arXiv 预印本 arXiv:2602.14338。外部链接:链接。被第 3.3.3 节引用。
  • J. Zhao, G. Chen, F. Meng, M. Li, J. Chen, H. Xu, Y. Sun, W. X. Zhao, R. Song, Y. Zhang, P. Wang, C. Chen, J. Wen, 和 K. Jia (2026) 《沉浸于 GitHub 宇宙:将编码智能体扩展至精通水平》。arXiv 预印本 arXiv:2602.09892。被第 1 节、第 3.2 节、第 3.5 节、表 7、第 6 节引用。
  • C. Zheng, S. Liu, M. Li, X. Chen, B. Yu, C. Gao, K. Dang, Y. Liu, R. Men, A. Yang, J. Zhou, 和 J. Lin (2025a) 《分组序列策略优化》。arXiv 预印本 arXiv:2507.18071。被第 3.3.3 节引用。
  • H. Zheng, Y. Zhou, B. R. Bartoldson, B. Kailkhura, F. Lai, J. Zhao, 和 B. Chen (2025b) 《只在有回报时行动:通过选择性回滚实现大语言模型推理的高效强化学习》。arXiv 预印本 arXiv:2506.02177。外部链接:链接。被第 3.3.3 节引用。
  • 郑立、黄伟强、盛颖、庄思远、吴子涵、庄宇轩、林志浩、李卓、李东、邢波、张浩、J. E. Gonzalez 和 I. Stoica(2023)《用 MT-Bench 和 Chatbot Arena 评判大语言模型作为评判者》。外部链接:2306.05685,链接。引用自第 5.1 节。
  • 周思远、徐凡凡、朱浩宇、周翔、罗瑞、A. Sridhar、程鑫、欧天宇、Y. Bisk、D. Fried、U. Alon 和 G. Neubig(2024)《WebArena:用于构建自主智能体的真实网络环境》。载于第十二届国际学习表征会议,外部链接:链接。引用自第 1 节。
  • 周宇、杨倩、林凯、白明、周翔、王宇、S. Levione 和李毅(2025)《提议者-智能体-评估者(PAE):面向基础模型互联网智能体的自主技能发现》。载于 ICML,外部链接:链接。引用自第 1 项、第 4.3 节。
  • 朱志远、谢晨、吕鑫及 slime 贡献者(2025)《Slime:面向强化学习扩展的大语言模型后训练框架》。注释:https://github.com/THUDM/slime GitHub 仓库。通讯作者:吕鑫。引用自第 3.3.1 节、第 3.3.2 节。

附录 A Orchard 环境设计细节

Orchard 环境的设计遵循一个核心原则:环境层应足够薄,以便能够跨训练方案、智能体框架和模型后端复用,同时提供大规模智能体训练所需的隔离性和生命周期管理。我们重点介绍实现这一原则的五项设计选择,它们共同满足了章节开头所述的要求 R1 至 R3。其中两项是使 Orchard 环境区别于现有环境服务的关键技术选择:智能体注入以近乎为零的适配成本解决图像异构性问题(R2),直接 Pod-IP 通信保持服务轻量化并将 Kubernetes 控制平面移出热路径(R1)。其余三项——网络隔离、基于心跳清理的异步生命周期以及基于就绪检查的等待机制——是使该服务在大规模智能体训练所需的并发性和可靠性水平上达到生产级标准的运营特性;它们与 Kubernetes 原生部署共同支持了 R3(量化结果见第 2.2 节)。以下五段先介绍关键选择,再介绍运营特性。

通过 Init 容器进行智能体注入。

为智能体训练构建环境服务时,一个核心挑战是镜像异构性:不同任务需要不同的基础镜像(例如,特定的 Python 版本、系统库或语言工具链),并且大规模地修改每个镜像以包含一个执行智能体是不切实际的。Orchard Env 通过一个 Kubernetes init 容器解决了这个问题,该容器在主容器启动前,将一个独立的 Python 运行时和智能体服务器复制到一个共享的 emptyDir 卷中。然后,主容器通过 `/opt/sandbox-agent/start.sh` 从共享卷启动智能体。这种设计避免了将 Python 或智能体打包到每个任务镜像中;在实践中,Orchard Env 针对 Linux 容器镜像,并默认通过 `sh -c` 启动注入的智能体。

直接 Pod IP 通信。

沙箱配置完成后,所有执行和文件操作请求都直接路由到 Pod IP,完全绕过 Kubernetes API 服务器。这避免了 Kubernetes exec API 的控制平面中介和 WebSocket 设置开销。直接通信减少了每条命令的往返开销,并消除了 API 服务器在高并发下成为吞吐量瓶颈的问题。

网络隔离。

Orchard Env 通过 Kubernetes NetworkPolicy 资源强制实施网络隔离。一个命名空间范围的默认拒绝出站流量策略阻止沙箱容器发起出站连接。当沙箱需要网络访问(例如,用于安装包)时,编排器会创建一个按沙箱划分的 NetworkPolicy,有选择地允许出站流量,该策略会随沙箱一起清理。这提供了纵深防御:即使一个用户提供的命令试图窃取数据,也会在网络层被阻止。

基于心跳清理的异步生命周期。

沙箱创建是异步的:API 在 Pod 创建后立即返回,客户端通过轮询或阻塞等待 `/wait` 端点,直到就绪。这种设计将 API 响应速度与 Kubernetes 调度延迟解耦。长期运行的沙箱可通过客户端 SDK 定期发送心跳消息来保持存活。编排器中的后台清理循环会检测心跳已过期的沙箱并将其删除,从而防止因客户端崩溃或遗弃而导致的资源泄漏。

基于 Watch 的就绪检测。

编排器不轮询 Kubernetes API 获取 Pod 状态,而是维护一个持久的 LIST+WATCH 流,实时跟踪所有沙箱 Pod 的状态转换。状态变更缓存在内存中,并通过 `asyncio.Event` 通知等待者,从而避免重复轮询 Kubernetes API。

附录 B 成本分析详情

本附录提供了表 2 中成本对比的完整方法和讨论。

场景设定。

我们估算了运行 128 个并行沙箱环境 240 小时的成本,每个沙箱配置为 2 vCPU 和 8 GiB 内存——与典型的 SWE-bench 任务环境一致。

Orchard 部署方案。

Orchard 部署在 17 个 Azure Standard_D16ads_v5 实例上(每个实例 16 vCPU、64 GiB 内存):其中 16 个节点各托管 8 个沙箱(共 128 个),1 个节点运行编排器。沙箱节点使用竞价实例(可抢占式虚拟机,享受 80% 折扣,每小时 0.13 美元,对比按需实例每小时 0.65 美元),非常适合可容忍偶尔抢占的临时沙箱工作负载。编排器节点采用标准按需付费定价以确保稳定性。

托管服务定价。

对于托管服务,我们使用其官方按秒或按小时定价,针对 2 vCPU、8 GiB 的沙箱,包含计算和内存费用:

  • •

    E2B:vCPU 费用为 0.000014 美元/vCPU/秒 × 2 = 0.000028 美元/秒,加上内存费用 0.0000045 美元/GiB/秒 × 8 = 0.000036 美元/秒。总计:0.000064 美元/秒 = 每个沙箱每小时 0.2304 美元。

  • •

    Daytona:vCPU 费用为 0.0504 美元/vCPU/小时 × 2 = 0.1008 美元/小时,加上内存费用 0.0162 美元/GiB/小时 × 8 = 0.1296 美元/小时。总计:每个沙箱每小时 0.2304 美元。

  • •

    Modal:CPU 费用为每物理核心每秒 0.00003942 美元,1 个核心(= 2 个 vCPU)即每秒 0.00003942 美元,加上内存费用每 GiB 每秒 0.00000672 美元,8 GiB 即每秒 0.00005376 美元。总计:每个沙箱每秒 0.00009318 美元,即每小时 0.3354 美元。Modal 沙箱定价默认不可被抢占。

  • •

    MegaFlow:基于阿里云 ecs.c8a.2xlarge 实例(8 个 vCPU,16 GiB 内存,每小时费用)估算,每个实例运行一个任务,如原论文所述。每个沙箱的资源分配超出了我们 2 个 vCPU 的目标。

关键观察。
  • •

    竞价实例的经济性。Orchard 的自托管设计支持使用云竞价实例——即以大幅折扣(D16ads_v5 实例竞价每小时费用 vs. 按需每小时费用)提供的可抢占虚拟机,代价是可能被短时通知后回收。由于沙箱容器是临时的,并且可以在被回收时重新创建,因此竞价定价非常适合沙箱节点池。托管服务无法传递竞价定价,因为它们控制着底层基础设施。

  • •

    虚拟机级别的多路复用。由于 Orchard 将多个沙箱打包到每台虚拟机上(每个 D16ads_v5 节点 8 个沙箱),因此每个沙箱的成本受益于共享开销。相比之下,MegaFlow 的每个实例一个任务模型为每个沙箱分配了一整台虚拟机,导致即使云定价相当,每个沙箱的成本也更高。

  • •

    按需实例对比。即使不使用竞价实例,Orchard 的按需成本(3,362 美元)也大约是 E2B 和 Daytona(各 7,078 美元)的一半,以及 Modal(10,305 美元)的三分之一。关键优势在于,Orchard 让研究人员完全掌控集群——他们可以调整节点池、自动扩缩容、网络策略和资源限制,而无需依赖供应商的控制平面。

这些成本差异在研究项目的过程中会不断累积。生成 16 万条 rollout 轨迹、运行消融实验以及迭代训练方案,很容易需要数千小时的环境交互。Orchard 自托管且支持竞价实例的设计,使得此类工作负载在学术研究预算下变得切实可行。

附录 C Orchard-GUI 工具列表

本附录完整复现了 Orchard-GUI 所使用的全部 13 个原子工具的 OpenAI 工具调用 JSON Schema。在每一步中,智能体会发起一个或多个工具调用,每个调用都包含在 `<tool_call>…</tool_call>` 块内。为便于阅读,这些 schema 按功能族分组,每个功能族用一个样式框呈现。

附录 D 示例 GUI 智能体运行轨迹

本附录展示了 Orchard-GUI 在 WebVoyager 风格任务上生成的一个典型多轮运行过程。第一个框给出了模型在最后一步接收到的提示词(系统提示词 + 通过先前步骤累积的运行轨迹)。第二个框显示了模型在该步骤的响应(其最终推理结果,后接终止的 done 调用)。整个包含七个 think、tool_call、tool_response 循环的完整运行轨迹被逐字呈现。仅系统提示词中的 JSON 工具 schema 被用 […] 缩写(完整 schema 见附录 C)。

附录 E Orchard-GUI 任务过滤流水线

我们从 WebGym(Bai 等人,2026b)整理的任务集中抽取任务实例,该任务集总共包含 292,092 个原始任务实例。为了生成一个干净、评估安全且多样化的训练提示词池,我们应用了一个五阶段过滤流水线:

  1. 1.

    移除常见的评估基准。我们剔除与保留的评估基准(例如 Online-Mind2Web(Deng 等人,2023)和 DeepShop(Lyu 等人,2025))重叠的数据划分,以防止训练/测试数据污染,仅保留两个互补的划分:PAE-WebVoyager(Zhou 等人,2025)和 InSTA-v3(Trabucco 等人,2025)(减少 13,840 个,剩余 278,252 个)。前者由上下文感知的任务提议器自动生成的网页导航任务组成,这些任务基于 WebVoyager(He 等人,2024)基准所涵盖的网站;后者则包含由大语言模型在大量且多样化的网站集合上自动合成的任务。每个任务都锚定在特定领域,并表述为真实的用户目标(例如,查找信息、检索属性或完成简单工作流),重点强调可行性和安全性。

  2. 2.

    仅保留父级任务。WebGym 额外提供了从每个父级意图分解出的子任务。由于子任务与父任务在结构上高度重叠,我们仅保留父级任务,以避免族内冗余(减少 23,437 条,剩余 254,815 条)。

  3. 3.

    排除 WebVoyager 任务。我们进一步剔除其意图出现在原始 WebVoyager 基准测试中的任何任务,从而在提示词层面消除残留污染(减少 411 条,剩余 254,404 条)。

  4. 4.

    限制为热门网站。长尾网站噪声更大(验证码更多、反爬虫拦截更多、页面损坏更多),且对真实浏览场景的代表性较低。我们仅保留目标网站同时出现在 SimilarWeb 前 100 名榜单和 MOZ 前 500 名最受欢迎网站中的任务,且同一网站至少包含两个任务,以确保下游智能体在每个网站上有足够的覆盖度(减少 114,349 条,剩余 140,055 条)。

  5. 5.

    语义去重。剩余池中充斥着近乎重复的意图(例如,对同一购物或搜索查询的改写版本,涉及数千种产品)。我们使用 Qwen/Qwen3-Embedding-8B 对每个任务意图进行嵌入向量化,并贪婪地移除那些与已保留任务的余弦相似度超过阈值的任务(减少 124,454 条,剩余 15,601 条)。

最终筛选出的 15,601 个独特任务意图池,作为我们从中采样教师轨迹以用于 SFT 和 RL 提示词的种子集。

来源:HuggingFace Daily Papers(社区热门论文) · arxiv.org