一步演化

概述

本技能将“火龙果架构”（火龙果架构）部署至全新的 OpenClaw 环境中，使最终系统具备长期稳定运行的能力。该架构面向单一强健的 main 代理、一个极简的 rescue 代理、基于磁盘的分层内存、显式的演化循环、以文件承载的项目事实、低噪声的心跳机制、精准的定时任务（cron），且仅采用官方认证的集成组件。

请参阅 fire-dragon-fruit-architecture.md 了解其定位与差异化特性；参阅 architecture.md 了解目标设计；参阅 checklist.md 获取实施操作手册与验收标准。

适用场景

当用户有以下任一需求时，请使用本技能：

• 直接在全新 OpenClaw 环境中搭建火龙果架构
• 优先围绕 main 重建系统，并移除 lab
• 添加持久化内存，使其跨越会话生命周期并支撑持续性工作
• 添加心跳与 cron 机制，使系统可在无人值守状态下自主运行
• 重构代理拓扑结构，确保 fallback 与 rescue 不干扰主脑逻辑
• 通过官方机制统一 Feishu 集成、运行时路径及项目结构
• 如有需要，将旧版 OpenClaw 安装规范化为同一架构

请勿将本技能用于微小的单文件调整或单条 prompt 优化。本技能专用于系统级的 OpenClaw 架构重构。

目标状态

期望达成的终态即为火龙果架构，具体包括：

• 一个强健的 main 代理作为核心决策大脑
• 一个极简的 rescue 代理，仅用于紧急连续性保障
• 稳态生产拓扑中不包含 lab
• 每台机器仅部署一个 gateway
• 以前沿托管模型作为主推理引擎
• Ollama 仅用于 memorySearch.provider = "ollama" 的嵌入向量生成，除非用户明确要求更多本地推理能力
• 基于磁盘的分层内存结构：
  • MEMORY.md
  • memory/YYYY-MM-DD.md
  • memory/topics/*.md
• 项目事实以文件形式固化，而非依赖聊天历史：
  • projects/INDEX.md
  • projects//PRD.md
  • projects//PROGRESS.md
  • projects//EXECUTION_PLAN.md
• 角色行为通过技能（skills）或显式模式（modes）实现，而非大量长期驻留的业务代理
• 通过 heartbeat 执行低噪声维护任务，通过 isolated cron 执行计划性工作
• 仅使用官方 @openclaw/feishu
• 采用固定运行时路径，避免依赖脆弱的版本管理器专属服务入口点

核心能力

本技能每次成功实施后，必须在文件结构与运行时行为中清晰体现以下三项能力。

1. 内存能力

系统需具备跨会话持久化的内存能力，并支持检索、维护与随时间演进的升级。

必需的文件结构：

• MEMORY.md：承载稳定、经人工筛选的核心事实
• memory/YYYY-MM-DD.md：记录每日事实性日志
• memory/topics/*.md：存放常青知识（evergreen knowledge）
• projects/INDEX.md 及各项目下的事实文件，确保工作上下文不被锁死在聊天记录中

必需的运行行为：

• 每日事实自动归入带日期戳的日志文件
• 可复用的模式被提升至 topic 文件中
• 仅高信噪比的核心事实保留在 MEMORY.md 中
• 活跃项目始终可通过文件完整恢复，无需依赖聊天记录

2. 演化能力

系统应能通过文件更新与工作流加固实现自我改进，而非依赖模糊的“模型自动学习”宣称。

必需的运行行为：

• 启用 reflect-mode 或等效机制，定期回顾近期每日日志、项目进展与失败案例
• 成功模式被提升至 memory/topics/*.md、MEMORY.md 或私有技能中
• 失效指令、无响应 prompt、过时工作流分支被主动清理
• 高频重复行为被升级为显式技能或写入标准化操作规程（SOP）文档
• 改进效果须以业务成果或运营成效为衡量依据，而非代理表面的“忙碌程度”

3. 调度能力

系统应在用户离线期间持续运转。

必需的运行行为：

• heartbeat 承担低噪声健康检查、停滞任务识别、审批队列处理与内存清洁等任务
• 常规 cron 承担定时可见输出任务，例如进度通报或晨间聚焦提醒
• isolated cron 承担较重负载的反思、综合分析、文档整理与内存升级任务
• 所有定时任务均须指向真实存在的文件与明确的实际目的
• 副作用行为必须受控于审批门禁或确定性工作流

模板套件

本技能附带一套开箱即用的初始工作区模板，位于 assets/templates/workspace/ 目录下。

使用方式如下：

• 从 assets/templates/workspace/ 复制缺失的根目录文件
• 基于提供的主题模板填充 memory/topics/
• 基于提供的角色技能骨架填充 skills/*-mode/
• 复制 projects/example-project/ 并重命名为实际项目名称
• 将 AUTOMATION.md 适配为目标机器的真实 heartbeat 与 cron 配置
• 若 rescue 尚未存在，可从 assets/templates/rescue/ 单独初始化一个极简的 rescue 工作区

重要提示：

• 对于全新 OpenClaw 环境，请将这些模板视作默认起点
• 若工作区已包含有价值的项目事实，请谨慎合并
• 切勿用模板占位符覆盖真实的项目历史
• 先借助模板使系统逻辑显式化，再根据具体机器与用户需求进行定制

工作流

1. 检查当前系统

在任何修改前，请先全面检查真实安装环境，并总结以下信息：

• 代理列表及其路由策略
• 当前 gateway 模式与运行时路径
• 模型策略（主模型与嵌入模型）
• 内存布局现状
• 已安装的技能列表
• Feishu 绑定配置
• 现有 heartbeat 与 cron 任务
• 已含有效事实的项目目录

尤其关注重复代理、半废弃实验、自定义 sidecar 组件，以及任何可能静默覆盖预期拓扑的配置项。

若为全新安装，本步骤可简略执行，仅用于确认基线状态，以便后续应用模板。

2. 重构代理拓扑

向以下目标重构：

• main 作为唯一日常运行的核心大脑
• rescue 作为独立的应急代理，仅保留最小化内存与技能集
• 除非用户明确要求研究型 sandbox，否则不保留 lab

规则：

• main 与 rescue 的内存文件不得相互依赖
• rescue 不得执行常规业务规划或学习循环
• 若存在第二个外部账号，仅在确保不引发跨代理干扰的前提下，将其路由至 rescue 以保障连续性

3. 重建内存层

新建或修复基于文件的内存系统：

• MEMORY.md：承载人工筛选的持久化核心事实
• memory/YYYY-MM-DD.md：记录每日事实性日志
• memory/topics/*.md：存放常青知识，如用户信息、产品方案、工作流、通信渠道与运营规则

MEMORY.md 应保持精简、高信噪比，切勿沦为信息垃圾场。

构建一条清晰的“晋升路径”，而不仅是存储容器：

• 原始事实首先进入每日日志
• 反复验证有效的事实迁移至 memory/topics/*.md
• 仅真正持久的运营事实进入 MEMORY.md
• 归档的项目结论写入对应项目文件

若项目已存在，请确立基于文件的事实源：

• projects/INDEX.md 显式声明活跃项目
• 每个活跃项目须包含 PRD.md、PROGRESS.md 和 EXECUTION_PLAN.md
• heartbeat 与 cron 指令必须显式引用上述项目文件

若上述文件缺失，请从 assets/templates/workspace/projects/example-project/ 初始化，并替换占位符为真实项目数据。

4. 将行为转化为技能与模式

优先采用单一 main 加角色技能（role skills）的模式，例如：

• scout-mode
• closer-mode
• ops-mode
• reflect-mode

除非存在硬性路由或权限隔离需求，否则不应将这些角色拆分为多个长期驻留的代理。

实现时，请将持久化运营逻辑迁移至以下位置：

• skills/ 目录
• AGENTS.md
• HEARTBEAT.md
• 项目事实文件

切勿将核心运营规则埋藏于临时聊天记录中。

若角色技能缺失，请从 assets/templates/workspace/skills/ 初始化。

5. 以稳健方式重建自动化机制

请使用：

• heartbeat 执行低噪声检查、停滞任务检测、审批队列处理与内存清洁
• 常规 cron 执行面向用户的定时更新
• isolated cron 执行高负载的反思、清理与文档维护任务

自动化规则：

• 保持 heartbeat 轻量、低成本
• 以项目文件为唯一事实源
• 对重型定时任务优先采用隔离会话（isolated session）
• 所有外部副作用行为必须置于显式审批门禁或确定性工作流控制之下

若当前安装缺乏有效调度节奏，请建立默认蓝图：

• heartbeat：在活跃时段每 30 分钟执行一次，涵盖健康检查、停滞任务识别与待批事项
• 主 cron：执行定时运营更新，如每小时进度通报或晨间聚焦
• isolated cron：每晚执行反思与内存维护

确保所有定时任务均明确引用其应读取与更新的实际项目文件。

若当前安装完全缺失调度文档，请从 assets/templates/workspace/AUTOMATION.md 启动。

6. 部署显式演化循环

添加周期性改进循环，使系统持续进化，而非仅累积冗余。

最小可行循环包括：

• 读取近期 memory/YYYY-MM-DD.md 日志
• 检查当前项目事实文件
• 识别重复的成功经验、失败案例与陈旧指令
• 将稳定规则晋升至 memory/topics/*.md 或 MEMORY.md
• 将高频重复工作转化为技能或持久 SOP 文档
• 删除或重写不再起效的 prompt 垃圾

演化循环必须在文件中可见。其他操作员打开工作区时，应能清晰看到系统的学习路径。

7. 标准化集成与运行时环境

尽可能使用官方组件：

• 官方 @openclaw/feishu
• 官方 Ollama 嵌入路径用于 memory search
• 固定运行时路径用于 gateway 或服务脚本

请避免：

• 在官方包已满足需求时引入非官方 Feishu fork
• 在官方 Ollama 嵌入可用时，额外部署 ad hoc 嵌入 sidecar
• 使用仅适配特定 shell 或版本管理器会话的脆弱服务包装器
• 在托管主模型已稳定且预算充足时，默认额外加载小型本地文本模型

8. 验证、清理与收尾

完成所有编辑后，请执行以下检查：

• 验证代理拓扑是否符合目标状态
• 验证内存布局是否已在磁盘上正确建立
• 验证 heartbeat 与 cron 是否指向真实文件与真实任务
• 验证内存晋升与反思路径是否显式定义
• 验证 Feishu 路由是否为有意设计
• 验证模型配置是否准确反映主模型与嵌入策略
• 清理已废弃代理、空置目录与误导性文档
• 运行相关验证命令
• 若代码仓库存在且用户期望版本化变更，请提交最终结果

防护准则

• 默认不得重新引入 lab
• 技能足以满足需求时，不得创建大量代理
• 不得将项目事实仅存储于聊天记录中
• 不得将 rescue 设计为 main 的影子副本
• 除非存在明确的可靠性或成本考量，否则不得默认安装额外本地文本模型
• heartbeat 与 cron 必须关联真实文件并具备明确的成功判定标准
• 除非演化循环已在文件与调度中显式体现，否则不得宣称“持续学习”

交付成果

当本技能被正确使用后，最终系统应达到如下状态：

• main 可持续执行日常运营任务
• rescue 存在但保持隔离且静默
• 关键事实因落盘而跨会话持久存在
• 各项目均拥有显式定义的事实文件
• heartbeat 与 cron 保障工作持续推进
• 整体配置易于其他操作员或另一 Codex 快速复现