DeepReinforce 把 Ornith-1.0 放上 GitHub。页面不花哨，但几个数字很抓眼：9B Dense、35B MoE、397B MoE，MIT license，无区域限制，面向 agentic coding。

最值得看的，不是它又参加了一轮代码榜单。代码模型会写函数，已经不新鲜。Ornith-1.0 押的是另一件事：模型能不能组织一个代理流程，把搜索、工具调用、执行、修复和验证跑成闭环。

这才是 coding agent 现在最硬的门槛。

事实压缩：它开源了什么

Ornith-1.0 是一组后训练模型。README 称，它基于 Gemma 4 与 Qwen 3.5 做后训练，目标场景是 agentic coding，而不是单纯代码补全。

项目Ornith-1.0 信息对使用者的直接影响
模型家族9B Dense、35B MoE、397B MoE从单卡试验到多卡服务有不同档位
许可MIT license、无区域限制企业私有化部署的法律顾虑更少
上下文支持 256K context更适合处理大仓库、长任务、复杂 issue
Agent 能力tool calling、OpenAI-compatible API更容易接入现有 coding agent 框架
格式bf16、FP8、GGUF 等方便高性能部署和量化推理尝试
部署门槛9B 可上单 80GB GPU；35B/397B 需要多 GPU开源不等于低成本，397B 不是个人电脑玩具

榜单部分也有看点。按 README 自报，397B 在 Terminal-Bench 2.1、SWE-bench、NL2Repo、ClawEval、SWE Atlas 等 agentic coding 基准上，接近或部分超过一些闭源模型和更大模型。

但这句话要加刹车。

这些成绩来自项目 README，不是第三方独立验证。它也不是全面领先。Claude Opus 4.8、GLM、Qwen Max 等模型在不同分项里仍有胜出。

所以，别急着把它写成“开源登顶”。现在能说的是：Ornith-1.0 把开源 coding agent 的上限又往前推了一段，但胜负还在分项里。

对开发者的动作也很具体：可以先拿 9B 或量化版本接进现有 agent harness 做任务回归，不必马上迁移生产流量。对企业团队，合理动作是放进私有化 POC 清单，而不是立刻替换 Claude、Qwen Max 或内部已有方案。

关键不在榜单，在 scaffold

Ornith-1.0 最重要的词是 self-improving training framework。

这个词很容易被读歪。它不是说模型上线后会自己无限进化。README 说的是训练阶段：强化学习不只优化 solution rollout，也优化驱动解题过程的 scaffold。

换成开发者听得懂的话：模型学的不只是“最后怎么答”，还包括“先看哪里、怎么拆任务、何时调用工具、失败后怎么换路”。

真实 coding agent 的失败，常常不在写代码本身。

它可能不知道该读哪个文件。可能不会判断哪个测试最关键。可能看见报错就乱改。也可能已经修好了，却不知道该停。

模型看着更强，产品反而更虚，很多时候就卡在这里。

这也是 Ornith-1.0 比普通代码模型更值得看的地方。它把训练目标从答案推进到过程。这个方向是对的。

历史上有个不完全一样、但很贴的参照：早期铁路公司比拼的不只是机车马力，还要比轨道、调度、维修和票务。机车再快，调度乱了照样撞车。

今天的 coding agent 也是这样。参数量是发动机，scaffold 和 harness 是铁路网。

“不谋全局者，不足谋一域。”放在这里不算装饰。代码代理如果不会组织全局任务，只会局部补丁，跑到复杂仓库里很快露馅。

真正该算的，是闭环能力和运行成本

我更在意两个变量。

一个是任务闭环能不能复现。Ornith-1.0 支持 OpenAI-compatible API 和 tool calling，可以接 OpenHands、OpenClaw、Hermes Agent、OpenCode 这类框架，也能通过 vLLM、SGLang 起服务。

这比“下载一个会写代码的模型”重要得多。

因为 coding agent 的实际效果，不只由模型决定。提示词、工具权限、文件检索、测试执行、沙箱、安全策略、重试逻辑，都会影响最终成功率。

如果一个团队要评估 Ornith，测试方式不该只问“HumanEval 多少分”。更该拿自己的仓库做三类任务：修 bug、补测试、改跨文件功能。看它能不能跑完，看花多少 token，看失败后是不是越改越乱。

另一个变量是成本。

397B MoE 开源很漂亮，但普通开发者不会因为 GitHub 上有权重，就突然多出一组多 GPU 机器。9B 单 80GB GPU 更现实。35B/397B 更像团队和企业的部署选项。

FP8、GGUF 能缓解压力，但不能把算力账抹掉。

这件事对两类人最直接。

AI 开发者可以做的是：用 9B 或量化版本接入本地 coding CLI，先验证 agent 流程，不急着追 397B。重点看任务完成率、平均耗时、失败模式，而不是只看 README 表格。

企业技术负责人可以做的是：把 Ornith-1.0 当成私有化备选。代码、日志、内部仓库不能随便送出去的团队，会在 MIT 许可和无区域限制里看到价值。但采购或迁移最好延后到 POC 之后，用自己的仓库和权限边界测，不要拿公开榜单替代验收。

我不太买账的是“开源追平闭源”这种说法。

太省事，也太误导。

闭源模型的优势不只在模型本体。还有推理基础设施、上下文工程、产品体验、工具链、持续调优和安全兜底。开源要赢，也不能只靠一个 397B 的名头。

开源真正的优势在另一边：可控、可改、可私有化、可审计。代价也清楚：部署贵，调参累，工程链条要自己扛。

所以，Ornith-1.0 至少把问题摆正了。

coding agent 的竞争正在从“会不会写代码”，转向“能不能把一个麻烦任务跑完”。

接下来最该看的不是谁又多赢一个 benchmark，而是三件事：第三方复测能不能站住；真实仓库任务的成功率和成本如何；9B/35B 档位能不能在普通团队预算内跑出稳定价值。

软件工程从来不是写几行聪明代码。它是在混乱里把事情收口。

模型如果学不会收口，榜单再亮，也只是纸上行军。