上周在 Terminal-Bench 上跑一个代码生成任务时，我发现了一个有意思的现象：模型能生成语法正确的代码片段，但当我要求它完成一个需要多步骤协作的复杂任务时，输出就开始变得混乱——不是代码本身有问题，而是执行逻辑的“脚手架”没搭好。这让我再次意识到，在 Agentic Coding 场景下，真正决定成败的往往不是单段代码的质量，而是任务分解和组织的能力。正好，最近开源的 Ornith-1.0 模型家族，就是冲着这个问题来的。它不是一个单纯的代码生成模型，而是一套专门为“智能体编码”（Agentic Coding）设计的全参数规模模型系列，从 9B 的密集模型到 397B 的混合专家模型（MoE）全覆盖。更重要的是，它的训练方式很有意思：不是只优化最终答案的正确性，而是用强化学习同时优化“任务脚手架”和最终解决方案，让模型自己学会如何搭建更好的执行框架。如果你也在尝试把大模型用于自动化编程、任务分解或复杂问题求解，那么 Ornith-1.0 可能值得你花时间了解一下——不是因为它号称“最强”，而是因为它试图解决的是这类场景下最实际的问题：如何让模型不仅会写代码，更会组织代码执行的逻辑。1. 先搞清楚 Ornith-1.0 真正要解决的是什么问题在讨论一个模型家族之前，我们需要先回到一个更根本的问题：当我们在说“Agentic Coding”时，我们到底在说什么？1.1 从代码生成到任务组织的范式转变传统的代码生成模型，比如早期的 Codex 或者一些专注于代码补全的模型，核心目标是生成语法正确、功能实现的代码片段。你给它一个函数签名或者一段注释，它返回对应的代码实现。这种模式在辅助编程、代码补全场景下很有用，但它有一个明显的局限：模型只负责“填充”，不负责“规划”。而 Agentic Coding 的关键差异在于，模型需要承担更多的规划和组织职责。举个例子，如果你对模型说“帮我写一个爬取知乎热门回答并生成摘要的脚本”，这就不再是一个简单的代码生成任务了。它至少涉及以下几个子任务：模拟登录或绕过反爬机制定位热门回答列表页面解析页面结构提取回答内容调用摘要模型处理文本处理分页和去重设计结果存储格式一个只会生成代码片段的模型，可能会给你一个语法正确的函数，但很可能无法正确组织这些子任务之间的依赖关系和执行顺序。而 Ornith-1.0 试图解决的，正是这个“组织”问题。1.2 为什么“脚手架”能力比代码正确性更难训练在 Ornith-1.0 的介绍中，特别提到了它的训练方式：用强化学习同时优化“任务脚手架”（scaffold）和最终解决方案。这里的“脚手架”指的是任务执行的框架性结构，比如先做什么、后做什么、如何传递数据、如何处理异常等。这种能力之所以难训练，是因为它需要模型具备对任务的整体理解能力，而不仅仅是局部代码生成能力。在传统的代码训练