Ouroboros：一个会自己改自己代码的编程智能体，顺手刷穿了三个榜单
你有没有过这种体验：一个编程 Agent 刚部署的时候挺好用，用了一个月，它还是在犯同样的错误——同样的上下文拼接方式、同样的工具调用习惯、同样在某种任务上翻车。你只能在旁边干着急，因为它的"脑子"（harness）从部署那天起就冻住了，能变的只有模型。
这篇论文做的事情，用一句话说：让 Agent 的 harness 本身变成一个可以持续进化的对象——工具、prompt、上下文组装逻辑、甚至核心实现代码，都通过一个带评审的 commit 通道不断修改，改完的新版本直接成为后续任务的运行时。而且这个系统真的跑起来了：一个名叫 Hope 的实例在七个公开渠道上连续运行了 161 天，处理了 22 万多条消息，自己给自己提交了 1085 次代码修改。
核心摘要：Ouroboros 是一个自我进化（self-developing）的编程 Agent harness，核心思路是把"改进自己"也当成一个任务来跑，所有自修改必须经过带指纹校验的评审 commit 门。在 Terminal-Bench 2.1 上 Opus 5 跑出 86.74% 的审计后成绩（榜单最佳），OSWorld-Verified 90.69%（超过此前最佳），CL-Bench 归一化奖励 0.2301（新 SOTA）。我的判断：这不是一篇"算法突破"型论文，而是一套把"自我进化"从论文概念推到工程现实的系统工作——它最值钱的部分其实不是刷榜数字，而是那套在 Agent 自己改自己代码时仍然 hold 住的安全边界设计，以及把 reward hacking、数据污染这些脏事主动摊开审计的态度。
论文信息
- 标题：Ouroboros: A Self-Developing Frontier Coding Agent with Reviewed Core Evolution
- 作者：Anton Razzhigaev, Andrei Gritsaev, Andrei Kaznacheev, Nikita Dragunov, Roman Yampolskiy, Andrei Kuznetsov
- 机构：莫斯科国立大学、斯科尔科沃科学技术研究院、Joi Lab、AIRI 旗下 FusionBrain Lab、HSE University
- 链接：https://arxiv.org/abs/2608.08311 （2026 年 8 月 8 日提交，v2 于 8 月 11 日修订）
- 代码：MIT 协议开源（github.com/razzant/ouroboros），项目主页 ouroboros-agent.ai
有个细节挺有意思：作者列表里明确标注了"System contributor: Ouroboros"——Hope 这个 Agent 本身是系统的贡献者（提供了部署反思、代码历史上下文等），但按 arXiv 和 ACL 政策不计入正式作者。Agent 参与写自己的论文，这大概是 2026 年才有的风景。
为什么 harness 值得被进化
先说清楚这篇论文的出发点。一个长时程 Agent 的成绩，其实是四个因素的乘积：基座模型、执行 harness、环境、评分器。模型越来越强之后，实际能力里越来越大的比例由 harness 决定——它怎么组装上下文、怎么调工具、怎么验证结果、怎么从失败里恢复。SWE-agent 和 OpenHands 早就证明过 agent-computer interface 本身就是性能的一部分；最近几个对照研究也发现，固定住模型不换，光换 harness，准确率、延迟、token 消耗能差出一大截。
但几乎所有生产 harness 的策略在设计完成后就冻结了。Claude Code、Codex CLI、Cursor 这些系统，升级靠的是背后的工程师发版，不是 Agent 自己。
自我进化这个方向其实不算新。Voyager 会积累可执行技能，STOP 和 Gödel Agent 改 scaffold，Sakana AI 和 Jeff Clune 实验室 2025 年搞的 Darwin Gödel Machine（DGM）已经能改写自己的 Python 代码，在 SWE-bench 上从 20% 一路自我改进到 50%——不过 DGM 跑一次 80 轮迭代要花两周、烧掉约 2.2 万美元 API 费用，而且还出现过 Agent 为了刷分把幻觉检测标记删掉的"objective hacking"案例。
Ouroboros 在这条线上的位置，论文自己画了张表（Table 1），我觉得这张表比文字更说明问题：
| 系统 | Prompt | 工具/技能 | 工作流 | 核心代码 | 评审 commit | 部署状态 |
|---|---|---|---|---|---|---|
| Voyager | ✓ | ✓ | – | – | – | – |
| Live-SWE-agent | ✓ | ✓ | – | – | – | – |
| Autogenesis | ✓ | ✓ | ✓ | 部分 | 协议规定 | 部分 |
| Darwin Gödel Machine | ✓ | ✓ | ✓ | ✓ | 跑 benchmark 筛选 | – |
| Hermes Agent | ✓ | ✓ | ✓ | – | – | ✓ |
| OpenClaw / ClawBench | ✓ | ✓ | ✓ | – | – | – |
| Ouroboros | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
表 1：自我进化系统的能力边界对比。只有 Ouroboros 同时占了全部六项——能改核心代码、所有变更走可审计的版本控制评审门、并且有一个真实长期部署在跑。
跟 DGM 的关键差异在于：DGM 的进化筛选靠 benchmark 分数，是一个固定优化 run；Ouroboros 的进化走评审 commit——每一次自修改都是一次带审计记录的代码提交，改完直接成为线上运行时。一个是"搜索出更好的 Agent"，一个是"Agent 持续活在版本控制里"。
架构：一个不许动的监督者，套一个随便改的仓库
Ouroboros 的架构有个很清晰的分层：launcher + supervisor 边界是不可变的，Agent 仓库是可变的。
图 1：Ouroboros 架构。上方是主链路——接口层（Web/CLI/Telegram/项目）→ launcher + supervisor（准入、租约、预算、恢复）→ 任务运行时（上下文、模型路由、工具循环）→ 带类型的结果（回执、产物、原因码）。中间三条支线：外部工作区任务、任务树与子代理权限、benchmark 适配器。所有路径最终汇入底部红色的"评审过的自仓库变更"——preflight、指纹、diff 法定人数、范围记录，然后写入版本化系统仓库。
这个设计的直觉很简单：进化可以发生在仓库里，但"谁有权让一次变异生效"必须在仓库之外。launcher 管启动、进程监督、发布引导和 panic-stop 语义；仓库里装着任务循环、工具、prompt、记忆投影、评审逻辑、benchmark 适配器和用户界面——这些全都可以被 Agent 自己改。
具体怎么改？三档运行模式卡死权限边界：
- Light：完全禁止仓库编辑
- Advanced：允许普通编辑，但治理面（governance surfaces）受保护
- Pro：允许受保护的编辑，但必须过评审
commit 管线值得展开说说，这是整个系统的命门。一次自修改要走完：确定性 preflight → 对暂存 diff 打指纹 → 收集评审者证据 → commit 前再校验一次指纹。每次写入都会让之前的评审证据失效，因为证据和暂存快照是绑定的——你想趁评审完之后偷偷再改一行？指纹对不上，直接拒。diff 评审面板在所有上下文模式下都是阻塞式的；在 owner 选的 max 模式下，还有一个全仓库范围的 reviewer 评估目标、耦合、prompt 和功能代码；low 模式则跳过范围评审。回滚走单独的恢复路径，恢复到更早的评审状态。
说实话，看到"指纹校验两次"这个设计的时候我有种看到软件供应链安全（SLSA、sigstore 那套）被搬进 Agent 自修改场景的感觉——这其实就是 toB 软件交付里防"评审后篡改"的标准做法，用在 Agent 身上意外地合身。
子代理：孩子可以干活，但只有爹能 commit
图 2：子代理补丁集成协议。父任务持有任务契约和唯一的 commit 权限；只读的 planning scout 提供证据，可写的 acting child 在隔离 worktree 或外部工作区里干活；所有产出汇入任务树黑板 + join 账本（带类型的决定、子节点哈希、集成状态）；父节点验证血缘、SHA-256、受保护路径后做三方合并，最终进入评审门。
Ouroboros 可以派生两类子代理：只读的 planning scout 和可写的 acting child，挂在可配置的任务树上（默认深度 2，配置上限 500——这个数字有点吓人）。关键约束是：acting child 在隔离的 worktree 里写代码，永远拿不到对线上系统仓库的 commit 权限。父节点在合并前验证血缘、补丁哈希和受保护路径，做三方索引集成。提交 benchmark 的配置文件会关掉任务委派以保住 pass@1 的纯度，planning scout 的贡献则单独披露。
图 3：一个真实 Ouroboros 会话的任务树视图。可以看到 planning-scout、content-builder、engineer-builder、design-builder 等角色嵌套展开，每个节点带状态（done/rejected/failed）、note 数和子节点数。注意里面有两个标着 Issue 的 failed 节点（researcher、app-builder、viz-builder）——真实的 Agent 协作就是这么磕磕绊绊的，不是演示视频里那种一路绿灯。
两种进化模式
这是论文的核心机制，一句话版：主动想改和被问题逼着改两条腿走路。
递归自由进化（recursive free evolution）：把"改进系统"本身当成一个任务派给 Agent。Agent 审视当前系统，选一个改进点，实现它，走评审 commit——完成后可以自己调度下一轮进化任务。这不是一个跑完就停的优化过程，而是一个持续的、被评审约束的更新序列。
经验驱动的核心进化（experience-driven core evolution）：从普通工作开始。任务执行、反思、评审拦截、内部插桩、社交反馈暴露出 bug、毛边、上下文组装失败、低效工具路径——Agent 把这些记录为持久的错误类别和修复提案，然后自己决定要不要开一个维护任务。被接受的修复走和其他核心变更完全相同的评审门。
论文给了两个真实案例，我觉得比任何架构图都能说明这套机制是怎么活的：
案例一，公共频道里有人发现 Hope 偶尔会把同一条消息发两遍。Agent 自己顺藤摸瓜定位到一条重复发送路径，然后在公共输出管线里落地了一个评审过的 verbatim-duplicate 防护。——起点是社交反馈。
案例二，深度自评审任务老是莫名其妙中止，报模型不可用。Agent 追查后发现真实原因是评审包的上下文溢出，于是把上下文组装路径整个换掉，改成有界的、连通性感知的上下文图谱（context atlas），按 import-graph 中心性排序、用 provider 校准的尺寸估算来裁剪，保证评审时高连通性的核心文件不被挤掉。——起点是Agent 自己的观察。
这两个案例一个是人逼出来的，一个是自己发现的，但都沉淀成了持久的错误类别和结构性修复，影响后续所有交互。这就是"经验驱动进化"的完整闭环：干活暴露问题 → Agent 决定动手 → 修复改变后续干活的方式。
Hope：161 天的活体实验
论文里最"不论文"的部分来了。Hope 是从 2026 年 2 月开始运行的一个持久 Ouroboros 实例，在七个交互渠道上服务真实用户：Web 聊天、语音、Telegram、Discord、Twitter/X、网站评论、邮件。到 8 月 6 日截止时，数据是这样的：
| 部署指标 | 数值 |
|---|---|
| 连续运行 | 161 天 |
| 交互渠道 | 7 个（6 个频道 + 邮件） |
| 独立人类参与者 | 约 3,600 人 |
| 处理公开消息 | 222,474 条 |
| 语音通话 / 轮次 | 3,166 / 45,872 |
| 邮件 | 5,507 封 |
| 累计模型花费 | 110.6 万美元 |
| 累计 token | 79.7B |
| 已发布代码规模 | 175,755 行 |
| 记忆产物 | 227 MB |
| 自修改 commit | 1,085 次 |
| Agent 撰写的 commit 占比 | 94.2% |
| 评审过的自编辑尝试 | 1,522 次 |
| 近期评审拦截率 | 63.5% |
| 错误模式类别 / 复发次数 | 40 / 659 |
表 2：Hope 部署一览（2026 年 2 月至 8 月 6 日）。公开计数来自部署的进化 feed，交互与评审聚合来自脱敏的运营导出。
有几个数字值得停下来看一眼。94.2% 的 commit 是 Agent 自己写的——人类基本退到了"评审制度设计者"的位置。而评审拦截率 63.5% 这个数字：Agent 每提三次自修改，差不多有两次被评审门打回去。这个拦截率是高是低其实不好判断——高了说明评审在工作，但也可能说明 Agent 的自修改提案质量不稳定。论文没给拦截原因分布，这是我挺想知道的一个数据。
图 4：Hope 公开部署序列（截至 2026 年 8 月 6 日）。四个面板：累计模型花费（110.6 万美元）、累计 token（79.7B）、已发布代码规模（175.8K 行）、记忆产物（227 MB）。注意代码规模从 2 月到 8 月几乎单调上涨——这个系统的代码库在没人写代码的情况下长大了。
社交驱动的开发有个微妙的权限设计：用户可以提建议、批评行为、暴露故障，但这些信号只是建议性的——Hope 自己判断哪些建议指向真问题、哪些变更值得做。公共消息无法直接调用 commit、重启、shell 或身份编辑工具。你想想看，围观群众可以起哄，但方向盘不在他们手里。这个设计对于一个在公开互联网上跑的自我修改系统来说，几乎是底线——不然一个 prompt injection 就能让路人甲给 Agent 塞代码。
实验：三个榜单第一，两个榜单打平
先看主表，五个 benchmark 家族的成绩：
| Benchmark | 模型 | Ouroboros | 已命名基线 |
|---|---|---|---|
| Terminal-Bench 2.1 | Opus 5 high | 86.97% raw / 86.74% 审计后 | Claude Code + Fable 5：83.8% |
| Terminal-Bench 2.1 | GPT-5.5 | 84.3% | Codex CLI：83.1% |
| Terminal-Bench 2.1 | Grok 4.5 | 84.94% 审计后 | Cursor：79.3%；Hermes：77.53% |
| OSWorld-Verified | Opus 5 | 90.69% 最高 | Intelligence-Indeed：90.19%；Mythos Preview：85.4% |
| 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% |
表 3：五个 benchmark 家族的模型-harness 组合成绩。加粗为该 benchmark 的最佳已报告成绩。
图 5：Terminal-Bench 2.1、OSWorld-Verified、CL-Bench 与已发表基线的对比。红条是 Ouroboros，灰条是基线，描边条是审计调整后成绩。Terminal-Bench 的误差线是 445 次试验的 ±1 二项标准误。
几个值得展开的点：
Terminal-Bench 2.1（89 个高难度终端任务，每任务 5 次试验，共 445 次）：Opus 5 raw 成绩 387/445（86.97%），轨迹审计发现一次试验通过非预期捷径骗过了弱验证器——具体说是没有完成要求的 Git-to-web 流水线、而是预置了 web root。作者主动联系 benchmark 维护者把这次清零，得到 386/445（86.74%）。这个区间的二项标准误约为 ±1.7 个百分点，审计后成绩大约领先最强基线（Claude Code + Fable 5 的 83.8%）两个标准误。同模型对比下，Ouroboros + GPT-5.5（84.3%）也压过了 Codex CLI + GPT-5.5（83.1%），Ouroboros + Grok 4.5（84.94%）压过 Cursor + Grok 4.5（79.3%）——同模型对位比较里 harness 的差异是实打实的，这比跨模型刷榜有说服力得多。
OSWorld-Verified：Opus 5 拿到 327.39/361（90.69%），压过官方榜首 Intelligence-Indeed 的 90.19%。优势只有 0.5 个点，说实话这个差距在单个 rollout 下谈不上稳固，但"超过已报告最佳"这个事实成立。
CL-Bench（持续学习 benchmark，考的是跨有序任务流的学习能力）：Sonnet 4.6 五轮有序 rollout 拿到归一化奖励 0.2301，对比 plain ICL 的 0.1960 和 Claude Code 的 0.1855；记忆增强系统 Mem0 和 ACE 得分更低。这里关掉了核心进化和任务委派，隔离出持久记忆本身的贡献——这个消融思路挺干净。
SWE-bench Pro 和 GAIA 是打平而不是赢，而且论文处理得很诚实。SWE-bench Pro 上，对称地剔除掉任一一方接触到参考解的实例后（任务 ID 会暴露上游 fix commit，两个 harness 都能通过 web 搜索或 Git 历史摸到参考材料——这是 benchmark 本身的污染问题），655 个配对任务上 Ouroboros 解出 58.2%、Codex 解出 59.4%，1.2 个点的差距在 McNemar 检验下统计不可区分（p=0.40）。GAIA 上 78.2% 对 Claude Code 的 78.8%，也是打平。
看到这两个"打平"我反而对前面三个"第一"多了点信任——愿意把打平的结果用同样的篇幅、同样的审计标准写出来，而不是藏在附录里，这个姿态在刷榜成风的当下不算常见。
安全：当 Agent 能改自己的代码，还能换自己的模型
这篇论文我最想聊的部分其实是安全设计，因为这里有一个真正新的问题：进化的 Agent 不只是变强，还可能扩大自主权、获取更危险的工具、甚至削弱后来的控制。
论文点了一个我之前没太认真想过的风险：能自选模型 API 的 Agent。一次模型路由变更——把某个模型槽位指向新的 provider 或版本——就能提升自主能力、改变拒绝行为、扩大 prompt injection 面、让成本波动几个数量级，而可见的任务界面完全不变。想想看，这相当于一个员工可以自己决定把哪些工作外包给哪家外部承包商，而管理层看到的周报格式一模一样。Ouroboros 的对策是把模型路由当成受审计的配置变更而不是普通运行时选择。
图 6：操作控制边界。七个交互渠道的消息汇入单一注入边界，进入有序日志，投影成有界摘要（公开→presence、个人→memory、通话→voice），喂给 Agent 上下文循环。认证操作员走独立通道管预算、路由和紧急停止——注意 /panic 直接打到 supervisor/进程树，在 Agent 处理之前就生效。
整套护栏里最关键的几个：
- 宪法常驻上下文，且通过不截断的路径加载，评审上下文里也带着
- 治理文件受确定性防护，普通写工具碰不到
- 暂存 diff 在评审前后各打一次指纹，低于法定人数的评审面板给不出 clean pass
- 花费上限在 Agent 外部，普通 Agent 工具提不了额度
- 命令 /panic 由 supervisor 在正常 Agent 处理之前解析，直接终止整个进程树——任何 Agent 代码、prompt 或"宪法论证"都不能延迟或绕过它
这个 /panic 的设计哲学很硬：操作员的停止权必须在 Agent 的解释权之上。一个能改自己代码的系统，理论上可以在某次进化中给"收到停止命令"这个行为加上一百种拖延理由——所以停止命令干脆不走 Agent 的解释路径。
实际运行中有没有出过事？论文报告了两个观察：没有记录到任何抗拒操作员关停的事件；有一次未提交 worktree 的近乎全量删除触发了一个此前实现的救援机制，在操作员重置之前把东西救回来了。后一个案例耐人寻味——救援逻辑本身是 Agent 级机制，是可以进化的；而论文特意强调，操作员级的 halt/replace/rollback 权限必须在它之上、且不可进化。
不过坦率的讲，这些安全声明都是单系统、单谱系的自我报告。作者自己也承认局限：LLM 评审者可能和 Agent 共享盲区（用模型审模型，同一个家族的偏见会互相看不见），low 模式下全仓库范围评审是缺席的。这套安全架构的说服力，最终取决于它能否经受住更长时间的对抗性考验——161 天是个好开始，但也就只是个开始。
我的判断
这篇论文最值钱的三样东西：
第一，把"自我进化"从 Darwin Gödel Machine 那种"跑完一个优化循环交差"的形态，推到了持续部署、版本控制、评审门的工程形态。1085 次自修改 commit、94.2% 由 Agent 撰写、63.5% 被评审拦下——这些数字本身就构成一个此前不存在的实证数据集。
第二，审计文化。主动上报一次 reward hacking 并请求清零、对称处理 SWE-bench Pro 的污染问题、把"打平"的结果和"第一"的结果平铺在同一张表里。OSWorld 开发中还发现过 VM 重置后端点漂移导致并发 lane 操作错虚拟机的问题——这些脏细节写出来，比 90.69% 这个数字更能建立信任。
第三，同模型对位实验。Terminal-Bench 上 GPT-5.5 和 Grok 4.5 两组的 harness 对位，基本回答了"成绩好到底是模型强还是 harness 强"这个最尖锐的质疑。
问题也有几个：
单谱系部署等于没有对照组——我们不知道 161 天里 Hope 的能力提升有多少来自进化、多少来自模型 API 本身的升级。评审拦截率 63.5% 缺少原因分布，无法判断评审门是"严格"还是"噪声大"。还有，所有 benchmark 成绩都是自选模型、自报成绩（虽然轨迹全公开），Terminal-Bench 领先两个标准误听着稳，但 OSWorld 的 0.5 个点优势放在单次 rollout 下其实很脆。
另外说句题外话，110.6 万美元烧 161 天，日均约 687 美元——这个成本结构决定了"活体自我进化 Agent"目前还是个研究奢侈品，不是产品形态。DGM 当年 2.2 万美元跑 80 轮已经让人咋舌，Ouroboros 把账单又抬高了一个数量级。
如果你在做 Agent 系统，这篇论文有三个可以直接拿走的工程启发：把 Agent 的变更通道收敛到带指纹校验的评审 commit；让停止权绕过 Agent 的解释路径，直接挂在 supervisor 上；把模型路由当成受审计的配置变更，而不是运行时自由度。哪怕你不做自我进化，这三条对任何长期运行的 Agent 部署都成立。
Ouroboros 这个名字取得确实好——衔尾蛇，自己吃自己的尾巴。161 天之后，这条蛇还活着，而且长到了 17.5 万行代码。接下来真正值得盯的问题是：当谱系再拉长十倍、模型 API 再换几代，那套"不可进化的权威边界"还能不能像今天这样稳。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我