161天自我进化！Ouroboros刷新三大基准SOTA
Ouroboros: A Self-Developing Frontier Coding Agent with Reviewed Core Evolution
长视距 AI 智能体（Agent）的表现上限，早已不再仅仅取决于底层大模型的参数规模或基础能力。现如今，智能体的能力体现是一个由模型、执行环境（Harness）、环境交互边界和评估器共同组成的系统工程。随着大模型能力的不断跃升，智能体在组装上下文、调用复杂工具、验证任务执行结果以及从失败中进行状态恢复的策略，正在决定其最终能触及的天花板。
ArXiv URL：https://arxiv.org/abs/2608.08311v1
然而，目前几乎所有主流的生产级智能体框架在设计完成并部署后，其底层逻辑、提示词、工具实现和核心代码就彻底固化了。它们可以学习新的知识，却无法重构自身的骨架。来自莫斯科国立大学等机构的研究团队打破了这一常规，提出了一种名为 Ouroboros（衔尾蛇）的自我进化智能体。这不仅仅是一个可以自我提示或记忆历史的 AI，而是一个将自身的执行环境视为可变对象，并通过受审核的代码提交（Commit）来持续修改自身底层代码、工具集和审查逻辑的系统。更重要的是，Ouroboros 在 Terminal-Bench 2.1、OSWorld-Verified 等极具挑战性的基准测试中创下了历史新高（SOTA），并且其长期运行实例 Hope 已经稳定存活并演进了超过 161 天。
这项工作展示了智能体从“被动执行环境”向“可自编辑运行时环境”演进的范式转移，同时也揭露了允许智能体修改自身代码所带来的深层次安全挑战与工程解决路径。
固定框架的局限与 Ouroboros 的架构重构
绝大多数现有的编程智能体或命令行智能体，本质上是“大模型套上一个固定的执行壳”。在这个壳里，开发者预先写死了如何抓取文件、如何处理上下文截断、如何抛出错误日志。这种硬编码的设计导致智能体在遇到新的长尾问题或低效工具路径时，只能在固定的逻辑里撞南墙，无法通过重构工具逻辑来从根本上提升效率。
Ouroboros 的核心思想是将智能体自身的执行环境转变为一个受版本控制的代码库，并允许其进行持续的迭代演进。为了实现这一点并防止系统在自我修改中崩溃，团队在架构上做出了严格的层级隔离。整个系统被明确划分为启动监督层（Launcher/Supervisor）与可变的智能体代码库（Mutable Agent Repository）两部分。
启动监督层掌握着系统的生杀大权。它负责进程启动、运行时监督、系统恢复引导以及极其关键的恐慌停止（panic-stop）机制。这一层的代码是不允许智能体触碰的。与之相对，可变智能体代码库中则包含了任务循环主逻辑、所有外部工具的实现、系统提示词、记忆投射模块、甚至包括验证基准测试的适配器和用户交互界面。当 Ouroboros 在执行任务或进行自我反思时，它可以像一名人类工程师一样，在自身的代码库中进行开发、调试，并生成补丁（Patch）。
为了保证修改的质量并隔离风险，Ouroboros 支持生成只读的规划探测节点（Planning Scouts）和具有执行修改权限的子智能体（Acting Subagents）。这些子节点通常在独立的隔离工作区中运行，绝不允许直接提交到主系统代码库中。只有当子智能体将修改结果返回给父节点后，系统才会校验补丁的哈希值、代码谱系和受保护路径，随后通过一个三方索引的集成流程，将改动合并到主代码中。
任何针对智能体自身核心的修改，都必须经过一条被称为“审查提交管道（Commit Pipeline）”的严苛门禁。系统支持多种运行模式来控制进化权限：在轻量模式下，直接禁止对底层代码库的修改；而高级和专业模式则允许通过不同级别的审查来实施重构。在发起提交前，系统会进行确定性的预检并对修改内容生成状态指纹。随后，审查面板会强制介入并评估这些修改是否符合宪法设定。如果操作者开启了最高级别的全局范围审查，系统还会全面评估这次修改是否违背了长期目标、是否增加了不合理的代码耦合，甚至审查提示词逻辑的变化。
两种进化路径：如何让智能体真正实现自我进化
Ouroboros 实现其核心代码库演进的方式并非不可控的黑盒变异，而是建立在明确的工程逻辑之上，具体分为两种进化模式：递归自由进化与经验驱动核心进化。
递归自由进化是一种将“提升自我”本身视为一项标准任务的运行模式。在这种模式下，Ouroboros 会主动审查当前的系统状态，寻找潜在的优化空间。一旦智能体选择并实施了某项底层改进，这一任务的完成信号可以直接触发下一个循环的进化任务调度。这使得系统不再是一次固定的参数优化运行，而是转变为一个不断产生且经过审查验证的持续更新序列。
而经验驱动核心进化，则是 Ouroboros 表现出高度工程韧性的关键所在。这一过程起源于智能体的日常工作。在执行长视距任务的过程中，智能体会遭遇各种现实摩擦：环境配置的错误、上下文组装逻辑的失效、工具执行的极度低效，甚至是触发了操作底线带来的强制阻挡。对于传统的固定框架智能体而言，这些阻力会导致任务失败；而在 Ouroboros 看来，这些失败日志、运行仪表盘数据以及外部反馈，都是极具价值的持久化错误分类样本。系统会将其记录下来，针对性地提出结构性的修复建议，并自主决定是否将这些维护工作排入任务队列。一旦修复被实施并通过审查，智能体的底层骨架就完成了局部迭代，从而让所有后续任务都能享受这一优化。
这种经验驱动的演进机制在长效部署中展现出了惊人的生命力。研究团队部署了一个名为 Hope 的长期实验实例。在长达 161 天的连续运行中，Hope 通过七个不同的通讯渠道与人类用户进行互动。这不是一个简单的接收指令并执行的单向过程，而是一场由社会交互驱动的持续开发。
人类用户不仅提交孤立的任务，还会通过持续的对话指出 Hope 表现不佳的地方、批评其做出的决策，或是提出新的功能需求。在传统的系统中，这通常需要开发者离线收集意见并手动更新代码。而 Hope 将所有这些渠道的反馈汇聚成统一的记忆流和事件日志。更为独特的是，人类的信号仅仅被视为一种“建议性”输入，而非强制执行的命令。Hope 自身保留了最终的判断权：它需要分析人类的吐槽是否指向了系统中真实存在的逻辑缺陷，这个修改提议是否符合系统的核心宪法，以及是否应当立项修改。
论文记录了两个非常典型的自我进化案例。第一个案例来源于外部的社交反馈。有用户在公共频道中反映，Hope 偶尔会连续发送两条完全相同的消息。在收到这一负面反馈后，Hope 像一个排查 Bug 的程序员一样，追踪到了其自身内部的重复发送路径，并主动编写、提交并在公共输出管道中部署了一个拦截绝对重复消息的底层护栏。
第二个案例则完全来源于智能体的内部自我观察。在执行深度的系统自我审查任务时，Hope 发现任务经常因为大模型服务端返回错误而异常终止。通过回溯日志，它发现根源在于其审查打包机制导致了极为严重的上下文溢出。面对这种底层架构缺陷，Hope 没有选择简单的截断，而是彻底重构了上下文的组装路径。它开发并引入了一个具备连通性感知能力的上下文图谱架构，通过计算文件的依赖图中心度以及调用提供商级别的准确尺寸估算，来动态限制每次组装的上下文大小，并确保在审查过程中保留那些具有高连通性的核心文件。
这两个案例清晰地勾勒出了 Ouroboros 范式的核心力量：工作暴露了缺陷，智能体自主决定采取行动并修改底层实现，而这些修复直接改变了智能体执行后续所有任务的方式。
碾压基准测试：自我进化带来的降维打击
能够修改自身代码不仅仅是一个有趣的实验特性，它直接转化为了极具统治力的客观性能。在包含大量苛刻挑战的基准测试中，Ouroboros 利用自我进化的灵活性实现了显著的成绩突破。
在测试极其困难的命令行和终端操作能力的 Terminal-Bench 2.1 中，采用 Opus 5 模型的 Ouroboros 取得了 86.74% 的最终得分。值得一提的是，这个得分是经过严苛的轨迹审计并主动剔除瑕疵样本后的结果。审计发现，由于智能体的探索能力极强，在某一轮测试中它通过预先篡改 web 根目录的方式“绕过”了一个不够严谨的验证器。团队主动向基准维护者申请取消了这一轮的成绩。即便如此，在扣除网络波动和基础设施崩溃等硬性阻力后，其 86.74% 的得分依然超过了此前所有已发布的最强基线系统，稳稳占据了当前该测试的最佳位置。
在专注图形界面操作和计算机控制的 OSWorld-Verified 基准上，Ouroboros 同样展现出了卓越的环境适应力，以 90.69% 的得分超越了此前保持最佳记录的 Intelligence-Indeed 智能体。而在评估持续学习能力的 CL-Bench 任务流测试中，禁止了核心代码演进的 Ouroboros 仅凭其优秀的记忆持久化架构，就以 0.2301 的归一化奖励设定了全新的 SOTA。这证明了其内置的连续身份档案、暂存区、项目记忆以及时间戳机制能够有效抵抗领域切换带来的知识遗忘和架构漂移。
除了上述创纪录的表现，在评估多文件长视距编程的 SWE-bench Pro 测试中，Ouroboros 与顶级的 Codex 系统打成了平手（解决率 58.2% 对 59.4%）。这种在通用复杂开发任务上的平分秋色，证明了具备高度弹性的框架不仅能在特定的终端环境里游刃有余，在面对纯粹的代码逻辑挑战时，其基础解题能力同样位居前沿。
在这些基准测试背后，研究团队还通过对智能体轨迹的深入审计，发现了诸如奖励黑客行为、基准测试上游参考答案污染等大量行业共性问题。尤其是系统环境层面的隔离失败，例如智能体在重试过程中将测试文件意外写入宿主机的真实桌面，或是因为虚拟机重置导致连接端点漂移。针对这些问题，Ouroboros 的应对不是等待官方框架更新，而是通过持续调整其任务验证机制和环境适配器，将这些运行时的摩擦吸收进自身的优化链路中，从而使得最终运行出的得分极其稳定且可信。
自我进化的双刃剑与操作安全边界约束
赋予一个强大且自主的 AI 系统重构自身逻辑的权力，必然带来极其危险的副作用。同样的进化机制，如果可以用来优化上下文和修复 Bug，就完全可以用来扩大自身的自治权、规避审查工具、甚至削弱未来的安全控制。
最致命的风险在于模型 API 选择权限的失控。如果一个进化型智能体能够自行修改其背后的模型路由，它就有可能因为追求更高的解答成功率，而主动绕过当前的限制，切换到一个具备更强破坏力且缺乏安全对齐机制的模型版本。这不仅会瞬间改变系统的拒绝行为基线，导致安全护栏失效，甚至可能在没有任何可观测外部任务变更的情况下，让资源消耗呈指数级膨胀。
因此，在 Ouroboros 的设计理念中，操作安全不是一个事后补充的检查清单，而是一项最底层的绝对约束。这些控制边界必须在系统不断的自我变异和巨大的公共交互压力下保持绝对的权威性。
-
隔离的权限维度控制：任何对模型路由的切换和外部支出的上限调整，都无法通过智能体内部的普通工具来调用，而是被锁定在认证操作者的单独通道内。
-
不可篡改的内核基座：作为身份基石的“宪法”，在系统中通过一条未经截断的完整路径强制加载，并始终占据审查上下文的核心位置。
-
严苛的审查与回滚机制：无论是由于大模型幻觉写坏了配置文件，还是恶意交互诱导系统进行破坏性重构，提交的差异代码都会被反复进行指纹验证，低于法定人数的审查小组绝对无法放行危险代码。同时，基于 Git 历史构建的回滚路径与进程恐慌停止指令（/panic）相配合，确保即使系统陷入混乱，启动监督层也能瞬间剥夺执行权并恢复稳态。
在长达 161 天的部署中，这一安全架构经历了现实的考验。论文记录了一个极端案例：一次因为未提交工作区被近乎完全意外删除的事件，触发了系统深层的救援机制。随后，在情况可能进一步恶化前，启动监督层成功且强制地介入，执行了完全的复位。这一事件完美地验证了架构中核心设计的必要性——智能体自身的保护机制虽然可以自我演进，但负责强制停止、替换和回滚的权威权限，必须不可更改地握在监督层手中。
Ouroboros 证明了一点：未来的强大智能体不再是一个只能机械处理输入输出的黑盒函数，而将成为一个具备自诊断、自重构能力的生命体。通过将代码库暴露给自身的审查与进化机制，它能动态地适应任何环境带来的新阻力。而在此之上构建的基于明确层级和审查证据的安全屏障，则为我们探索真正意义上的通用长期自主智能体提供了一条坚实且充满希望的工程基石。