Ornith-1.0 开源 Agentic Coding 模型家族——RL 同时优化「任务脚手架」与最终答案

类别：ai-models · 2026-06-25
原文链接：https://x.com/berryxia/status/2070167806700908957

事件内容

2026 年 6 月 25 日，开源大模型团队 Ornith 发布 Ornith-1.0——一个专门面向智能体编程（agentic coding）的开源 LLM 家族。全家族覆盖从 9B Dense、31B Dense、35B MoE 到 397B MoE 的全参数规模，在 Terminal-Bench、SWE-Bench 等多个 agent coding benchmark 上达到当前开源同尺寸模型的 SOTA。

更值得注意的是训练方法：Ornith-1.0 用强化学习同时优化「任务脚手架（scaffold）」和最终解决方案，让模型自己学会怎么搭建更好的执行框架。

发布要点：

• 全尺寸开源：9B / 31B Dense + 35B / 397B MoE，覆盖从本地笔记本到数据中心全场景。
• MIT 开源协议——商用友好，且提供 GGUF 格式，可在 Ollama、Unsloth 等本地推理工具里直接跑。
• agent coding 基准 SOTA：SWE-Bench Verified、SWE-Bench Pro、Terminal-Bench 等多个编程智能体评估的同尺寸开源最优。
• 核心创新点：把「怎么搭脚手架」也变成可学习信号——RL 奖励不仅看「最终答案对不对」，还看「执行框架是不是合理」。

深度剖析

Ornith-1.0 的提法，准确地击中了当前 AI Coding 工具链最隐蔽的瓶颈：模型本身能写代码，但大多数失败发生在「怎么组织执行流程」。

第一层：「脚手架学习」为什么重要？

传统 AI coding 训练的奖励信号几乎都聚焦在「最终代码能不能通过测试」上。但实际工程中的失败模式有相当一部分并非「代码错」，而是：

• 工具调用顺序错（先 read 后 grep 与先 grep 后 read 的差异）。
• 中间步骤冗余（重复检索同一文件）。
• 上下文管理失控（把整个 repo 塞进 context，导致关键信息被淹没）。
• 错误恢复策略弱（一次失败就放弃，没有 retry-with-different-approach）。

这些问题都不在「最终答案」里，而在「执行流程」里。Ornith-1.0 把执行流程本身纳入 RL 优化，本质上是承认了一个事实：agentic coding 是一个「流程工程」问题，而非单纯的「代码生成」问题。

这一思路与 Anthropic 在《Building effective agents》中提到的「agents are about scaffolding, not models」形成呼应——但 Ornith-1.0 是把脚手架学习内化进模型权重里，而不是把它外置在工程代码里。

第二层：与开源 agentic coding 梯队的对比。

2026 年 Q2 的 agentic coding 开源梯队大致有：

• Qwen3-Coder（阿里通义千问）：覆盖 30B / 480B，原生支持工具调用和长上下文。
• DeepSeek-Coder V3 / V3.1（深度求索）：以 MoE 架构与极致成本效率见长。
• Kimi K2（月之暗面）：开源 MoE，长上下文与代码能力并重。
• GLM-4.5 / GLM-5（智谱）：以 coding 与 tool use 为核心优化目标。
• Claude Sonnet / Opus（Anthropic，闭源）：SWE-Bench Verified 长期 SOTA。
• Ornith-1.0（Ornith）：全尺寸 MIT 开源，专注 RL 优化脚手架与最终答案。

Ornith-1.0 的差异化点不在模型架构（与 Qwen3-Coder 同样是 MoE），而在训练范式：把 scaffold 纳入 RL 奖励信号。如果这条路线被验证有效，它将直接影响后续所有 agentic coding 模型的训练策略——尤其那些在「SWE-Bench 上刷到顶，但真实任务里表现平庸」的模型。

第三层：MIT + GGUF 协议选择的工程含义。

• MIT 开源意味着任何公司都能直接基于 Ornith-1.0 训练垂直领域模型、嵌入产品、或蒸馏成更小版本。Apache 2.0 与 MIT 是这一梯队的两个常见选择，MIT 的「禁止诉讼」条款比 Apache 2.0 更友好，对商业用户更安心。
• GGUF + Ollama + Unsloth 三件套意味着本地推理能力成熟——这与 OpenRouter 在 MCP 服务器文章里「最佳编程模型是 GLM-5.2」的描述（详见 Topic 4）形成对照：开源 agentic coding 正在从「云端 API」走向「本地可跑」的临界点。

第四层：上下文与工具调用能力的隐含指标。

虽然本次发布没有具体披露 9B / 31B Dense 与 35B / 397B MoE 的上下文长度、tool calling schema、function calling 兼容性等参数，但既然面向 agentic coding，这些能力必然已对齐主流协议（如 Anthropic MCP、OpenAI Function Calling）。未来一周内的 GitHub README 与技术报告将是观察重点。

值得关注的原因

1. 「RL 优化脚手架」是 agentic coding 训练范式的新前沿。过去两年开源 coding 模型大多在「数据」与「架构」上卷，Ornith-1.0 是首批公开把「执行流程本身」纳入 RL 奖励的——这对 Qwen3-Coder、DeepSeek-Coder、Kimi K2、GLM-5 等同梯队选手的训练策略都将产生直接影响。
2. MIT + GGUF + 全尺寸开源，意味着中小团队能真正本地部署一个 SOTA 级 agentic coding 模型。9B / 31B Dense 适合单卡 4090/5090；35B / 397B MoE 适合数据中心。这与「OpenRouter 推荐 GLM-5.2 做最佳编程模型」一起，标志开源模型在 coding agent 领域已具备与闭源模型正面竞争的实力。
3. 对 AI Coding 工具厂商是潜在威胁。Cursor、Claude Code、Trae、Codex CLI 等前端工具如果基于开源 Ornith-1.0 微调自己的版本，将绕过对 Anthropic / OpenAI 的依赖——这是 agentic coding 工具链「模型层民主化」的开始。
4. 对 AI Coding 评测基准是潜在改进。如果 Ornith-1.0 在 SWE-Bench Verified 上达到开源 SOTA 但「执行流程」上有独特优势，那 SWE-Bench 这类「只看最终答案」的基准就需要补充「流程合理性」的二级评测。

风险与待观察

• 「脚手架 RL」的复现性未知。训练细节（reward shaping、轨迹收集方式、是否引入过程监督）尚未公开，是否能复现到其他模型上是开放问题。
• 397B MoE 的本地化部署成本。即便开源，普通开发者也跑不动 397B 级别——实用性更多在数据中心和云端 SaaS。本地党主要看 9B / 31B Dense。
• 与 Anthropic Claude Sonnet / Opus、OpenAI GPT-5.5 闭源梯队的代差。Ornith-1.0 在「同尺寸开源」上是 SOTA，但 SWE-Bench Verified 绝对数值上与闭源顶级仍有差距（后者通常 80+）。
• 评测基准的针对性。Ornith-1.0 主要在 Terminal-Bench、SWE-Bench 系列上成绩突出，是否在真实业务（多文件、长链路、需要设计决策的任务）上一致强，未验证。
• 缺乏第三方独立评测。发布初期数据来自团队自报，需要等 HuggingFace 社区、Artificial Analysis、Design Arena 等独立机构跑分确认。
• 商业模式未定。MIT 开源 + 无明确商业化路径，对项目长期维护是隐忧。

结论：Ornith-1.0 不是又一次「开源又追上闭源」的常规叙事，它代表了 agentic coding 训练从「代码答案 RL」转向「执行流程 RL」的范式转移的早期信号。如果后续有更多团队跟进这条路，2026 年下半年 agentic coding 模型层的迭代节奏会从「刷榜单」切换到「刷流程合理性」。