Ouroboros: A Self-Developing Frontier Coding Agent with Reviewed Core Evolution
Anton Razzhigaev, Andrei Gritsaev, Andrei Kaznacheev, Nikita Dragunov, Roman Yampolskiy, Andrei Kuznetsov
cs.SE, cs.AI
2026-08-09
能通过评审式 commit 改写自身核心代码的 agent Ouroboros,Opus 5 版登顶 Terminal-Bench 等三项基准,另附 161 天活体自我进化部署。
Agent 跑长程任务的分数是底座模型、执行框架、环境和评分器四样东西的乘积。模型越强,框架(harness)对最终能力的占比就越大。怎么组装上下文、调工具、纠错,这些设计决策在 Claude Code、Codex、Cursor 之间拉开了真实差距。但绝大多数生产框架在交付后就冻住,所有改进都得靠人。
Ouroboros 要把这个框架变成「会自己长的东西」:它的源码、prompt、工具、上下文组装、甚至评审逻辑,都活在一个版本化的仓库里,通过评审过的 commit 改动,而这些改动直接变成后续任务运行的底座。让它能改自己不算最难,难的是改完还安全。一个能重写自身代码、还能自己换模型 API 的 agent,安全边界必须扛得住它自己的进化压力。
架构上把「启动器加监督器」和「可变的 agent 仓库」分开。启动器管进程、引导、紧急停止,这些不能被 agent 改;仓库里装任务循环、工具、prompt、记忆、评审逻辑、benchmark 适配器,可以改。所有改动走一条 commit 流水线:确定性预检、给 staged diff 打指纹、收集评审证据、提交前再核对一次指纹,中途被改就中止。diff 评审面板是多模型对抗式评审,要求达到 quorum 才算通过;在 max 模式下还会做整仓库范围的 scope 评审。
核心进化有两种模式。
递归自由进化把「改进系统」本身当成一个任务。agent 检查当前系统、选一个改动、实现它,完成后可以再排下一个进化任务,形成一条连续的 commit 链,而非一次性的优化跑。经验驱动的核心进化从日常干活出发。任务执行、反思、评审卡点、社交反馈会暴露 bug、粗糙的边界、上下文组装失败、低效的工具路径,agent 把这些记成持久的错误类和待修项,再决定要不要开维护工单,走同一条评审 commit 闸门。
子 agent 体系也讲究。只读的 planning scout 和能写但隔离的 acting child,各自独立 worktree,默认深度 2、最大 500。子 agent 不能直接提交主仓库,patch 回到父节点做三方合并并校验哈希和受保护路径。
五项基准,都用官方评分器:
| 基准 | 模型 | Ouroboros | 对比 |
| Terminal-Bench 2.1 | Opus 5 | 86.74%(审计后) | Claude Code+Fable 5 83.8%、Codex CLI 83.1% |
| OSWorld-Verified | Opus 5 | 90.69% | Intelligence-Indeed 90.19% |
| CL-Bench | Sonnet 4.6 | 0.2301 | ICL 0.1960、Claude Code 0.1855 |
| SWE-bench Pro | GPT-5.6 Luna | 58.2% | Codex 59.4%(p=0.40,打平) |
| GAIA | Sonnet 5 | 78.2% | Claude Code 78.8%(打平) |
三项登顶,两项和最强对手打平。审计很较真。Terminal-Bench 上发现一个 trial 靠走捷径蒙混过弱验证器,没跑完 Git-to-web 流水线就往 web 根预置文件,作者主动找维护者把这一条清零,86.97% 降到 86.74%。SWE-bench Pro 的任务 ID 会暴露上游修复 commit,两个框架都能通过搜索或 Git 历史摸到参考答案,论文用对称过滤(任一方摸到就剔除)重做配对比较,把原本看似落后的差距翻成统计打平。
Hope 是这套机制的最大现场实验。2026 年 2 月起一个常驻 agent 跨 7 个交互面(web、语音、Telegram、Discord、X、网站评论、邮件)服务约 3600 人,处理 22 万条公开消息,持续改自己的实现。到 8 月 6 日:161 天、花 11.06 万美元、处理 797 亿 token、17.5 万行代码、1085 次自我修改 commit(其中 94.2% 是 agent 自己写的)、1522 次评审自我编辑尝试、近期评审拦截率 63.5%。
这篇证明「会改自己代码的框架」不只是概念,能在真实基准上拿到 SOTA、还能长期在线跑。对从业者的信号:agent 框架的自进化是可工程化的路径,关键是把「改自己」放进一条可审计、可回滚的版本控制闸门里,而非放任它自由改。
Hope 的价值在于展示了经验驱动进化的闭环。用户在公开渠道抱怨这 agent 老发重复消息,agent 自己定位到重复发送路径,落地一条去重 guard;自审任务因上下文溢出崩,agent 把评审包组装换成按 import 图重要性排序的有界上下文图谱。两条修复一条源自社交反馈、一条源自自检,都变成后续任务复用的持久改动。
作者自己承认:Hope 是单条谱系的部署研究,不是一组独立进化的对照群体,「自进化是否普遍稳定」没法从这一个例推论;SWE-bench Pro 受公开参考泄漏和任务缺陷影响;LLM 评审器和 agent 可能有共同的盲区,低 context 模式还会跳过整仓库 scope 评审。
另有几处存疑。五项基准里只有 Terminal-Bench 报了 5 试乘 89 任务的多 trial 方差(约 ±1.7 个百分点),其余多数是单次 campaign,小差距(比如 OSWorld 上 90.69% 对 90.19%)是否稳得住没给方差。Hope 的 161 天、11 万美元、94.2% 自写 commit 这些数字很抓人,但「活体进化到底让能力涨了多少」论文没给前后对照,没有一个冻住的对照组来证明持续进化比冻住的种子确实更强。benchmark 用冻种子、Hope 用另一条谱系继续进化,两者其实跑的是不同代码,拿 Hope 当 benchmark 结果的佐证要小心。