Orchard 深度拆解：微软如何把 Agent 训练的"基础设施地狱"变成 Kubernetes 上的乐高积木
> 这篇论文不是"我们又训了个 Agent"。它是"我们造了套基础设施，让任何人都能训 Agent"——而且训练数据、代码、环境服务全部开源。微软研究院这次干了一件非常"工程主义"的事。
---
序章：Agent 训练的基础设施之痛
如果你训过 Agent，你一定懂这个痛：
你的模型要操作终端、浏览器、文件系统。但这些"环境"和"训练流程"紧紧绑在一起——换一套 harness，数据格式全变；换一个任务域，环境要重写；想复现别人的结果，发现他的 Dockerfile 里有你跑不起来的私有服务。
Orchard 的核心洞察很朴素：环境层应该像数据库一样——薄、独立、可复用。
不是"每个 Agent 项目搭一套环境"，而是"一套环境服务，支持所有 Agent 训练"。
---
一、Orchard Env：Kubernetes 上的 Agent 沙箱工厂
这是 Orchard 最硬核的工程组件。论文花了大量篇幅讲它，因为它是整个框架的地基。
1.1 三层架构
┌─────────────────────────────────────┐
│ Client SDK │
│ - 同步/异步 Python 接口 │
│ - 自动清理的上下文管理器 │
│ - 指数退避重试逻辑 │
└─────────────┬───────────────────────┘
│ REST API
┌─────────────▼───────────────────────┐
│ Orchestrator (FastAPI) │
│ │
│ • Sandbox provisioning │
│ • Readiness tracking (PodWatcher) │
│ • Execution scheduling │
│ • Lifecycle management │
└─────────────┬───────────────────────┘
│ K8s API (冷路径: 创建/删除)
│ 直接 HTTP (热路径: 执行/文件/健康)
┌─────────────▼───────────────────────┐
│ In-Pod Agent (注入的) │
│ (轻量级 FastAPI, 每个沙箱内) │
│ • /exec - 命令执行 │
│ • 文件上传/下载/列出 │
│ • 健康检查端点 │
└─────────────────────────────────────┘
冷路径 vs 热路径分离是核心设计哲学：
- 冷路径（低频）：创建/删除沙箱，走 K8s API Server
- 热路径（高频）：命令执行、文件操作、健康检查，直接 HTTP 到 Pod IP
kubectl exec 的链路是：你的代码 → API Server → kubelet → container → 返回。每一步都有延迟。Orchard 把热路径砍成了：你的代码 → Pod IP → in-pod agent → 返回。1.2 运行时注入：零镜像修改
这是最巧妙的机制。你想在任意 Docker 镜像里运行 Agent（比如 SWE-bench 的 300+ 个不同仓库镜像），但不想重建镜像。
Orchard 的做法：
用户提供的任意 Docker 镜像
│
▼
[Init Container] ──────────────────┐
1. 包含自包含的 in-pod agent 二进制│
2. Pod 启动时先运行 init container│
3. 将 agent 复制到共享卷 │
│
[主容器] ◄─────────────────────────┘
1. 从共享卷启动 in-pod agent
2. agent 作为容器内 FastAPI 运行
这意味着：
- 零镜像修改：不用重建、不用改 Dockerfile
- 异构兼容：SWE-bench 的 Python 3.8 镜像、浏览器环境、桌面环境，全部适配
- 版本解耦：agent 可以独立更新，不绑定任务镜像版本
1.3 性能数字
| 指标 | Orchard | SkyPilot | E2B | Modal |
|---|---|---|---|---|
| 平均命令延迟 | 0.280s | 0.284s | 0.747s | 2.046s |
| 相对速度 | 1× | 1.0× | 2.7× | 7.3× |
- 成功率：100%
- 端到端时间：26 秒
- 平均创建时间：11.75 秒
- 有效吞吐量：~154 命令/秒
1.4 成本
论文提到用 spot 实例 降低 10 倍成本。Orchard Env 可以跑在标准 K8s 集群上——不管是本地集群、云厂商 K8s、还是自己的服务器。对比 E2B、Daytona 这些托管服务，自托管的长期成本优势明显。
---
二、训练创新：从失败里挖金子
2.1 Credit-Assignment SFT
传统 Agent 训练只保留成功轨迹（resolved）。失败轨迹直接丢弃。但失败轨迹占了很大一部分——Orchard-SWE 的 107K 轨迹里，32K 是失败的，占 30%。
问题：失败轨迹里可能有"正确的开头"——模型前 10 步都走对了，第 11 步犯错导致失败。如果只保留成功轨迹，模型永远学不会"前 10 步怎么做"。
Credit-Assignment 的方法：
Step 1：回顾性价值估计
用教师模型作为零样本价值函数，估计轨迹每步的成功概率：
V(s_t) = P(resolve | h_t, outcome)
提示词设计的关键约束：
- 从已知失败反向推理
- P 必须在关键错误处下降
- 最终步骤 P < 0.2（已知失败）
- 禁止单调递增的 P（防止模型说谎"每一步都越来越好"）
credit_t = V(s_{t+1}) - V(s_t)
提取最大连续子序列，其中 credit_t ≥ ε（ε=0.05）。这就是"rise segments"——轨迹中实际取得进展的片段。
Step 3：SFT
- 成功轨迹：所有 action token 都参与损失
- 失败轨迹：只让 rise segments 内的 action token 参与损失，前面的历史保留为上下文
2.2 Balanced Adaptive Rollout (BAR)
这是 RL 阶段的核心创新。解决 GRPO 的两个痛点：
痛点 1：计算浪费
GRPO 固定 N 组 rollout（比如 N=8）。如果模型已经熟练，8 个全成功；如果不熟练，8 个全失败。无论哪种，组内方差接近零，信息梯度极小——但你已经花了 8 次环境交互成本。
痛点 2：组不平衡噪声
当成功率远离 0.5 时，组被某一类主导，优势估计有偏。
BAR 的解决方案：
输入: 提示 x, 策略 πθ, 奖励 R
训练组大小 N=8, 最大预算 N_max=16, 步幅 s=16
正例比例区间 [0.375, 0.625]
T ← ∅ // 已完成轨迹池
for t = 0, 16, 32, ...:
B_t ← 并行生成 s=16 条轨迹
T ← T ∪ B_t
(G, ok) ← TRY_ASSEMBLE(T, 正例比例区间)
if ok: return G // 早停
// 回退：松弛约束或尽力取 top
TRY_ASSEMBLE 的逻辑： 1. 把轨迹池分区：T+（正例）和 T-（负例） 2. 按（完成状态, 响应长度）排序——优先完成且简洁的 3. 在正例比例区间内找平衡组合 4. 返回 N=8 的平衡组
行为特征：
- 简单提示：第一组 16 个 overwhelmingly positive → 过滤或用最小正例满足下界
- 困难提示：继续生成直到发现足够正例或耗尽 16 个预算
- 平衡提示：第一组即可完成，产生最大信息梯度
2.3 两阶段训练流程
Stage 1: SFT (5 epochs)
├── 107K 轨迹（多教师蒸馏：MiniMax-M2.5 + Qwen3.5-397B）
├── Credit-assignment 提取失败轨迹信号
├── Batch 128, lr 1e-5 → 1e-6
├── 64K→128K 上下文长度
└── Orchard Env 执行后端
Stage 2: RL (最多 150 步)
├── 环境 grounded 二元奖励
├── BAR 自适应采样
├── 全局 batch 128
├── 64K 上下文
└── lr 1e-6
RL 四服务架构： 1. Policy Trainer（Megatron-LM 分布式训练） 2. Rollout Inference（SGLang，支持 KV 缓存复用） 3. Sandboxed Execution（Orchard Env） 4. Agentic Loop Driver（每样本异步协程，编排推理-执行交互）
---
三、三个领域：同一套配方，三种用法
Orchard 的核心主张是通用性——同一套环境抽象和训练方案，适配三个完全不同的领域。
3.1 Orchard-SWE：软件工程
| 属性 | 详情 |
|---|---|
| 基座 | Qwen3-30B-A3B-Thinking |
| 数据 | 107,185 条轨迹（74,649 成功 + 32,536 失败） |
| 来源 | SWE-rebench、SWE-rebench V2、Scale-SWE |
| 教师 | MiniMax-M2.5（230B）+ Qwen3.5-397B |
| Harness | OpenHands + mini-swe-agent（双 harness） |
| 任务实例 | 19,287 个唯一实例 |
| 平均交互 | 47.5 轮/轨迹，~21K tokens/轨迹 |
- SFT：64.3%
- SFT+RL：67.5%（+3.2 点）
| 系统 | 基座模型 | 解决率 |
|---|---|---|
| Orchard-SWE | Qwen3-30B-A3B | 67.5% |
| Scale-SWE-Agent | Qwen3-30B-A3B | 64.0% |
| GLM-4.7-Flash-30A3B | — | 59.2% |
| CoderForge-32B | Qwen3-32B | 59.0% |
与大模型的对比：
论文说 Orchard-SWE "性能接近比它大 10-30 倍的前沿 MoE 模型"。虽然论文没有给出具体大模型的数字表，但结合公开信息：
- Claude 3.5 Sonnet + SWE-agent：~50%
- GPT-4 + SWE-agent：~40%
- 专用系统（如 FactoryCode）可能更高
3.2 Orchard-GUI：浏览器导航
| 属性 | 详情 |
|---|---|
| 基座 | Qwen3-VL-4B-Thinking（4B 视觉-语言模型） |
| 数据 | 仅 2.6K 任务（0.4K 蒸馏 + 2.2K 开放式训练） |
| Harness | 通用 ReAct 风格浏览器 harness |
| 基准 | Orchard-GUI | 对比 |
|---|---|---|
| WebVoyager | 74.1% | — |
| Online-Mind2Web | 67.0% | — |
| DeepShop | 64.0% | — |
| 平均 | 68.4% | — |
这意味着：环境 grounded RL 可以提升超越教师的能力。4B 模型通过 RL 在真实环境中试错，学到了教师模型（235B）在纯蒸馏中没有展现的能力。
这是一个很重要的信号：小模型 + 环境交互 RL > 大模型纯蒸馏。
3.3 Orchard-Claw：个人助手
| 属性 | 详情 |
|---|---|
| 基座 | Qwen3-30B-A3B-Thinking |
| 数据 | 仅 0.2K 合成任务 |
| 教师 | MiniMax-M2.5 |
| 条件 | pass³ | pass@3 |
|---|---|---|
| ReAct-style harness | 31.7% | 59.6% |
| + ZeroClaw harness | 41.0% | 73.9% |
这验证了论文的核心设计哲学：模型能力可跨 harness 迁移。你训的是"通用 Agent 技能"，不是"某个特定 harness 的套路"。
---
四、方法论的深层洞见
4.1 "环境即服务"的范式转移
Orchard 最大的贡献不是某个 SOTA 数字，而是提出了一个新的基础设施范式：
| 范式 | 传统 | Orchard |
|---|---|---|
| 环境 | 与训练代码耦合 | 独立服务 |
| 可复现性 | 依赖特定 Docker 镜像 | 标准 K8s，任何集群 |
| 跨领域 | 每个领域重写 | 同一套抽象 |
| 跨 harness | 数据格式不兼容 | 统一接口 |
| 成本 | 托管服务昂贵 | 自托管 + spot 实例 |
4.2 从失败中学习
Credit-assignment SFT 的方法论价值不止于 SWE。它解决了一个通用问题：
> Agent 训练中的奖励稀疏性问题
Agent 任务的奖励通常是二元的（成功/失败），而且失败率很高。如果只看成功轨迹，你的训练数据利用率极低。Credit-assignment 提供了一种从失败中提取信号的通用框架。
4.3 小模型 + RL > 大模型蒸馏
Orchard-GUI 的 4B > 235B 教师是最刺眼的数字。它说明：
- 蒸馏只能复制教师的能力上限
- 环境 grounded RL 可以让模型在真实交互中发现教师没有展示过的策略
- 小模型在 RL 中的探索空间可能更"大胆"（因为参数少，不容易过拟合到教师模式）
---
五、局限与未来
5.1 轨迹收集成本
Orchard-SWE 的 107K 轨迹不是凭空来的——需要先用教师模型（MiniMax-M2.5 + Qwen3.5-397B）在 Orchard Env 上运行收集。这个过程的计算成本不低。
5.2 教师模型依赖
SFT 阶段依赖多教师蒸馏。如果没有访问大教师模型的能力，轨迹质量可能下降。论文没有讨论"无教师"或"弱教师"的情况。
5.3 RL 阶段收益有限
Orchard-SWE：SFT 64.3% → RL 67.5%，只提升了 3.2 点。说明大部分能力来自 SFT 阶段的数据质量和多样性，RL 是"锦上添花"而非"雪中送炭"。
5.4 领域覆盖
三个领域（SWE、GUI、个人助手）都偏向"计算机操作"类任务。还没有覆盖：
- 机器人控制（物理环境）
- 科学实验（实验室环境）
- 多模态创意任务（图像生成、音乐创作）
5.5 安全性
1000 并发沙箱跑在 K8s 上，如果任务代码有恶意行为（如挖矿、网络扫描），隔离机制是否足够？论文没有深入讨论安全沙箱的设计。
---
六、结语：开源 Agent 生态的基础设施时刻
Orchard 的发布时间点很有意思。2026 年 Agent 研究正处于一个拐点：
- 闭源系统（OpenAI、Anthropic、Google）不断刷新 SOTA
- 开源社区有模型（Qwen、Llama、DeepSeek）但缺基础设施
- 每个研究团队都在重复造轮子：环境搭建、数据收集、训练 pipeline
1. 环境标准化：Orchard Env 成为"Agent 的 Linux"——任何人可以在上面运行任何 Agent 2. 数据可复现：107K 轨迹 + 训练代码全部开源 3. 跨领域验证：同一套方案在 SWE、GUI、个人助手上都 work 4. 成本可控：K8s + spot 实例，10 倍成本降低
如果把 Agent 研究比作软件工程的发展史：
- 早期：每个人都在自己的机器上写代码
- 中期：出现了 Linux 和标准化开发环境
- 现在：出现了云原生和 Kubernetes
---
参考文献
1. Peng, B., Yao, W., Wu, Q., Cheng, H., Yu, X., Yang, R., Ge, T., Sordoni, A., Yuan, X., Shen, Y., He, P., Zhang, T., Yu, Z., & Gao, J. (2026). Orchard: An Open-Source Agentic Modeling Framework. *arXiv preprint arXiv:2605.15040*. https://arxiv.org/abs/2605.15040
#Orchard #Microsoft #Agent训练 #开源框架 #SWEbench #GUIAgent #Kubernetes #小凯