Claude Code、Codex组队干活，Raven新版本既做总调度，也让Harness持续进化

　　EverMind开源Raven V0.2.0，为RSI设计Harness框架与统一编排专业Agent的机制，在多Agent任务中表现优于同底座模型下对比方案，已开源。

　　· EverMind开源Raven V0.2.0突破AI递归自我改进（RSI）仅发生在模型参数层的局限，推出Harness框架与Harness编排两大核心设计多Agent编排、专业任务表现优于同底座对照模型，已完成宣传物料制作等实际应用，RSI实验中相同预算下val_bpb相对下降5.8%，还开源可复用任务图与Playbook。

　　· Curator仅为实验性功能，跨场景多次重复验证未完成核心源码无需改动即可被AI改写，存在一定安全风险。

　　总结：Raven V0.2.0在多Agent编排、RSI落地及专业协作上具备技术优势，开源属性打开应用空间，但核心功能仍处实验阶段，建议关注技术成熟度与商业化节奏。

　　递归自我改进（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 已作为实验性功能开源，跑通了从反馈、生成代码到校验安装的闭环。

　　围绕 AI 改进 AI，Raven 目前有两条探索：一是 AI 改进 Agent 自身的工作方式，即上述 Curator（见第四部分）；二是 AI 改进 AI 的研发工作，Raven RSI 项目在 nanochat 预训练实验中完成 7 轮、172 次训练，在相同的单次训练预算下使 val_bpb 相对下降 5.8%（见第六部分）。

　　Raven 自身的发布也是一次实际应用：它完成了浏览器端物理小游戏、16 页产品介绍、中英文海报和项目 README，将多种专业能力用于制作自己的宣传物料。

　　当你把一项复杂任务交给 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 连接第三方成员。

　　给一根悬臂梁逐步加载，观察仿真求解器在不同载荷下的收敛情况，看起来是一项具体的计算任务，实际却包含研究、编码和实验三个环节。Raven 展示了一条接力链：Raven-Research 研究方法，Raven-Code 实现计算，Raven-Oncall 接续运行实验。

　　Raven 首先把目标拆成任务图，再为每个节点选择成员，并根据前置任务的完成状态决定下一步。研究节点完成后，被引用的上游结论进入代码节点；代码产物就绪，再由实验节点接续。每个成员承担专业工作，Raven 负责组织它们之间的输入、输出和启动条件。

　　这里的关键机制是 DAG，即有向无环图。没有相互依赖的分支可以并行启动，需要前置结果的节点则等待依赖完成。节点启动时，Raven 会把任务目标、角色职责以及明确引用的上游输出或产物入口组织成输入。当前置任务失败时，依赖它的节点可以被跳过，不相关的独立分支仍可继续。

　　这种组织方式让协作过程变得可观察：任务是否已经启动，依赖是否满足，交接了什么结果，后续节点为什么能够继续。用户也可以把成员、任务与依赖保存为 Playbook，在类似需求中再次使用。一次执行形成的工作链，因此有机会成为可复用的流程。

　　一项任务完成后，后面的成员需要接到的不只是 “已完成” 的状态，还包括可以继续使用的结论、文件、引用和上下文。对支持本地文件读取的后端，Raven 可以附上依赖节点的记忆记录入口；支持会话续接的后端，则可以沿用连续步骤中的上下文。

　　跨会话的积累由 EverOS 承接。用户上下文、Agent 经验和世界知识，可以成为后续任务的参考。任务图负责组织这一次的执行顺序，记忆则帮助判断过去哪些信息仍然有用，减少重复交代背景和重新寻找材料的成本。

　　经验要进一步影响工作效果，还需要进入实际的执行策略。某次任务暴露了什么问题，用户反复强调了什么要求，哪些做法值得继续采用，都需要转化为后续可执行的调整。Raven 的模块化 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 则规定了标准旅行规划场景下个人常用的工作流程。

　　这些要求经由 Curator 理解后，用于定制当前的 Harness 状态，并落实为一条工作链。一个可能的编排是：主角色与客户沟通并整理需求，研究成员查找和核对目的地信息，设计成员将路线、预算和注意事项整理成方案演示。Curator 既在上层设计 Playbook 的成员分工、任务依赖与产物交接，也在必要时把规划师的工作要求转化为相关 Harness 的策略调整。

　　九游娱乐最新动态

　　Raven 将自身 Harness 中可调整的策略划分为 Memory、Planning、Capability 和 Action 四个模块。它们通过既定接口参与完整的 Agent Loop，让信息准备、任务规划、工具使用和行动判断都有具体的调整位置。

　　例如，在旅行规划中，Memory 决定当前轮次能看到哪些客户需求、既往经验；Planning 决定先确认约束、再比较路线、最后组织方案的工作顺序。当涉及接入地图、天气等服务，Capability 可以决定每次模型迭代向模型开放哪些工具；Action 决定在执行前如何并且是否检查相应的待执行动作。

　　用户反馈会先由 Curator 判断其对应的策略问题，再转化为 Harness 层面的调整，例如补充 Memory 中需要保留的信息、修改 Planning 的规划方式，或在 Action 中增加检查；用户继续反馈时，这一过程也可以继续迭代。

　　例如，旅行规划师指出方案 “连续步行太多、跨区往返频繁，还缺少雨天备选”，Curator 就可以让后续规划更多考虑同行人的体力与节奏，优先按区域组织路线，并在交付前检查天气备选。这样，一次反馈改变的不只是当前方案，也能成为后续类似任务采用的工作方法。

　　类似的过程已在代码库自带的一个模拟案例中跑通：一家虚构旅行社的老板（由模型扮演）只上传店里的资料、扮成客人演练、演练后提意见。入职时，Curator 仅凭资料就生成了流程与检查代码，例如在每条消息发出前数问号，超过两个就打回重写；此后按老板的意见逐轮把问题落实到执行层，第 3 轮评审标准中的 11 条红线全部通过。完整的培养记录、每一轮的代码改动、前后两版方案与复现命令均随代码仓库公开（experimental/simulation/cases/s0925c）。

　　需要说明的是，这只是一次模拟运行，旅行社是虚构的，老板和客人由模型扮演，Curator 在 V0.2.0 中也仍是实验性功能。目前做到的，是 Curator 能按资料与反馈改写提示、配置、工具闸门与策略代码，校验后安装，并在一个完整场景中跑通多轮闭环；尚未做到的，是跨场景、多次重复的统计验证，以及与模型参数层慢更新的打通。

　　团队能否协作，既取决于任务与依赖如何组织，也取决于成员能否完成各自的专业工作。Raven 的评测覆盖这两个层次：编排评测考察任务图的生成，领域评测考察研究、编码、设计和持续执行能力。评测涵盖多项公开基准及 AI4S 内部基准，具体设置见相应图表。这些评测检验的是 Harness of Harnesses 的编排与各成员的专业能力，不涉及 Harness 层自改进的效果。

　　Raven-Design 面向演示文稿、网页、图表、SVG 与品牌视觉。在幻灯片生成和视觉设计评测中，Raven-Design 与 Claude Code 在相同模型下的得分见表 1。

　　这些专业能力进入同一条任务链后，可以共同支撑从研究分析到代码实现、实验运行和视觉交付的完整项目。

　　Raven RSI 探索让 AI 自主开展研发实验。与第四部分的 Harness 自改进不同，这里被持续改进的是任务中的训练与计算方案，而非 Raven 自身：在给定任务与不可自行修改的评价标准下，Raven 自主规划每一轮，编写代码、运行实验，再根据结果决定后续调整。

　　在另一组 nanochat 预训练实验中，Raven 持续优化训练方案，共完成 7 轮、172 次训练，没有发生训练崩溃；在每次训练相同的 20 分钟单 GPU 预算下，val_bpb 相对下降 5.8%。完整交付还包括实验结果、可视化、海报、演示文稿和项目网站。

　　Raven 也将自身发布作为一项完整任务，端到端完成了用于介绍和传播自己的一套物料：浏览器端物理小游戏提供可直接体验的交互内容，16 页产品介绍系统呈现产品信息，中英文海报用于视觉传播，README 则承接开发者了解和使用项目所需的说明。这套物料覆盖了从代码实现、内容组织到视觉制作的完整工作。

　　Godot 游戏资产制作展示了更复杂的项目型协作：先进行参考研究和资产审查，形成美术规范，再并行制作武器与 Boss 资产，随后由编码成员集成和验证，最后由设计成员审阅游戏内效果。八个节点构成了一条包含并行分工、产物交接和最终检查的工作链。

　　在 THRESHOLD 完整游戏项目中，需求文档由人提供，Raven 自主运行约 4 天，经过 42 轮规划、开发与验证，使用 Godot 4 完成以竞技场 Boss 战为核心的第 一人称射击游戏。最终交付包括可玩的游戏、海报、演示文稿和网站。

　　“对比三款 AI 编码产品，给我一份带来源的分析，再做成可以交互的看板。” 可以用这项需求说明数字伙伴的分工：市场分析员关注产品定位、用户与使用场景，技术研究员关注架构、集成与部署，两者并行整理带来源的结论，再由设计成员统一比较维度、制作看板并检查交付。

　　在这一配置示例中，同一个 Raven-Research 后端可以承担不同研究角色，角色差异体现在任务职责与输入要求上。Playbook 组织成员、节点与依赖，成员 Harness 则决定信息怎样进入上下文、模型可以使用哪些工具，以及行动需要通过哪些检查。

　　用户的知识、经验、SOP、工作习惯和判断标准，可以由此进入成员的工作方式。图 4 描绘的数字伙伴培养过程，也就有了可操作的含义：把要求落实到分工与策略，在实际使用中观察结果，再将反馈交给 Curator 继续调整。

　　这些积累由不同机制承接。用户可以从自然语言或已有文件生成并保存 Playbook，在 playbook.md 中保留成员、节点任务、依赖和输入安排，审阅后再次使用；EverOS 承接跨会话的上下文与经验；应用后的 Harness 调整，则成为对应 Agent 后续运行时采用的策略。

　　SkillForge 从本地技能库、EverOS 记忆和 SkillHub 目录中按需检索相关技能，为任务提供专业知识与操作方法。Proactivity 将事件监测与定时执行结合起来，支持在约定条件下发起任务。WebUI 提供统一入口，帮助用户选择成员、跟踪进度并检查交付。

　　Raven V0.2.0 将专业协作与工作方式的持续调整连接起来，也迈出了让 RSI 从模型参数层延伸到 Harness 层的第 一步：研究、编码、设计和实验成员围绕同一个目标工作，任务留下的上下文、技能与经验继续发挥作用，Curator 则把使用中的要求与反馈转化为具体的策略调整。

　　对用户来说，这一变化最终体现在具体的工作体验上：任务能否推进，结果能否交接，证据能否追溯，过去纠正过的问题能否影响后续的执行方式。一支有用的 Agent 团队，需要完成眼前的交付，也需要形成可以长期积累的工作方法。

　　2. 可复用的任务图与 Playbook。复杂任务被拆成带依赖的 DAG，独立分支并行执行，前置任务失败时下游节点跳过、其他分支继续；跑通的流程可以保存为 playbook.md，经 raven playbook validate 校验后在类似需求中复用。

　　3. 四个可直接使用的专业 Agent。Raven-Research、Raven-Code、Raven-Design 与 Raven-Oncall 分别面向深度研究、编码与数据分析、设计交付和长时持续执行，既可以单独使用，也可以编入任务图协同工作。

　　4. 一套为 AI 修改而设计的 Harness 接口。Memory、Planning、Capability、Action 四个策略面，通过 home 文件、配置、钩子、插件与公共策略协议对外开放；开发者可以自己编写策略、工具与闸门，也可以交给 AI 改写，无需改动 Raven 的核心源码。

　　5. 一个可供研究的 Harness 自改进参考实现（实验性）。experimental/curator 中的 Curator 按理解、选择、设计、实现、修复分阶段生成改动，校验通过才安装；安装失败时，触发上一版本 Harness 及受管理内容的恢复流程。s0925c 案例附有完整的培养记录、每一轮的代码改动与复现命令。

　　6. 跨会话的记忆与技能。EverOS 保留跨会话的上下文与经验，SkillForge 按需从本地技能库、EverOS 记忆和 SkillHub 目录中检索技能，为任务补充专业知识与操作方法。

　　7. 可观测、可回放的执行过程。Tracing 默认开启，失败的执行轨迹可以导出、回放，并沉淀为确定性的回归测试。