Ornith 1.5 会让 Agent 越用越聪明吗：自生成训练任务不等于在线自我进化
最近看 Ornith 1.5 时，一个说法很容易让人兴奋：它能自己生成训练任务，所以 Agent 是不是会在日常使用中“越用越聪明”？
我的答案是：**可以形成越用越贴近真实工作的改进闭环，但它不是聊天时自动学习，更不是不需要数据。**真正发生的事情是，系统把已授权的使用信号转成可验证任务，在隔离环境里训练候选版本，再由独立评测决定是否发布。
这条差别听起来像措辞，实际上决定了系统会不会越学越稳，还是把偶然成功、敏感内容和错误习惯一起固化下来。
Ornith 1.5 做的不是“凭空出题”
Ornith 1.5 的官方说明把一次训练拆成三个相连的环节：
- 生成新的任务；
- 为任务生成脚手架，包括指令、工具、拆解方法和验收环境；
- 生成解题轨迹，并把验收结果作为奖励信号。
它和传统“人工整理一份 JSONL 题库，再反复训练”的区别在于，任务不必完全静态。系统可以根据已有解题历史继续提出更难、但仍然可验证的问题。官方描述的任务奖励同时看三件事：任务是否有效且可验证、难度是否落在模型当前能力前沿、与已有任务是否足够不同。这样做的目的不是让题目越怪越好，而是避免一直训练已经会做的简单题。
这套思路并不神秘。强化学习最需要的不是一堆自然语言题目，而是可靠的反馈。没有可靠验收，模型即使生成了一万条任务，也只是对一万条自己说的话继续拟合。
它能少用题库，但不能少掉“任务世界”
“不需要额外数据集”这句话只在很窄的实现意义上成立。
例如 Hugging Face 的 TRL GRPO 环境接口支持由环境在每次 rollout 的 reset() 中自行抽样任务或程序化生成状态，此时可以不传传统 train_dataset。环境还可以用 get_reward() 根据自身状态给整条轨迹打分。
但这只是把数据从一份静态文件，移动到了环境和生成器里。它仍然需要下面这些东西：
| 需要的资产 | 作用 | 缺失后的结果 |
|---|---|---|
| 初始模型与已有能力 | 让系统有提出任务和解决任务的起点 | 不会从零产生工程能力 |
| 代码库、业务流程或程序化环境 | 提供真实状态、约束和变化空间 | 任务只能在空泛文本里打转 |
| 可执行验收器 | 判断结果是否真的正确 | 模型会学会迎合格式而不是完成任务 |
| 隔离策略与防投机检查 | 阻止读取答案、删测试、联网抄答案 | 高分会变成“钻了评测空子” |
| 独立 holdout 评测集 | 判断新版本有没有真正变强 | 系统会把自出自测误判为进步 |
所以更准确的说法是：它减少的是人工枚举训练题目的成本，不是数据、环境和评价体系本身。
“越用越聪明”中间还隔着一次训练发布
线上 Agent 在一次任务里通常只是在推理。它可以读取上下文、调用工具、运行测试、修复失败，但除非系统明确启动训练流程，它的模型权重不会因为一次成功或失败而改变。
一个更可信的闭环应该长这样：
已授权使用记录 / 失败样本
↓
脱敏、筛选、去重、标注风险
↓
任务生成器 + 可执行脚手架
↓
隔离 rollout：读代码、改代码、跑验证
↓
奖励与反投机检查
↓
训练候选模型
↓
独立评测、人工闸门、灰度发布
↓
新的线上版本
这里最容易被省掉的两步是“脱敏筛选”和“独立评测”。但恰好它们决定了这个系统能不能上线。
用户对话、代码片段、日志和工具调用记录都可能带有凭证、个人信息、商业数据或错误结论。它们不能因为“以后也许能训练模型”就被原样收集。一个实际系统至少应当先解决授权范围、脱敏、保留时间、删除机制和访问审计，再讨论训练收益。
训练后也不能只看生成任务上的奖励。因为题目、脚手架和解题策略来自同一个闭环，模型很容易学到某个验收器的偶然模式。应该用没有参与任务生成的仓库、时间切分后的真实问题、不同语言或不同工具组合来做 holdout 测试。
对代码 Agent，最有价值的是“失败变成可复现任务”
这个方向在代码场景里尤其有吸引力。人工标注“这个 Bug 应该怎么修”很贵，但系统中本来就会产生很多有价值的过程信号：
- CI 在哪个命令失败；
- 哪个补丁被测试拒绝；
- 用户为什么回滚；
- 工具调用在哪一步超时；
- 修复后哪些隐藏条件仍不成立。
把这些信号变成训练任务，正确的单位不是一段聊天记录，而是一个可回放的工程单元：任务描述、可见文件、允许的动作、测试命令、隐藏检查、资源限制和最终证据。
这也是为什么 SWE-bench 这类评测有价值：它把真实仓库问题放入统一环境，并以是否解决问题来衡量，而不是只比较回答看起来像不像答案。Ornith 的模型卡也明确说明，其 SWE-bench 评估移除了 Git 历史、禁用了网络；NL2Repo 评测会阻断目标仓库和 pip 包访问。这些限制不是细节，而是在防止模型绕过任务本身。
先从一个小闭环做起
如果团队想验证“使用数据能不能带来下一版提升”，我不建议一开始就把所有对话和所有仓库纳入训练。更实际的起点是一个低风险、重复多、验收确定的场景，例如：
| 场景 | 可以收集的信号 | 验收方式 | 不应自动做的事 |
|---|---|---|---|
| CI 失败分流 | 日志、退出码、最小复现命令 | 分类准确率、复现成功率 | 直接改主分支 |
| 文档漂移检查 | API diff、文档差异、构建结果 | 链接与示例校验 | 擅自发布文档 |
| 依赖升级修复 | 锁文件变化、类型错误、测试输出 | 构建和回归测试 | 自动合并和部署 |
| 工具调用修复 | 参数校验失败、超时、重试记录 | 模拟环境中的状态断言 | 带着真实凭证重放 |
先把一个环境做成“任务可复现、验收可解释、失败可归因、结果可回滚”，再扩大数据源和任务类型。这样得到的不只是一个更会生成题目的模型，而是一条可以持续审计的学习管道。
看 Ornith 1.5，应该看什么
官方发布的 9B、35B-A3B 和 397B 模型都强调代码、推理和工具调用能力；其中 35B-A3B 是约 35B 参数、每 token 激活约 3B 参数的 MoE 模型。模型卡给出了 Terminal-Bench、SWE-bench、MCP-Atlas 等分数，但这些是供应商在特定运行设置下报告的结果，应当作为能力信号，而不是采购结论。
真正值得借鉴的不是某一个跑分，而是它提出的工程问题：任务由谁产生？验收器奖励什么？系统如何识别投机？历史使用数据如何在授权和脱敏后变成可回放样本？新版本又如何证明没有只学会迎合自己的考题？
这些问题答得越具体，“越用越聪明”就越接近可验证的工程能力；答不出来，它通常只是一个很会讲故事的产品词。
参考资料
- Ornith-1.5: From Self-Scaffolding to Self-Improvement，官方发布说明，任务、脚手架与 rollout 的联合优化机制。
- Ornith-1.5-35B-A3B model card，官方模型卡、部署接口、评测设置与限制。
- TRL GRPO Trainer: Environments，环境自采样任务、环境奖励与可选外部数据集。
- DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models，GRPO 的早期公开论文。
- SWE-bench，基于真实 GitHub issue 的软件工程 Agent 评测。