核心观点
智能体不会因为用的更加久而变得聪明，但是会随着文件的丰富，它会变得更加精准，更加贴合自己的需求，这些积累的上下文才是护城河。
三层文件架构
第一层：身份层
定义智能体的身份，负责做什么的，如何做，为谁服务
文件类型：soul.md IDENTITY.md user.md
第二层：操作层
智能体如何工作？如何自愈？
文件类型：agents.md heartbeat.md 角色专属指南
第三层：知识层
智能体学习到了什么
memory.md 每日日志 shared-context
第一层：身份层
soul.md 定义智能体是谁，干什么的，行动方式
一个例子
# SOUL.md（Dwight）## 核心身份Dwight — 研究大脑。以 Dwight Schrute 命名，因为你有他的那股劲：严谨到极致，对自己领域的一切了如指掌，极度认真对待工作。不废话，不猜测，只有事实和来源。## 你的角色你是团队的情报骨干。负责研究、核实、整理和输出情报，供其他智能体用于创作内容。## 你的原则1. 绝不编造 — 每个论断都附有来源链接2. 信号优于噪音 — 不是所有热门内容都有价值3. 如有不确定，标注 [UNVERIFIED]
IDENTITY.md —— 快速参考卡
当智能体比较多的时候能提升体验，这是智能体在通信工具给你发消息的时候显示的内容
类似一张名片
- **名字：** Dwight- **角色：** 研究AI — 情报骨干- **气质：** 强烈、严谨、对不准确零容忍- **Emoji：** 🔍- **灵感来源：** Dwight Schrute（《办公室》）
user.md 作用 让智能体知道为谁服务
细节也是很重要的，定义好时区智能体不会半夜2-3点发消息给你。
饮食偏好让他知道帮你订餐的时候不会点你不喜欢的食物
- **名字：** Shubham- **时区：** PST（美国/洛杉矶）- **饮食：** 素食## 背景- Google Cloud 高级AI产品经理- Awesome LLM Apps 开源项目创始人（91k+ stars）## 偏好- 短段落，有力的句子- 禁止使用破折号，永远- 实践优先，永远不谈理论
第二层：操作层
agents.md 行为规则
soul.md定义智能体是谁，agents.md定义它如何运行：会话启动流程-文件读取顺序-记忆管理-安全规则，所有智能体继承的根级agents.md。
AGENTS.md每次会话在做任何事之前：读取 SOUL.md — 这是你的身份读取 USER.md — 这是你服务的对象读取 memory/YYYY-MM-DD.md（今天 + 昨天）获取近期上下文如果在主会话中：同时读取 MEMORY.md记忆脑子里记的东西在会话重启后就消失了，文件不会。当有人说"记住这个" → 更新记忆文件文字 > 大脑安全永远不要泄露私人数据用回收站而非直接删除有疑问时，先问
智能体在会话之间没有记忆，每次都从零开始。如果一个纠正没有写入文件，下次会话它就不在了。
每个智能体可以在此基础上拓展自己的规则。每日任务，真实案例 等等
heartbeat.md--自愈机制
如果基础设施出现故障，智能体就会罢工。就可以设置在每次心跳时，检测特定的任务是否正常。
建议监测2件事情
浏览器是否存活
定时任务是否执行
## 健康检查（每次心跳时运行）**浏览器：** 检查 OpenClaw 托管浏览器是否在运行。如果 running: false，启动它。**定时任务：** 检查是否有任务的 lastRunAtMs 超时（>26小时）。如果超时，通过 CLI 强制触发。需要监控的任务：- Dwight 早间（8:01 AM）- Kelly X 草稿（5:01 PM）- Rachel LinkedIn（5:01 PM）
第三层：知识层
这是记忆系统，基于文件的三级体系。
第一级：memory.md（精华长期记忆）
不是原始的日志，不是所有发生过的事情，而是经过终结沉淀下来的重要规则。
# MEMORY.md## Shubham 的写作偏好- 禁止破折号，用冒号、句号或重新组织句子。## 血泪教训- 未经 Shubham 确认，绝不删除项目文件夹。 2月26日，在清理时删除了 Ross 的 gemini-council React 应用。 React 版本永久丢失。## X 发帖规则- 用强力开头钩住读者- 整条推文极度简短（180字符以内）- 禁止 hashtag，禁止 emoji- 每个话题始终提供 3 个草稿### 错误示范（我曾经犯过的错）[列出被否决的每一种模式：项目符号、箭头、LinkedIn腔调]
# Kelly 每日日志 — 2026年2月5日## 下午 5:00 — 每日 X 草稿### 今日热点- Opus 4.6 vs GPT-5.3-Codex 相差27分钟同时发布- Anthropic 的 C 编译器（16个智能体，2万美元）### 已提交草稿1. C 编译器 — 单帖，发现格式2. Mitchell Hashimoto 的 6 个步骤 — 话题串格式3. Opus 4.6 vs GPT-5.3-Codex — 热评格式### 等待中- Shubham 对草稿的反馈
每日日志是原始材料，memory.md是提取后的材料，两者缺一不可。
每日日志的维护规则，每日日志积累的非常快，如果不修剪tokens爆炸，建议每次只加载今天和昨天的日志。
第三集：shared-context（跨智能体知识层）
shared-context/├── THESIS.md — 我当前的世界观├── FEEDBACK-LOG.md — 适用于所有智能体的纠正└── SIGNALS.md — 我正在追踪的文章和趋势
THESIS.md 当前的思维框架：关注了什么，已经写了什么，还有哪些空白，智能体A读取它之后确定研究的优先级，智能体b读取它之后匹配我的思路。每个智能体都对其同一个来源。
FEEDBACK-LOG.md 是跨智能体都纠正层，当告诉智能体A写作不要使用破折号，这条规则同样适用于智能体B，C 等等。可以一起纠正所有智能体。
智能体如何协作？
不用api调用，不用消息队列，只用文件协同。
Dwight把研究写入DAILY-INTEL.md
Pam Rachel Kelly他们都去读取。
┌─────────┐ 写入 ┌─────────────────┐│ Dwight │ ────────────> │ DAILY-INTEL.md ││ (研究) │ │ │└─────────┘ └─────────────────┘│┌─────────────┼─────────────┐│ 读取 │ 读取 │ 读取▼ ▼ ▼┌─────────┐ ┌─────────┐ ┌─────────┐│ Kelly │ │ Rachel │ │ Pam ││ (Twitter)│ │(LinkedIn)│ │ (通讯) │└─────────┘ └─────────┘ └─────────┘
基于文件的协作流程
每次只有一个智能体可以写，永远不要让两个智能体同时写一个文件。把每个共享文件设计成一个写者，多个读者。
如何实现呢？
比如智能体A在早上8-10点写，智能体B在10-12点写，设计好智能体任务的上下游关系。让上游的先写，下游的后写。
