欢迎访问本站，持续更新中…
RSS

WikiFw 维基框架

微软开源Orchard 智能体研究缺的不是模型是环境

5 天前 智能体Orchard微软开源框架Kubernetes

微软开源Orchard 智能体研究缺的不是模型是环境

微软Orchard框架研究场景

做智能体研究的人应该都遇到过这个瓶颈：模型可以下载，但训练智能体的环境拿不到。想复现一篇 agent 论文，需要自己搭沙箱、造训练管线、攒数据集——这些恰恰是各实验室最不愿意公开的部分。微软研究院这次开源的 Orchard 框架，瞄准的就是这个缺口：把智能体的运行环境做成一个可复用的独立服务，而不是嵌在某个训练框架里的私有件。

环境层为什么成了瓶颈

Orchard 的核心组件叫 Orchard Env，一个基于 Kubernetes 的轻量环境服务，负责创建、管理、销毁隔离组件，可以并行跑几千个。它不绑定具体任务：软件工程、网页浏览、个人助手，同一个服务都能支持。训练数据收集、强化学习 rollout、评估，各阶段共用一套环境。

这个设计背后是一个判断：现在最强的智能体几乎都不是裸模型，它们跑在 Claude Code、Codex、OpenClaw 这类复杂 harness 里——多轮推理、工具调用、外部系统连接，全靠 harness 管理。但开源训练工具通常处理不了这种有状态、多进程的 harness，结果研究人员只能在一个简化版的环境里训练，部署时再换到真实环境，中间必然出现偏差。Orchard 的做法是用一个轻量代理记录 harness 自己的模型调用作为训练数据，每个 rollout 跑在自己的容器里，从而直接在真实 harness 里端到端训练。

小模型在逼近大模型的成绩

框架之外，论文最扎眼的是三个领域方案的成绩。Orchard-SWE 在 SWE-bench Verified 上做到 69.7%，加上值模型重排后到 73%——用的只有约 30 亿激活参数，而对比的前沿系统大它十倍以上。Orchard-GUI 用 40 亿参数的视觉语言模型，在 WebVoyager、Online-Mind2Web、DeepShop 三个基准上平均 68.4%，是目前开源 GUI agent 里最强的。Orchard-Claw 在 Claw-Eval 上 59.6%，配上 ZeroClaw 系统能到 73.9%。

Orchard小模型逼近大模型成绩对比

数字背后是训练方法的变化。Orchard-SWE 的训练数据来自对 MiniMax-M2.5 和 Qwen3.5-397B 两个模型的 10.7 万次交互蒸馏。一个细节值得注意：它用了 credit-assignment 监督微调，失败的尝试不会整个丢弃，而是从里面挑出有效的部分继续学习——这跟过去"要么成功要么丢弃"的做法不一样，等于把负样本里的有效劳动也回收了。强化学习阶段，因为成功信号稀疏，先用 Balanced Adaptive Rollout 最大化利用稀缺的成功反馈，再加上过程奖励模型，让模型为"写复现测试、验证修复、确认旧行为没坏"这类过程行为获得奖励，而不是只看最终测试过没过。

环境标准化的代价

把环境层抽出来做成服务，收益很明确：换任务、换 agent、换训练算法，不用重建基础设施。但代价同样存在。Kubernetes 底座意味着团队需要容器化和编排能力，对个人研究者来说门槛并不低；而且环境服务本身要维护，隔离、网络控制、资源调度这些事都得有人管——等于把原来藏在训练框架里的复杂度，变成了一份明面上的运维工作。

对工程团队来说，Orchard 真正值得参考的不是某个分数，而是"训练环境要和部署环境一致"这个原则。很多团队用智能体时遇到过类似问题：在测试环境跑得好好的，接到生产 harness 里就不行。Orchard 用代理记录真实 harness 调用、直接在部署 harness 里训练的做法，至少提供了一个可操作的解决思路。

环境层之后的问题

微软在展望里提到一个方向：把训练轨迹当成持久资产，而不是跑完就丢。轨迹可以蒸馏成值模型，让下一代智能体继承上一代的经验——这跟人积累项目经验的过程有点像，但距离落地还很远。轨迹数据怎么管理、怎么去重、怎么避免旧经验的错误被放大，这些问题都还没有答案。

目前公开的信息里也没有 Orchard Env 在真实生产负载下的性能数据，几千个并发容器的调度开销、训练一个完整 agent 的总成本，都需要团队自己验证。环境层标准化是这轮开源最大的贡献，但标准化解决的是"能不能做"，还没回答"做得好不好、贵不贵"。对大多数团队来说，先用它跑通一个任务，再判断值不值得把自己的训练管线迁过去，可能是更稳妥的路径。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。