Ouroboros：会改写自己的编程 Agent
Ouroboros 能通过受审查的 Git commit 修改自身 harness。本文拆解它的记忆、进化循环、benchmark 边界，以及自修改 Agent 的安全底线。
Ouroboros：会改写自己的编程 Agent
大部分“自我改进 Agent”只是记一条经验，或者重写 prompt。Ouroboros 动的是未来任务真正会运行的 harness：应用代码、工具、prompt、context 组装、依赖，甚至自身的运行方式。候选修改通过审查后写成 Git commit，后续任务直接跑新版本。
这比 reflection 激进得多，问题也更难：连续自改 30 次之后，reviewer、sandbox、身份约束和 rollback，还是最初那套东西吗？
先说结论
- Ouroboros 是 MIT 协议的 local-first Agent runtime，支持桌面和 headless CLI。
- 它有递归自由进化和经验驱动进化两条路径，修改通过 Git commit 进入后续 runtime。
- 身份、记忆和任务状态跨重启保存，Git 负责记录实现变化。
- 论文报告了 Terminal-Bench 2.1、OSWorld-Verified 和 CL-Bench 的领先成绩，但这些是作者在冻结 snapshot 上报告的结果，不能证明每次 live evolution 都让系统变好。
- 自修改要站得住脚，protected surface、独立 review、预算、重启测试和 rollback 必须在候选修改的控制范围之外。
它到底能改什么
官方仓库把可编辑范围放得很宽：代码、架构、prompt、工具和依赖都能动，reflection 还能调整它对自身身份和经验的描述。
项目把 self-modification、持久记忆和 reviewed evolution 做进同一个 runtime。来源：Ouroboros GitHub。
它同时保留不可随意修改的区域。BIBLE.md 是所谓的宪法单一事实源，架构与开发文档定义当前运行边界。README 还提到 protected path、Git 历史和 restart check。
这条线不能含糊。一个系统如果连“修改必须 review”这条规则也能自己删掉，就不存在长期治理。自进化必须有一个不归候选 patch 管的信任根，哪怕项目用了一套很哲学的语言描述它。
两条进化路径
2026 年 8 月发布的 Ouroboros 论文描述了两种 core evolution。
递归自由进化
改进本身就是任务。Agent 找到结构变化，完成实现，收集 review 证据，然后可能继续安排下一轮。这种模式最有戏剧性，也最容易优化成“系统自己喜欢的样子”，而不是用户真正需要的结果。
经验驱动进化
正常干活时不断遇到同一种摩擦：工具易碎、context 浪费、崩溃重复出现，或者 review 总在打回同类问题。它们先进入 improvement backlog，再变成有边界的改动。
生产环境里，第二条更靠谱。它从真实故障出发，不是丢一句“让自己变得更好”。一条合格的改进记录至少要写清触发任务、破坏的 invariant、修改机制、评测方法和 rollback 条件。
任务证据
-> improvement backlog
-> 有范围的修改提案
-> 隔离环境实现
-> 独立 review
-> 测试 + 重启检查
-> reviewed Git commit
-> 后续 runtimeGit commit 不只是保存代码，而是“Agent 正在评估候选方案”到“未来 Agent 正式继承新系统”的交接点。
所谓身份连续，本质是数据模型
Ouroboros 喜欢用“continuous being”来描述自己。落到工程上，就是 self-modifying repo、状态和预算、memory、聊天历史、事件、上传文件与版本记录都持久化到本地。
连续性最终靠文件和版本历史实现。是否接受它的哲学叙事不重要，数据生命周期必须说清楚。
| 连续性层 | 必须保存什么 | 最常见故障 |
|---|---|---|
| 身份 | 稳定原则与自我描述 | 性格和目标悄悄漂移 |
| 记忆 | 来源、范围、置信度、过期时间 | 旧推断被反复引用成“事实” |
| 实现 | Reviewed Git history | 未审代码进入 runtime |
| 任务 | 输入、动作、输出、状态 | 重启后 ghost task 或重复执行 |
| 预算 | 已花费用与剩余额度 | 一重启计费器清零 |
最难的是 memory provenance。Reflection 不是外部确认的事实。如果两者都变成知识文件里的一段普通文字，系统反复引用自己，猜测很快会固化成身份。Identity 修改应该进入 candidate 状态，review 强度也要高于普通 working memory。
Benchmark 数字要怎么读
论文报告：Opus 5 在 Terminal-Bench 2.1 得到 86.74%，OSWorld-Verified 为 90.69%，五次 rollout 的 CL-Bench normalized reward 为 0.2301。作者将它们描述为 best reported 或 state of the art。
Benchmark 使用冻结 snapshot，长期运行的 Hope 在另一条 lineage 上继续进化。来源：arXiv:2608.08311。
这些数字值得研究，但不能光秃秃搬过来：
- 结果来自项目作者的新 preprint；
- 强 base model 对成绩贡献很大；
- Benchmark 跑的是冻结 snapshot，评测过程中不会继续改自己；
- 最终高分没有拆出 self-evolution、harness、模型和评测配置各自贡献；
- best reported 不等于 benchmark 官方独立复现。
冻结 snapshot 是对的。要是系统在评测过程中修改面对 evaluator 的代码，横向比较基本失去意义。但这也意味着 benchmark 证明的是“之前进化得到的某个版本很强”，并没有证明进化过程安全，更没有证明质量单调上升。
我最想看到的不是另一个终点分数，而是一张逐 commit 曲线：每次 core change 对固定 regression suite、任务质量、成本和 rollback rate 的影响。一个漂亮终点看不出中途是否出现 10 次回归，最后靠人工 review 才救回来。
自我 review 不等于独立 review
Ouroboros 可以给规划、代码、轻量 safety 和 deep review 配不同模型。多模型有帮助，但同一模型家族调用 3 次，不会凭空产生真正独立性。共同盲区还是共同盲区。
| Review 层 | 能抓什么 | 不能保证什么 |
|---|---|---|
| 作者 Agent 自评 | 明显实现错误 | 摆脱自己的原始计划 |
| 独立模型 review | 不同推理路径 | 不同训练盲区 |
| 确定性测试 | 已知 invariant 与回归 | 未知危险行为 |
| 人工审批 | 范围和组织判断 | 穷尽所有技术错误 |
| Runtime policy | 禁止动作 | 被允许的动作一定明智 |
Core evolution 至少要有一个 reviewer 不受候选 patch 修改。测试从干净的外部 harness 发起，approval record 和 commit 一起签名。重启后先核对运行 revision 与 protected-file hash，再允许系统接新任务。
一次安全的进化应该像事务
每次自修改都按数据库 migration 来做，别按聊天回复来做。
- Snapshot：记录 repo revision、memory manifest、runtime config 和预算。
- Scope：列出可编辑路径和必须保留的 invariant。
- Fork：在没有生产凭证的一次性 workspace 实现。
- Evaluate：跑目标测试与固定 regression suite。
- Review：由候选 runtime 外部的模型和人收集证据。
- Commit：只签署真正通过 review 的 tree。
- Restart：用受限凭证启动候选版本并做 health check。
- Promote：重启验证通过后才设为 current。
- Observe：保留上一 revision，触发约定信号时自动回滚。
很多 Agent 系统在 promote 这步偷懒。开发进程里的测试通过，不代表打包后的 runtime 能启动、能读旧 memory，也不代表 protected path 仍然生效。
SandBase 一类一次性环境很适合做 fork 和 evaluate。提升到正式版本的 credential 必须留在 sandbox 外面，不能让生成代码自己批准自己。
Ouroboros 真正有意思的地方
它把很多通常分开演示的概念装进了一套系统：持久身份、任务连续、多 Agent、后台 reflection、自修改、Git 历史和 protected constitution。这比“循环改 prompt 直到 benchmark 过关”更值得研究。
但它仍然是实验，不是“自主进化普遍安全”或“每次进化都累计收益”的证明。README 里不少“living agent”说法既是产品哲学，也是设计叙事。真要运行，先读 BIBLE.md、docs/ARCHITECTURE.md、protected-path 实现和 release history，再决定给它什么仓库权限。
相关基础可以继续看 带 Reflection 的自修正 Agent 与 Agent Memory 架构对比。
我的判断
Ouroboros 值得关注，因为它真的把 self-improvement 延伸到 runtime，并留下可 review 的 Git 历史。它最重要的贡献可能不是某个 benchmark，而是把自修改变成一笔事务：提案、证据、protected surface、review、commit、restart 和 rollback。
我会把它放在隔离研究 workspace 里，使用假 secret 和随时可重建的仓库。我不会让自修改 Agent 拿广泛生产凭证，除非外部 controller 能证明当前跑的是哪个 revision、哪些 invariant 仍然成立，以及无需向 Agent 求助就能回滚。
FAQ
Ouroboros 是开源项目吗？
是。官方仓库使用 MIT License。
Ouroboros 会重新训练模型权重吗？
这里讨论的 core evolution 不训练权重，而是修改模型外部的 harness、代码、prompt、工具、context、memory 和模型选择。
Ouroboros 能完全本地运行吗？
Runtime 和状态保存在本地，也支持 GGUF 本地推理。实际能力取决于本地模型，远程 provider 是可选项。
Benchmark 已经被独立验证了吗？
引用的结果来自近期 arXiv preprint，由作者报告。除非 benchmark 官方另行公布，应把独立复现视为仍待完成。
最大的安全风险是什么？
是治理逐步被削弱：某次 self-change 降低了 review、protected path、monitoring 或 rollback 强度，随后新 runtime 又负责判断下一次修改。
