Ornith-1.0来了：代码模型不只会写代码，还开始学会“自己干活”

过去一年，代码模型的进化速度很快。

从代码补全、函数生成，到项目问答、Bug 修复，再到接入终端和开发工具，AI 编程助手已经不再只是“帮你写几行代码”的工具。真正有价值的方向，是让模型能进入一个完整的开发任务里：看懂项目、定位问题、修改代码、运行测试、根据报错继续调整，直到把任务推进完成。

DeepReinforce 发布的Ornith-1.0，正是沿着这个方向而来。

它是一组面向Agentic Coding的开源模型。Agentic Coding 就是让模型像一个代码 Agent 一样工作：不只是回答问题，而是能够围绕一个目标，自己规划步骤、调用工具、执行任务并持续修正。

这也是 Ornith-1.0 最值得关注的地方：代码模型正在从“会写代码”，走向“会完成工程任务”。

01 代码 AI 的下一步，不是写得更快，而是做得更完整

很多人第一次使用代码模型时，最直观的感受是：它能快速生成代码。

比如让它写一个接口、写一个脚本、解释一段报错，它通常都能给出不错的结果。但真实开发并不是一道单题。一个项目里的问题，往往需要经过一整套流程才能解决。

比如你让 AI 修复一个登录异常，它真正要做的可能包括：

• 先理解项目目录和登录模块的位置；
• 找到相关配置、接口和数据库逻辑；
• 根据错误日志判断问题来源；
• 修改代码后运行测试；
• 如果测试失败，再继续读取报错并调整；
• 最后确认功能恢复正常。

这和“生成一段代码”完全不是一回事。

所以，代码模型的竞争正在发生变化。以前大家更关心模型能不能写出正确函数，现在更重要的问题变成了：模型能不能像开发者一样，把一个真实工程任务一步步推进下去？

Ornith-1.0 的定位就在这里。它关注的不是孤立的代码片段，而是更接近真实开发流程的任务：终端操作、仓库理解、代码修改、测试验证、多轮修复。

这让它看起来更像一个“工程执行助手”，而不只是一个“代码生成器”。

02 Self-Scaffolding：让模型学会自己搭建工作流程

Ornith-1.0 最核心的概念，是Self-Scaffolding。

这个词看起来有些技术，可以用一个更简单的比喻来理解。

如果把完成一个工程任务看成盖房子，那么代码不是唯一重要的东西。真正影响效率的，还有施工顺序、工具选择、检查方式和返工策略。这里的 “Scaffold” 就像脚手架，它决定模型如何把任务拆开、如何推进、如何验证结果。

过去很多代码 Agent 的流程，是人提前设计好的。人告诉模型应该先看文件，再运行测试，再根据错误继续修复。模型更像是在按照人类写好的流程办事。

而 Ornith-1.0 想做的是：让模型在训练过程中，不只学习答案，也学习完成任务的方法。

也就是说，它不只是学“这段代码该怎么写”，还要学：

• 面对一个任务，应该先看哪里；
• 遇到报错，应该怎么判断；
• 修改之后，应该怎样验证；
• 如果失败，下一步该怎么调整；
• 怎样避免只给一个看起来正确、实际跑不通的答案。

这就是 Ornith-1.0 和普通代码模型的关键差别。

• 普通代码模型更像是“会回答问题的同事”；
• Ornith-1.0 更想成为“能自己推进任务的协作者”。

03 35B 不遥远，也够有代表性

Ornith-1.0 不是只发布了一个模型，而是提供了不同规模的版本，包括 9B、35B、397B 等。

35B版本最值得关注。它没有 397B 那么“遥远”，也比 9B 更能体现模型能力。对于开发者、小团队和企业技术团队来说，35B 更像是一个性能与可用性之间的平衡点。

从结果看，Ornith-1.0-35B 在多个代码 Agent 相关评测中表现突出。这里的重点不是简单“分数高”，而是这些评测本身更接近真实开发场景。

• Terminal Bench 更关注模型在终端环境中的任务执行能力；
• SWE-Bench 更关注模型是否能处理真实软件工程问题；
• NL2Repo 则更接近从自然语言需求到仓库级代码修改的任务。

这些都说明，Ornith-1.0 的目标不是让模型只在单个代码题上表现好，而是让它在更复杂、更真实的开发流程里发挥作用。

当然，跑分不是全部。更重要的是，它反映了代码模型评价标准的变化：

未来真正有价值的代码模型，不只是会写代码，而是要能在真实工程任务中持续推进。

04从9B到397B，Ornith-1.0 把代码 Agent 做成了一个系列

Ornith-1.0 还有一个值得注意的地方：它不是只有一个大模型，而是做成了一个模型家族。

这对实际使用很重要。因为不同团队的硬件条件、任务复杂度和使用目标都不一样。有人只是想本地试一试，有人希望接入开发工具，有人关注企业级任务自动化，也有人想看模型能力上限。

Ornith-1.0 的不同版本，大致可以这样理解：

• 9B 版本：更适合轻量体验和本地测试，门槛相对低；
• 35B 版本：更适合观察代码 Agent 能力，是性能和实用性的平衡点；
• 397B 版本：更适合展示旗舰能力，面向更复杂的工程任务。

同时，Ornith-1.0 还提供了 GGUF、FP8 等版本，方便在不同推理环境下尝试。它也支持 OpenAI-compatible API，可以接入现有工具链。对开发者来说，这意味着它不是只能“看榜单”，而是有机会真正接入工作流中测试。

如果说 397B 展示的是能力上限，那么 9B 和 35B 展示的就是另一个信号：代码 Agent 能力正在逐渐从“大模型展示”走向“更多人可以尝试的工具形态”。

05 结语：代码模型的竞争，正在换一个方向

Ornith-1.0 值得关注，不只是因为它有一组新的评测结果，也不只是因为它发布了多个规模的模型。

更重要的是，它代表了代码模型发展的一个新趋势：

从写代码，到完成任务；从给答案，到搭流程；从聊天助手，到工程协作者。

过去，我们评价一个代码模型，常常看它能不能写出正确代码。

但未来，我们可能会更关心另一个问题：它能不能理解一个真实项目，能不能在终端里执行任务，能不能根据测试结果自我修正，能不能把一个复杂需求一步步推进到完成。

Ornith-1.0 的出现，正好把这个变化放到了台前。

它让我们看到，代码模型不再只是一个“更聪明的补全工具”。当模型开始学习如何组织流程、如何使用工具、如何验证结果时，它就开始接近真正的工程 Agent。

这或许才是 Ornith-1.0 最重要的意义：

AI 编程的下一站，不是让模型写得更多，而是让模型做得更完整。

06 社区地址

OpenCSG社区：

https://opencsg.com/models/AIWizards/Ornith-1.0-9B

Hugging Face社区：

https://huggingface.co/deepreinforce-ai/Ornith-1.0-9B

07 OpenCSG vs 魔搭：如何选择？

维度	OpenCSG/CSGHub	魔搭/ModelScope
平台定位	企业级AI资产管理中心	面向开发者和AI 社区的MaaS平台
本地部署对象	一套模型资产管理平台本身	偏向模型、SDK 和工具链的本地使用
是否支持私有化/离线化	明确支持私有化部署、离线运行	支持模型下载、本地缓存、本地训练/推理等能力
开源代码	平台型产品本身	SDK 和大量工具链项目
管理能力	模型、数据、代码、应用的统一资产治理。	管理模型使用链路

模型部署和推理使用在魔搭、OpenCSG 等模型社区中均可实现，但OpenCSG/CSGHub 的核心差异在于，它不只是让模型“跑起来”，而是进一步支持企业把模型、数据集、代码和应用等 AI 资产放到本地、内网或离线环境中统一管理。它解决的不只是“模型怎么部署、怎么调用”的问题，更是“模型进入企业后如何被安全管理、版本沉淀、权限控制和持续运营”的问题。

对于企业来说，CSGHub 可以帮助构建自己的私有模型资产中心，降低对外部平台的依赖；对于个人开发者来说，也可以用更系统的方式管理模型、实验项目和 AI 应用流程。相比更偏向模型发现、体验和使用入口的魔搭，CSGHub 更适合那些希望把 AI 能力真正沉淀下来，并长期维护、持续迭代的用户。

08关于OpenCSG

OpenCSG是全球领先的开源大模型社区平台，致力于打造开放、协同、可持续生态，AgenticOps是人工智能领域的一种AI原生方法论，由OpenCSG（开放传神）提出。AgenticOps是Agentic AI的最佳落地实践也是方法论。核心产品 CSGHub 提供模型、数据集、代码与 AI 应用的 一站式托管、协作与共享服务，具备业界领先的模型资产管理能力，支持多角色协同和高效复用。