Ornith-1.0：开源代码智能体的自我改进之路

代码大模型已经能写单文件函数，但把它们塞进智能体（agent）里反复调用工具、执行脚本、根据报错修正——这才是真正的差距。大多数开源代码模型在静态评测集上分数好看，一旦进入 agentic coding 环境（多步推理 + 实时反馈），表现骤降。原因不复杂：训练数据里没有这类交互轨迹，模型不知道下一步该看日志还是改语法。

Ornith-1.0 瞄准的就是这个缺口——一个开源模型，且声称能通过自我改进在 agentic coding 场景里持续提升，不需要额外人工标注。

什么是 Ornith-1.0

Ornith-1.0 是一系列基于 LLaMA-2 / CodeLlama 架构微调的开源模型，专为 agentic coding 设计。目前发布了 7B、13B 两个规模版本，许可证为 Apache 2.0。

它和普通代码模型的区别主要在两点：

• 训练目标对齐智能体行为：除了生成代码，模型还要能输出工具调用（bash、文件读写、搜索等 JSON 动作），并根据执行结果调整下一步动作。这一层被明确编码进了微调数据。
• 自我改进训练流程：模型先用静态数据微调出一个基础版本，然后部署到一系列编程任务中，收集自己的执行轨迹，自动过滤出成功案例作为新训练数据，再进行下一轮微调——循环多次，不需要人工奖励标记者。

这种循环借鉴了 STaR（Self-Taught Reasoner）和 Self-Rewarding 的思路，但专门针对代码执行的可验证性做了定制：判断一次交互是否“成功”，不是靠 LLM 打分，而是看终端返回的退出码、测试通过率、以及是否符合预定义的任务目标。客观信号降低了奖励噪声。

为什么自我改进对智能体编码重要

现有开源模型在 agentic coding 任务上提升慢的根本原因是数据瓶颈。手动构造高质量的 agent 交互轨迹成本极高：需要人类设定任务、等待模型执行、人工评估成功与否。规模化几乎不可能。

自我改进机制让模型自己产生训练数据，只保留那些实际执行成功的轨迹。只要任务环境能提供客观的成功/失败判断（测试用例通过、目标文件生成等），模型就可以无监督地滚雪球。Ornith-1.0 论文报告，在 SWE-bench Lite 子集上，经过两轮自我改进后，13B 模型的 pass@1 从 14.3% 提升到 21.7%，增加了 7.4 个百分点——远低于 GPT-4 的 36.7%，但考虑到模型参数少一个数量级，且完全开源，这个增量表明方法有潜力。

实现方法：自我改进循环

整个流程分为四个阶段：

1. 初始微调：基于 CodeLlama-13B，用静态 agent 轨迹（人工编写或从 GPT-4 蒸馏）进行 SFT，得到 v0 模型。
2. 自采样：将 v0 部署到一组编程任务（如软件工程、Git 操作、包管理），用任务环境执行每条轨迹，收集所有动作和反馈。
3. 过滤：只保留最终完全成功的轨迹。这里的“成功”由任务定义，例如修复 bug 后所有测试通过、安装依赖后项目能正常启动。
4. 再训练：将成功轨迹作为新的 SFT 数据，与旧数据合并后微调得到 v1。重复 2-4 若干次。

关键在于过滤阶段不依赖 LLM 作为评判，因此不会引入模型自身的偏好偏差。代价是任务必须提供可验证的成功信号——不是所有 agentic coding 场景都能做到。对于需要人工判断审美或模糊目标的修复任务，这套循环会失效。

实际使用：部署与微调要点

模型已发布在 Hugging Face，使用标准 Transformers 库即可加载。推理代码与 CodeLlama 一致，但需要特别注意输出格式：模型预期输出为 JSON 序列，例如 {"action": "bash", "args": "ls -la"}。如果你要接入 IDE 插件或 Cline 这类 agent 框架，需要解析这个 JSON 并发送给执行器。

显存需求：

• 7B 模型（FP16）约 14 GB，适合 RTX 3090/4090。
• 13B 模型（FP16）约 26 GB，需要 A100-40G 或两张 3090 用张量并行。

要做自我改进微调，你需要准备一个带可验证成功条件的任务集（例如修复指定的开源 bug、运行给定测试套件）。官方提供了一个基于 Docker 的 sandbox 环境，用于封闭执行和日志采集。微调脚本使用 DeepSpeed ZeRO-3，13B 模型在 8×A100 上约 6 小时完成一轮。

社区可复制性：这是或有价值的部分——Ornith-1.0 开源了全部训练数据和微调代码。如果你有自己的编程任务集（比如内部仓库的测试框架），可以用同样的 pipeline 生成定制 agent 模型。

看法与展望

自我改进对 agentic coding 是个务实且可缩放的方向。比起依赖人类反馈或更大量的静态数据，利用代码执行本身的确定性判断来驱动迭代，是一条更持久的路径。Ornith-1.0 的贡献在于把这个流程固化为可复现的开源系统。

但有两重隐忧：一是任务信号可验证的边界——当任务从“修复 bug”升级为“设计架构”或“优化性能”时，成功判定会模糊，自我改进就会崩塌；二是多轮循环可能放大模型固化的错误模式，虽然执行客观性降低了奖励噪音，但模型仍会在自己成功的轨迹里钻洞，陷入局部最优。

值得关注的是：这种自我改进能否在纯开源模型上逼近 GPT-4 在 agentic coding 上的表现？Ornith-1.0 当前在 SWE-bench 上的 21.7% 与 GPT-4 的 36.7% 仍有差距。多轮自训练是否能突破这个天花板，取决于任务多样性、初始模型的推理上限、以及循环中是否会出现能力饱和。

如果模型只能从自己成功的小任务里学习，它永远不会撞到复杂任务的边界——那么自我改进也就停在了舒适区。这个问题，Ornith-1.0 没有回答，但它的开源设计让其他人可以尝试不同的答案。