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 性能数字

1000 并发沙箱压力测试：

• 成功率：100%
• 端到端时间：26 秒
• 平均创建时间：11.75 秒
• 有效吞吐量：~154 命令/秒

可靠性机制：

1. Watch-based readiness：PodWatcher 持久监听 K8s 事件流，不是轮询
2. Per-sandbox locking：同一沙箱的并发请求序列化
3. Heartbeat cleanup：后台循环检测孤儿沙箱并清理
4. 异步生命周期：创建/删除与执行操作解耦

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（防止模型说谎"每一步都越来越好"）

Step 2：上升段提取

credit_t = V(s_{t+1}) - V(s_t)

提取最大连续子序列，其中 credit_t ≥ ε（ε=0.05）。这就是"rise segments"——轨迹中实际取得进展的片段。

Step 3：SFT

• 成功轨迹：所有 action token 都参与损失
• 失败轨迹：只让 rise segments 内的 action token 参与损失，前面的历史保留为上下文

效果：32,536 个失败轨迹产生了探索导向的监督信号，与 74,649 个成功轨迹互补。

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：软件工程

性能演进：

• SFT：64.3%
• SFT+RL：67.5%（+3.2 点）

SWE-bench Verified 对比（表 7）：

跨 harness 泛化：SFT 时在 OpenHands 上训（62.1%），直接迁移到 mini-swe-agent 评估提升到 64.3%——说明学到的技能与 harness 解耦。

与大模型的对比：

论文说 Orchard-SWE "性能接近比它大 10-30 倍的前沿 MoE 模型"。虽然论文没有给出具体大模型的数字表，但结合公开信息：

• Claude 3.5 Sonnet + SWE-agent：~50%
• GPT-4 + SWE-agent：~40%
• 专用系统（如 FactoryCode）可能更高

Orchard-SWE 的 67.5% 在同参数规模开源模型中是最好的。

3.2 Orchard-GUI：浏览器导航

性能：

关键发现：Orchard-GUI 超过其 235B 教师模型（Qwen3-VL-235B: 61.2%）。

这意味着：环境 grounded RL 可以提升超越教师的能力。4B 模型通过 RL 在真实环境中试错，学到了教师模型（235B）在纯蒸馏中没有展现的能力。

这是一个很重要的信号：小模型 + 环境交互 RL > 大模型纯蒸馏。

3.3 Orchard-Claw：个人助手

跨 harness 迁移实验：

同一个模型，配更强的 harness（ZeroClaw），pass@3 从 59.6% 跃升至 73.9%（+14.3 点）。

这验证了论文的核心设计哲学：模型能力可跨 harness 迁移。你训的是"通用 Agent 技能"，不是"某个特定 harness 的套路"。

四、方法论的深层洞见

4.1 "环境即服务"的范式转移

Orchard 最大的贡献不是某个 SOTA 数字，而是提出了一个新的基础设施范式：

这个范式的影响是：降低了 Agent 研究的门槛。以前训 Agent 需要先成为 K8s/DevOps 专家，现在你只需要会写 Python。

4.2 从失败中学习

Credit-assignment SFT 的方法论价值不止于 SWE。它解决了一个通用问题：

Agent 训练中的奖励稀疏性问题

Agent 任务的奖励通常是二元的（成功/失败），而且失败率很高。如果只看成功轨迹，你的训练数据利用率极低。Credit-assignment 提供了一种从失败中提取信号的通用框架。

4.3 小模型 + RL > 大模型蒸馏

Orchard-GUI 的 4B > 235B 教师是最刺眼的数字。它说明：

• 蒸馏只能复制教师的能力上限
• 环境 grounded RL 可以让模型在真实交互中发现教师没有展示过的策略
• 小模型在 RL 中的探索空间可能更"大胆"（因为参数少，不容易过拟合到教师模式）

这跟 RLHF 的经典发现一致：小模型通过 RL 可以超越其 SFT 基座。

五、局限与未来

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

Orchard 相当于开源社区的"标准化基础设施"。它做了几件关键的事：

1. 环境标准化：Orchard Env 成为"Agent 的 Linux"——任何人可以在上面运行任何 Agent
2. 数据可复现：107K 轨迹 + 训练代码全部开源
3. 跨领域验证：同一套方案在 SWE、GUI、个人助手上都 work
4. 成本可控：K8s + spot 实例，10 倍成本降低

如果把 Agent 研究比作软件工程的发展史：

• 早期：每个人都在自己的机器上写代码
• 中期：出现了 Linux 和标准化开发环境
• 现在：出现了云原生和 Kubernetes

Orchard 想成为 Agent 研究的 "Kubernetes"——不是最 flashy 的，但是最必要的。

参考文献

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 #小凯