8个AI智能体全天运转，靠的不是模型升级而是一套Markdown文件体系

核心认知：智能体不会变聪明，但文件会变丰富

智能体不会因为你用得更久而变聪明，但它周围的文件会变得更丰富、更精准、更贴合你的需求。这些积累的上下文才是真正的护城河。

很多人把精力花在调prompt、换模型、研究编排框架上。但真正产生差异的不是模型本身，而是文件体系。没有消息队列，没有数据库，没有复杂的编排框架——整个系统就是磁盘上的Markdown文件，文件系统本身就是集成层。

三层文件架构

整个操作系统由三层构成，每一层解决一个核心问题：

第一层：身份层

SOUL.md——智能体的人格文件

定义智能体的身份、职责和行为方式。比如一个研究智能体Dwight，它的SOUL.md会描述它的角色定位、工作风格和输出标准。

IDENTITY.md——快速参考卡

SOUL.md是完整人格，IDENTITY.md是名片。文件很小，但当你同时跑8个智能体时，这个设计会大幅提升管理体验。它也是智能体在Telegram给你发消息时显示的身份标识。

USER.md——智能体服务的对象

每个智能体都需要知道它在帮谁。时区信息意味着智能体不会在凌晨3点给你安排事情；饮食偏好意味着负责通讯的智能体不会给素食者推荐牛排馆。这些个人细节会产生复利效应。

写一次，所有智能体都来读。

第二层：操作层

AGENTS.md——行为规则

SOUL.md定义智能体是谁，AGENTS.md定义它如何运作：会话启动流程、文件读取顺序、记忆管理、安全规则。

关键设计：智能体在会话之间没有记忆，每次都从零开始。如果一个纠正没有落入文件，下次会话它就不存在了。AGENTS.md明确了这一点，确保智能体把一切都写下来。

每个智能体可以在此基础上扩展自己的规则。比如内容智能体Kelly的AGENTS.md额外添加了写作风格指南、帖子格式参考、真实案例、每日任务等6个文件。

HEARTBEAT.md——自愈机制

智能体团队是基础设施，基础设施会出故障。心跳文件监控关键依赖：

• 浏览器是否存活（研究智能体的情报扫描依赖它）
• 定时任务是否正常执行（如果漏跑，下游智能体就会基于过时情报工作）

实战教训：第三周时调度器出现bug，任务在队列里推进但从未真正执行，好几个小时都没发现。此后才建了心跳机制。

建议：第一天不需要这个，在你第一次遇到故障之后再建。 你会清楚地知道该监控什么，因为你已经亲身感受过什么会崩。

第三层：知识层

这是真正有效的记忆系统——基于文件的三级体系。

第一级：MEMORY.md（精华长期记忆）

不是原始日志，不是所有发生过的事，而是真正重要的内容。重点关注"血泪教训"和"错误示范"两个板块。比如某个智能体曾经删了一个项目文件夹，这个错误从此永久写入它的长期记忆，再也不会重蹈覆辙。

一次纠正，存储一次，防止同样的错误在未来每次会话中重演。仅这一个机制，就比任何prompt工程指南都值钱。

第二级：每日日志（原始记录）

每日日志是原材料，MEMORY.md是精炼产品，两者缺一不可。

维护要点： 每日日志积累速度很快，不修剪的话智能体的上下文会膨胀。Kelly的日志一度达到161,000 tokens，输出质量急剧下降，不得不压缩到40,000。实操建议：每次只加载今天和昨天的日志。

第三级：shared-context/（跨智能体知识层）

这是最晚加入的部分，也是改变一切的部分。

• THESIS.md——当前的思维框架：你关注什么，已经写了什么，还有哪些空白。研究智能体读它来确定优先级，内容智能体读它来匹配你的思路。每个智能体都对齐到同一个真相来源。
• FEEDBACK-LOG.md——跨智能体纠正层。当你告诉一个智能体"不要用破折号"，这条反馈同样适用于其他所有智能体。与其逐个纠正，写一次，所有人都来读。

这单一改变节省的时间，比做过的任何prompt优化都多。

智能体如何协作

没有API调用，没有消息队列，只有文件。

研究智能体Dwight把成果写入 intel/DAILY-INTEL.md，内容智能体Kelly读，分发智能体Rachel读，通讯智能体Pam读。协作就是文件系统。

两条核心原则：

• 单写者原则： 永远不要让两个智能体同时写同一个文件。每个共享文件设计为一个写者、多个读者，从根本上杜绝协调冲突。
• 调度顺序： Dwight在早8点和下午4点运行，Kelly和Rachel在下午5点运行。上游先跑，因为所有人都依赖它的输出。顺序搞错了，下游智能体读到的就是过时或空白的文件。

文件的进化轨迹

文件不是静态的，它们在持续进化：

• Kelly的SOUL.md第一天只是粗略草稿。到第40天，已经有了具体的语气示例、被否决模式列表，以及"永远不要再建议"专区。
• Dwight的原则第一天是"找到热门趋势"，第10天变成"如果今天无法对此采取行动，跳过"，第20天又加入了核实步骤。
• 共享上下文层直到第20天才出现——那时在对多个智能体重复同样的纠正，才建了THESIS.md和FEEDBACK-LOG.md，一次纠正就能传播到所有地方。

从零开始的实操路线

不要试图在一个周末搭完整个系统。按以下节奏推进：

• 今天： 安装OpenClaw，写一个SOUL.md、IDENTITY.md、USER.md。挑最重复的日常任务，设置定时任务让它跑起来
• 第3天： 开始给出具体反馈，确保反馈落入记忆文件，而不只是停留在聊天记录里
• 第1周： 创建AGENTS.md，定义会话启动流程，添加记忆管理规则
• 第2周： 开始写MEMORY.md，回顾每日日志，把反复出现的纠正蒸馏成永久条目——这时你会感受到复利开始发生
• 第3周： 添加第二个智能体，建立基于文件的协作。用THESIS.md记录当前思考，用FEEDBACK-LOG.md管理跨智能体纠正
• 第4周： 在你第一次遇到故障之后，添加HEARTBEAT.md

写在最后

没有人能通过使用同一个模型来复制你的系统，因为真正的壁垒是你每天出现、与智能体对话时积累下来的上下文文件。不是调prompt，不是换模型，不是重构架构——就是说话，给反馈，看着它们把内容记下来。文件会完成其余的一切。