做智能体研究的人应该都遇到过这个瓶颈模型可以下载但训练智能体的环境拿不到。想复现一篇 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-SWE 的训练数据来自对 MiniMax-M2.5 和 Qwen3.5-397B 两个模型的 10.7 万次交互蒸馏。一个细节值得注意它用了 credit-assignment 监督微调失败的尝试不会整个丢弃而是从里面挑出有效的部分继续学习——这跟过去要么成功要么丢弃的做法不一样等于把负样本里的有效劳动也回收了。强化学习阶段因为成功信号稀疏先用 Balanced Adaptive Rollout 最大化利用稀缺的成功反馈再加上过程奖励模型让模型为写复现测试、验证修复、确认旧行为没坏这类过程行为获得奖励而不是只看最终测试过没过。环境标准化的代价把环境层抽出来做成服务收益很明确换任务、换 agent、换训练算法不用重建基础设施。但代价同样存在。Kubernetes 底座意味着团队需要容器化和编排能力对个人研究者来说门槛并不低而且环境服务本身要维护隔离、网络控制、资源调度这些事都得有人管——等于把原来藏在训练框架里的复杂度变成了一份明面上的运维工作。对工程团队来说Orchard 真正值得参考的不是某个分数而是训练环境要和部署环境一致这个原则。很多团队用智能体时遇到过类似问题在测试环境跑得好好的接到生产 harness 里就不行。Orchard 用代理记录真实 harness 调用、直接在部署 harness 里训练的做法至少提供了一个可操作的解决思路。环境层之后的问题微软在展望里提到一个方向把训练轨迹当成持久资产而不是跑完就丢。轨迹可以蒸馏成值模型让下一代智能体继承上一代的经验——这跟人积累项目经验的过程有点像但距离落地还很远。轨迹数据怎么管理、怎么去重、怎么避免旧经验的错误被放大这些问题都还没有答案。目前公开的信息里也没有 Orchard Env 在真实生产负载下的性能数据几千个并发容器的调度开销、训练一个完整 agent 的总成本都需要团队自己验证。环境层标准化是这轮开源最大的贡献但标准化解决的是能不能做还没回答做得好不好、贵不贵。对大多数团队来说先用它跑通一个任务再判断值不值得把自己的训练管线迁过去可能是更稳妥的路径。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版
