夜雨聆风.md 文件——AGENTS.md、SOUL.md、IDENTITY.md、MEMORY.md……一堆文件堆在一起，它们到底是干什么的？哪些会被"读取"？谁在读？读完了之后又去了哪里？说实话，网上关于这个话题的资料，写得要么太浅、要么太碎，看完还是一知半解。这篇文章，就是要把这件事彻底讲清楚——OpenClaw 怎么读 MD 文件，一级二级三级标题怎么组织，以及本地读取和大模型读取到底有什么区别。读完你不会再有疑问。
先说最重要的：本地读 vs 大模型读
这是很多人最容易搞错的地方，必须放在最前面说。
一个反直觉的真相
我先问一个问题："OpenClaw 读取 MD 文件"——这个"读取"动作，是谁来做的？
很多人的第一反应是：Agent 在本地把文件读了，然后提炼出关键信息，再告诉大模型。这听起来很合理，对吧？
错。
实际情况是这样的：几乎所有工作区里的 MD 文件，内容都会原封不动地发送给大模型，作为 context（上下文）的一部分。也就是说，"读取"这个动作，是大模型自己在做的——不是 Agent 读完总结给大模型，而是大模型直接看到了文件内容。
你可以理解为：大模型每次回答你的问题之前，OpenClaw 会把一堆 MD 文件的内容"塞进"它的上下文窗口里，大模型自己去看、自己去理解、自己去用。没有中间商赚差价。
那"本地读"发生在什么时候？
既然绝大多数时候都是大模型在读，那"本地读"还存在吗？存在的，但场景很有限，主要有三种：
第一种：执行脚本的时候。 当 OpenClaw 用 exec 工具执行 shell 命令或脚本时，如果脚本里需要读文件，那是操作系统在本地读，大模型根本不知道里面写了什么。
第二种：读取附件的时候。 如果你的文件是 PDF、图片、音频、视频这类非文本附件，系统会调用专门的解析工具在本地提取内容，再转成文本送给大模型。这个过程是工具层面的本地操作。
第三种：Agent 主动用 read 工具读文件来提取信息。 这是一种特殊场景——Agent 自己决定去读某个文件，然后从里面抓取特定信息。这个"读"确实是本地发生的，但它是工具调用，不是系统自动行为。
总结一下：日常会话中你接触到的 MD 文件，几乎都是大模型在读，不是 Agent 在本地读。Agent 更像是一个"看门人"，负责决定把哪些文件交给大模型，但 Agent 自己不会先把文件嚼一遍再喂给大模型。
七大核心文件：每次会话都会注入
明白了谁在读之后，我们来看 OpenClaw 工作区里最重要的七份 MD 文件。这些文件的特点是：每次新建会话，它们都会被自动注入到大模型的上下文里，不需要你手动指定，也不需要触发任何条件。
AGENTS.md：工作区的宪法
文件名：AGENTS.md 位置：工作区根目录 作用：工作区的总纲文件
这份文件定义了工作区的基本运行规则。你可以把它理解成"宪法"——它是整个工作空间最高层次的行为指引。你是谁？你启动的时候应该先做什么？你能做什么、不能做什么？这些都在 AGENTS.md 里规定。
通常 AGENTS.md 会包含会话启动流程（比如先读 IDENTITY.md、再读 SOUL.md）、工具管理规范、记忆管理规范，以及某些操作的红线限制（比如禁止修改 AGENTS.md 和 SOUL.md 本身）。
为什么重要：大模型看到这份文件，就知道这个工作区"是什么"、应该"怎么运转"。它是上下文注入的第一层。
SOUL.md：行事准则与安全规范
文件名：SOUL.md 位置：工作区根目录 作用：定义智能体的行事准则和安全边界
如果说 AGENTS.md 是"宪法"，SOUL.md 就是"道德与安全准则"。它规定了智能体在执行任务时必须遵守的安全规范——哪些事情绝对不能做（比如泄露用户数据、未经确认执行破坏性操作），哪些行为是鼓励的，哪些情况需要主动停下来询问用户。
SOUL.md 里通常包含提示注入防御规则（防止外部恶意指令干扰）、敏感操作确认机制（资金操作、删除操作必须明确获得用户同意）、受限路径规定（不能随意访问 ssh、aws、gnupg 等敏感目录），以及爬虫与数据处理的基本原则。
为什么重要：这是保护用户安全的护栏，大模型每次回答问题前都会"看到"这些规则，确保它的输出不会越过安全红线。
IDENTITY.md：智能体的身份定义
文件名：IDENTITY.md 位置：工作区根目录 作用：定义智能体是谁、叫什么、扮演什么角色
这份文件回答了一个根本问题："我是谁？"
它通常会包含智能体的名称（比如"公众号管家"）、花名、角色定位（公众号运营管家 + 内容编辑助手）、风格描述（专业细致、创意无限）、口头禅，以及具体的工作职责。OpenClaw 读取它之后，大模型就知道自己应该以什么身份、什么语气、什么风格来和用户交流。
为什么重要：它决定了对话的人格基底。不同的 IDENTITY.md 塑造出完全不同的对话体验——同一个大模型，读了"公众号管家"的 IDENTITY.md，会表现得像一个专业运营助手；读了"法律顾问"的 IDENTITY.md，就会切换成严肃的法律专业人士。
USER.md：服务对象信息
文件名：USER.md 位置：工作区根目录 作用：记录你在帮助谁
这份文件回答的问题是："我在为谁服务？"
它包含服务对象的基本信息：名字称呼（比如"UP主"）、时区（UTC+8，中国标准时间）、背景描述（内容创作者，专注视频和公众号运营）、关心的东西（内容质量、粉丝增长、互动率）、正在做的项目、容易惹恼他们的事情，以及其他个性化备注。
为什么重要：大模型读了这部分，就知道怎么称呼用户、什么话会让他们开心、什么行为会让他们不爽。它让对话更有温度，而不是千篇一律的机器人腔调。
TOOLS.md：本地工具备注
文件名：TOOLS.md 位置：工作区根目录 作用：记录与本地工具和外部服务相关的配置信息
这份文件比较特殊，它不是给大模型读的"规范"，而是给 Agent 自己的小抄。它通常记录 API 密钥配置、环境变量、本地工具的使用说明、以及各种集成的配置信息。
比如在"公众号管家"的工作区里，TOOLS.md 可能包含微信公众号的 AppID 和 AppSecret、MiniMax AI 的 API Key、飞书机器人的配置信息，以及其他第三方服务的凭证。
为什么重要：虽然大模型不会直接执行 TOOLS.md 里的内容，但当 Agent 需要调用某个工具时，会参考这里的配置信息。这是 Agent 高效工作的基础数据源。
HEARTBEAT.md：心跳任务配置
文件名：HEARTBEAT.md 位置：工作区根目录 作用：定义周期性任务和心跳轮询的处理方式
"心跳"是 OpenClaw 里的一个特殊机制——当 Agent 收到定期的心跳轮询时，它不会简单地回复一句"心跳正常"，而是会根据 HEARTBEAT.md 的配置去执行具体的任务。
这份文件定义了心跳的触发条件、执行哪些动作、任务的优先级，以及失败时的处理策略。它让 Agent 不只是被动等待用户指令，还能主动推进工作。
为什么重要：没有 HEARTBEAT.md，Agent 在心跳时只会说"正常"，有了它，Agent 每次心跳都能产生实际价值——比如更新记忆文件、检查待办事项、或者执行例行数据统计。
MEMORY.md：长期记忆的索引
文件名：MEMORY.md 位置：工作区根目录 作用：智能体的长期记忆整理文件
这份文件是智能体的"记忆仓库索引"。它记录了 Agent 对长期记忆的整理情况——哪些事情已经记住了、哪些事情需要跟进、重要的历史决策和结论是什么。
与 daily memory 文件不同，MEMORY.md 更像是经过提炼和组织的"知识摘要"，而不是流水账式的会话记录。它帮助大模型在面对新问题时，快速调用历史积累的知识，而不是从零开始。
为什么重要：它是连续性的关键。一个没有 MEMORY.md 的 Agent，每次会话都是全新的开始；有了它，Agent 能记住上次做到哪里、用户的偏好是什么、重要结论是什么，真正做到"越用越懂你"。
Skills 技能文件：按需读取，不是每次都注入
说完了七大核心文件，我们来看另一类很重要的 MD 文件——skills/ 目录下的技能文件。这部分规则和核心文件有本质区别，是很多人最容易混淆的地方。
核心区别：按需 vs 强制注入
七大核心文件是每次会话都会强制注入的，不管当前任务是什么，大模型都会看到它们。
Skills 目录下的文件默认不加载。系统提示词里只包含技能的 name（名称）、description（描述）和 location（路径），这是一份轻量级的"技能清单"，不是技能的具体内容。
只有当某个技能被触发时，OpenClaw 才会去读取对应的 SKILL.md 文件，加载完整内容，然后大模型才能使用这个技能的详细指令。
触发条件是什么？
技能被触发的条件很简单：当用户的请求与某个技能的 description（描述）高度匹配时。
举个例子。如果你对 Agent 说"帮我写一篇公众号文章"，OpenClaw 的系统会扫描可用技能列表，发现"article-writer"（文案撰写）技能的 description 是"根据策划案完成各类内容撰写"，和你的请求高度匹配，于是就触发这个技能，读取 article-writer/SKILL.md，把技能说明加载到大模型上下文里，然后执行任务。
如果你只是说"今天天气怎么样"，没有任何技能被触发，skills/ 目录下的文件就完全不会被读取。
为什么这样设计？
你可能会问：为什么不把所有技能文件都预先加载进去呢？
原因很简单：性能与上下文窗口。
一个大型 OpenClaw 工作区可能有几十个、上百个技能，每个技能的 SKILL.md 可能几千到几万字不等。如果全部预加载，光是技能说明就可能占满整个上下文窗口，大模型就没空间处理用户的实际问题了。
按需读取的机制，既保证了每个技能有足够的发挥空间，又不会浪费宝贵的上下文容量。这是一种经过实践验证的工程权衡。
技能文件的典型结构
虽然每个技能的内容各异，但结构上通常有共同模式：
触发词/条件：定义什么情况下激活这个技能 技能说明：这个技能是做什么的，适合什么场景 使用指南：具体怎么用，有哪些参数、注意事项 工具调用：这个技能依赖哪些工具，怎么组合使用
系统提示词里只放前两项（name + description + location），详细的使用指南在 SKILL.md 里，按需加载。
截断规则：文件太大怎么办
到这里，你已经知道了哪些文件会被读取、以及谁来读。但还有一个关键问题：文件太大怎么办？
单文件上限
OpenClaw 对单个文件有字符数限制，默认是 20,000 字符，这个数字可以通过配置调整。如果一个文件超过 20,000 字符，超出部分会被截断，大模型只能看到前 20,000 字。
这意味着：不要把所有东西都塞进一个 MD 文件。如果你写了一份 5 万字的使用手册，它有 60% 的内容大模型永远看不到。
最佳实践是：把大文件拆分成多个小文件，每个文件专注一个主题。OpenClaw 会按文件注入，多个小文件的组合效果往往比一个大而全的文件更好。
总注入上限
除了单文件上限，还有总上下文上限，默认是 150,000 字符（可配置，不同模型上限不同）。
当注入的内容接近上限时，OpenClaw 会给出警告，提示你需要清理上下文或者精简注入的文件数量。
实际能注入多少，取决于你用的模型——比如 GPT-4o 上下文窗口是 128k，Claude 3.5 可以到 200k，而很多开源模型可能只有 32k 或更小。150,000 字符是 OpenClaw 的默认注入上限设定，如果你的模型上下文更大，可以在配置里调高这个数字。
管理好每个文件的大小，是保持 Agent 高效运转的基本功。
记忆文件也有截断风险
MEMORY.md 和 memory/ 目录下的每日笔记同样受到截断规则的约束。如果你的记忆文件写得过长，每次会话开始时大模型可能只能看到记忆文件的开头部分，后面的内容被截掉了。
这提示我们：记忆文件也要定期整理和精简。不要把记忆文件当成聊天记录备份，而是要提炼关键信息——结论、决策、待办事项。流水账式的记忆文件既占用空间，大模型实际用到的信息密度又很低。
记忆文件的读取时机
除了七大核心文件和技能文件，还有一类特殊的 MD 文件需要单独说明：记忆文件。
MEMORY.md：按需读取
MEMORY.md（长期记忆索引）的加载方式比较特殊：它不是每次会话都强制注入的，而是按需读取。
也就是说，只有当 Agent 觉得需要查询历史记忆来解决当前问题时，才会主动去读 MEMORY.md。日常简单问答，如果跟历史记忆无关，MEMORY.md 可能全程不被加载。
这与七大核心文件形成鲜明对比。七大核心文件是"不管用不用，先读了再说"；MEMORY.md 是"需要的时候再读"。这种设计是合理的——MEMORY.md 通常记录的是长期积累的知识和关键决策，不一定每次会话都用得到，按需读取避免浪费上下文空间。
memory/YYYY-MM-DD.md：每日会话笔记
OpenClaw 的 memory/ 目录下，以日期命名存储每日会话笔记，格式通常是 YYYY-MM-DD.md。
这类文件的读取规则是：今天和昨天的每日笔记，会话开始时会被优先读取。
这是连续性设计的体现。Agent 每次启动新会话时，会先看"最近两天发生了什么"，然后再开始处理当前的请求。这保证了即使会话不连续，Agent 也能快速了解近期上下文。
比如你今天上午让 Agent 帮你写了一篇文章草稿但没发布，下午新建一个会话，Agent 会通过 memory/ 目录下的昨日记录，了解到"还有一篇草稿待发布"这个事实，并主动跟进。
记忆文件的写入时机
说完读取，必须提一下写入。OpenClaw 的记忆管理规范里有一条铁律：每次会话结束后，必须更新记忆文件。
具体操作是：
检查今天的记忆文件是否存在，不存在则创建 在文件开头添加本次会话记录，包括：会话主题、采取的行动、结果产出、遇到的问题、重要结论、后续待办
这条规则的重要性怎么强调都不为过。Agent 的连续性完全依赖记忆文件——没有它，每次会话都是零基础开始，用户体验会断崖式下跌。
标题层级结构：Markdown 语法基础
在结束之前，我们简单过一遍 OpenClaw 文章中使用的 Markdown 标题层级，这是写好文档结构的基本功。
一级标题 #
一级标题用单个 # 符号开头，表示整篇文章的主标题。在微信公众号的语境下，这通常就是文章的封面标题——读者第一眼看到的就是它。
一级标题应该简洁、有力、概括全文核心主题。不要在一级标题里堆砌太多细节，它的作用是"让人一眼知道这篇文章在讲什么"。
二级标题 ##
二级标题用 ## 开头，用来划分文章的主要章节。一篇结构良好的文章，通常有 3 到 6 个二级标题，每个二级标题对应一个相对独立的主题模块。
二级标题是读者浏览目录时的主要导航点。它应该用简洁的语言概括这个章节的主题，格式通常和一级标题保持一致的粒度。
三级标题 ###
三级标题用 ### 开头，用于在二级章节内部继续细分。它对应的是一个子主题，或者某个主题下的不同侧面。
三级标题是文章信息密度最高的部分——读者如果只是快速扫一眼，可能只看一二三级标题，就能理解文章的完整骨架。
层级使用的最佳实践
关于标题层级，有几条经验值得分享：
不要跳级。 写了一级标题，下一个直接写三级标题，中间没有二级标题，这种结构会让读者困惑。层级应该逐级递进，形成清晰的包含关系。
同级标题数量要均衡。 如果你有三个二级标题，第一个下面有 8 个三级标题，第二个下面只有 1 个，第三个下面有 0 个——这种悬殊说明你的结构可能需要重新设计。
标题本身要有信息量。 避免"其他内容""其他情况""补充说明"这类泛泛的标题，好的标题应该让人光看标题就知道这节在讲什么。
总结：一张图看清楚整个机制
我们来把整篇文章的内容串起来：
会话启动时，OpenClaw 会自动把七大核心文件（AGENTS.md、SOUL.md、IDENTITY.md、USER.md、TOOLS.md、HEARTBEAT.md、MEMORY.md 的索引）注入到大模型的上下文里。大模型同时还会收到最近两天的每日记忆文件（memory/ 目录下的 YYYY-MM-DD.md）。
用户发送消息后，OpenClaw 会根据消息内容，匹配最合适的技能。匹配成功的技能会被触发，对应的 SKILL.md 会被读取并加载。多个技能可能同时被触发，按需读取，按需加载。
大模型处理整个上下文，生成回复。如果触发的是非技能类任务（比如只是聊天），skills/ 目录全程不参与。
会话结束时，Agent 按照规范更新今天的记忆文件，记录会话内容和待办事项，为下一次会话做好准备。
整个循环，周而复始。
理解了这个机制，你就知道怎么高效地配置和管理 OpenClaw 工作区了——核心文件要写好、记忆要勤更新、文件大小要控制、层级结构要清晰。这些做好了，你的 Agent 会越来越好用，越来越懂你。
行了，关于 OpenClaw 读取 MD 文件的规则，该说的都说了。如果还有不清楚的地方，可以再问。
