★微软开源 Orchard：给 AI 智能体一个标准化的“操作间”★

AI 已经会聊天、会写诗、会画图，但让它真正像人一样去操作软件、浏览网页、写代码并提交 Pull Request，事情就没那么简单了。问题出在哪？模型“动手”需要环境——一个能执行命令、读写文件、操作浏览器、并且能安全隔离的运行空间。过去每做一个新项目，就要重新搭一套这样的环境。数据集不通用，训练代码不通用，评估方法也不通用，换一个研究方向，一切推倒重来。

微软刚开源的 Orchard 框架，想解决的就是这个“重复造轮子”的问题。

简单说，Orchard 提供了一个标准化的后端环境服务——Orchard Env。它像一个统一的操作间，任何智能体都可以在里面反复操练。所有训练数据、训练脚本、评估流程都跑在同一个基底上，换项目也不需要从头再来。

我仔细读完了它的论文和技术文档，发现这套东西不光是个理论框架，它已经实实在在地跑出了几个很能打的结果：软件工程任务上拿到 73.0% 的 SWE-bench Verified 通过率，浏览器操作平均分 68.4%，在通用计算机使用场景下换一个更强的操作界面，得分能从 59.6% 直接跳到 73.9%。这些数字背后是一套可以复现、可以自己部署、可以直接拿去用的工程方案。

这篇文章会拆解 Orchard 到底是什么、怎么用、以及你在自己动手部署和训练时会遇到什么，不绕弯子，直接给干货。

一、先回答最直接的问题：Orchard 到底解决了什么？

核心答案：它把“智能体运行环境”做成了一个标准化的、可大规模并发的云服务，让研究者不用再为环境折腾，可以把精力集中在算法和模型上。

为什么需要这么一个东西？

训练一个能“动手”的智能体，本质上是让它在一个环境里反复试错：执行一条命令，观察输出，决定下一步，循环往复。每一次试错都是一次环境交互。如果单次交互慢 1 秒，十万次交互就多出 27 个小时。如果环境不稳定，训练到一半容器崩了，前面的计算全部作废。如果数据格式不统一，换个任务就要重写数据处理管道——这些都不是算法问题，全是工程问题。

Orchard Env 的定位就是把这些脏活累活标准化。

你可以在自己的 Kubernetes 集群上部署它，然后通过一个 Python SDK 或 REST API 来调用。每次调用 create_sandbox()，它就在几秒内给你拉起一个隔离的容器，容器里预装了代码执行、文件读写、网络访问、Git 操作这些基础能力。智能体通过 HTTP 接口与容器交互。任务结束，调用 delete()，容器销毁，不留痕迹。

我注意到一个设计上的细节：Orchard Env 支持任何 Docker 镜像作为基础环境。不管你是想用 python:3.11-slim，还是 ubuntu:22.04，甚至是带 CUDA 的深度学习镜像，它都能直接用。它的做法是把自己的一套“智能体助手”通过一个 Init Container 注入进去，这个助手自带独立的 Python 解释器，所以目标镜像里有没有 Python 根本不重要。

这意味着什么？你不需要为了适配 Orchard 去定制镜像，原来用什么，现在还用什么。

二、Orchard 的“三层结构”拆解

从架构上看，Orchard 分三层，每一层解决一类问题，分工很清晰：

层级	名称	做什么的	白话解释
顶层	Recipes	具体的研究项目，比如 Orchard-SWE（软件工程）、Orchard-GUI（图形界面）、Orchard-Claw（计算机使用）	像菜谱，告诉你“用这个环境，这套数据，这种方法，能做出什么结果”
中间层	Orchard Env	环境服务，提供沙箱生命周期管理、命令执行、文件操作、网络策略、REST API	像标准化厨房，提供灶台、刀具、锅具，谁来用都一样
底层	Trainer	训练框架，基于 Slime 改造，包含强化学习训练代码	像厨师的操作手册，告诉你怎么“炒菜”

这三层的关系是：底层和中层是“基础设施”，顶层是“研究成果”。你用 Orchard，可以只拿中间层的环境服务来跑你自己的训练代码，也可以直接复现顶层的研究成果。都开源，都可用。

三、Orchard Env 怎么用？从安装到跑通第一个例子

这部分我直接从文档里把操作步骤抠出来，你照着做，应该十分钟内能跑通。

第一步：安装 Python 包

pip install -e "orchard_env[dev]"

这会把 Orchard Env 的 Python SDK 装到你的环境里。[dev] 选项会额外安装开发依赖，如果你只是使用，不加也行。

第二步：配置环境变量

你需要告诉 SDK 你的 Orchard 服务端在哪里：

export SANDBOX_BASE_URL="http://your-orchestrator-host"
export SANDBOX_API_KEY="your-api-key"

如果你还没有部署自己的 orchestrator，文档里提供了在 Azure AKS 上一键部署的脚本。这个后面会讲。

第三步：写 Python 代码

from orchard_env import SandboxClient

with SandboxClient() as client:
    with client.create_sandbox("python:3.11-slim") as sandbox:
        result = sandbox.exec("echo 'Hello, Orchard!'")
        print(result.stdout)

这段代码做了四件事：

连接 Orchard 服务。
创建一个基于 python:3.11-slim 镜像的沙箱。
在里面执行 echo 'Hello, Orchard!'。
打印输出，然后自动销毁沙箱（因为用了 with 语句，退出上下文时自动清理）。

为什么用 with？ 手动管理沙箱生命周期容易出问题——如果代码中途抛异常，delete() 可能没机会执行，造成资源泄漏。with 语句保证无论成功还是失败，沙箱都会被销毁。我建议你在所有代码里都用这种写法，不要贪图方便省略上下文管理器。

四、部署你自己的 Orchard 集群（实操向）

文档里提供了完整的部署脚本，针对 Azure AKS，整个过程大约 20 分钟。我把它拆成四个步骤，每一步执行一个脚本。

前提条件

🍄

一个 Azure 订阅
🍄

安装 az 命令行工具并登录
🍄

安装 kubectl

操作步骤

1. 设置环境变量

定义资源组、集群名称、虚拟机规格、节点数量等。文档里给的是默认值，你可以按需调整：

export RESOURCE_GROUP="orchard-rg"
export CLUSTER_NAME="orchard-aks"
export VM_SIZE="Standard_D4s_v3"  # 4核16G
export NODE_COUNT="3"
export REDIS_SKU="Standard_B2s"

2. 执行 provision-aks.sh

./provision-aks.sh

这个脚本会创建 AKS 集群和一个 Redis 实例（用于状态存储）。

3. 执行 build-and-push.sh

./build-and-push.sh

构建 Orchard Env 的 Docker 镜像，并推送到你的 Azure Container Registry。这一步需要等几分钟。

4. 执行 deploy-orchard.sh

./deploy-orchard.sh

把镜像部署到你的 AKS 集群上，启动服务。

5. 验证部署

./test-deployment.sh

跑几个 smoke test，确认服务正常。

如果你不是 Azure 用户

文档里有非 Azure 集群的手动部署指引。核心是找到 orchard_env/deploy/kubernetes/ 目录下的 YAML 文件，根据你的集群情况调整 StorageClass、Service 类型等参数，然后 kubectl apply -f。

部署时的几个注意点

🍄

Redis 是必选的：Orchard Env 用 Redis 做分布式锁和状态同步，多副本部署时依赖它。没配 Redis，服务起不来。
🍄

镜像仓库权限：build-and-push.sh 会往 ACR 推送镜像，确保你的 az 登录了正确的订阅，且 ACR 存在。
🍄

网络策略：文档提到 Orchard Env 默认启用了 Calico NetworkPolicy，默认策略是“拒绝所有出站流量”。这意味着沙箱内的智能体默认不能访问外网。如果你需要它访问公网（比如下载依赖包），需要在 NetworkPolicy 里开白名单。这一点容易被忽略，导致训练任务莫名其妙地失败。

五、三个已跑通的“菜谱”：结果和数据

Orchard 文档里详细介绍了三个已经完成的研究项目，我挑最硬核的信息整理出来。

Orchard-SWE：软件工程

项目	内容
训练数据	107,185 条轨迹，覆盖 2,788 个仓库、19,287 个独立任务
平均轨迹长度	47.5 步
核心方法	先 SFT（模仿学习）再 RL（强化学习），用过程奖励模型做信用分配
基准测试结果	SWE-bench Verified 73.0%
泛化测试	SWE-bench Multilingual 51.0%（同类开源模型 28.7）
跨 Harness 测试	用 Kimi-CLI 评估，仍保持 45.0%（同类模型 3.6）

这组数字里，我最关注的是“泛化测试”那一行。很多模型在训练过的测试集上成绩好看，换个环境就崩。Orchard-SWE 在没见过的操作界面（Kimi-CLI）上还能保持 45.0%，说明它学到的是真正的任务解决能力，而不是某个特定操作工具的“肌肉记忆”。

Orchard-GUI：图形界面（浏览器操作）

项目	内容
训练数据	仅 400 条 SFT 轨迹 + 2,200 个 RL 任务
核心方法	先用蒸馏数据做初始化，再在真实、在线的网站上做强化学习
基础设施	构建了容错的在线浏览器环境——有重试、超时、失败归因
平均得分	68.4%（三个在线测试集的平均值）

一个反直觉的事实：Orchard-GUI 只用了 400 条蒸馏数据做初始化，就通过在线 RL 把性能推到了很高的水平。这说明在稳定、真实的环境上做在线学习，数据效率可能比我们想象的高得多。

Orchard-Claw：通用计算机使用

项目	内容
训练数据	仅 200 个合成任务
核心方法	在两种不同的操作界面（Harness）上训练
弱 Harness 得分	59.6%（pass@3）
强 Harness 得分	73.9%（pass@3），提升 14.3 个百分点

我注意到一个关键信息：Orchard-Claw 是所有被测试模型中，换用更强操作界面后性能提升最大的一个。这恰恰验证了 Orchard 的设计理念——环境与操作界面解耦，训练时用的环境和部署时用的环境可以不一样，模型在这个环境里学到的基础能力，到另一个环境里也能用。

六、数据集：107K SWE 轨迹 + 3K GUI 轨迹

除了代码和环境，微软还开源了在 Orchard Env 上生产的两份数据集，都在 Hugging Face 上，搜索 microsoft/Orchard。

SWE 子集

🍄

107,185 条多轮交互轨迹
🍄

覆盖 2,788 个 GitHub 仓库
🍄

19,287 个独立任务实例
🍄

每条轨迹平均 47.5 步
🍄

数据带“是否解决”标签，解决的有 74,649 条，未解决的 32,536 条

这应该是目前开源社区里规模最大的、带过程标注的软件工程智能体数据集。它不是只有“问题”和“最终答案”，而是记录了完整的解题路径。

GUI 子集

🍄

3,070 条经过验证的成功轨迹
🍄

每条轨迹带屏幕截图（多模态）
🍄

基于 409 个 WebVoyager 风格的任务采集

如果你在做多模态浏览器智能体的研究，这份数据可以直接用来做 SFT 初始化。

七、未来方向：状态化沙箱

文档末尾提到了一个正在开发的功能，我觉得值得单独拎出来说——状态化沙箱。

目前的 Orchard Env 是线性的：创建沙箱 → 执行 N 步 → 销毁。如果一个轨迹有 47.5 步，最后只得到一个“成功/失败”的奖励信号，你很难判断到底是哪一步起了决定性作用。这是强化学习中经典的“信用分配”问题。

Orchard 计划加入的能力：

🍄

暂停/恢复：把沙箱的完整状态（文件系统、进程、环境变量）像游戏存档一样保存，下次从同一个点继续。
🍄

分支：从同一个存档点派生多个分支，并行探索不同的后续路径。
🍄

前缀共享：多个分支共享前面的执行结果，避免重复计算。

有了这些能力，你就可以在第 5 步的位置分出 10 个分支，看不同的后续选择会带来什么不同的结果，从而精确衡量第 5 步的价值。这个能力直接构建在环境层，所有上层的训练代码都能受益。

我判断：这个方向走通之后，智能体训练的效率和效果都会有质的提升——它把“猜哪一步重要”变成了“直接测量哪一步重要”。

八、实操避坑清单

基于文档里透露的信息，我整理了几个实际操作中容易踩的坑：

沙箱清理：务必用 with 语句或用 try/finally，确保沙箱一定被销毁。漏清理的沙箱会在集群里堆积，慢慢耗光资源。
网络隔离：默认 deny-egress，沙箱内不能访问外网。如果你的智能体需要 pip install 或 apt-get update，记得在 NetworkPolicy 里配置出口规则。
API Key 管理：不要把 Key 写死在代码里。用环境变量或密钥管理服务。
基础镜像选择：虽然 Orchard 支持任意镜像，但镜像体积越大，create_sandbox 的时间越长。尽量选 -slim 或 -alpine 版本。
训练与评估的 Harness 一致性：Orchard Env 支持在沙箱里预装多种 Harness（codex、claude、pi、opencode、hermes 都在 PATH 上）。我建议你在训练和评估时用同一个 Harness，或者在训练时就在多种 Harness 上做，这样能提前暴露适配问题。

实用摘要

🍄

Orchard 是什么：一个开源智能体建模框架，核心是标准化的环境服务 Orchard Env，让智能体可以大规模并行地执行命令、读写文件、操作浏览器。
🍄

它能解决什么问题：消除研究项目中“重复搭环境”的工程成本，让研究者可以聚焦算法和模型本身。
🍄

核心结果：在 SWE-bench Verified 上达到 73.0%，在在线浏览器任务上平均 68.4%，且泛化能力优于同类开源模型。
🍄

如何上手：pip install + 配置两个环境变量 + 十几行 Python 代码，就能拉起一个沙箱执行命令。
🍄

如何部署：提供了 Azure AKS 一键部署脚本，非 Azure 集群也有手动 YAML。

一页速览

你想知道的	答案
这项目是干什么的？	给 AI 智能体提供标准化的、可大规模并发的运行环境，并在此基础上提供训练框架和已跑通的“菜谱”
环境服务叫什么？	Orchard Env，核心组件，所有上层研究都依赖它
单个命令执行延迟多少？	平均 0.28 秒
能并发跑多少个沙箱？	测试过 1,000 个并行拉起，26 秒完成，成功率 100%
支持哪些基础镜像？	任何 Docker 镜像，因为 Orchard 会注入自带 Python 解释器的 Agent
预装了哪些操作界面？	codex、claude、pi、opencode、hermes 都在 PATH 上
开源了哪些数据？	SWE 子集 107K 条轨迹 + GUI 子集 3,070 条多模态轨迹，在 Hugging Face
能自己部署吗？	能，提供了 Azure AKS 脚本，约 20 分钟完成

常见问题

问：Orchard 只能跑在 Azure 上吗？

不是。Azure AKS 只是官方提供了一键部署脚本。Orchard Env 是标准的 Kubernetes 应用，提供了 Helm chart 和手动 YAML，可以部署在任何 Kubernetes 集群上，包括自建集群或其他云厂商的托管集群。

问：我不做强化学习，Orchard 对我有用吗？

有用。Orchard Env 本身就是一个通用的沙箱编排服务，你可以只用它来管理隔离的执行环境，不跑 RL。比如批量评估模型、做数据采集、跑 CI/CD 流水线，都可以用。

问：Orchard 和 E2B、Modal 这类服务有什么区别？

Orchard 是开源的、可以完全自部署的，不绑定任何云厂商。从文档里的性能对比看，Orchard Env 的命令执行延迟是 0.28 秒，E2B 是 0.747 秒，Modal 是 2.046 秒。成本方面，自部署在 Spot Instance 上大约是托管服务的十分之一。

问：训练数据里平均 47.5 步意味着什么？

意味着信用分配是个大问题。47.5 步的轨迹最后只给一个奖励信号，很难判断哪一步对最终结果贡献最大。这也是为什么 Orchard 在规划“状态化沙箱”来支持分支和回溯——让每一步的价值都可以被独立测量。

问：我已经有自己的训练框架，能用 Orchard Env 吗？

能。Orchard Env 暴露的是 REST API，不是特定框架的插件。你的训练代码只要能把“执行命令”这个动作替换成 HTTP 调用就行。Python SDK 只是方便你调用，不是必须的。

Orchard：微软开源的标准化AI智能体操作间，一招终结环境搭建噩梦