Orchard：一个开源的智能体建模框架 Orchard: An Open-Source Agentic Modeling Framework

Orchard Env 运行分三步。(1) 创建：客户端 `POST /sandboxes` 提交 Docker 镜像，编排器转 K8s Pod 规格，init container 把 agent 拷进用户镜像并启动。(2) 执行：`exec(command)` 通过 Pod IP 直连到 pod 内 FastAPI 代理的 `/exec` 端点，命令作为子进程执行（带可配置超时，per-sandbox 锁防并发交错）。(3) 清理：后台 reconciliation loop 清理心跳过期或 Pod 被驱逐的孤立沙箱。Orchard-SWE 训练两阶段：Stage 1 SFT 用交叉熵损失，损失仅计算上升段内 token 及解决轨迹全部 token；Stage 2 RL 用 BAR+GRPO，从 SFT 检查点在 ~2K 难度过滤的 SWE-rebench V2 任务上做 on-policy rollout，奖励为测试通过 ±1。Orchard-GUI/Claw 流程类似但 SFT 池分别只有 412 和 561 条，RL 用 GPT-4.1 当 judge 给二元奖励。

在环境层，与 ProRL Agent 的关键区别是 ProRL 把环境层和 agent handler 插件、LLM 推理路由、评估逻辑绑在同一个 rollout server 里，而 Orchard Env 的 REST API 显式独立于训练循环和 harness；与 MegaFlow 的区别是 MegaFlow 的环境服务与 Qwen 训练管线共同设计，第三方训练器无法接入；与 E2B/Daytona 的区别是 Orchard 自托管在标准 K8s 上、利用 spot 实例可降本 10×。在训练方法层，「信用分配 SFT」和已有失败轨迹利用方法（如 ReST、Self-Refine）的本质区别是用 LLM 作为回溯价值函数（已知结果 + 完整历史 → 估计每步成功概率），提取的是「上升段」而非整条失败轨迹的简单 SFT；BAR 与 DAPO（丢弃全 0/全 1 组）、历史成功率预过滤、rollout 后下采样这些已有策略的区别是 BAR 在「每个 prompt、每个梯度步」按 stride 在线组装目标平衡组，可以提前停止以节省算力，也可以回退到最优排序，适应性更强。

四个弱点。(1) **信用分配价值估计器可靠性未验证**。教师做 zero-shot 回溯价值估计，但教师自身对成功概率的判断可能不准确——当失败原因是教师不理解的概念时，价值曲线会系统性偏高或偏低。改进：多教师 ensemble 或 calibration（temperature scaling）。(2) **BAR 的 [$\rho_{min}, \rho_{max}$] 区间静态**。训练早期需宽松上界，训练后期需宽松下界，固定区间可能持续卡在 fallback。改进：区间随训练步数或 prompt 难度自适应（按最近 K 次平均成功率滑窗调整）。(3) **故障域未充分覆盖**。1,000 沙箱 26s 是清洁实验室结果，生产环境会遇到网络分区、镜像拉取失败、节点 OOM；agent 注入到任意用户镜像也带来安全风险。改进：镜像签名验证、默认 deny-all 网络策略、细粒度资源监控。(4) **数据规模相对教师蒸馏偏小**。Orchard-SWE 107K、Orchard-GUI 412 SFT 相比 MolmoWeb 278.5K 有 2-3 个数量级差距，论文优势是更少数据更好泛化，但要刷窄分布极值可能需 1M+ 轨迹。

作者在文末和附录里暗示了几个方向：(1) 把环境层从 K8s 进一步抽象，兼容 Slurm+Singularity 等 HPC 基础设施，让学术机构无需云账号也能跑；(2) 把 BAR 推广到多模态 rollout（如带截图的 GUI 任务），因为当前 $\rho$ 选择依赖标量奖励，多模态奖励方差结构更复杂。基于成果可延伸的方向：(a) 把 Orchard Env 作为「harness 无关 RL 评估平台」开放，任何团队的 agent 可用同一份 sandbox 评测脚本对比，避免 leaderboard 不可比问题；(b) 把信用分配 SFT 推广到多模态轨迹（GUI 截图序列），用 VLM 当回溯价值函数；(c) 用 BAR 训练「轨迹质量评估器」反过来过滤教师蒸馏的失败轨迹；(d) 探索 spot instance 的更激进容错训练——在沙箱随时被驱逐的不稳定环境下做 RL，看能否训练出更鲁棒的 agent。

复现评估分三层。**环境层**：Orchard Env 完全开源，可在自有 K8s 集群 1-2 天部署；最低配置 8 节点 32 vCPU/128 GiB，研究组用 2 节点 16 vCPU/64 GiB 也能跑小规模。**数据层**：Orchard-SWE 全部 107K 轨迹、Orchard-GUI 15,601 任务池和 412 SFT 轨迹、Orchard-Claw 192 合成任务均开源；SWE 任务 Docker 镜像由 Scale-SWE/SWE-rebench 预构建，用 init container agent 注入避免重 build。**训练层**：使用 Qwen3-30B-A3B-Thinking、Qwen3-VL-4B-Thinking、MiniMax-M2.5、Qwen3-VL-235B-A22B-Thinking 等公开模型，slime 训练框架开源；SFT 5 epoch、64K 上下文、cosine LR 1e-5→1e-6、global batch 128，8×H100 节点预计 2-3 天；RL 阶段 BAR+GRPO，max 150 step，rollout batch 16、group size 8，依赖 0.28s 延迟才能在合理时间内完成。**难度评估**：完整复现需多张 H100/A100 + ≥128 沙箱K8s 集群 + 容器化仓库镜像管理经验，对资源受限研究组是中等偏高门槛；复现单点设计（BAR 开源实现、credit-assignment prompt 模板）门槛较低。