DeepReinforce 的第一个模型发布，直接打到了本地代码代理这个点上。

Ornith-1.0 是开放权重，MIT 许可，面向 agentic coding。也就是让模型不只是补代码，而是在代码库里检索、读文件、调用工具，连续完成开发任务。

更有意思的是，它不是只给一个巨型模型。公开信息里有 9B Dense、31B Dense、35B MoE 和 397B MoE 几个版本，并声称在同等规模开源代码模型基准上达到领先表现。

我更在意的不是榜单口号。

对本地 LLM 用户来说，真正的问题更朴素：能不能合规用，能不能在自己的机器或私有环境里跑，能不能撑住一串工具调用而不乱。

先看清 Ornith-1.0 到底给了什么

Ornith-1.0 基于 Gemma 4 和 Qwen 3.5 预训练模型构建。原记录里的判断是，这两个底座均为 Apache 2.0 许可，因此和 Ornith-1.0 以 MIT 许可开放权重的做法大体兼容。

这句话要留边界。

它是基于公开许可文本的判断，不是法律意见。真要放进公司流程，还是要按自己的合规要求再审一遍。

维度Ornith-1.0 已知信息对开发者的实际影响
发布方DeepReinforce，首个模型发布需要观察后续维护和说明是否跟得上
模型版本9B Dense、31B Dense、35B MoE、397B MoE小模型适合本地试验，大版本更偏部署或研究
权重许可MIT比只给 API 更适合私有代码场景
底座模型Gemma 4、Qwen 3.5许可链条相对清楚，但企业仍需复核
官方说法同规模开源代码基准领先可以作为线索，不能直接等同生产可用

这里和 Copilot、Cursor、Claude Code 这类云端代码代理不是一条路。

云端产品的优势是省心，工具链、界面、上下文管理都已经包好了。代价也很清楚：私有代码要不要上传，成本怎么控，供应商锁定能不能接受。

Ornith-1.0 这类开放权重模型给的不是完整产品，而是一块可接入本地工具链的底座。对已经在折腾 LM Studio、llama.cpp、本地 agent harness 的人，这个差别很关键。

初步体验看的是“能不能连续干活”

Simon Willison 的记录里，使用 LM Studio 跑的是 ornith-1.0-35b-Q4_K_M.gguf，文件约 20GB，并接入 Pi。

这个组合说明一件事：35B 量化版本已经能进入个人或小团队的本地实验范围。它不等于低门槛，但也不是只能在大型机房里看演示。

测试任务也比较贴近真实代码代理。

他让模型在 Datasette 代码库里查找两件事：一是 actor cookie 的解码逻辑，二是点击按钮后打开 insert dialog 的代码。模型都处理得比较顺。

这类任务比“写一个排序函数”更有参考价值。

代码代理最难的地方，常常不是生成一段漂亮代码，而是在陌生仓库里找对文件、跟住调用链、读懂命名、连续调用工具。中间一步跑偏，后面就会越走越远。

所以 Ornith-1.0 这次给出的信号是：35B GGUF 版本至少值得本地代码代理用户拉下来试一轮。

但别把它当成系统评测。

一次顺利的终端会话，只能说明它在这个仓库、这些任务、这套 harness 下表现不错。大仓库、长任务、多语言项目、复杂重构，仍然要重新验证。

还有一个绘制鹈鹕的小测试，输出速度达到 103 tokens/s。结果有瑕疵，但还能看出是鹈鹕。

这个例子更适合看成本地推理速度和生成稳定性的旁证。它不能证明模型具备完整多模态能力，也不该被拿来夸大。

现在适合谁试，谁该等等

Ornith-1.0 现在最适合两类人。

一类是已经在本地跑模型的开发者。他们有 LM Studio、llama.cpp 或类似工具链，也愿意处理量化文件、上下文长度、工具调用失败这些麻烦。

这类人可以把 35B GGUF 当作新的候选模型，放进现有 agent harness 里跑几个真实仓库任务。重点不是看它会不会聊天，而是看它能不能连续查代码、改代码、解释路径。

另一类是不能轻易把私有代码送上云的小团队。

他们不一定马上迁移，但可以安排一次小范围试用：挑一个内部仓库，设计 5 到 10 个高频任务，比如查调用链、定位配置、生成小补丁、解释测试失败。跑完再决定是否进入日常工具链。

更谨慎的团队可以先观望。

原因也简单：DeepReinforce 公开信息还不多。原记录里提到，能找到的较早论文是 2025 年 6 月的《CUDA-L1: Improving CUDA Optimization via Contrastive Reinforcement Learning》。除此之外，团队背景、训练细节、数据来源、评测方法、后续维护节奏，目前都看不清。

接下来不必盯着“又高了几个点”。更该看四个变量：

观察点为什么重要适合采取的动作
GGUF 等量化版本是否持续更新决定本地用户能不能长期用本地开发者可先试，不急着替换主力模型
多工具调用在长任务里是否稳定决定能否胜任真实代码代理用真实仓库压测，不只跑小 demo
训练与评测说明是否更透明决定信任成本企业团队先做合规和安全审查
发布方维护节奏是否稳定决定生态能不能跟上小团队避免一次性迁移

我的判断是，Ornith-1.0 已经进入“值得试”的区间，但还没进入“可以押注”的区间。

对本地代码代理来说，分数只是入场券。真正的门槛是长活：多轮工具调用不漂，仓库理解不乱，量化版本有人维护，许可链条经得起审查。

回到开头那个问题：它是不是本地代码代理的新选择？

是。

但现在更像一把刚开刃的刀。可以上手试锋利，别急着拿它替掉整套工具箱。