# 火龙果架构说明

火龙果架构不是“给 OpenClaw 多装几个 agent”，也不是“把自动化堆满”。它是一套给全新 OpenClaw 直接落地的默认 operating model，目标是把 OpenClaw 变成一个强主脑、可持续推进、可跨会话记忆、可调度干活的个人经营控制中枢。

## 一句话定义

火龙果架构 = 一个强 `main` + 一个隔离 `rescue` + 分层文件记忆 + 项目真相文件 + 低噪音 heartbeat + 精确定时 cron + 可见的反思进化回路。

## 关键搜索词

为了让 OpenClaw 用户更容易发现这套方案，可以把它理解为这些关键词的组合：

- OpenClaw architecture
- OpenClaw memory
- OpenClaw heartbeat
- OpenClaw cron
- OpenClaw Feishu
- OpenClaw Ollama
- OpenClaw rescue
- OpenClaw main
- agent operating system
- personal operating system
- 火龙果架构
- 分层记忆
- 持续进化
- 调度任务
- 长期记忆
- 自动调度
- 飞书机器人
- 主脑架构
- 个人经营系统
- 智能体中枢

## 它解决什么问题

普通 OpenClaw 很容易掉进几种常见问题：

- 主脑不够强，靠多个 agent 互相推诿
- 记忆只停留在聊天上下文，跨会话就断
- 项目进展只存在对话里，没人知道当前真相
- 自动化只有“看起来很忙”，没有稳定节奏
- 所谓“自我进化”只是口号，没有文件化痕迹

火龙果架构就是为了解掉这些问题。

## 核心设计

### 1. 强 `main`

`main` 是唯一的日常主脑，负责：

- 全局判断
- 长期项目上下文
- 记忆整理
- 绝大部分日常调度

它不是众多 agent 之一，而是整个系统的默认中心。

### 2. 隔离 `rescue`

`rescue` 只负责应急连续性，不负责长期经营。

它的价值是：

- 主脑异常时还能有最小可用性
- 第二个渠道或第二个账号可以有兜底
- 不污染 `main` 的长期上下文

它不是第二个主脑，也不是变相 `lab`。

### 3. 分层文件记忆

记忆不靠模型“自己记住”，而是靠文件结构：

- `MEMORY.md` 放长期高价值真相
- `memory/YYYY-MM-DD.md` 放每日事实
- `memory/topics/*.md` 放 evergreen 知识
- `projects/*` 放项目级真相

这让系统跨会话、跨模型、跨操作者都能接得上。

### 4. 项目真相文件

每个活跃项目至少有：

- `PRD.md`
- `PROGRESS.md`
- `EXECUTION_PLAN.md`

这样 heartbeat、cron、reflect-mode 都有明确文件可读，不需要靠聊天历史猜。

### 5. 调度分层

火龙果架构不是只有“自动化”，而是调度分层：

- `heartbeat` 做低噪音巡检
- main `cron` 做定时可见输出
- `isolated cron` 做夜间整理、反思、记忆升级

这比把所有任务都塞进一个 agent 循环里稳定得多。

### 6. 可见的进化回路

火龙果架构不接受“它会自己学习”这种说法。

真正的进化要可见：

- daily log 持续记录事实
- `reflect-mode` 提炼有效经验
- topic files 与 `MEMORY.md` 持续升级
- 重复动作被升级成 skill 或 SOP
- 失效指令和死分支被清理

如果文件里看不到这些痕迹，就不叫进化。

## 和普通 OpenClaw 的差别

### 差别 1：不是多 agent 表演

很多做法会拆出 `main / lab / worker / planner / sender` 一串 agent。看起来很高级，实际常见结果是：

- 责任分散
- 记忆断裂
- 路由混乱
- 维护成本上升

火龙果架构默认反过来：

- 强化一个 `main`
- 能用 skills 解决的，不先拆 agent
- 只保留一个明确隔离的 `rescue`

### 差别 2：不是聊天记忆

很多系统把“最近聊过”误当成“系统记住了”。

火龙果架构默认要求：

- 记忆有文件入口
- 项目有文件真相
- 反思有文件痕迹

所以它不是“上下文堆栈”，而是“文件化操作系统”。

### 差别 3：不是忙碌自动化

很多自动化看起来每天都在跑，但没有稳定结果。

火龙果架构要求每个调度任务都能回答：

- 读哪些文件
- 产出什么
- 失败了怎么识别
- 为什么这个任务值得存在

不能回答这些的问题，就不该进调度层。

### 差别 4：不是口号式自我进化

火龙果架构只承认一种进化：

- 文件结构更清晰
- 记忆层更强
- 项目真相更完整
- 自动化更稳
- 重复工作更少依赖临场发挥

如果系统只是“越来越复杂”，那不是进化。

## 推荐模型与集成策略

- 主推理模型：优先最强 hosted model
- 本地模型：默认不为了“看起来本地化”而强上
- Ollama：默认只承担 embeddings / memory search
- Feishu：只用官方 `@openclaw/feishu`

核心原则很简单：

- 把最强的大脑给 `main`
- 把最稳定的本地能力给记忆层
- 把不必要的复杂度尽量删掉

## 适合谁

火龙果架构最适合：

- 想把 OpenClaw 做成长期经营系统的人
- 想让它能持续推进项目的人
- 想让别的 Codex 能快速接手的人
- 想让记忆、调度、反思都真正落盘的人

它不适合只想随便试一个临时 demo 的场景。

## 判断有没有落地成功

如果一个全新 OpenClaw 最终具备这些特征，就算真正落成火龙果架构：

- 只有一个明确强势的 `main`
- 有一个明确隔离的 `rescue`
- 有分层文件记忆
- 有项目真相文件
- 有 heartbeat / cron / isolated cron 分层
- 有 reflect-mode 或等价反思回路
- 新会话和新操作者都能迅速接上上下文

## 最终理解

火龙果架构的本质不是“做更多”，而是“让 OpenClaw 形成一个能长期运转、能持续变强、能稳定交接的真实系统”。