微软研究院推出Orchard：让AI智能体训练像搭积木一样灵活，开源框架重塑大模型自主行动能力

这项由微软研究院联合哥伦比亚大学和伊利诺伊大学香槟分校共同开展的研究，以预印本形式于2026年5月14日发布在arXiv平台，论文编号为arXiv:2605.15040v1。有兴趣深入了解技术细节的读者可以通过该编号查阅完整论文。

一、为什么我们需要一个"会自己动手"的AI？

你有没有想过，如果手机上的AI助手不只是回答问题，而是能替你真正完成一件事——比如帮你修复一段代码、在网上找到符合你要求的商品、甚至处理你的邮件和日程安排——那会是什么体验？这种能够"自己动手"解决问题的AI，在学术界有一个专门的名字：智能体（Agent）。

普通的AI，你问它一个问题，它给你一个答案，到此为止。而智能体AI则不一样，它会一步一步地思考、行动、观察结果，然后继续调整策略，就像一个真正在解决问题的人。比如，当你告诉一个AI智能体"帮我把GitHub上这个报错的代码修好"，它会先读懂问题，然后打开代码文件、尝试修改、运行测试、看看有没有通过，没通过就继续调整，直到真正解决为止。这个过程可能需要几十步甚至更多。

要训练这样的AI，最大的麻烦不是算法本身，而是"练习场"的问题。每一次练习，AI都需要一个真实的、隔离的环境来执行操作——就像学生做实验需要实验室，而不能在真实的生产环境里乱改代码。更棘手的是，不同任务需要不同的"实验室"，软件工程任务需要装好各种依赖的代码仓库，网页操作任务需要真实运行的浏览器，个人助手任务需要模拟的邮件和日历系统。当你要同时训练成千上万个AI智能体时，你需要同时开启成千上万个这样的"实验室"，管理它们的启动、运行、清理，同时还要保证速度够快、成本够低。

这正是目前业界面临的核心难题。现有的解决方案要么是封闭的商业平台，研究者无法自由定制；要么是把"实验室管理系统"和"AI训练系统"死死绑在一起，换一个任务就要重建整套系统。微软研究院的团队意识到，这个问题的根源在于没有人专门把"实验室管理"这件事做成一个干净、独立、可以被任意复用的服务。于是他们构建了Orchard。

二、Orchard的核心理念：把"实验室管理"从训练系统中独立出来

Orchard框架的设计哲学，可以用一个厨房的比喻来理解。假设你要开一家餐厅，厨房本身——灶台、烤箱、冰箱、操作台——是一套基础设施。不同的厨师可以在这个厨房里做中餐、西餐、日料，同一套厨房设备，搭配不同的食材和菜谱，就能产出完全不同的菜品。Orchard的核心组件Orchard Env，正是这样一个"厨房基础设施"——它管理的是AI练习所需的沙盒环境，但它本身不关心AI在做什么任务、用什么方式训练、要解决什么问题。

具体来说，Orchard Env是一个运行在Kubernetes（一种主流的容器编排系统，可以理解为管理大量"小型虚拟计算机"的调度系统）之上的轻量级环境服务。它提供了四类核心能力：沙盒的生命周期管理（创建、运行、销毁一个隔离的执行环境）、命令执行（在沙盒里运行任意命令并返回结果）、文件读写（往沙盒里传入文件，或把结果文件取出来）、以及网络隔离策略（控制沙盒能否访问外网）。这些功能通过一套REST API对外暴露，任何训练系统、任何评估脚本、任何数据收集工具，都可以通过这套API来使用沙盒，不需要关心底层实现。

这个设计带来了一个非常实用的特性：同一套环境服务可以横跨三个维度复用。跨任务领域方面，软件工程、网页导航、个人助手这三类完全不同的任务，都可以共用Orchard Env来管理各自的执行环境。跨智能体框架方面，同一批训练数据可以用OpenHands框架收集，然后在另一个叫mini-swe-agent的框架下评测，不需要为每个框架单独搭建一套环境基础设施。跨训练阶段方面，数据收集阶段、监督微调阶段、强化学习阶段、最终评估阶段，都可以调用同一套Orchard Env，整个训练流水线共享同一个基础设施层。

Orchard Env还有一个技术上的关键设计叫做"运行时智能体注入"。不同任务往往需要不同的基础镜像——SWE-bench这个软件工程基准就需要数百个不同的Docker镜像，每个都对应一个特定的代码仓库和依赖环境。通常情况下，你需要把执行代理（Agent，负责在沙盒内实际运行命令的小程序）提前烧录进每一个镜像，工作量极大。Orchard Env的做法是在容器启动时，通过Kubernetes的init container机制（可以理解为容器启动前运行的准备程序），把一个自包含的Python运行时和执行服务动态注入进去。这样一来，不管目标镜像是什么，都不需要修改，直接用就行。

在性能层面，Orchard Env采用了直接路由到Pod IP的通信方式，绕开了Kubernetes API服务器这个性能瓶颈。实测结果显示，平均命令执行延迟只有0.28秒，与直接用Docker相比几乎没有损耗，比商业沙盒平台E2B快2.7倍，比Modal平台快7.3倍。在压力测试中，1000个沙盒同时并发运行，完整经历创建、执行4条命令、销毁的全流程，成功率达到100%，整个过程只用了26秒。

说到成本，这是Orchard Env相对于商业替代品的一个显著优势。以128个并行沙盒、每个配置2核CPU和8GB内存、连续运行240小时为参照场景来估算：E2B和Daytona这两个主流商业沙盒平台的费用约为7078美元；而Orchard Env在正常按需计费模式下只需3362美元，不到商业平台的一半；如果使用云服务商的竞价实例（即可以被随时回收的低价虚拟机，非常适合可以容忍中断的批量训练任务），成本可以降到673美元，节省超过90%。

三、三套"菜谱"：用同一个厨房做出三种完全不同的大餐

有了厨房基础设施，研究团队在上面开发了三套完整的智能体训练方案，分别针对软件工程、网页操作和个人助手三个领域。每套方案都遵循相同的两阶段训练流程：先用监督微调让模型学会基本动作，再用强化学习让模型在实际互动中精进。

先来看软件工程领域的Orchard-SWE。要训练一个能修复真实GitHub问题的AI，首先需要大量的"示范样本"——也就是让高水平的模型先去解决这些问题，把解题过程记录下来，让学生模型模仿学习。研究团队从MiniMax-M2.5和Qwen3.5-397B这两个顶级"老师模型"出发，分别在三个任务数据集上收集轨迹数据：SWE-rebench提供了来自1400多个Python仓库的真实GitHub问题；SWE-rebench V2将范围扩展到20种编程语言、超过3.2万个任务；Scale-SWE则从真实GitHub Pull Request中构造了10万个任务实例，覆盖5200个代码仓库。

整个数据收集过程在Orchard Env的支撑下并行进行，每个任务都在独立的沙盒环境中运行，保证互不干扰。最终收集到的训练数据集包含107185条轨迹，覆盖19287个独特的任务实例，平均每条轨迹有47.5个交互回合、约2.1万个token。

这里有一个值得关注的做法：通常的训练方案只保留"成功解决了问题的轨迹"，失败的轨迹直接丢掉。但研究团队保留了32536条未能解决问题的轨迹，并为它们开发了一套叫做"信用分配监督微调"（Credit-Assignment SFT）的方法。这个方法的逻辑是这样的：一条失败的轨迹并不是一无是处，它在失败之前可能做了很多正确的事情——比如准确找到了相关文件、正确分析了问题根源——只是最后一步走偏了。如果能识别出这些"有价值的片段"并从中学习，就相当于从失败中提取经验，而不是把所有努力都扔进垃圾桶。

具体实现方式是用老师模型回顾每一条失败轨迹，在已知最终结果的情况下，为每个步骤估算一个"当前成功概率"——如果在步骤5之前成功概率一直在上升，说明前5步是在走向正确答案的；如果步骤6开始成功概率急剧下降，说明步骤6出现了关键错误。研究团队把成功概率持续上升的片段提取出来作为训练信号，称为"上升片段"。实验结果显示，在规模匹配的对比实验中，加入信用分配SFT后，模型在SWE-bench Verified上的解题率从59.3%提升到61.2%。

强化学习阶段则引入了一个叫做"平衡自适应采样"（Balanced Adaptive Rollout，BAR）的新方法。强化学习的基本逻辑是：让模型多次尝试解决同一个问题，根据成功与失败的对比来调整策略。但标准做法（GRPO，一种常用的强化学习算法）有一个明显的浪费问题：如果一个问题对当前模型来说太简单（每次都成功），或者太难（每次都失败），那么这批尝试产生的训练信号几乎为零——你无法从"全赢"或"全输"中学到有效的策略改进方向。这就像一个学生考试，题目要么全会要么全不会，无论哪种情况都学不到东西；真正有价值的练习是那些有时对、有时错的题目。

BAR的解决方案是动态调整采样策略：对每个问题，先生成一批尝试，检查成功与失败的比例是否落在一个目标区间（比如37.5%到62.5%之间的成功率）。如果比例合适，直接用这批数据训练；如果所有尝试都失败了，继续多生成几批；如果所有尝试都成功了，说明这道题太简单，调低它的优先级。这个机制把每一次训练迭代的信息密度最大化，不让计算资源浪费在无效的练习上。

最终，使用Qwen3-30B-A3B-Thinking这个基座模型（这是一种混合专家架构的模型，总参数量30B，但每次推理只激活约3B参数），Orchard-SWE在SWE-bench Verified上达到了64.3%（仅SFT阶段）和67.5%（SFT加RL阶段）的解题率，在同等规模的开源模型中排名第一。这个结果的参照系是：同类开源方案中最强的OpenSWE-72B达到66%，但它用的是72B参数的密集模型，激活参数量是Orchard-SWE的20多倍。

更值得关注的是跨框架泛化能力。研究团队还额外测试了Scale-SWE和OpenSWE-32B这两个性能相近的开源竞品在不同框架下的表现。Scale-SWE（只用一个框架训练的）在切换到其他框架后直接崩溃，输出了无法解析的格式，解题率变为零。OpenSWE-32B从62.4%暴跌到在Kimi-CLI框架下的3.6%。而Orchard-SWE在三个不同框架下的表现区间是45%到64.3%，最坏情况的跌幅被控制在20个百分点以内。研究团队分析认为，这种泛化能力来自于数据多样性：同时使用了两种框架收集训练数据，覆盖了两种不同的"工具操作风格"，让模型学到了更通用的问题解决能力，而不是特定框架的操作习惯。

四、四亿像素背后的视觉导航：Orchard-GUI如何用4B模型超越235B的老师

网页操作智能体面临的挑战和软件工程有很大不同。软件工程任务主要是读代码、改代码，输入和输出都是文字；而网页操作需要"看"屏幕截图——理解网页的布局、找到要点击的按钮、判断操作是否成功。这需要模型同时处理图像和文字，称为视觉语言模型（VLM）。

Orchard-GUI的训练目标是一个4B参数的视觉语言模型，任务是操作真实的网页完成用户的各类请求，比如"在亚马逊上找一个可水洗的、长度至少30英寸的狗床"。评测在三个基准上进行：WebVoyager覆盖15个固定的热门网站；Online-Mind2Web覆盖更广泛多样的网站分布；DeepShop专注于电商购物场景。

训练数据的来源是WebGym数据集，原始包含29.2万个任务。研究团队经过五道筛选：去掉与评测集重叠的任务、去掉从属任务、去掉WebVoyager原有的任务（防止训练集泄题）、只保留知名度排行前列的网站上的任务（过滤低质量的长尾网站）、最后用语义相似度算法去除重复意思的任务。最终得到15601个高质量训练任务。

数据收集阶段，用Qwen3-VL-235B这个235B参数的视觉语言大模型作为老师，在每个任务上生成4条独立尝试轨迹，总计约6.2万条原始轨迹。用GPT-4.1作为裁判对每条轨迹进行评分，只保留被判定为成功的轨迹。在这6.2万条中，68.4%的任务至少有一条成功轨迹，26.3%的任务四条全部成功；剩下31.6%全部失败，其中41.1%是因为被网站的验证码拦截导致的，并非真正无法解决。

用于SFT阶段的数据只保留了412个任务的成功轨迹，而且故意不用全部成功数据。原因是一个有趣的观察：如果让学生模型大量模仿老师的解题过程，模型会陷入一种"只会照着书念"的状态，后续的强化学习反而很难再提升它。所以研究团队刻意保持SFT数据量较小，让模型建立基本动作能力即可，把更多的提升空间留给强化学习阶段。

强化学习阶段使用了2198个任务，奖励信号由两部分组成：格式是否符合要求（每一步都必须先写思考过程，再写工具调用），以及GPT-4.1判定最终任务是否完成。训练采用分阶段的步数预算策略：先在最多15步的短序列任务上训练，等性能稳定后再切换到最多30步的任务，让模型循序渐进地学习处理更复杂、更长的任务。

结果方面，Orchard-GUI在三个评测基准上的成功率分别为74.1%（WebVoyager）、67.0%（Online-Mind2Web）、64.0%（DeepShop），平均68.4%。作为参照，之前最强的开源模型MolmoWeb-8B的平均成功率是51.9%，差距超过16个百分点。更戏剧性的是，Orchard-GUI一个4B的学生模型，在Online-Mind2Web和DeepShop上分别超越了自己235B的老师模型3.3和7.3个百分点——一个小班同学考了比老师还高的分。研究团队认为这说明基于真实环境交互的强化学习能够挖掘出监督微调无法达到的能力边界。

五、个人助手智能体：只用200个任务，如何让AI学会处理复杂工作流？

Orchard-Claw针对的是个人助手场景——帮用户整理邮件、管理日程、协调各种日常工具。这类任务的特点是需要跨多个工具调用、逻辑链条很长、还需要考虑安全性（不能乱删邮件或发送错误信息）和鲁棒性（遇到意外情况要能合理应对）。

由于这个领域比较新，没有现成的大规模训练数据，研究团队采用了合成数据的方式。他们用Claude Opus 4.6设计了一个四步数据生成循环：先提议并筛选任务想法，然后自动生成任务所需的环境（包括虚拟邮箱、文件系统、工具服务器）和测试脚本，接着让MiniMax-M2.5实际去解决这些任务，最后根据解决情况修改任务设计使其更合理、更清晰。每生成一个任务平均花费4.9美元，最终生成了192个高质量合成任务。

这个方案里还有一个有意思的设计：数据同时覆盖两种不同的使用框架，一种是Claw-Eval基准自带的ReAct风格框架（一种标准的思考-行动交替循环），另一种是ZeroClaw（一个更轻量、基于Rust语言实现的框架，提供了更多高级功能比如子智能体和自动压缩）。训练时同时在两个框架上进行，目的是验证：如果一个模型在两种框架下都练习过，它在其他框架下会不会更擅长发挥？

评测指标采用Claw-Eval基准，每个任务有两个关键指标：pass3（三次尝试都必须通过）衡量稳定性，pass@3（三次中至少一次通过）衡量上限能力。Orchard-Claw（SFT+RL）在ReAct框架下达到31.7% pass3和59.6% pass@3，比同规模的基座模型Qwen3-30B-A3B-Thinking提升了17个百分点以上。

在ZeroClaw框架下，同一个模型的表现进一步跳升到41.0% pass3和73.9% pass@3，分别提升9.3和14.3个百分点。相比之下，同样切换到ZeroClaw框架的Qwen3-Coder-30B-A3B-Instruct几乎没有提升甚至略有下降。这个对比说明：因为Orchard-Claw在训练时就接触过ZeroClaw的使用模式，它能更充分地利用ZeroClaw提供的高级功能；而只在单一框架下训练的模型，即使换了一个"更好的工具"，也不知道怎么用。

这个发现在实践中意义很大：智能体的能力不只取决于模型本身有多强，还取决于它在什么框架下工作、它是否在训练中见过这个框架。一个在多框架环境下训练的模型，在使用新工具时往往能更快适应。

六、整个框架的意义：为什么"基础设施"才是最重要的东西？

回到最初的那个问题：为什么要花那么大力气去做环境基础设施？微软研究院团队的答案是，环境层不是训练系统的配件，而是训练系统能否复用的根本。

当Orchard Env提供了一个和任何上层系统都解耦的环境接口，一件很微妙的事情就发生了：数据可以在框架A下收集，然后在框架B下训练，再在框架C下评测，而不需要为每个阶段和每个框架单独搭建一套基础设施。这种灵活性在实际研究中至关重要——研究者可以复用已有的轨迹数据、在新任务上快速扩展、比较不同框架的效果，而不是每次都从头重建整套系统。

从三个领域的实验中可以看出一个共同规律：数据多样性（多个教师模型、多个训练框架、多个任务来源）结合环境交互的强化学习，是当前提升智能体泛化能力最有效的路径。单纯增大模型规模不一定有效；只在单一框架下训练会造成严重的"框架锁定"；大量模仿学习而不做强化学习会让模型失去探索能力。Orchard三个模块的成功，都可以归因于这些正确的训练设计选择，而这些选择能够实施的前提，是有一套足够灵活的基础设施支撑。

研究团队将完整的Orchard框架开源，包括Orchard Env的全部代码、三套训练方案的实现、以及涵盖软件工程、网页导航和个人助手三个领域的全量训练数据集。这对于学术研究者来说是一个相对罕见的礼物——不仅有方法论，还有可以直接跑起来的系统和数据。

归根结底，这项工作提醒我们，AI能力的进步往往不只靠更大的模型，也靠更好的训练工具。当训练基础设施足够开放和灵活，更多的研究者就能把精力放在真正有价值的智能体能力设计上，而不是每次都在重复搭建那些已经有人做过的基础工程。

Orchard的开放，或许意味着未来会有更多能"自己动手"解决问题的AI出现，而它们背后共享着同一个干净、高效的练习场。

---

Q&A

Q1：Orchard框架和E2B、Daytona这些商业沙盒平台有什么本质区别？

A：Orchard Env最大的不同是完全自托管、成本可控，并且与训练框架彻底解耦。商业平台如E2B和Daytona提供的是托管服务，定价由平台决定，研究者无法调整底层配置，也无法利用云服务商的竞价实例降低成本。Orchard Env运行在标准Kubernetes环境上，既可以部署在AWS、Azure、谷歌云等主流云服务商，也可以自建集群，使用竞价实例后成本可比商业平台低90%。此外，Orchard Env通过运行时注入机制支持任意Docker镜像，不需要修改镜像本身，能够直接适配SWE-bench等需要数百种不同环境的复杂任务集。

Q2：Orchard-GUI训练的4B模型为什么能超越235B的老师模型？

A：这是强化学习阶段的关键作用。在监督微调阶段，学生模型学习的是老师模型的成功轨迹，能力上限由老师的示范决定。但在强化学习阶段，学生模型通过与真实网页环境的反复交互，依靠奖励信号自主探索，可以发展出老师模型的示范数据中并不包含的策略。简单说，老师能教你的只是它自己会的，但通过实际练习和即时反馈，学生有可能在某些方面超过老师。Orchard-GUI在Online-Mind2Web和DeepShop两个评测集上的超越幅度为3到7个百分点，说明基于真实环境的强化学习确实能突破监督学习的上限。

Q3：Orchard-SWE的"信用分配"方法在训练失败轨迹上具体怎么操作？

A：这个方法的核心是回溯性价值估计。对于每一条最终失败的轨迹，研究团队在已知失败结果的前提下，让老师模型重新审视整条轨迹，为每个步骤估算一个当前成功概率——哪些步骤是在接近解答、哪些步骤是关键的转折点。具体估算逻辑是让老师模型先读懂问题和测试结果，找出轨迹中的关键错误，然后以此为参照反向推算每个步骤的成功概率，要求概率在错误出现前上升、错误出现后下降。最终提取成功概率持续上升的片段（称为上升片段），只对这些片段计算训练损失，而忽略错误出现后的部分。这样即便整条轨迹最终失败，其中有价值的探索过程依然为模型提供了学习信号。