机器之心发布
导读｜RSI（递归自我改进）不应只发生在模型参数层：类比人类大脑的不是 LLM，而是整个 Agent。EverMind 开源的 Raven V0.2.0 为此提供了两个核心设计：为 RSI 而设计的 Harness 框架，以及统一编排专业 Agent 的 The Harness of Harnesses。在多 Agent 编排、深度研究、编码、设计与持续执行评测中，Raven 的多项结果优于同底座模型下所比较的 Harness。
递归自我改进（Recursive Self-Improvement，RSI），指 AI 系统利用执行结果与反馈，持续改进产生这些结果的机制本身。谈到 RSI，人们往往首先想到模型参数，但人类大脑给出了另一种答案：按照互补学习系统理论（CLS；Kumaran, Hassabis & McClelland, 2016），海马快速记住具体经历，皮层则通过回放与整合，缓慢沉淀出可复用的能力。因此，真正可以类比大脑的不是 LLM，而是整个 Agent：模型参数如同皮层，适合慢速巩固；由记忆、技能、提示、控制代码与决策策略构成的 Harness，则应像海马一样快速适应。RSI 同样可以、而且应当发生在 Harness 层。学术界已有不少工作探索让 AI 改写 Agent 本身，但主流的工程化 Harness 框架仍以人工编写和维护为主：提示靠人调，流程靠人写，出错靠人修。EverMind Raven V0.2.0 正是从这里出发，围绕两个核心设计理念构建。
其一，为 RSI 而设计的 Harness 框架。Raven 把 Harness 中可被 AI 改写的部分分为四类：Modules（如 playbook 与子 Harness 的组合）、Code（如执行前检查等策略代码）、Prompt（如系统提示与上岗手册）和 Policy（如工具开放与闸门配置）。这四类内容共同构成 Harness 的装配方案，每一类都可以独立替换、改写。AI 可以依据任务中积累的知识、经验与反馈修改这些部分，持续改进个体 Harness 与团队协作策略。V0.2.0 迈出了第一步：运行时的 Curator 已作为实验性功能开源，跑通了从反馈、生成代码到校验安装的闭环。
其二，The Harness of Harnesses。Raven 把自身深度优化的四个子 Agent（Raven-Research、Raven-Code、Raven-Design 与 Raven-Oncall）与 Claude Code、Codex 等专业 Agent 统一编排，负责成员选择、任务拆解、依赖调度与结果交接，并由 EverOS 保留跨会话的上下文与经验，支持跨模型、跨框架的能力组合。
围绕 AI 改进 AI，Raven 目前有两条探索：一是 AI 改进 Agent 自身的工作方式，即上述 Curator（见第四部分）；二是 AI 改进 AI 的研发工作，Raven RSI 项目在 nanochat 预训练实验中完成 7 轮、172 次训练，在相同的单次训练预算下使 val_bpb 相对下降 5.8%（见第六部分）。
Raven 自身的发布也是一次实际应用：它完成了浏览器端物理小游戏、16 页产品介绍、中英文海报和项目 README，将多种专业能力用于制作自己的宣传物料。
图 1｜Raven V0.2.0 主视觉。产品界面、案例及评测图由 EverMind 提供。
一 Harness of Harnesses 如何组织专业 Agent
当你把一项复杂任务交给 AI，真正费力的往往不只是得到一个答案。你还要决定先查什么、交给谁做、哪些工作可以并行、结果如何交接，以及出现问题后怎样调整。下一次遇到类似任务时，这些判断和纠正能否继续发挥作用，同样影响着 AI 是否真正成为可靠的工作伙伴。
研究需要检索与证据，编码需要实现与调试，设计需要组织表达与交付，实验任务还需要持续运行、观察结果并推进下一轮。不同专业 Agent 已经形成了各自的工具、技能和工作方式。复杂任务需要把这些能力组织起来，也需要让执行中积累的经验进入后续的工作过程。
Claude Code、Codex 等专业 Agent 可以保留自己的专长与执行机制，Raven 在更上层承担协调工作：谁先做、谁接着做、谁需要读取哪些结果，以及什么时候可以进入下一步。接入一个成员，意味着把它的专业能力纳入一条更完整的任务链。
这也是 Harness of Harnesses 的含义。Harness 是一套把模型能力转化为行动的机制，涵盖上下文管理、规划、工具使用、结果检查与执行循环。Raven 连接的成员可以拥有完整的 Harness，并按自己的方式完成被分配的工作。
由此可以看见两个相互衔接的层次：外层组织成员、任务与依赖，成员内部的 Harness 则决定信息如何被使用、工具如何被调用、行动如何推进。Raven-Research、Raven-Code、Raven-Design 与 Raven-Oncall 分别承担研究、编码、设计和持续执行工作；Raven 也可以通过 ACP、CLI 或 OpenAI 兼容 API 连接第三方成员。
图 2｜跨 Harness 协作示意。不同成员分别完成研究、发布材料与网站开发，并交接产物。
二 从一个目标到一张任务图
给一根悬臂梁逐步加载，观察仿真求解器在不同载荷下的收敛情况，看起来是一项具体的计算任务，实际却包含研究、编码和实验三个环节。Raven 展示了一条接力链：Raven-Research 研究方法，Raven-Code 实现计算，Raven-Oncall 接续运行实验。
Raven 首先把目标拆成任务图，再为每个节点选择成员，并根据前置任务的完成状态决定下一步。研究节点完成后，被引用的上游结论进入代码节点；代码产物就绪，再由实验节点接续。每个成员承担专业工作，Raven 负责组织它们之间的输入、输出和启动条件。
图 3｜悬臂梁仿真任务图。研究、代码与实验节点按依赖关系顺序接力。
这里的关键机制是 DAG，即有向无环图。没有相互依赖的分支可以并行启动，需要前置结果的节点则等待依赖完成。节点启动时，Raven 会把任务目标、角色职责以及明确引用的上游输出或产物入口组织成输入。当前置任务失败时，依赖它的节点可以被跳过，不相关的独立分支仍可继续。
这种组织方式让协作过程变得可观察：任务是否已经启动，依赖是否满足，交接了什么结果，后续节点为什么能够继续。用户也可以把成员、任务与依赖保存为 Playbook，在类似需求中再次使用。一次执行形成的工作链，因此有机会成为可复用的流程。
三 记忆如何连接任务与经验
一项任务完成后，后面的成员需要接到的不只是 "已完成" 的状态，还包括可以继续使用的结论、文件、引用和上下文。对支持本地文件读取的后端，Raven 可以附上依赖节点的记忆记录入口；支持会话续接的后端，则可以沿用连续步骤中的上下文。
跨会话的积累由 EverOS 承接。用户上下文、Agent 经验和世界知识，可以成为后续任务的参考。任务图负责组织这一次的执行顺序，记忆则帮助判断过去哪些信息仍然有用，减少重复交代背景和重新寻找材料的成本。
经验要进一步影响工作效果，还需要进入实际的执行策略。某次任务暴露了什么问题，用户反复强调了什么要求，哪些做法值得继续采用，都需要转化为后续可执行的调整。Raven 的模块化 Harness 为这些变化提供了具体落点。
四 Harness 自进化：让一次任务成为下一次任务的起点
Raven 的 Harness 从设计上就是可以被 AI 改写的。在运行时承担这项工作的是 Curator（V0.2.0 中为实验性功能，随代码仓库提供）：它读取当前实际装配出的 Harness、任务要求、执行留痕与用户反馈，生成具体改动，可以是提示与上岗手册（Prompt）、配置与工具闸门（Policy）、实现策略协议的代码（Code），也可以是 playbook 与子 Harness 的组合方式（Modules）。它可以调整 Raven 原生的根 Harness、子 Harness，以及团队的编排与交接策略。所有改动先经过声明检查、真实装配和预检运行，通过后才安装；安装失败时，触发上一版本 Harness 及受管理内容的恢复流程。生成物全部落在 Raven 原生的扩展点上，无需修改 Raven 的核心源码。
这里的 "为 AI 修改而设计"，可以在代码里直接核对：Memory、Planning、Capability、Action 四个策略面各有一个公共策略协议，Curator 生成实现协议的 Python 类，由适配层绑定到 Raven 已有的回调点；提示、技能包与 playbook 写进 Agent 的 home 目录，新工具与闸门以插件形式注册。AI 通过公开策略协议和扩展接口实施这些改动，每一次改动都可以被检查、回滚和追溯。
设想一位旅行规划师，希望培养一个按自己方法工作的数字伙伴："按照我的服务流程接待客户，结合我整理的目的地资料，给出适合他们的行程和方案演示。" 图 4 中的旅行规划分身，便从这样的需求开始。
把知识经验与 SOP 变成工作安排
规划师交给它的，是自己过往的经验、工作模式等知识资产，比如以往的路线方案、积累沉淀的各类 SOP。资料提供出行所需的各类信息；经验告诉它怎样安排更舒适、哪些组合容易赶路；SOP 则规定了标准旅行规划场景下个人常用的工作流程。
这些要求经由 Curator 理解后，用于定制当前的 Harness 状态，并落实为一条工作链。一个可能的编排是：主角色与客户沟通并整理需求，研究成员查找和核对目的地信息，设计成员将路线、预算和注意事项整理成方案演示。Curator 既在上层设计 Playbook 的成员分工、任务依赖与产物交接，也在必要时把规划师的工作要求转化为相关 Harness 的策略调整。
四个策略模块承接具体的规划方法
Raven 将自身 Harness 中可调整的策略划分为 Memory、Planning、Capability 和 Action 四个模块。它们通过既定接口参与完整的 Agent Loop，让信息准备、任务规划、工具使用和行动判断都有具体的调整位置。
例如，在旅行规划中，Memory 决定当前轮次能看到哪些客户需求、既往经验；Planning 决定先确认约束、再比较路线、最后组织方案的工作顺序。当涉及接入地图、天气等服务，Capability 可以决定每次模型迭代向模型开放哪些工具；Action 决定在执行前如何并且是否检查相应的待执行动作。
图 4｜从一句需求到可持续塑造的 "数字伙伴"。旅行规划师的知识、经验、SOP 与反馈进入分工和 Harness 策略。图中的演示制作能力由 Raven-Design 承接。
让一次反馈影响后续的行程规划
用户反馈会先由 Curator 判断其对应的策略问题，再转化为 Harness 层面的调整，例如补充 Memory 中需要保留的信息、修改 Planning 的规划方式，或在 Action 中增加检查；用户继续反馈时，这一过程也可以继续迭代。
例如，旅行规划师指出方案 "连续步行太多、跨区往返频繁，还缺少雨天备选"，Curator 就可以让后续规划更多考虑同行人的体力与节奏，优先按区域组织路线，并在交付前检查天气备选。这样，一次反馈改变的不只是当前方案，也能成为后续类似任务采用的工作方法。
类似的过程已在代码库自带的一个模拟案例中跑通：一家虚构旅行社的老板（由模型扮演）只上传店里的资料、扮成客人演练、演练后提意见。入职时，Curator 仅凭资料就生成了流程与检查代码，例如在每条消息发出前数问号，超过两个就打回重写；此后按老板的意见逐轮把问题落实到执行层，第 3 轮评审标准中的 11 条红线全部通过。完整的培养记录、每一轮的代码改动、前后两版方案与复现命令均随代码仓库公开（experimental/simulation/cases/s0925c）。
需要说明的是，这只是一次模拟运行，旅行社是虚构的，老板和客人由模型扮演，Curator 在 V0.2.0 中也仍是实验性功能。目前做到的，是 Curator 能按资料与反馈改写提示、配置、工具闸门与策略代码，校验后安装，并在一个完整场景中跑通多轮闭环；尚未做到的，是跨场景、多次重复的统计验证，以及与模型参数层慢更新的打通。
五 从编排到专业执行看能力表现
团队能否协作，既取决于任务与依赖如何组织，也取决于成员能否完成各自的专业工作。Raven 的评测覆盖这两个层次：编排评测考察任务图的生成，领域评测考察研究、编码、设计和持续执行能力。评测涵盖多项公开基准及 AI4S 内部基准，具体设置见相应图表。这些评测检验的是 Harness of Harnesses 的编排与各成员的专业能力，不涉及 Harness 层自改进的效果。
编排评测关注任务与依赖关系
多 Agent 编排评测包含 Node F1、Edge F1、Partial Order Accuracy 和 Exact Match Rate，分别对应节点、依赖关系、执行偏序与整张任务图的匹配情况。在 Qwen3.8-27B 组中，Raven 的四项结果依次为 0.923、0.812、0.950 和 0.711；在 DS-V4-Flash-0731 组中，依次为 0.963、0.897、0.918 和 0.867。两组均高于图中同模型下的 Hermes 与 Claude Code。
图 5｜多 Agent 编排评测。按底座模型比较节点、依赖关系、执行偏序与整图匹配表现。
研究能力兼顾证据组织与任务完成
Raven-Research 面向深度研究、文献梳理与技术分析。在 DeepResearch Mixed 中，Qwen3.6-35B、Qwen3.5-397B 和 DS-V4-Flash 三组的准确率分别为 56.3%、59.3% 和 76.5%；对应的 DeepSeek-Harness 结果分别为 49.7%、56.0% 和 68.9%。该评测组合了 BrowseComp、FRAMES、HLE 与 xBench-DeepSearch。
图 6｜DeepResearch Mixed 评测。比较准确率、平均每次查询的 Token 用量与费用；输入 Token 包含缓存，自托管组费用未测量。
DS-V4-Flash 组中，Raven-Research 平均每次查询的输入 Token 为 2.380M、输出 Token 为 41.6k，费用为 0.0242 美元。
编码能力覆盖修复重构与数据分析
在 SWE-bench Pro 的 Qwen3.8-27B 组中，Raven-Code 的问题解决率为 54.4%，Claude Code 为 52.4%；该组采用离线生成、在线评分。在 SWE-bench Verified 的 DS-V4-Flash 组中，在线生成的问题解决率为 91.0%，DeepSeek-Harness 与 OpenCode 分别为 90.4% 和 90.2%。
在 SWE-Refactor 的 DS-V4-Flash 组中，Raven-Code 的平均得分为 16.5，Claude Code 为 7.0；GPT5.6-Luna Max 组中，Raven-Code 与 Codex 分别为 13.5 和 10.5。在 WorkBuddy-Code 的 DS-V4-Flash 组中，Raven-Code 的全量集 Reward 为 78.1%，其他模型分组与对照结果见图 7。
图 7｜代码能力评测。指标包括问题解决率、Reward 与平均得分。
在 DataAgentBench 的 2026-08-24 Live 榜单中，Raven-Code 使用 Opus-5 位列榜首，Pass@1 为 0.8762；Permute EQ 使用同一模型，对应结果为 0.8713。
设计能力覆盖演示文稿与视觉交付
Raven-Design 面向演示文稿、网页、图表、SVG 与品牌视觉。在幻灯片生成和视觉设计评测中，Raven-Design 与 Claude Code 在相同模型下的得分见表 1。
表1｜设计评测得分。每格依次为 Raven-Design 与 Claude Code，分数越高越好。
持续执行能力结合质量时间与成本考察
Raven-Oncall 面向实验与持续执行。AI4AI 采用 Nanochat 50M 预训练任务，分配两张 A800 80GB GPU。BPB（每字节比特数）越低越好，运行时长、Token 用量与费用见表 2。
表 2｜AI4AI 评测的训练质量与资源消耗。
在 AI4S 内部自动科研基准中，Raven-Oncall 使用 Opus-5 的任务成功率为 82.35%，Claude Code 使用同一模型为 64.71%。
表 3｜AI4S 内部基准。成功率越高越好，时长、Token 用量与费用越低越好。
这些专业能力进入同一条任务链后，可以共同支撑从研究分析到代码实现、实验运行和视觉交付的完整项目。
六 实际应用案例
Raven RSI：让 AI 改进 AI 的研发工作
Raven RSI 探索让 AI 自主开展研发实验。与第四部分的 Harness 自改进不同，这里被持续改进的是任务中的训练与计算方案，而非 Raven 自身：在给定任务与不可自行修改的评价标准下，Raven 自主规划每一轮，编写代码、运行实验，再根据结果决定后续调整。
在另一组 nanochat 预训练实验中，Raven 持续优化训练方案，共完成 7 轮、172 次训练，没有发生训练崩溃；在每次训练相同的 20 分钟单 GPU 预算下，val_bpb 相对下降 5.8%。完整交付还包括实验结果、可视化、海报、演示文稿和项目网站。
Raven 为自己的发布制作宣传物料
Raven 也将自身发布作为一项完整任务，端到端完成了用于介绍和传播自己的一套物料：浏览器端物理小游戏提供可直接体验的交互内容，16 页产品介绍系统呈现产品信息，中英文海报用于视觉传播，README 则承接开发者了解和使用项目所需的说明。这套物料覆盖了从代码实现、内容组织到视觉制作的完整工作。