Ouroboros 试图把智能体从“执行既定流程”推进到“持续改造执行系统”。它可以修改工具、提示词、上下文组装方式和核心实现，但变更需要以经过审查的提交进入代码库，随后才会成为后续任务使用的运行时。这里演化的是智能体框架，材料并未说明其会训练或更新底层模型权重。
两种核心演化路径
第一种是递归自由演化：系统把“改进自身”直接作为任务，一轮演化完成后还可以安排下一轮。第二种是经验驱动演化：智能体在日常工作和社会互动中暴露缺陷、操作摩擦与低效的上下文构造，再据此提出并实施结构性修改。
这套设计的关键不只是自动写代码，而是让修改经过审查后进入后续运行环境，从而形成可持续积累的闭环。与此同时，智能体能够重写自身代码并选择新的模型 API，也使安全约束面临持续变化：论文强调，护栏必须在演化过程和公开社交压力下仍保持权威。
基准成绩与长期部署
论文报告，在 Terminal-Bench 2.1 上，一次 Opus 5 运行取得 86.74%，为该基准已报告的最佳结果；在 OSWorld-Verified 上，Opus 5 达到 90.69%，超过此前最佳成绩。由五次 rollout 组成的 CL-Bench 测试获得 0.2301 的归一化奖励，论文称其刷新了当前最佳水平。
Hope 是公开记录时间最长的 Ouroboros 部署：它进行了 161 天的自由演化实验，并在七类受治理的人类沟通界面上运行。人类互动负责暴露问题和产生提案，但由智能体决定推进哪些修改。为避免持续演化干扰评测，基准测试使用冻结的系统快照，Hope 则在独立分支上继续演化。
我的判断
Ouroboros 的价值，在于把智能体改进从零散调参变成可审查、可进入运行时的工程流程，也明确区分了冻结评测与在线演化。其适用边界同样清楚：允许系统改写核心代码、替换模型 API，意味着代码审查、权限控制和护栏独立性必须优先于自治程度。当前材料给出了领先成绩与长期案例，但没有提供更细的消融、审查成本及失败统计，因此还不能据此判断自我演化本身贡献了多少增益，也不足以证明这套机制能安全迁移到所有生产环境。