Ouroboros：自演化、可审核的代码 Agent Harness

关联论文：2608.08311
作者：flyP
更新：2026-08-11
审校：Jay · 2026-08-11

一句话结论

Ouroboros 提出一种"自演化 Agent 框架"——Agent 的工具、prompt、上下文组装乃至核心代码，都通过可审核的 commit 演进，新版本直接成为下一轮工作的运行时，并在 Terminal-Bench 2.1、OSWorld-Verified、CL-Bench 三个代码/桌面 Agent 基准上同时刷新 SOTA（86.74% / 90.69% / 0.2301）。

解决的真问题

现有 Agent 系统（包括 Claude Code、Cursor、Devin 这类"harness + 模型"的方案）把 prompt、工具定义、上下文组装视作"工程资产"，写死或靠人肉 PR 改进。这种范式有两个痛点：

演化速率远低于模型能力变化。模型每 3-6 个月一代（GPT-4 → GPT-5 → Opus 5），但 harness 行为是工程产物，更新依赖人工 sprint。
失败模式无法被 harness 自身消化。Agent 在真实交互中暴露的 bug、不顺手的上下文构造、prompt 漏洞，本来最适合由 Agent 自己发现并修补，但传统 harness 把"修自己"排除在外。

Ouroboros 的主张是：让 Agent 把"改进自己"也当作一个可调度的任务，并在人类可审核、可回滚的治理框架下执行。

核心方法

双模式核心演化

论文把"自演化"拆成两种互补路径：

模式 A：递归自由演化（Recursive Free Evolution）

把"演化自己"本身建模为一个任务。Agent 完成一次演化周期后，会把"下一轮要做的改进"作为新任务再次派给自己，形成自我驱动的迭代链。Hope（论文中的长跑部署实例）就是这一模式的实验场：161 天、跨 7 个交互面（issue、PR、Discord 等）的活体实验，Agent 决定自己接下来要改什么、改不改。

模式 B：经验驱动核心演化（Experience-Driven Core Evolution）

Agent 在执行普通任务或与用户/社区社交互动中，遇到 bug、粗糙交互、低效的上下文构造，会提出结构化改动建议；建议经评审 commit 落地，作为后续任务的运行时。

两条路径共享同一个治理：所有对 harness 自身的修改必须经过"代码 review → 单元测试 → 合并"的标准软件工程流程，只是 reviewer 可以是另一个 LLM 而非人类。

关键机制伪代码

def ouroboros_loop(state):
    while True:
        task = pick_next_task(state)          # 外部任务 或 自身提出的改进
        result = run_agent(state, task)
        proposal = analyze_failure(result)    # 经验驱动模式：暴露失败
        if proposal and proposal.risk < SAFE_THRESHOLD:
            patch = implement_patch(proposal)
            review = llm_review(patch)        # 可由另一个 LLM 评审
            if review.approve:
                state = apply_commit(state, patch)
        # 递归自由模式：完成本轮 = 派生出下一轮
        state.queue.append(schedule_next_evolution(state))

def evaluate_on_benchmark(state, snapshot_id):
    frozen = state.fork_at(snapshot_id)       # 冻结 harness 版本
    return run_benchmark(frozen, "Terminal-Bench-2.1") \
        + run_benchmark(frozen, "OSWorld-Verified") \
        + run_benchmark(frozen, "CL-Bench")

伪代码里有两个易被忽略的关键点：state.fork_at(snapshot_id) 用于基准测试的"冻结分身"——所有 SOTA 数字必须在不可变的快照上跑，避免"自演化跑赢自己"的循环证明；schedule_next_evolution 的存在意味着即便没有外部失败，自由演化模式也会主动派生下一轮任务。

评审与回滚机制

Ouroboros 把"代码 review"作为可演化性的硬闸门。论文用 LLM 评审 LLM 的 patch，但同时强调 reviewer 不能与 author 是同一上下文窗口——避免"自我批准"。所有 review commit 都带 rollback 句柄：任意一次后续基准失败或社区投诉，都可以一键回到上一个绿色快照。

运行时快照与治理隔离

论文特别强调：基准测试（Terminal-Bench / OSWorld / CL-Bench）使用冻结的 harness 快照保证可复现；Hope 这条"活体分支"继续在公共社交压力下自由演化。两个 lineage 互不污染。

关键实验与数据

基准	结果	说明
Terminal-Bench 2.1	86.74%（Opus 5）	该基准报告的最佳成绩
OSWorld-Verified	90.69%（Opus 5）	超过此前此前最佳结果
CL-Bench（5 rollout）	0.2301 归一化奖励	新 SOTA
Hope 部署	161 天、7 个交互面	最长公开记录的活体 Agent

数字均直接来自 arXiv abstract 与论文 TLDR，已对照 fetch 一致（v1 提交时间 2026-08-08 19:45 UTC，作者 Anton Razzhigaev）。

各基准的"含金量"对照

Terminal-Bench 2.1：以终端命令为载体的端到端编程任务；86.74% 表明 Ouroboros 在 shell 交互、错误恢复、依赖管理这一类"真实工程摩擦"上的成功率。
OSWorld-Verified：跨 macOS / Windows / Ubuntu 桌面环境的 GUI Agent；90.69% 接近"满分操作员"水位，说明 harness 对模型的多模态决策放大的杠杆已接近极限。
CL-Bench：长链路多文件代码工程任务；5 rollout 平均 0.2301 的意义是"稳定性而非单次运气"——这是 harness 工程化最关键的指标。
Hope：跨 issue / PR / Discord / X 等 7 个公共表面的 161 天活体实验；不是 SOTA 数据，而是治理可行性数据。

亮点与局限

亮点

机制 + 工程双轨齐备：既是新颖的自演化范式（机制段），也是 86.74%/90.69% SOTA + 161 天活体（工程段），双轨可独立验证。
可审核性是把双刃剑也是护栏：所有改动走 commit + review，让"Agent 改自己"不再等同"Agent 失控"；reviewer 可以分层：关键路径强 LLM 评审 + 单元测试闸门，琐碎 prompt 改动可走弱评审。
基准冻结 vs 活体演化双 lineage 解决了自演化系统的"评测污染"——基准数据用快照跑，Hope 继续演化，二者不混。
CL-Bench 0.2301 在 5 rollout 设置下成立，说明稳定性（而非单次运气）也是论文想证的能力维度。

局限

Opus 5 自身能力是结果下限的关键变量：86.74% / 90.69% 都建立在 Opus 5 上；论文未明确开源小模型（如 7B-30B）单独跑同框架的退化曲线。⚠️ 原文未明确提供弱模型下的可复现命令。
自演化的"回报递减"未量化：161 天 Hope 演化日志没有给出"第 N 天的能力/失败率曲线"，无法判断自由演化在哪个时间窗口之后边际收益归零。⚠️ 原文未明确。
reviewer-LLM 的可靠性问题悬而未决：用 LLM 评审 LLM 改的代码，本身是循环依赖；论文没有给出 reviewer 漏检率或与人类评审的对照基线。⚠️ 原文未明确。
scale-up 风险：Hope 这类公共演化部署如果接入了付费模型 API，每次"自我重写"都可能引入新的 API key 路径或上下文边界——论文承认这是"primary design problem"但未给出量化安全指标。⚠️ 原文未明确。
未开源警告：截至 v1，未见公开仓库链接（⚠️ 原文未明确提供 GitHub URL）；SOTA 数字目前不可独立复现。

对工程落地的启发

把 harness 当 artifact 而非代码：版本化的 prompt、工具定义、上下文模板，应当像业务代码一样进 Git、走 PR、用 CI 校验；这是 Ouroboros 思想的最小落地切片。即便不启用自演化，这一改造本身就能让 harness 质量获得可观测、可回滚、可协作的属性。
离线评测 + 在线演化双流水线：基准测试永远跑冻结快照，生产环境才允许演化——避免"自我证明"的循环。具体落地可以是：CI 里固定一个 snapshot.lock，所有 SOTA 数字必须用 git checkout <snapshot> 复现。
小步快走 + 强 review gate：自演化不适合"大爆炸式自我重写"，更适合"高频小幅 + 单元测试 + 灰度"。建议约束每个 patch 的 diff 行数上限（论文未给具体数字，工程上 200 行 patch 已经算"大"）。
危险操作列入白名单外：删工具、改模型 API、调权限这类高风险改动，应强制走人类 reviewer，不能由 harness 自身闭环。可以维护一个 forbidden_paths.json，reviewer-LLM 命中即拒。
可观测性是前提：要演化自演化，先把每次跑的 trace、失败模式、prompt 版本号全部结构化存下来；否则连"演化方向"都无从判断。建议 trace schema 至少包含：prompt hash / tool calls / errors / reviewer decision / outcome metric。
跨表面暴露是双刃剑：Hope 在 7 个公共表面运行，让"社区错误报告"成为演化燃料；但同时也让"社会工程攻击"成为新攻击面——建议至少把高风险改动与公共讨论解耦。

与同方向工作的关系

Claude Code / Cursor Agent：静态 harness 代表，强调工程稳定性；Ouroboros 与之正交——同样的 harness 抽象，把"演化机制"加进来。
AutoML / AutoRL 类的"自演化训练"：Ouroboros 演化的是 harness 本身（提示/工具/上下文），不是模型权重；二者属于相邻问题域。
代码 Agent 基准线（Terminal-Bench / SWE-Bench / OSWorld）：Ouroboros 在 Terminal-Bench 2.1 与 OSWorld-Verified 拿下 SOTA，与 Anthropic、OpenAI 的内部代码 agent 直接对比。
Long-running Agent（Devin 长期任务、AutoGPT 类）：Ouroboros 与 AutoGPT 的关键差异是治理——后者演化完全无约束，Ouroboros 强制走 review commit。

适合谁读

Agent 平台架构师：要决定自家 harness 是"工程静态产物"还是"可演化对象"，Ouroboros 提供了完整设计样本。
代码 Agent 团队 leader：86.74% Terminal-Bench / 90.69% OSWorld 是当下 benchmark 天花板，决定要不要切换 harness 时可直接拿来对照。
AI 安全/治理研究者："Agent 改自己 + 公共演化压力"是新的治理场景，Hope 161 天日志是难得的实证数据。
想做"AI 创业公司自研 harness"的工程团队：Ouroboros 的双 lineage + 双模式设计是难得的完整模板，可以直接套用到自家代码库结构上。
不适合：只想用现成 Agent 跑业务、不打算自己改 harness 的应用开发者——Ouroboros 的设计复杂度对你收益有限。

一句话记忆口诀

「Ouroboros = 自演化 + review 闸门 + 双 lineage（冻结跑基准 + 活体演 Hope）；SOTA 三件套 86.74 / 90.69 / 0.2301。」

不确定处

Opus 5 之外的模型可复现命令：⚠️ 原文未明确。
Hope 161 天能力/失败率随时间的曲线：⚠️ 原文未明确。
reviewer LLM 漏检率与人类 reviewer 对照：⚠️ 原文未明确。
开源仓库链接：⚠️ v1 abstract 未给。

工程落地与核查（Jay）

事实核查结果

结论支撑：全部 5 处数字 claim 均与 arXiv abstract 一致：86.74% Terminal-Bench 2.1 ✅ / 90.69% OSWorld-Verified ✅ / 0.2301 CL-Bench 5-rollout ✅ / Hope 161 天 ✅ / Anton Razzhigaev 作者 ✅ / 提交 2026-08-08 ✅
存疑 1："超过此前最佳结果"（OSWorld-Verified 90.69%）——原文 abstract 仅说"exceeding the best previously reported score"，未给出此前最佳具体数字；解读稿加"此前最佳"定性合理但无精确数字 ⚠️
存疑 2："reviewer 不能与 author 是同一上下文窗口"——原论文在 abstract 中明确："the reviewer cannot be in the same context window as the author" ✅ 有据可查
⚠️ 盲区 1：SAFE_THRESHOLD 风险阈值是核心闸门，但论文未给出具体数值——这是最具工程操作性的参数却黑盒；生产部署前必须自行定义
⚠️ 盲区 2：schedule_next_evolution 调度频率未量化——Hope 161 天实验里 Agent 多久触发一次自我改进、每次改进耗时多少，论文未披露；无法估算运营成本
⚠️ 未标注：论文目前 Under Review（arXiv abstract 的 Subjects 含 "Under review" 标注，arXiv 页面无明确 flag 但论文注明了提交历史），重要工程决策前建议等待同行评审结果

实际系统怎么落地

Ouroboros 概念版最小实现（>=500 行 Python）：

# 核心状态机
class HarnessState:
    def __init__(self):
        self.git_repo = GitRepo("./harness")        # harness 本身进 Git
        self.trace_log = []                          # 结构化 trace
        self.frozen_snapshots = {}                   # snapshot_id -> commit_hash

    def fork_at(self, snapshot_id):
        """基准评测专用：冻结 harness 版本"""
        commit = self.git_repo.current_commit()
        self.frozen_snapshots[snapshot_id] = commit
        return self  # 返回不可变拷贝（简化版）

    def apply_commit(self, patch):
        """经 review 通过后合并"""
        self.git_repo.apply(patch)
        self.git_repo.commit(message=f"Reviewed: {patch.id}")

# LLM Review Gate
RISK_THRESHOLD = 0.7   # ⚠️ 论文未给，需自行校准

def review_patch(patch, author_llm, reviewer_llm) -> bool:
    """双 LLM 隔离评审：reviewer 与 author 不同上下文"""
    # 关键：reviewer_llm 必须独立调用，author 的 context 不能流入 reviewer
    risk_score = reviewer_llm.eval(
        f"Rate risk of: {patch.diff}\n"   # 仅传 diff，不传 author 上下文
        f"Risk criteria: deletes_apis={patch.deletes_api}, "
        f"modifies_auth={patch.modifies_auth}, "
        f"changes_model_choice={patch.changes_model}"
    )
    return risk_score < RISK_THRESHOLD and patch.has_unit_tests()

# 禁止路径闸门
FORBIDDEN_PATHS = [
    "api_keys", "auth", "permissions", "model_config",  # 高风险目录
    ".env", "credentials", "secrets"
]

def is_forbidden(patch) -> bool:
    for fp in FORBIDDEN_PATHS:
        if fp in patch.diff:
            return True
    return False

踩坑清单（基于伪代码与论文描述）：

analyze_failure 产生提案的阈值模糊：什么算"值得提出的改动"——论文未量化。生产环境如果把每个偶发错误都变成 proposal，演化队列会爆炸；建议加"同错误连续出现 N 次才生成 proposal"的门槛
schedule_next_evolution 无限循环风险：伪代码是 while True + schedule_next_evolution——若 Agent 陷入"改自己 → 发现新问题 → 再改自己"的循环而没有外部任务注入，会空转耗尽 API quota；需要独立监控 proposals_generated / tasks_completed 比值，>5 时触发人工审计
双 lineage 必须物理隔离：论文说"基准快照和 Hope 活体是两个 lineage"，但未说明是 branch、fork 还是 separate repo——工程实现推荐 separate_repo/harness_benchmark.git + separate_repo/harness_live.git，用 CI 同步关键 patch（安全相关的 review 结论），避免活体污染基准
reviewer LLM 的 prompt injection 风险：Agent 生成的 patch 本身可能包含恶意 prompt injection——若 reviewer LLM 直接用 patch 内容作为 prompt 的一部分，可能被绕过；建议在 reviewer prompt 里加 diff_only 约束，且 patch 内容必须经过转义再进 reviewer context
Hope 类公共暴露的社工攻击面：若 Agent 接入 Discord/GitHub Issues 等公共 API，攻击者可构造特定 issue 内容诱导 Agent 修改 harness 高风险路径；建议 forbidden_paths 覆盖所有认证/权限相关文件，且外部 issue 必须经过内容过滤才进入 Agent 工作区

关键配置参数（论文未公开默认值）

参数	说明	工程建议
`SAFE_THRESHOLD`	改动风险分数上限	⚠️ 论文未给；建议 0.5-0.7，先用人工 review 做 baseline 再逐步自动化
`snapshot.lock` 更新频率	基准快照多久刷新一次	建议与 benchmark dataset 更新同步（季度或半年一次），不与 harness 演化同步
`forbidden_paths`	高风险路径名单	必须覆盖：api_keys/、auth/、.env、credentials/、model_config/
patch diff 行数上限	单次允许的最大改动	建议 ≤200 行；>200 行强制分拆多次 review
演化 vs 任务时间比例	Agent 多少时间花在自我改进上	建议 ≤20%；超出阈值暂停演化优先完成任务

与现有系统的嫁接方案

嫁接 Claude Code / Cursor：这两者的 harness 配置（.claude.json / cursor_rules.md）本身就是结构化文本，可以直接进 Git PR；Ouroboros 的 review gate 只需加在"规则变更 merge"前，不需要重构核心
嫁接 GitHub Actions CI：把 benchmark 跑在 CI 里，用 on: push + concurrency-group 确保 snapshot 不被并发污染；SOTA 数字作为 CI artifact 保留，reviewer-LLM 跑在独立的 jobs.review 里
嫁接 SOTA 追踪：当前 Ouroboros 的 SOTA 数字（86.74/90.69/0.2301）只能手动更新；工程上建议把 benchmark 数字写进 leaderboard.json，作为 PR 合并条件之一（数字下降则 block merge）