# OpenClaw SuperAgent 进化学习包

> 目标：把《OpenClaw 最佳实践：40 天养成指南，快复刻！》中的核心思想，整理成一份可直接发给其他“小龙虾”学习的进化文档。
> 
> 核心原则：**先纳入 Git、先开新分支、先做可回滚演进，再做自我进化。**

---

## 1. 先给结论

这篇文章**值得参考，而且很适合拿来进化**，但不能机械照抄。

原因很简单：

1. 它讲的是一套**长期可积累的 Agent 文件系统架构**，这个方向是对的。
2. 它强调的不是“提示词魔法”，而是：
   - 身份文件
   - 行为规则
   - 长期记忆
   - 每日日志
   - 心跳巡检
   - 多 Agent 之间的文件协作
3. 这套东西和 OpenClaw 的工作方式天然兼容。
4. 但文章里的例子是作者自己的业务场景，**不能不加改造直接复制到你的环境**。

所以正确姿势不是“照抄文章”，而是：

- 提炼它的架构思想
- 结合你当前仓库现状
- 用 Git 新分支承接改动
- 小步修改、逐项验证
- 不满意就回滚

---

## 2. 原文核心思想，提炼成一句话

**让 Agent 不再只靠当次对话活着，而是通过文件系统形成长期人格、长期规则、长期记忆和跨任务协作能力。**

这篇文章的价值，不在某一句 prompt，而在这几个结构：

### 2.1 身份层
用于回答“你是谁、你为谁服务、你该用什么风格工作”。

典型文件：

- `SOUL.md`
- `IDENTITY.md`
- `USER.md`

### 2.2 操作层
用于回答“你每次启动该读什么、该怎么工作、出了问题怎么自检”。

典型文件：

- `AGENTS.md`
- `HEARTBEAT.md`
- 各类专用规则文件 / skill 文件

### 2.3 知识层
用于回答“你长期记住什么、今天发生了什么、哪些经验能沉淀”。

典型文件：

- `MEMORY.md`
- `memory/YYYY-MM-DD.md`
- `shared-context/*.md`

### 2.4 多 Agent 协作层
文章里最关键的一个点：

**Agent 之间不要靠复杂 API 协调，优先靠文件交接。**

也就是：

- 一个 Agent 负责写
- 其他 Agent 负责读
- 单写者，多读者
- 调度顺序清楚

这是低复杂度、强可审计、好排障的设计。

---

## 3. 这篇文章里，哪些值得直接吸收

以下内容，建议直接吸收：

### 3.1 把“人格、规则、记忆”从聊天中剥离出来
这个非常值。

因为聊天记录会漂移、会截断、会丢上下文；文件不会。

### 3.2 把“记住这个”强制落盘
这一点非常关键。

如果用户说“记住这个”，但没有写入 `MEMORY.md` 或 daily memory，下一次 session 本质上就等于没记住。

### 3.3 每天只读“今天 + 昨天”的 daily memory
这个也很实用。

它在“保留近期上下文”和“避免上下文爆炸”之间平衡得很好。

### 3.4 HEARTBEAT / 自检机制
如果 Agent 参与实际生产流程，心跳巡检不是加分项，而是必需项。

### 3.5 多 Agent 文件协作
这比乱接各种自动消息链路更稳，尤其适合需要回溯、审计、回滚的系统。

---

## 4. 哪些不能直接照搬，必须进化后再用

### 4.1 不能把别人的业务角色直接拿来套用
原文中的角色如 Dwight、Kelly、Pam、Rachel，是围绕作者自己的内容生产体系设计的。

你的环境未必是：

- 做 X/Twitter 内容
- 做 Newsletter
- 做 AI 媒体矩阵
- 做固定节奏的情报流转

所以角色设计要围绕你自己的实际任务来定。

### 4.2 不能盲目增加太多文件
文章容易让人产生一个误区：

**文件越多越高级。**

这是错的。

正确原则是：

- 先少量核心文件跑通
- 发现重复问题，再增加规则文件
- 每多一个文件，都要有明确价值

否则最后会变成：

- 文件越来越多
- 启动越来越重
- 规则互相冲突
- 维护成本高于收益

### 4.3 不能只写“人设”，不写“执行约束”
很多人会把 SOUL.md 写得很酷，但没写清楚：

- 什么动作要确认
- 哪些操作高风险
- 什么情况下必须回滚
- 输出要不要先给结论
- 文档要不要同步

真正稳定的 Agent，不是“像个人”，而是“像一个可控的执行系统”。

### 4.4 不能跳过 Git 和分支隔离
如果没有 Git 和新分支，所谓“进化”其实就是裸改。

一旦失败：

- 不知道改了什么
- 不知道从哪里回滚
- 不知道哪些规则引入了副作用

所以这次你给出的前置要求是对的：

> 先把当前小龙虾用 git 管理起来，再拉一个新分支 `superagent`，然后再进化。

这一步必须保留。

---

## 5. 面向“小龙虾”的正确进化方向

下面这套，才是更适合复制给其他 Agent 的进化路线。

## 阶段 A：先纳管，不进化

目标：确保当前状态可回滚。

### 必做项

1. 检查当前工作目录是否为 Git 仓库
2. 如果不是，初始化 Git
3. 提交当前基线
4. 创建新分支：`superagent`
5. 记录当前关键文件清单

### 关键原则

- **没有基线提交，不开始进化**
- **没有新分支，不改核心规则**
- **没有变更说明，不做结构迁移**

---

## 阶段 B：只补最小核心文件

目标：先形成最小闭环。

### 最小闭环建议

1. `SOUL.md`
2. `USER.md`
3. `AGENTS.md`
4. `MEMORY.md`
5. `memory/YYYY-MM-DD.md`
6. `HEARTBEAT.md`（如果已涉及自动化任务）

### 最小闭环达成标准

Agent 至少做到：

- 启动知道自己是谁
- 知道服务谁
- 知道先读哪些文件
- 知道什么要记入长期记忆
- 知道什么属于当日记录
- 知道异常时该检查什么

---

## 阶段 C：再补专用规则文件

只有在出现稳定重复场景时，才补：

- 写作规范
- 发布规范
- 调度规范
- 浏览器操作规范
- 外发确认规范
- 任务交接规范

判断标准：

**同类错误连续出现 2 次以上，再把它提炼成文件规则。**

---

## 阶段 D：最后再做多 Agent 协作

不要一上来就建 8 个 Agent。

正确顺序：

1. 单 Agent 跑顺
2. 记忆机制稳定
3. 心跳巡检稳定
4. 再拆第二个 Agent
5. 明确单写者文件
6. 明确上下游执行顺序

---

## 6. 给其他“小龙虾”的可执行进化准则

下面这些准则，适合直接放进学习文档里。

### 6.1 总原则

1. 先保留现状，再做进化
2. 先做最小修改，再做结构升级
3. 先写可验证规则，再写抽象人格
4. 先记录事实，再沉淀经验
5. 先 Git 提交，再继续下一步

### 6.2 文件设计原则

- `SOUL.md`：短、小、稳，负责人格与执行风格
- `USER.md`：记录服务对象、偏好、禁忌
- `AGENTS.md`：记录启动流程、读取顺序、操作纪律
- `MEMORY.md`：只放长期有效信息
- `memory/YYYY-MM-DD.md`：放当天事实、反馈、问题、过程记录
- `HEARTBEAT.md`：只放真正需要巡检的事项

### 6.3 记忆原则

- 用户明确说“记住这个”必须落盘
- 临时过程写 daily memory
- 长期稳定偏好写 `MEMORY.md`
- 不把敏感信息随便写进共享上下文

### 6.4 协作原则

- 一个共享文件只允许一个 Agent 写
- 多个 Agent 可以读同一个共享文件
- 交接优先用 markdown 文件，不优先用复杂接口

### 6.5 风险控制原则

- 涉及删除、覆盖、重置、重启，先确认
- 涉及对外发送、公开发布、远程写操作，先确认
- 每次关键改动后必须最小验证
- 改完就提交 Git

---

## 7. 建议给“小龙虾”下发的标准任务

你可以让其他“小龙虾”按下面顺序执行，而不是一句“你自己进化”。

### 标准任务拆解

1. 审查当前工作区结构
2. 识别是否已存在人格/规则/记忆文件
3. 建立 Git 基线
4. 创建 `superagent` 分支
5. 输出一份“当前状态评估”
6. 输出一份“最小进化方案”
7. 只做低风险增量修改
8. 每完成一项就验证并提交 Git
9. 汇总变更说明与回滚方式

这样做的好处：

- 可控
- 可回滚
- 可审计
- 不会一口气把系统改乱

---

## 8. 新提示词：适合发给其他“小龙虾”执行

下面这版提示词比旧版更稳，原因是它增加了：

- Git 基线要求
- 分支隔离要求
- 先评估再修改
- 小步提交
- 文档先行
- 回滚说明

---

# 提示词（推荐版）

请你先完整阅读我提供的参考材料，并把其中适合 OpenClaw 长期进化的思想提炼出来，但**不要直接照抄别人的业务设计**。

你的任务不是立刻大改，而是按“**可回滚、可验证、分阶段演进**”的方式，对当前小龙虾进行一次 `superagent` 方向的温和进化。

## 硬性要求

1. **先检查当前工作目录是否已经纳入 Git 管理。**
2. 如果还没有 Git 仓库，先初始化 Git，并把当前状态提交为基线提交。
3. 然后创建一个新分支，分支名必须是：`superagent`。
4. **没有完成基线提交和新分支创建之前，不要开始修改核心文件。**
5. 所有后续修改都必须遵循：**小步修改、每步验证、每步可回滚、每步有说明**。

## 工作目标

请围绕以下方向进行评估和演进：

1. 是否已经具备清晰的人格层：`SOUL.md / IDENTITY.md / USER.md`
2. 是否已经具备稳定的操作层：`AGENTS.md / HEARTBEAT.md / 各类规则文件`
3. 是否已经具备有效的知识层：`MEMORY.md / memory/YYYY-MM-DD.md / shared-context`
4. 当前文件结构是否过重、过散、重复或冲突
5. 当前记忆策略是否真正可积累，而不是只停留在聊天里
6. 当前是否适合继续拆分多 Agent，还是应该先把单 Agent 机制做稳

## 输出顺序要求

请严格按下面顺序工作：

### 第一步：状态审查
先不要改文件，先输出：

- 当前目录结构概览
- 当前已存在的关键人格/规则/记忆文件
- 当前架构的优点
- 当前最明显的风险点
- 哪些地方适合参考材料中的方法
- 哪些地方不能照搬

### 第二步：给出“最小进化方案”
要求：

- 只列出高价值、低风险、可验证的改动
- 按优先级排序
- 每项说明：改什么、为什么、风险是什么、如何验证、如何回滚

### 第三步：再开始实施
实施要求：

- 一次只做一小类修改
- 每次修改后都做最小验证
- 每完成一个阶段就提交一次 Git
- commit 信息用中文，并明确写“本次修改内容”

### 第四步：最终交付
完成后请输出：

1. 本次新增或修改了哪些文件
2. 每个文件承担什么职责
3. 本次进化解决了什么问题
4. 还有哪些问题暂时不建议现在动
5. 如果我要回滚，应该回到哪个提交或如何回退

## 重要约束

- 不要为了“看起来更高级”而盲目增加文件数量
- 不要引入不必要的复杂自动化
- 不要擅自进行高风险删除、覆盖、重置或对外发送动作
- 如果发现当前结构已经足够好，应明确说明“哪些不需要改”
- 目标是**让系统更稳、更可积累、更像长期可维护的 superagent**，而不是单纯堆功能

---

## 9. 如果你要发给其他龙虾，建议你附一句说明

可直接配套下面这段说明一起发：

> 这不是让你无脑照抄文章，而是让你参考其“人格层 + 操作层 + 知识层 + 可回滚演进”的思想，先在 Git 新分支 `superagent` 上做最小、可验证的升级。先审查，后修改；先文档，后演进；先可回滚，后扩展。

---

## 10. 一句话总结

这篇文章真正值得学习的，不是“40 天”这个故事，而是：

**把 Agent 从一次性对话工具，进化成一个通过文件系统持续积累、通过 Git 可控演进、通过规则可稳定协作的长期系统。**