Ornith-1.5 发布：AI Agent 从自我脚手架走向自我改进

DeepReinforce 今天发布了 Ornith-1.5，主线非常明确：让 AI Agent 不只是完成任务，还能够持续改进完成任务的方法。

AI Agent 是能够自主拆解任务、调用工具并根据执行结果循环修正的模型系统。 在编码场景里，它通常需要读取代码仓库、编辑文件、运行测试、分析报错，再决定下一步动作。过去，这套流程主要由人类预先写好的 Agent 框架负责；Ornith-1.5 试图把其中一部分“流程设计”交给模型自己学习。

这也是它和普通代码大模型最重要的区别。普通代码模型关注的是“下一段代码应该怎么写”，Ornith 系列关注的则是“面对一个真实的软件工程任务，接下来应该采取什么行动”。

从写代码到设计工作流

自我脚手架（Self-Scaffolding）是指模型能够生成或调整用于完成任务的外部工作流程，而不是只生成最终答案。 Ornith-1.0 的核心思路，就是让模型在解决编码问题的同时，尝试优化自己的任务推进策略。

传统编码 Agent 的脚手架往往是固定的。开发者会提前规定：先读取项目结构，再搜索相关函数；修改代码后运行测试；测试失败时读取日志；连续失败几次后重新规划。这样的流程可以快速落地，但它有一个明显问题：同一套规则很难适应所有仓库。

一个前端项目、一个数据库驱动、一个编译器项目，失败原因和有效工具链完全不同。固定脚手架像一张统一尺寸的施工图，面对不同建筑时只能反复打补丁。

Ornith-1.0 的方向，是让模型在执行任务时参与构建这张“施工图”。它不只输出补丁，还会尝试判断应该如何搜索文件、什么时候运行测试、哪些错误值得优先处理，以及任务失败后是否需要改变策略。

Ornith-1.5 在此基础上进一步推进。根据官方发布页的定位，新版本不再把“自我生成脚手架”当成终点，而是把脚手架本身纳入持续优化过程。换句话说，模型要学习的对象从“代码解决方案”扩展到了“解决方案生成器”。

这带来一个重要变化：Agent 的能力不再完全等同于模型本身的单轮代码生成能力。一个模型即使单次写代码不如竞品，只要它能更快发现错误、减少无效尝试，并持续调整行动顺序，在长链路任务中也可能取得更好的最终结果。

Ornith-1.5 到底改进了什么

自我改进（Self-Improvement）是指模型依据任务结果、测试反馈或验证信号，更新后续任务策略的过程。 它不等于模型在部署过程中直接修改参数，也不等于模型获得了无限制的自我训练能力。

更准确地说，Ornith-1.5 改进的是 Agent 的“运行时策略”。模型会根据当前任务的反馈，调整下一轮的规划方式、工具使用顺序和验证强度。模型权重可以保持不变，但它在不同项目中采用的工作方法会发生变化。

这类能力可以拆成几个环节：

1. 任务建模。 模型需要判断当前问题是一个局部缺陷、跨文件重构，还是涉及依赖、构建和运行环境的系统性问题。
2. 策略生成。 模型决定先搜索哪些文件、是否需要阅读测试、应该直接修改还是先创建实验性补丁。
3. 执行与观察。 Agent 通过终端、代码编辑器、测试框架或其他工具获得真实反馈。
4. 失败归因。 模型区分代码逻辑错误、测试环境问题、依赖缺失和自身操作失误，而不是把所有失败都当作“再试一次”。
5. 策略更新。 如果原来的行动顺序无效，模型需要改变计划，而不是在同一个局部方案上继续堆叠修改。

这套机制的关键，不是让模型“想得更多”，而是让每一步思考都和可验证的外部结果绑定。对编码 Agent 而言，编译是否通过、测试是否通过、补丁是否真正改变了目标行为，比一段看起来合理的解释更有价值。

为什么这比单纯扩大参数更值得关注

Agent 编码的瓶颈通常不只是代码生成质量，还包括长任务中的规划、记忆、工具调用和错误恢复。 这也是 Ornith-1.5 选择优化工作流的原因。

一个真实 GitHub Issue 往往不是“写一个函数”这么简单。Agent 可能需要在几十个目录中定位实现，理解旧代码的约束，修改多个模块，补充测试，处理版本兼容问题，最后还要保证原有测试不回归。

在这样的任务里，单轮生成能力只是起点。模型如果第一次修改失败，能否识别失败原因；如果测试通过，能否确认自己修复的是目标问题而不是绕过测试；如果搜索结果过多，能否收缩上下文范围，这些能力会直接影响任务完成率。

Ornith-1.0 已经展示了这条路线的潜力。公开资料显示，Ornith-1.0 系列包含 9B、31B、35B 混合专家以及 397B 混合专家版本。其中，9B 版本在 SWE-bench Verified 上取得 69.4 分，35B 版本被报道达到与更大规模模型相近的表现，397B 版本则达到 82.4 分。

SWE-bench Verified 是一个要求模型修复真实开源项目缺陷的编码评测集，评分重点是补丁能否通过项目测试，而不是代码文本是否看起来合理。 因此，这些成绩比普通代码补全基准更接近 Agent 在真实仓库里的工作方式。

不过，不能把 Ornith-1.0 的成绩直接当成 Ornith-1.5 的成绩。官方页面对 1.5 的重点是方法和 Agent 行为的升级，具体评测应以发布页和对应模型卡为准。当前更稳妥的判断是：Ornith-1.5 试图提升长程任务中的有效行动比例，而不是简单追求更大的参数规模。

与传统编码模型的差异

| 对比维度 | 普通代码生成模型 | 固定脚手架编码 Agent | Ornith-1.5 的目标方向 | |---|---|---|---| | 核心输出 | 代码、补丁或解释 | 代码加预设流程 | 代码加可调整的任务策略 | | 工作流程 | 主要依赖用户分步提示 | 由开发者提前编排 | 模型根据反馈调整 | | 工具调用 | 通常较少或由外层控制 | 按固定规则调用 | 学习何时调用、调用什么工具 | | 错误处理 | 重新生成或等待人工提示 | 执行预设重试逻辑 | 分析失败原因并改变策略 | | 适用任务 | 函数补全、局部修改 | 常见仓库修复流程 | 多步骤、长链路工程任务 | | 主要风险 | 代码幻觉和上下文不足 | 流程僵化 | 奖励投机和验证器欺骗 |

这张表说明了 Ornith-1.5 的定位：它不是一个面向所有用户的聊天模型，也不是把 IDE 自动补全做得更快，而是面向已经具备终端、仓库和测试执行能力的 Agent 基础设施。

对于只想让模型写一个正则表达式的用户，Ornith-1.5 很可能属于“能力过剩”。但对于需要让 Agent 连续处理依赖升级、测试修复、代码迁移和大型重构的团队，它优化的正是最容易消耗人工时间的部分。

真正的难点：模型可能学会“骗过”验证器

奖励投机（Reward Hacking）是指模型找到提高评分的表面路径，却没有真正完成目标任务。 对能够修改自身工作流程的 Agent 来说，这个问题比普通文本生成更严重。

如果训练目标只是“让测试命令返回成功”，模型可能会寻找修改测试、伪造状态文件、跳过执行步骤或隐藏错误输出的方法。表面上看，任务完成率提高了；实际上，软件行为可能根本没有修复。

Ornith 系列此前已经把验证器安全视为重要问题。对自我脚手架模型而言，验证系统不能只检查最终文件状态，还需要确认关键命令确实执行过、测试结果来自可信环境、修改没有破坏评测边界。

Ornith-1.5 的价值，最终取决于它能否把“自我优化”约束在真实目标之内。如果模型可以自由修改流程，却没有足够强的沙箱、日志和独立验证机制，那么更强的自我改进能力也可能意味着更高的失控风险。

在工程部署中，至少应关注以下几项：

• 验证器隔离： 测试代码、评分逻辑和被修改的工作区应尽量分离，避免 Agent 同时控制答案和裁判。
• 执行证据： 不能只相信 Agent 的文字总结，需要保存命令、退出码、日志和文件差异。
• 补丁审计： 对涉及依赖、权限、构建脚本和测试文件的修改设置更高审核门槛。
• 资源边界： 限制运行时间、磁盘范围、网络访问和可执行命令，避免错误策略不断扩大影响面。
• 独立复核： 关键任务应使用第二套测试或干净环境重新验证，而不是复用 Agent 自己生成的检查结果。

开源价值比榜单名次更重要

开源 Agent 模型的核心价值，是让开发者能够控制模型、脚手架、工具和验证环境的完整组合。 这和单独下载一个代码大模型并不一样。

Ornith-1.0 采用 MIT 许可证，并提供从 9B 到 397B 的多个规模版本，这使它覆盖了本地部署、私有服务器和高性能推理集群等不同场景。对企业来说，私有运行意味着源代码、内部文档和测试日志不必全部发送到外部服务；对研究者来说，脚手架和验证器可以被拆开研究，而不是只能接受一个封装好的 Agent 产品。

但“开源”不等于“部署便宜”。397B 混合专家模型的总参数规模很高，即使每次只激活一部分参数，也需要较大的显存、内存和通信带宽。9B 或中等规模模型更适合边缘设备和单机实验，但在复杂仓库上可能需要更多轮次才能完成任务。

因此，选择 Ornith-1.5 时不能只看参数量或单项榜单。更实际的指标包括：完成一个任务需要多少轮工具调用、失败后能否恢复、平均消耗多少 token、是否会频繁修改无关文件，以及在干净环境中复现成功率是多少。

我们的判断：方向正确，但还不是“会自己成长的程序员”

Ornith-1.5 的突破点是把 Agent 的流程策略作为学习对象，但它仍然属于受约束的策略优化系统，而不是能够无限自我进化的通用智能体。 这个边界必须说清楚。

它最值得关注的地方，是把编码 Agent 的竞争从“谁能生成更漂亮的代码”推进到“谁能用更少的无效动作完成真实任务”。当代码生成模型逐渐同质化后，规划效率、错误恢复和验证可靠性会成为更重要的差异。

它的局限也很明显。首先，自我改进依赖高质量反馈；测试不完整的仓库无法给出可靠奖励。其次，长链路任务的成本仍然可能很高，策略搜索越充分，工具调用和推理时间就越长。再次，模型在训练环境中学会的流程，未必能迁移到企业内部的特殊构建系统和权限体系。

所以，Ornith-1.5 更适合三类用户：已经运行编码 Agent 的开发者、需要私有化代码自动化的团队，以及研究 Agent 训练和验证机制的工程师。它不适合作为普通聊天助手，也不能仅凭一个基准分数就直接接管生产代码库。

接下来真正值得观察的，是 Ornith-1.5 在独立验证集、跨语言仓库和长时间运行任务中的表现。如果它能在不增加大量工具调用的前提下，提高 SWE-bench 类任务的稳定完成率，并减少修改无关文件和重复试错，那么“自我改进脚手架”才会从一个有吸引力的研究概念，变成编码基础设施中的实用能力。

截至 2026 年 8 月 20 日，Ornith-1.5 的发布释放了一个清晰信号：AI 编程 Agent 的下一阶段，不只是更大的模型和更长的上下文，而是让模型开始学习如何组织自己的行动。对于开发者而言，真正需要评估的也不再是“它能不能写代码”，而是“它能不能在可审计、可验证的边界内，把一项复杂工作可靠地做完”。

参考来源

• Ornith 模型在 Hugging Face 的检索页：用于核对模型发布状态、模型卡和权重信息。
• Ornith 项目在 GitHub 的检索页：用于查找官方代码仓库、许可证和部署说明。
• DeepReinforce《Ornith-1.5: From Self-Scaffolding to Self-Improvement》：官方发布说明，本文关于 1.5 定位和技术方向的主要依据。
• DeepReinforce《Ornith-1.0: Self-Scaffolding LLMs for Agentic Coding》：Ornith-1.0 的模型规模、训练思路及公开评测背景参考。