Microsoft 开放 Orchard，但可复用 Agent 训练仍面临规模化难题
Microsoft Research 以三套 Agent 训练方案开放了 Orchard，挑战了每个 Agent 项目都需要专属基础设施的观念。该框架涵盖软件工程、浏览器交互和个人助手任务。其核心承诺在于复用：同一环境层可支持数据收集、监督训练、强化学习和评估。
这很重要，因为开放 Agent 研究面临基础设施难题。研究人员可以研究许多编排库，但要复现高能力 Agent 背后的训练系统仍然困难。沙箱、工具接口、奖励函数和长轨迹往往会与某一特定任务紧密耦合。
Microsoft Orchard 试图将这些部分拆分开来。它并非推出又一个应用框架，而是聚焦于 Agent 行动和学习所在的环境。这一区别使它更接近实验性训练平台，而非主要帮助开发者构建和运行 Agent 应用的 Microsoft Agent Framework 或 AutoGen。
报告中的结果颇具分量。不过，它们仍是项目团队的研究结果，而非对性能或易用性的独立验证。此次发布也带来一个现实张力：可复用软件能够减少重复工程工作，但大规模 Agent 训练仍需要模型、算力、任务环境和运营专业能力。
Orchard 将 Agent 环境变为共享基础设施
关键变化不是又一个 Agent 接口，而是一个可伴随 Agent 完整训练周期的可复用环境层。
该项目的核心是 Orchard Env，这是一项 Kubernetes 原生服务，用于管理隔离环境。沙箱是一个受控工作区，Agent 可在其中执行命令、修改文件、浏览应用并接收观察结果，同时不会获得对宿主系统的不受限制访问权限。
根据该项目的 agentic modeling framework，这项服务通过 REST 接口公开通用操作。其中包括创建和删除沙箱、执行命令、读取或写入文件，以及应用网络策略。
该环境与 Agent harness 保持分离；后者负责将模型输出转化为工具操作。它也与推理系统和训练算法保持分离。因此，研究人员可以更换模型或 harness，而无需重建所有环境管理组件。
这种分离解决了一个反复出现的摩擦来源。编码 Agent 可能需要代码仓库快照、构建工具和隐藏测试。浏览器 Agent 需要视觉界面和网站状态。个人助手则需要工具 API 和针对任务的验证机制。
这些设置在应用层看起来不同。但在底层，它们都需要隔离环境、生命周期管理器、观察通道和结果评分方法。该框架试图明确这些共享需求。
Microsoft 表示，该服务在其测试中执行命令的平均耗时为 0.28 秒。配套论文还报告了一项涉及 1,000 个沙箱的压力测试，成功率为 100%。这些测量结果描述的是研究人员的配置，不应被视为普适的生产环境保证。
该架构采用运行时 Agent 注入，使任务专用容器镜像能够与控制服务保持分离。它还将执行和文件操作直接路由至沙箱 pod 地址。论文认为，这避免了与 Kubernetes 执行通道相关的部分开销。
其他运营细节揭示了 Agent 训练对基础设施的要求之高。该系统包含异步沙箱创建、就绪状态监控、基于心跳的清理、网络隔离、重试和资源扩容。这些功能并不光鲜，但其中任何一项出现故障，都可能使一次训练运行失效或停滞。
这种广度解释了该项目的研究价值。研究不同 Agent 任务的团队可以复用同一控制层，同时保留各自的模型、工具和奖励系统。原则上，由于实验之间变化的基础设施变量更少，实验也更易于比较。
该框架并未消除专门的任务设计。研究人员仍必须创建有效环境、定义允许的操作、保护沙箱安全，并开发有意义的评估器。它减少的是围绕这些决策的重复工程工作，而非让这些决策本身消失。
真正的压力落在任务专用训练栈上
Orchard 对“编码、浏览器和助手 Agent 需要各自独立的端到端训练系统”这一假设提出了挑战。
大多数公开 Agent 框架专注于编排。它们帮助模型调用工具、交换消息、遵循工作流或协调多个 Agent。这些能力对应用很重要，但并不会自动产生改进模型所需的数据与反馈。
训练增加了另一层要求。Agent 必须在受控环境中尝试任务，生成多步骤轨迹，获得可靠奖励，并将这些交互转化为模型更新。每个阶段都可能依赖不同的软件与基础设施。
轨迹是任务过程中生成的完整推理、操作、工具响应和环境状态序列。这些记录可以成为训练示例，但前提是系统保留其结构，并确定哪些行为起到了帮助作用。
面对长程任务时，这一挑战会更加突出。编码 Agent 可能检查多个文件、尝试补丁、运行测试、调整方案，最终仍告失败。简单的成功或失败标签并不能说明哪些中间决策是有价值的。
该项目的答案是，在流水线各阶段复用环境和轨迹。同一环境服务支持教师模型数据收集、监督微调、强化学习 rollout 和最终评估。研究人员不必为每个阶段分别建立沙箱系统。
这一设计与面向生产的编排有所不同。Microsoft 独立的 agent application framework 面向在 Python 和 .NET 中构建和部署 Agent。AutoGen 同样为多 Agent 对话和工具使用建立了常见模式。
这一新的研究栈回答的是另一个问题：团队如何训练决定 Agent 下一步行动的底层策略？这种差异使直接的产品比较并不成立。应用框架和训练环境可以彼此互补。
压力反而落在封闭、垂直整合的研究流水线上。如果同一个开放环境层能跨多个领域发挥作用，团队就更没有理由接受将模型、harness、沙箱和评估器捆绑为不可分割整体的方案。
从理论上看，规模较小的研究团队获益最大。它们可以从共享环境原语和已发布方案起步，而不必自行构建完整的分布式沙箱服务。它们也可以针对过去与更大型系统相关联的任务测试较小模型。
不过，“较小”仍是相对概念。运行 Kubernetes 沙箱、推理服务器、教师模型和强化学习任务仍需深厚的技术能力。这次发布降低了一类复杂性，但并未让 Agent 训练变成普通笔记本电脑上的工作流。
围绕这些实验，组织同样需要严谨的知识管理。轨迹、评估失败、配置变更和任务定义很快会变得难以检索。一个 technical knowledge base 能够保留结果背后的推理，而不仅仅是最终基准分数。
因此，战略转变在于模块化。研究人员可以保留自己偏好的模型和 Agent 接口，同时替换自定义环境后端。如果这一模式得到采用，基础设施复用可能成为开放 Agent 研究的基本预期。
Microsoft Orchard 从有价值的失败中学习
该框架最有力的理念是：一次未成功的 Agent 运行仍可能包含有价值的训练证据。
名为 Orchard-SWE 的软件工程方案，首先使用了约 107,000 条从 MiniMax-M2.5 和 Qwen3.5-397B 蒸馏而来的轨迹。Microsoft 表示，该语料库覆盖了 2,788 个 GitHub 代码仓库。
该项目的 trajectory dataset 描述了 107,185 条软件工程记录，其中包括 74,649 条已解决轨迹和 32,536 条未解决轨迹。已解决记录意味着最终补丁通过了任务的隐藏测试套件。
传统监督微调偏向成功示例。这很符合直觉，因为模型学习的是达成正确结果的行为。然而，丢弃每一条失败轨迹可能会浪费有用的中间工作。
一次失败的编码运行可能正确定位了相关模块、识别出错误条件，并写出了大部分有效补丁。只需一次后续编辑就可能破坏整个解决方案。将完整轨迹视为毫无价值，会丢失此前的进展。
该方案引入了信用分配监督微调，以恢复这种信号。信用分配指的是识别哪些操作推动了进展，而不是把单一结果附加到每一步。
对于未解决的运行，教师模型会结合最终测试结果审查完整轨迹。它估计每一步之后解决任务的概率如何变化。随后，流水线选择该估计概率上升的连续片段。
这些上升片段成为监督目标。较早的观察结果仍作为上下文保留，而训练损失则聚焦于被判断为代表进展的、由助手生成的推理和操作。工具响应不计入预测损失。
这项技术并不会把失败变成成功。它提出的是更有限的主张：一次未成功尝试的某些部分，能够教会模型富有成效的探索是什么样子。这一经验的可靠性取决于回顾性教师模型的估计。
随后，该方案加入强化学习，由模型生成新的尝试并获得任务级奖励。难点在于，在不将大部分预算耗费于结果一致的尝试的前提下，获得信息量充足的尝试组。
如果每次尝试都成功，该组对于判断哪些策略选择更优几乎提供不了信息。所有尝试均失败时也是同样的问题。标准固定规模采样可能消耗大量算力来生成这些低方差组。
Microsoft 将其替代方案称为 Balanced Adaptive Rollout。该方法渐进式生成尝试，并试图构建一个正负奖励之间具有有用平衡的训练组。它可以在找到信息量充足的组后停止，也可以在固定最大预算内继续。
该方法追求的是效率，而不只是准确率。它会为那些需要更多尝试才能形成有意义比较的提示分配更多采样。持续不适合的组可以被筛除，并由其他任务补充。
该项目称，一个以 Qwen3-30B-A3B-Thinking 初始化的模型在监督微调后，在 SWE-bench Verified 上达到 64.3%。经过强化学习后，这一成绩达到 67.5%。
SWE-bench Verified 测试智能体能否在可复现的代码仓库环境中解决真实的 GitHub 问题。分数取决于基准测试版本、测试框架、推理设置和评估流程，因此进行比较时需要严格对齐方法。
Microsoft 将这一结果描述为同等规模开源模型中的新高点。这一限定很重要。该结果并不能证明其优于所有智能体系统，尤其是那些采用不同计算预算或未披露支撑框架的闭源模型。
不过，相较于排行榜位置，其机制更值得关注。从部分进展中训练，以及为获得有信息量的奖励变化而进行采样，都是其他团队可以独立验证的技术。它们的价值并不完全取决于某一项报告分数。
一个环境支持三种截然不同的智能体
这三套方案检验了基础设施复用能否经受模型规模、接口、任务结构和奖励设计变化的考验。
编程是规模最大的演示，但并非唯一一个。Orchard-GUI 将同一环境抽象应用于一个与浏览器界面交互的 40 亿参数视觉语言模型。
据称，该方案使用了约 400 条蒸馏轨迹和 2,200 个开放式任务。Microsoft 表示，所得模型在 WebVoyager 上的成功率达到 74.1%，在 Online-Mind2Web 上达到 67.0%，在 DeepShop 上达到 64.0%。
这些基准覆盖了不同形式的网页交互。浏览器智能体必须理解视觉状态、选择操作，并在网站作出响应时进行适应。不同于编程任务，成功可能取决于能否导航动态界面，而非生成可测试的补丁。
报告中的数据量值得注意，因为它远小于软件工程语料库。这支持了 Microsoft 的观点：聚焦的方案与稳定的环境能够帮助更小的模型参与竞争，而无需在参数数量上匹配最大的专有系统。
不过，基准测试上的成功并不保证在测试分布之外也能可靠浏览。网站会变化，界面可能呈现模糊状态，细微的视觉差异也可能让智能体偏离方向。评估者还需要对任务完成给出精确定义。
第三套方案 Orchard-Claw 面向个人助理智能体。论文称，它采用 Qwen3-30B-A3B-Thinking 作为骨干模型，并使用了约 200 个合成任务。
Microsoft 报告称，其在 Claw-Eval 上的 pass@3 为 59.6%。pass@3 允许智能体最多尝试三次，只要至少有一次通过，就将该任务计为成功。当模型搭配更强的 ZeroClaw 框架运行时，该结果升至 73.9%。
这一差距说明了智能体基准测试中的一项关键经验：模型只是智能体系统的一部分。框架设计、工具格式、重试行为、上下文管理和评估规则都会显著影响最终结果。
这也使关于小模型的说法变得更复杂。紧凑型策略在有效基础设施的支持下可以表现出色，但整个系统在运维上仍可能要求很高。仅凭参数数量无法衡量部署成本或复杂性。
这三套方案共同构成了比同一编程基准的三个变体更可信的可移植性测试。它们涵盖文本与视觉、确定性测试与开放式界面，以及不同的模型规模。
这一公共层并不会让所有领域变得相同。每套方案仍有各自的数据收集、奖励计算、模型骨干和智能体框架。复用发生在这些任务特定选择之下。
这一边界是合理的。通用环境服务应当标准化生命周期和通信原语，而不应假装浏览器任务与代码仓库修复具有相同的成功标准。
更广泛的问题在于，外部团队能否复现这种分离。内部研究系统在图表中往往看起来模块化，但可能依赖未记录的约定、云配置或数据准备步骤。社区使用将检验这些接口是否真正具备可移植性。
开源主张仍面临可复现性检验
已发布的架构和强劲的基准测试结果，只是开放研究发布的开始。
论文提供了大量实现细节、算法描述和实验设置。Microsoft 的项目材料也列出了研究人员、模型、任务来源和主要评估结果。
但实际意义上的开放包含多个层面。研究人员需要可访问的代码、安装说明、兼容的数据集、模型检查点、环境镜像、许可证，以及足以复现实验的配置细节。
该数据集页面目前显示发布暂缓的通知，并称数据将再次上传。页面表示，已记录的模式是准确的，但可能并不代表最终形式。团队在围绕其设计管道之前，应先核实页面状态。
这一暂停并不会使研究失效。但它限制了立即复现的可能性，尤其是软件工程方案，因为其价值高度依赖于轨迹收集。
许可证同样需要仔细关注。数据集文档警告称，轨迹涉及拥有各自许可证的上游代码仓库。重新分发补丁、测试材料或衍生产物的研究人员，必须逐一审查这些条款。
安全性是另一项限制。智能体训练会刻意执行模型生成的操作。即使在隔离环境中，也需要网络策略、资源限制、凭据控制、镜像扫描和清理流程。
论文描述了网络隔离和故障处理机制，但每次部署都有自己的威胁边界。处理公共代码仓库的研究集群，与包含私有代码或内部工具的企业环境，面临的风险不同。
基准污染依然难以被彻底排除。教师模型可能在预训练期间接触过公开问题、补丁或相关代码。隐藏评估测试能够降低部分风险，但无法解决有关记忆化的所有疑问。
回溯式信用分配方法也增加了另一层不确定性。教师模型会估计中间步骤是否提高了成功概率。只有当教师能够可靠地理解轨迹和测试结果时，这些估计才是有用的标签。
错误的估计可能奖励看似合理却无关紧要的行为。它也可能忽略一个价值只有在后续才显现的步骤。独立消融实验应测试，性能中有多少来自部分失败数据，而非模型规模、教师质量或数据集构成。
Balanced Adaptive Rollout 同样需要类似审视。选择具有有用奖励变化的组可以提高训练效率，但真实环境故障可能看起来像策略失败。超时、容器错误或损坏的测试不应成为误导性的奖励。
Microsoft 报告了重试逻辑、超时控制和针对不可用组的过滤机制。外部团队需要确定，这些防护措施在不同集群、工作负载和任务分布下是否仍然有效。
因此，这些报告数字应被视为支持一种设计的证据，而非普适性的最终证明。在独立基础设施上进行复现将增强这一论点。在新领域取得结果，则可检验环境抽象是否能扩展到这三套既定方案之外。
最具影响力的结果或许不是又一项基准纪录，而是一个共享的实验底座，使研究人员能够比较训练方法，而无需为每项实验重新搭建底层机制。
研究人员接下来应关注什么
三个信号将决定 Orchard 会成为常见的研究基础设施，还是停留在令人印象深刻的 Microsoft 参考实现。
第一个信号是发布完整性。研究人员应关注数据集访问是否恢复、代码仓库是否稳定、安装说明是否可复现、模型产物是否可用，以及环境定义是否有版本管理。
完整发布将强化 Microsoft 关于小团队能够复用该系统的主张。持续存在的缺口则会削弱这一主张，因为智能体训练中最困难的部分往往存在于数据准备和运维配置中。
第二个信号是独立复现。可信的测试应在独立管理的基础设施上使用已发布方案，并同时报告基准结果和总资源需求。
复现完全相同的头条分数并非唯一有价值的结果。研究人员应记录设置时间、沙箱故障率、轨迹吞吐量、计算消耗，以及对框架选择的敏感性。这些测量能够揭示复用是否带来实质性节省。
独立实验还应隔离信用分配微调带来的贡献。比较可以分别使用仅成功轨迹、完整未解决轨迹和选定进展片段，来训练等效模型。
同样的方法也适用于自适应 rollout。研究人员可以在模型、任务、奖励函数和预算保持不变的情况下，对比固定采样与平衡采样。这将表明，该方法是否能为每条生成轨迹带来更多学习信号。
第三个信号是 Microsoft 既定领域之外的采用情况。一个新环境将提供最有力的测试，尤其是使用不同工具和奖励结构的环境。
安全分析、数据工作、科学工作流和办公应用都是合理候选。它们各自引入了不同于代码仓库修复或浏览器导航的环境要求。成功复用将支持这一抽象真正与框架无关的主张。
竞争对手的回应同样重要，但应作为辅助证据，而非主要叙事。其他智能体训练项目可能采用兼容的环境接口、发布替代后端，或标准化轨迹格式。
互操作性将比框架泛滥创造更多价值。研究人员可以在系统之间迁移数据集、策略和评估器，而无需转换每一种操作和观测格式。
与此同时，开发者不应将该发布视为现成的生产级智能体。该项目是用于创建和评估策略的研究基础设施。生产系统仍需要应用逻辑、用户权限、监控、回退行为和安全审查。
对于企业买家，相关问题不是该框架是否赢得某一项基准测试，而是模块化训练基础设施能否减少对单一专有模型或供应商控制的评估栈的依赖。
对于研究人员，下一步实际行动更为具体：查阅研究论文，核实哪些产物可用，并选择一套与现有评估环境匹配的方案。在衡量任务性能的同时，也衡量运维成本。
微软提出了一个明确主张：当环境成为可复用的基础设施，而非隐藏在项目内部的管线时，开放式智能体研究将得到改善。现在，社区必须检验这一主张中更困难的另一半。独立团队能否复现这些成果，将这套机制迁移到新任务中，并在微软自身体系之外保持所承诺的效率？
