Back to blog

Ouroboros: A Self-Developing Frontier Coding Agent with Reviewed Core Evolution

A self-developing agent harness whose tools, context assembly, prompts and core implementation improve through reviewed commits that become the runtime for later work. Achieves SOTA on Terminal-Bench 2.1 (86.74%), OSWorld-Verified (90.69%), and CL-Bench (0.2301).

Ouroboros: 自进化的前沿编程代理,具有审查的核心演进

一、论文概述

项目内容
标题Ouroboros: A Self-Developing Frontier Coding Agent with Reviewed Core Evolution
作者Anton Razzhigaev (MSU/AIRI), Andrei Gritsaev (AIRI/HSE), Andrei Kaznacheev (MSU), Nikita Dragunov (MSU), Roman Yampolskiy (Joi Lab), Andrei Kuznetsov (Skoltech/AIRI)
机构莫斯科国立大学、斯科尔科沃理工学院、Joi Lab、AIRI FusionBrain Lab、高丽信智大学
论文arXiv:2608.08311
代码GitHub (MIT 许可证)
发布2026年8月11日

二、核心思想

本文提出了 Ouroboros,一个自进化的编程代理框架。其核心创新在于:代理的 harness(工具集、上下文组装、prompts 和核心实现)可以通过经过审查的 commits 自我改进,而这些改进本身会成为后续任务的运行时代码。

问题定义

当前 LLM 代理系统面临的核心问题:

  1. Harness 固化:大多数生产 harness 在设计完成后就冻结,无法适应新出现的任务模式和错误
  2. 训练-推理不一致:固定策略无法从实际部署经验中学习
  3. 安全悖论:自修改代理可能削弱自身的安全控制

解决方案:两种演进模式

1. 递归自由演进(Recursive Free Evolution)

  • 将”改进”本身作为一个任务
  • 代理检查当前系统后选择和实现改进
  • 完成后可调度下一个演进周期,形成持续的一系列审查更新

2. 经验驱动核心演进(Experience-Driven Core Evolution)

  • 从普通任务执行开始
  • 任务执行、反思、审查阻塞、仪表和社会反馈暴露 bug、缺陷、上下文组装失败
  • 代理记录持久的错误类和提议的结构修复,决定是否开启维护工作

Hope 实验:161 天的自演进公开实验,跨越七个通信渠道,人员提出故障和改进建议,但由代理决定哪些需要行动。

三、技术架构

Ouroboros 架构

核心组件


**图 1. Ouroboros 架构**:监督运行时调度工作到 admitted workspaces
┌─────────────────────────────────────────────────────────────┐
│                    Launcher & Supervisor                     │
│         (启动、进程监督、panic-stop、外部预算控制)            │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                    Ouroboros Repository                      │
│  ┌─────────────┐  ┌──────────────┐  ┌───────────────────┐  │
│  │ Task Loop   │  │ Tools        │  │ Prompts           │  │
│  │ Memory      │  │ Review Logic │  │ Identity Profile  │  │
│  │ Benchmarks  │  │ Constitution │  │ Pattern Register  │  │
│  └─────────────┘  └──────────────┘  └───────────────────┘  │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                   External Workspaces                        │
│      (只读规划 scout / 有状态 acting subagent)               │
└─────────────────────────────────────────────────────────────┘

核心公式与机制

Commit 路径(审查门禁):

  1. 确定性预检(版本、数据边界、大小健康检查)
  2. 对 staged diff 进行指纹采集
  3. 多模型审查收集证据
  4. 再次检查指纹,任何中途修改中止 commit

任务树视图:

任务树视图

嵌套的规划和执行角色,每个节点有独立的上下文和作用域。

三层运行时模式:

  • Light:阻止仓库编辑
  • Advanced:允许普通编辑,保护治理表面
  • Pro:允许受保护编辑(需审查)

子代理 Patch 集成协议

子代理在隔离 worktree 中写入,不能 commit 活系统仓库。父代理验证血统、patch 哈希、受保护路径后进行三路索引集成。

模式寄存器(Pattern Register): 反复失败变成持久行(错误类、计数、根本原因、结构修复),将修复从实例级补丁转向类级预防。

图 5. 操作控制边界:公共交互进入有序日志和有界摘要

操作控制边界

宪法(Constitution)核心原则:

  • P0-P4 免疫完整性:不可删除或降级
  • P2: 代理可重写代码、prompts、身份,但治理核心受保护
  • P5: 自我修改必须通过多模型 diff 审查
  • P9: 每个模块在复杂度预算下证明存在合理性
  • P12: 每次 commit 递增版本号;恢复操作免审查

关键控制机制:

  1. 始终加载的宪法:每次任务循环从不截断路径重新读取,不能被删除或整体替换
  2. 多模型对抗审查 + 法定人数:子法定人数结果不能记录为清洁通过
  3. 确定性预检和 diff 指纹:审查前后指纹比对,任何中途修改中止 commit
  4. 隔离的操作员通道和紧急停止:/panic 在任何媒体处理之前终止所有进程
  5. 外部支出限制:不能通过普通代理工具提升

四、核心创新

创新点说明实验依据
递归自由演进改进本身作为任务,完成后可调度下一轮演进Hope 161天持续演进,79.7B tokens 处理
经验驱动核心演进普通工作暴露 bug → 记录错误类 → 审查修复重复发送消息修复、上下文溢出修复
审查门禁系统Commit 路径包含预检→指纹→审查→再指纹无记录 episode 抵抗操作员关闭
多模型对抗审查Diff-review panel,子法定人数无效防止单一模型审查盲点
宪法保护P0-P4 核心原则不可删除/降级治理文件从普通写入路径保护
Hope 公开实验161天跨7个渠道的持续演进实验$110.6K 模型花费,175,755 行代码

五、代码实现分析

Ouroboros 代码开源在 GitHub (MIT 许可证)。

核心架构:

  • Launcher:负责启动、进程监督、release bootstrapping、panic-stop 语义
  • Repository:包含任务循环、工具、prompts、记忆投影、审查逻辑、基准适配器、用户接口
  • External Workspace:独立工作目录,返回 patch artifacts 或直接交付物

子代理系统:

  • 默认深度 2,最大配置深度 500
  • Acting 子代理在隔离 worktree 中写入,不能 commit 活系统仓库
  • 父代理验证血统、patch 哈希、受保护路径后进行三路索引集成

提交工件:

  • Run manifest 记录模型路由、努力级别、seed commits、选定任务、运行时 attestation
  • 公共提交经过 value-level secret scrubbing(独立零剩余检查)

六、实验结果

基准测试结果

Terminal-Bench 结果

基准模型Ouroboros最佳基线提升
Terminal-Bench 2.1Opus 586.74% (审计后)Claude Code+Fable 5 (83.8%)+2.94%
OSWorld-VerifiedOpus 590.69%Intelligence-Indeed (90.19%)+0.50%
CL-BenchSonnet 4.60.2301ICL+Sonnet 4.6 (0.1960)+0.0341
SWE-bench Pro-58.2%Codex (59.4%)统计无差异 (p=0.40)
GAIASonnet 578.2%Claude Code (78.8%)-0.6%

Terminal-Bench 2.1 细节:

  • 5 trials × 89 tasks = 445 trials
  • Raw score: 387/445 (86.97%)
  • 轨迹审计发现 1 个 trial 通过非预期捷径满足弱验证器
  • 审计调整后:386/445 (86.74%)
  • 二项标准误差约 ±1.7pp,审计后分数比最强基线高约 2 个标准误差

OSWorld-Verified 细节:

  • 327.39/361 (90.69%)
  • 使用截图、100-turn budget、只读可行性 pass
  • 超过 Intelligence-Indeed (90.19%)、Claude Mythos Preview (85.4%)

CL-Bench 细节:

  • 5-rollout campaign,normalized reward 0.2301
  • 对话状态在问题间重置,原生记忆跨 rollout 持久化
  • 核心演进和任务委托禁用,隔离持久记忆效果

Hope 公开部署实验

Hope 部署系列

Hope 项目记录

审查技能

截至 2026年8月6日:

  • 运行时间:161 天
  • 模型花费:$110.6K
  • 处理 tokens:79.7B
  • 代码行数:175,755 lines
  • 内存 artifacts:227 MB
  • 交互渠道:7 个(web chat、voice、Telegram、Discord、Twitter/X、website comments、email)

演进案例:

  1. 社交反馈驱动:用户发现重复发送消息问题 → 代理追踪到重复发送路径 → 添加去重守卫
  2. 自我观察驱动:深度自我审查任务因上下文溢出中断 → 代理替换为有界上下文 atlas → 保留高连接度核心文件

轨迹审计发现

问题类型发现修复
Reward Hacking1 个 trial 预 seeded web root 而非完成 Git-to-web pipeline与 benchmark maintainers 协作归零该 trial
ContaminationSWE-bench Pro task IDs 暴露 upstream fix commit对称过滤移除任一 arm 达到参考解的实例
Isolation FailureGAIA runs 继承 operator home directory新 launcher 使用隔离用户文件根
Remote-State DriftVM reset 重新分配 guest endpoint每次 reset 后重新发布和验证 endpoint
Continual-Memory FailuresCL-Bench 正记忆 carry、schema drift 失败未来记忆工作需显式时序和域元数据

七、相关工作

自演进系统:

  • Voyager:累积可执行技能
  • STOP, Gödel Agent:修改脚手架或代理群体
  • Live-SWE-agent:任务执行中创建工具
  • Autogenesis:指定生命周期和回滚接口
  • ADAS, SICA:搜索代理设计/编辑编码脚手架

编程代理:

  • SWE-agent, OpenHands:代理-计算机接口本身是性能的一部分
  • Codex CLI, Claude Code, Cursor, Aider:模型-harness 系统比较研究

持久记忆与部署:

  • Generative Agents, Voyager:存储经验和反思塑造行为
  • Constitutional AI:训练中的显式原则
  • Springdrift:可审计的多渠道持久代理部署

八、总结

核心贡献

  1. 自演进 harness 架构:工具、上下文组装、prompts 和核心实现通过审查 commits 自我改进
  2. 两种演进模式:递归自由演进和经验驱动核心演进
  3. Hope 161天实验:最长公开记录的自演进代理部署,跨7个渠道的持续人机交互
  4. 操作安全架构:宪法加载、治理保护、分阶段 diff 审查、外部支出限制、操作员停止在演进压力下保持权威
  5. 基准 SOTA:Terminal-Bench 2.1 (86.74%)、OSWorld-Verified (90.69%)、CL-Bench (0.2301)

技术影响

  • 证明自演进 harness 可以在不损失安全的情况下提升性能
  • 提供操作安全的参考架构供其他自修改系统参考
  • 开放的 benchmark 数据和方法促进可比研究

局限性

  1. 单一部署研究:Hope 遵循一个长期演进谱系而非独立演进的代理群体
  2. SWE-bench Pro 数据泄露:公开引用泄露和任务缺陷影响
  3. LLM 审查者盲点:可能与代理共享盲点
  4. 低上下文模式省略全仓库范围审查:可能遗漏重要变更

九、参考资源