If you’re building agents and hate re-explaining yourself every session — try EverOS. Local Markdown memory, simple write→recall loop. I cut a 60s beginner walkthrough (Milvus shows up when you scale).

模型一直在升级，是不是可以不需要给 「Agents」当项目经理了？ 前几天我给大家分享了 Raven 做的游戏、PPT，还有调研和实验案例，在不同程度上说明了现在多 Agent 的能力边界，无论是视觉效果还是功能，都很强大。 现在让 AI 完成一项具体工作，已经不稀奇了。但真正做项目时，我们的精力却经常花在安排顺序、同步信息和检查结果上。 研究报告生成了，要挑出有用的结论交给写代码的 Agent；代码改了，要通知负责测试的 Agent；设计调整了，还要确认其他成员有没有用错版本。 每个工具都节省了一些时间，管理这些工具又成了一份新工作。 这就是 Raven 希望解决的问题：当一项任务需要多个专业 Agent 参与时，怎样减少协调成本，让整个项目持续推进？ 多 Agent，其实有不同的组织方式。如 图1 所示。 一种是任务之间相对独立。比如调研几个不同的项目，可以同时执行，最后汇总结果。这类独立并行的协作方式，可以称为 Swarm。 另一种存在明确的前后依赖。比如代码实现完成后才能进行相应的集成测试，游戏资产准备好后才能完成集成。这类按依赖关系组织的方式，通常采用 Graph（图式编排），其中常见的一种结构就是 DAG（有向无环图）。 还有一种强调长期协作。不同成员持续负责研究、开发、审查等工作，保留各自的上下文和经验，在项目中反复参与。这类组织方式可以称为 Agent Team（智能体团队）。 这些方式可以组合使用。选择哪一种，取决于任务有没有依赖、上下文是否需要隔离，以及成员是否需要长期保留经验。 Raven 的任务编排，首先处理其中的依赖问题。 DAG 是工作流系统中常见的结构。每个节点代表一项任务，箭头表示任务之间的依赖。 拿我们之前展示的游戏来说，其中一条资产制作流程包含八个节点： 参考研究、现有资产审查、美术规范、武器制作、Boss 制作、资产集成、构建验证，以及游戏内效果审阅。 参考研究与资产审查可以同时进行。美术规范确定后，武器与 Boss 可以并行制作。集成则必须等到资产准备好。 无环不代表不能修改。一个开发节点内部可以多次测试和修复；当前一轮完成后，也可以根据结果安排新的任务。无环约束的是图中的依赖关系。 节点也不必与 Agent 一一对应。同一个成员可以承担多个任务，没必要为每一步都创建一个新角色。 执行顺序确定以后，还有一个容易被低估的问题：交接。 研究节点显示已完成，开发节点也并不能开始工作。它需要知道采用哪种方法、结论有什么依据、哪些条件还不确定，以及具体该读取哪份文件。 缺少这些信息，后续成员可能重复研究，也可能把一个有前提的结论当成通用事实。 因此，Raven 在调度任务时，也会组织明确引用的上游输出和产物入口。前置任务失败时，依赖它的节点可以被跳过，不相关的独立分支继续执行。 这也涉及上下文管理。研究成员不需要读取所有调试日志，设计成员也不需要了解每一次参数实验。每个成员获得与当前任务相关的信息，同时保留查阅上游依据的入口。 我们希望减少的不只是等待时间，还有重复阅读、重复判断和信息误传。 当然，状态上的“完成”不代表质量已经合格。验收标准仍然需要提前定义。 Harness of Harnesses，是在这个基础上的进一步选择。 Harness 是支撑 Agent 执行任务的运行机制，包括上下文管理、工具调用、规划、检查和错误处理。 不同专业 Agent 已经形成了不同的工作方式。Research 需要检索和证据组织，Code 需要开发与调试，Design 需要视觉制作与交付，Oncall 需要实验运行和持续观察。 Claude Code、Codex 等工具，也各自拥有成熟的执行机制。Raven 希望保留这些专业能力，在更上一层安排成员、任务、依赖和结果交接。成员内部如何执行，则由各自的 Harness 负责。 这就是我们所说的 Harness of Harnesses。 它的价值需要通过完整任务来检验。多一个成员，就会增加一次协调和交接。简单任务交给一个 Agent 完成，往往更合适；复杂任务才需要认真考虑专业分工带来的收益。 但完成一次项目，还不够。 我们更在意的是：这个项目里纠正过的问题，下次能不能少出现一些？ 用 AI 久了，很容易遇到这种情况：它能复述你的要求，执行时却还是用了旧方法。 保存一段聊天记录，并不一定会改变后续行为。经验需要进入实际的规划、工具使用和检查过程。 在 Raven 中，EverOS 承接跨会话的上下文与经验，Playbook 保存成员、任务和依赖安排。我们进一步探索的是，让执行中的反馈能够修改 Harness 本身。 这与 RSI，也就是递归自我改进有关：系统利用执行结果和反馈，改进产生这些结果的机制。 这种改进不一定发生在模型参数上，也可以发生在提示、策略代码、工具规则和工作流程中。 例如，一个旅行规划 Agent 经常安排跨区折返。用户指出问题后，后续规划可以增加区域优先的安排方式，并在交付前检查交通与步行负担。反馈如果落实成这样的执行变化，就不需要每次重新提醒。 Raven V0.2.0 中的 Curator 是这方面的实验性实现。它结合任务要求、执行记录和用户反馈生成 Harness 改动，经过声明检查、实际装配与预检后安装；安装失败时，触发恢复流程。 用户提出的要求，由此有机会成为后续任务实际采用的方法。 自我改进最需要验证的，是“改进”这两个字。 修改了提示或代码，只能说明系统发生了变化。当前任务表现更好，其他任务有没有退步？提升是否能重复出现？额外消耗的时间和 Token 是否值得？评价标准能否保持独立？ 这些问题不能靠一次漂亮的演示回答。 目前，Curator 已在模拟案例中完成多轮反馈与修改，但跨场景、重复实验和长期效果仍需要继续验证。专业能力评测也不能直接作为自我改进有效的证据。 对 Raven 来说，DAG 负责组织当前任务，专业 Harness 负责执行，记忆和 Playbook 保留可以复用的信息与安排，Curator 则探索如何根据反馈调整工作机制。 这些设计最终应该减少的是人的重复劳动，而不是人的判断权。 目标是什么、哪些行为不能接受、资源有限时如何取舍、什么结果可以交付，仍然需要由人决定。 我们最希望的是一个项目结束时，留下的不只有作品，还有完成这类工作的经验。 下一次面对类似问题，我们能从这些经验继续，而不是重新解释背景、重复同样的纠正。 模型会更新，工具会更换。我们在真实工作中积累的判断，应该能够保存下来，并继续发挥作用。 Raven 0.2.0，带着最先进的理念以及强大的功能，开放给大家！欢迎体验！ @evermind