别再调 Prompt 了：我用一套 Markdown，让 OpenClaw 40 天越用越聪明

40 天前，我的内容 Agent 写出来的东西像“模板拼接”：热闹但没重点；研究 Agent 更惨——真正的信号被噪音淹没。我改稿改到怀疑人生，甚至觉得“这玩意还不如我自己做”。

40 天后，我几乎没再改架构，也没换模型。每天早上打开 Telegram，看一眼草稿，做几个取舍，然后去喝咖啡。团队里多个 Agent 24/7 在跑：有人专职研究，有人专职写作，有人负责运营和自检。

差别不在 Prompt，而在磁盘上的一套文件栈：它会随着反馈变得更具体、更贴近我，也更不容易犯同样的错。

本文按“更克制的技术文风”把这套栈拆开：你照着做，不需要天才提示词，也能把 Agent 养成“越用越懂你”的团队。

一、三层文件：我的“智能体操作系统”

我把整个系统拆成三层，每一层都是 Markdown 文件：

Identity（身份）：它是谁、为谁服务（SOUL.md / IDENTITY.md / USER.md）
Operations（操作）：它怎么工作（AGENTS.md / HEARTBEAT.md / 角色专用指南）
Knowledge（知识）：它学到了什么（MEMORY.md / daily logs / shared-context/）

没有消息队列，没有数据库，没有“复杂编排”。文件系统就是集成层。

二、Layer 1：Identity —— 先把“它是谁”写清楚

1）Relationships：从一个 Agent + 一个高频任务开始

不要一上来就拉满多个 Agent。你会得到一堆“看起来能干活”的角色，但没有稳定交付的流程。

更有效的顺序是：

选你每天最重复的一件事
只做一个 Agent
初稿允许一般
接下来一个月，基于真实使用反复迭代（10 次很正常）

目标不是一次写完美，而是让系统进入真实工作流，然后持续修正。

2）IDENTITY.md：名片文件，小但提升巨大

SOUL.md 是完整人格；IDENTITY.md 是名片：名字、角色、气质、一句话介绍。

当你同时跑多个 Agent 时，这张“名片”会显著降低管理成本：你能立刻判断“谁在说话、他负责什么、他应当用什么口吻”。

3）USER.md：个人细节会产生复利

每个 Agent 都要知道自己在服务谁。USER.md 写一次，全员读取。

时区、写作偏好、背景、禁忌……这些看似琐碎，但会不断出现在输出里。写进去一次，就能减少无数次“同一句纠正”。

三、Layer 2：Operations —— 它怎么开工、怎么记、怎么不犯错

1）AGENTS.md：把“开机流程”写死

现实是：Agent 在会话之间没有记忆。断线重连，它就像刚出生。

因此我会在 AGENTS.md 里写清楚会话启动顺序：先对齐身份与服务对象，再读取最近上下文，最后再进入任务。

并且写一句硬规则：

如果纠正没有写进文件，那么下次会话它就不存在。

这条规则会逼系统走向“落盘”。

2）专业文件（Specialist files）：按“纠错频率”生长

不要在第一天就写一堆指南。

我的规则是：

只有当某个问题反复出现、你需要一遍遍纠正时，才新增一个专业文件。

例如写作 Agent 的风格指南、格式参考、案例库、每日任务清单等，都应当从实际纠错中长出来。

3）HEARTBEAT.md：自检与自愈（在第一次故障后再做）

Agent 团队是基础设施。基础设施必然会坏。

最危险的故障不是报错，而是“看起来都在跑，但关键环节已经断了”。例如浏览器挂了导致研究扫不到，或 cron 任务悄悄停摆导致全链路用的是过期输入。

我的建议：第一天不需要 HEARTBEAT。等第一次失败后再补，因为那时你会非常清楚需要监控什么。

四、Layer 3：Knowledge —— 让系统“越用越聪明”的分层记忆

能工作的记忆系统，不是“记住一切”，而是分层过滤。

Tier 1：MEMORY.md（长期精选记忆）

MEMORY.md 不是日志，只存两类：

稳定偏好（会长期复用）
惨痛教训（踩过一次就要永久免疫）

一次纠正，写进去一次，未来每次会话自动生效。

Tier 2：daily logs（每日日志：原材料）

daily logs 是流水账：今天发生了什么、交付了什么、反馈是什么。

它的意义在于：你无需一开始就写“永久规则”。先记录真实工作，等模式出现，再提炼进 MEMORY.md。

维护规则很重要：日志会涨得非常快。

每次会话只加载：今天 + 昨天
每两周审查一次旧日志：归档/压缩/提炼

否则上下文膨胀会拖垮输出质量。

Tier 3：整理好的记忆目录 + shared-context（跨 Agent 对齐）

当系统变大，你需要结构化目录（按人或按项目都行）。

我认为最有价值的新增层是 shared-context/：所有 Agent 开工时都会读取的共享对齐层。

THESIS.md：当前关注点/世界观/写过什么/还缺什么
FEEDBACK-LOG.md：跨 Agent 的纠错层（一次纠正，全员生效）
SIGNALS.md：持续追踪的趋势与资料

五、协作不靠 API：只靠“文件交接”

我的协作方式非常简单：

一个 Agent 写文件，其他 Agent 读文件。交接就是磁盘上的 Markdown。

这里有一条关键工程规则：

one-writer rule：永远不要让两个 Agent 写同一个共享文件。

共享文件必须设计成：一个写入者 + 多个读取者。它能避免绝大多数协调冲突。

调度也很关键：上游先跑、下游后跑；顺序错了，下游读到的就是空文件或过期内容。

六、把目录树换成我的真实版本（Alan-Workspace / 莫菲）

下面这份结构，与你现在的 Vault 约束一致（包含 rules/、01-Articles/、04-Memory/ 等）。它不是唯一解，但符合“能跑、可维护、可扩展”的目标。

Alan-Workspace/
├── SOUL.md                 # 莫菲（Murph）人格与边界
├── IDENTITY.md             # 名片（简版身份）
├── USER.md                 # 蓝葛格偏好与背景（服务对象）
├── AGENTS.md               # 工作区规则（会话启动顺序/落盘规范/目录分区）
├── HEARTBEAT.md            # 可选：巡检/心跳（默认可空）
├── TOOLS.md                # 本机环境备注（私有）
├── INDEX.md                # Vault 入口
├── rules/
│   ├── frontmatter-spec.md # frontmatter 规范
│   └── openclaw-writing-workflow.md
│
├── 00-Inbox/               # 临时收集
├── 01-Articles/            # 公众号/技术文章/复盘（可发布）
├── 03-Projects/            # 可执行资产/项目说明
├── 04-Memory/              # 系统级记忆（topics/daily/core/prefs...）
├── 05-Daily/               # 每日/周期性产出
├── 99-Attachments/         # 附件
│
├── shared-context/         # 跨任务/跨角色共享对齐层（可选）
│   ├── THESIS.md           # 当前关注点/写作主题地图
│   ├── FEEDBACK-LOG.md     # 跨场景纠错（一次写入，多处生效）
│   └── SIGNALS.md          # 追踪中的信号/资料
│
└── memory/                 # 运行期日志/原始记录（建议只加载今日+昨日）
    ├── 2026-04-06.md        # 今日操作日志（原材料）
    ├── 2026-04-05.md        # 昨日操作日志
    ├── shared/              # 可选：按项目/主题整理
    └── alan/                # 可选：私密个人笔记（注意权限与加载范围）

说明：

你当前工作区已经有 04-Memory/（系统级记忆镜像）。上面的 memory/ 更偏“运行期 daily logs”。两者可以并存：一个用于“结构化长期沉淀”，一个用于“短期流水账 + 提炼”。
shared-context/ 建议从空开始；当你开始反复纠正同一类问题（跨多任务/多角色复用）时再启用。

七、如何开始（时间表）

不要试图在一个周末搭完：

今天：写好 SOUL/IDENTITY/USER，挑一个高频任务，让它跑起来
3 天后：开始给具体反馈，并确保反馈落盘（日志/记忆文件）
1 周后：补齐/强化 AGENTS.md 的启动顺序与落盘规则
2 周后：回看 daily logs，把反复出现的纠错提炼进 MEMORY.md
第一次故障后：再写 HEARTBEAT.md（你会知道该监控什么）

你只需要持续出现、持续反馈。剩下的交给文件栈产生复利。