---

摘要： 升级 OpenClaw 2026.6.6 后，一天的 API 用量飙升到 239 次模型调用、2900 万 token。排查根因不是模型贵，而是文件体系混乱——49 个 Skill 全部注入但只用 1 个，SOUL 写得像操作手册，SOP 根本不存在，Session 历史越滚越大。本文先讲 OpenClaw 整体架构，再逐一拆解六大文件体系的正确用法，配上 usage.json 的真实数据。

前段时间我把 OpenClaw 升级到 2026.6.6。第一个发布任务就把我打醒了。

我导出了 7 月 29 日的 usage.json，数据让人盯着屏幕愣了几秒：239 次模型调用，2900 万 token。用户说了 51 句话，Agent 自己做了 190 次工具调用。我说一句，它做 4.7 件事。

排查过程让我意识到一个更深的问题：不是模型涨价了，是我根本没理解 OpenClaw 的文件体系是怎么工作的。SOUL 写得像操作手册，SOP 根本不存在，Memory 被当成规则库用，历史 Session 越滚越大没人清理。

这篇文章不聊功能更新，聊一个被大部分人忽略但最重要的事：OpenClaw 的整个架构是怎么设计的，SOUL、AGENTS、Skill、SOP、Memory、Session 这六个体系各自该扮演什么角色。

---

一、OpenClaw 整体架构

在理解各个文件之前，先看整体。OpenClaw 的架构可以从三个层面来理解：物理层、运行时层、记忆层。

物理层：两个目录

OpenClaw 在磁盘上有两个核心目录，职责完全不同：

~/.openclaw/workspace — 工作区。Agent 的工作目录（cwd），存放项目的文件、文档、脚本。AGENTS.md、SOUL.md、MEMORY.md 等引导文件都在这里。这是 Agent “看到” 的世界。

~/.openclaw/ — 配置区。存放 openclaw.json（主配置）、credentials（密钥和 OAuth token）、agents//sessions（会话记录）、managed skills（托管的技能包）。配置区对于 Agent 是不可见的——Agent 只能在 workspace 里读写文件。

官方文档特别强调：workspace 是默认工作目录，但不是硬沙箱。 工具解析相对路径时以 workspace 为基准，但绝对路径可以访问系统其他地方。如果你需要隔离，要用 sandbox 配置。

运行时层：引导文件注入

每次新建 session（新对话），OpenClaw 的 Agent 运行时会把以下文件注入到系统提示的 Project Context 区域：

文件	注入时机	用途
AGENTS.md	每次 session 启动	操作规则
SOUL.md	每次 session 启动	人格和边界
IDENTITY.md	每次 session 启动	Agent 名称/Emoji
USER.md	每次 session 启动	用户信息
MEMORY.md	每次 session 启动	长期记忆（如有）
HEARTBEAT.md	心跳轮询	定时任务清单
memory/YYYY-MM-DD.md	每天	今天+昨天的日报

关键设计：启动注入 ≠ 实时读取。 这些文件只在 session 开始时注入一次。如果你在 session 运行中修改了 AGENTS.md，新规则不会自动生效——只有下一个 session 才能看到变化。这是导致 “Agent 改错规则 → 同一个 session 继续犯错” 的根因之一。

大文件会被截断。 官方默认限制是：单文件最大 20,000 字符（bootstrapMaxChars），总注入不超过 60,000 字符（bootstrapTotalMaxChars）。而在我的实际环境中，引导文件合计 20,435 字符，Skill 列表 9,974 字符，工具 Schema 19,345 字符——系统提示词总长 43,240 字符。这些内容在每次请求时都占据模型的注意力预算。

记忆层：三层记忆模型

OpenClaw 的记忆不是单一的，而是分为三个层次：

USER.md          ← 用户模型层（稳定偏好、沟通风格）
MEMORY.md        ← 长期记忆层（持久事实、重要决策）
memory/YYYY-MM-DD.md  ← 工作记忆层（每日记录、会话摘要）

官方文档的设计意图非常清晰：USER.md 存不变的东西，MEMORY.md 存需要跨 session 记住的东西，memory/*.md 存当天的上下文。 长期来看，有意义的工作记忆会被做梦（dreaming）流程蒸馏到 MEMORY.md 里，没意义的自然过期。

---

二、六个文件体系的正确分工

用一句话概括每个文件的核心定位：

文件	核心定位	一句话
SOUL.md	人格 + 安全边界	Agent 是什么样的人
AGENTS.md	工作规则 + 权限约束	Agent 能做什么不能做什么
Skill	可复用的能力模块	Agent 会用哪些工具
SOP	任务的执行流程	这件事应该怎么做
Memory	经验 + 用户偏好	过去发生过什么
Session	当前对话上下文	现在正在做什么

它们的优先级关系：

SOUL          ← 最高：人格 + 安全红线（不可被下层覆盖）
  ↓
AGENTS        ← 工作规则 + 权限约束（安全规则优先）
  ↓
SOP           ← 任务执行流程（固化步骤，减少现场推理）
  ↓
Skill         ← 可调用能力模块（封装好的工具和方法）
  ↓
Memory        ← 长期经验 + 用户偏好（辅助决策）
  ↓
Session       ← 当前上下文（临时，每次对话独立）

---

三、逐层拆解

3.1 SOUL.md：人格定义，不是操作手册

SOUL 控制 Agent 的行为倾向：遇到错误是主动修复还是停下来问、回答是直接还是啰嗦、对风险的态度是激进还是保守。

应该放的内容：

• 行为原则：面对错误的态度（主动修复 vs 停下来问）
• 安全红线：绝对不能做的操作（如递归删除、修改系统配置）
• 沟通风格：直接/委婉、精简/详细、是否使用 emoji

应该避免的内容：

• 具体的操作步骤（应该放 SOP）
• 工具参数说明（应该放 Skill）
• 历史错误记录（应该放 Memory）

一个血的教训。 我之前把发布失败的处理流程全塞在 SOUL 里，导致 SOUL 膨胀到了几千字。每次新建 session，这些内容全部注入系统提示——但它们其实只在"发布失败"这个场景下有用。其他 95% 的对话里，这些内容纯属占用 token 预算。

issue 更严重：SOUL 膨胀的直接后果是挤占关键规则的注意力份额。 使用 usage.json 分析的当天，系统提示词 43,240 字符中有将近一半来自引导文件本身。如果把非必需的流程描述移到 SOP 里，引导文件的字符数可以砍掉 30-40%——等于每次请求凭空少了几千 token 的固定开销。

Stack Junkie 的 OpenClaw 教程有一个很精准的总结：每个 bootstrap 文件每次会话都加载到上下文，文件大小直接影响 token 成本和可用上下文空间。 SOUL 越精简越好。

3.2 AGENTS.md：项目宪法，安全规则优先

官方文档对 AGENTS.md 的定义：operating instructions for the agent and how it should use memory. 它是 Agent 的操作合同——定义了这个项目里什么能做、什么不能做。

LaunchMyOpenClaw 的 AGENTS 指南提出了一个关键设计原则：AGENTS 的配置层级是安全规则优先。 禁止项应该放在建议项前面，Agent 读到冲突指令时，禁止项永远胜出。

从我的踩坑经验，AGENTS 里最有价值的几个条目：

编码安全规则（用钱买来的）：

Markdown 文件（*.md）上严禁使用：
- PowerShell Set-Content / Out-File / 重定向
- 原因：可能破坏 UTF-8 编码
- 替代方案：只用 write 工具

发布失败上限：

每次发布任务最多尝试 3 次
超过 3 次：停止所有自动修改，输出错误原因和尝试记录，等待人工确认

错误分类策略：

401/403/IP/Token 权限类错误 → 立即停止，禁止修改文章
45166 内容审核 → 按 SOP 的 5 步流程逐项排查

这些规则的价值在于：它们是硬约束。 Agent 在任何上下文中读到 AGENTS 里的禁止项都必须服从——不管 session 有多膨胀、上下文有多少噪音，安全规则不可被推理覆盖。

一个数据证明这个原则的重要性。 在当天 75 次 exec 调用中，如果 Agent 每次都先读错误码然后按分类策略走，至少有 60 次工具调用可以被避免。但因为当时没有分类策略，Agent 对每一个错误都执行同一套"分析 → 改文件 → 重试"的流程——不管错误是编码问题还是 Token 过期。

3.3 Skill：可调用的工具模块，不是备忘录

OpenClaw 使用 AgentSkills 兼容的技能文件夹系统。每个 Skill 是一个包含 SKILL.md（带 YAML 前置元数据）的目录，告诉 Agent “你有这个能力，怎么调用”。

但这里有一个巨大的坑。

系统会给 Agent 展示所有可用 Skill 的列表作为 available_skills 指令。在我的环境里，这个列表有 49 个条目——agent-browser、aicdragon-operator、canvas、meme-maker、buffett-perspective、elon-musk-perspective……每个条目大约 180-215 字符。49 个全加在一起，9,974 字符。

但实际任务中我只用了 wechat-mp 一个。剩下 48 个 Skill 的简介在每一次模型请求中都被注入，但永远不会被调用。

这不是 48 × 200 = 9,600 字符的简单数学题。对注意力机制来说，上下文里的每一条无关信息都是在稀释模型对关键指令的关注度。就像你面前摊了 49 张说明书但你只需要其中 1 张——其余 48 张不光没用，还会让你找不到你需要的那张。

解决办法： 把不常用的 Skill 移到独立备份目录。workspace/skills 作为"活跃开关"，需要的放进去，不需要的移走。如果以后需要用到 buffett-perspective 来分析公司财报，从一个路径加回来就行。

一个判断标准： 如果改了这个文件的频率超过一周一次，说明你把 Skill 当 Memory 用了。Skill 应该像代码库里的公共库——改一次，长期稳定。

3.4 SOP：最容易被忽略的环节

SOP（Standard Operating Procedure）在我之前的文件体系里是空白的。结果就是：每个发布任务，Agent 都在"现场推理"而不是"执行流程"。

45166 来了，Agent 开始分析——可能是格式问题，改 Markdown 语法；再试，还是 45166；再分析——可能是字数问题，删内容；再试，还是失败。每一步推理消耗 token，积累的上下文全是试错记录。全天的 token 时间线完美印证了这一点：高峰期（Quarter 9-14）的 1570 万 token 中，input 占了绝大部分——说白了就是 Agent 把大量错误历史和修改后的文章内容一次又一次地重新喂给模型。

什么情况下该写 SOP？

两个条件同时满足：

1. 同一任务执行了 2 次以上
2. 存在可复现的失败风险

一份合格的发布 SOP 包含四个阶段：

阶段 1 — 发布前检查：

• 文件编码正常（read 工具验证）
• frontmatter 完整
• 封面图是 PNG/JPG（非 SVG）

阶段 2 — 成功样本对比：

• 读取最近成功发布的文章格式
• 对比字节量级

阶段 3 — 发布执行：

• 执行 publish.mjs
• 记录返回码和 Media ID

阶段 4 — 失败处理：

• 第一步：错误分类（A 编码 / B 参数 / C 权限 / D 审核）
• C 类 → 立即停止，等人工（这类错误跟文章内容无关）
• A/B/D 类 → 单次修复机会
• 失败 → 停止 → 等人确认

SOP 的核心价值：让 Agent 执行流程，而不是每次重新推理。 每少一次现场推理，就少一份上下文膨胀。当天 75 次 exec 调用中，如果严格按 SOP 流程走，至少能砍掉 60 次。

3.5 Memory：三层模型，各司其职

回到前面说的三层记忆模型：

USER.md（用户模型层） — 存几乎不变的东西：用户名、时区、偏好、项目背景。变更频率：月级。

MEMORY.md（长期记忆层） — 存需要跨 session 记住的关键信息：决策记录、用户反馈、已建立的规律。变更频率：周级。OpenClaw 的做梦（dreaming）流程会定期从 memory/*.md 中蒸馏重要信息到 MEMORY.md。

memory/YYYY-MM-DD.md（工作记忆层） — 每日记录，今天+昨天自动加载。存当天具体操作、问题排查过程、临时发现。变更频率：日级。

最典型的误用：把操作流程塞进 Memory。

❌ "发布文章：第一步检查 frontmatter，第二步..."
    ↑ 这是 SOP，不是 Memory

✅ "45166 错误在过去一周出现 4 次，阈值在 4000-6500 bytes 之间"
    ↑ 这是需要记住的历史模式

同时，OpenClaw 内置的 Memory Search 功能依赖 Embedding 向量搜索。但 DeepSeek API 不提供 /embeddings 接口——每次查询返回 HTTP 404，然后重试。虽然工具统计中只触发了 2 次，但作为一个持续运行的机制，它一直在后台消耗不必要的 API 往返。关闭后立刻少了这些无效调用。

3.6 Session & Compaction：潜藏的成本杀手

Session 是六个体系中唯一的"临时存储"，但它是成本最大的盲区。

OpenClaw 的 session 数据存在 SQLite 数据库中，trajectory 文件在 sessions/ 目录下作为辅助。每个 session 记录对话历史、工具调用、输出结果——全部是 LLM 上下文原料。

来自 usage.json 的真实数据： 我的 session 包含 3 个串联的历史 instance，缓存读取达到了 16,160,128 token。OpenAI/Anthropic 的 prompt caching 可以省 90% 费用，但 DeepSeek 价格低到这种差别可以忽略。真正浪费的是模型的注意力——1616 万 token 的旧内容，每次都重新计算注意力权重。

之前排查 session 目录时，更发现 61 个 trajectory 文件、72 MB。 虽然大部分不加载到主上下文，但 compact 过的摘要版本会作为历史注入。

上下文膨胀的数学原理。 长 session 下 Agent 的成本不是线性增长，而是 O(N²)。Zylos Research 在 2026 年 4 月的研究中给出了具体数据：一个 20 步的 Agent 循环，每步输出 1,000 token，实际累积输入 token 是 210,000，而不是单步估算的 20,000。差 10 倍，来自每一步都把历史全量重新注入。

Compaction（压缩）的副作用。 当上下文接近窗口上限时，OpenClaw 会触发压缩——把历史总结成紧凑版本。但 Empromptu 在 2026 年 6 月的白皮书指出了 Context Rot：长 session 中模型输出质量因累积的无用内容而逐渐下降，但系统不报错——它只是默默地变笨。压缩后的摘要把原始对话的错误推理和无效操作继承下来，形成"垃圾进，垃圾出"循环。

Liu et al. 在 ACL 2024 的 “Lost in the Middle” 效应加剧了问题： 模型对中间位置的上下文注意力最弱。当一个关键指令被压缩到上下文中间位置时，Agent 可能根本上就"看不到"它——这就是为什么明明 SOUL 里写了禁止操作，Agent 还是会在长 session 里犯错。

我的实际调整：

1. contextWindow 从 1M 降到 128k — 更早触发压缩，压缩质量更高。当天数据证明：窗口更大的时候压缩触发更晚，意味着压缩时已有大量噪音
2. reserveTokensFloor 从 35,000 降到 12,000 — 更多空间让给核心规则
3. 关闭 Memory Search — DeepSeek 不支持 /embeddings
4. 61 个旧 session 文件备份后删除，只保留最近 5 个活跃的

---

四、错误处理管道：从"自由修复"到"管道模式"

在我搞清楚上面这些之前，Agent 的错误处理是"自由修复模式"：

出错 → Agent 自行分析 → 改文件 → 再出错 → 继续改 → 循环

当天最典型的例子：Quarter 9 时段有 1,480,542 token 消耗，但 user 消息是 0——整整 15 分钟，Agent 自己在不停地读文件、改内容、重新发布，没有等用户输入。全是自由修复模式的循环。

调整后的"管道模式"：

出错
  ↓
记录：错误码 + 输入 + 输出 + 环境
  ↓
分类：A 编码问题 / B 参数问题 / C 权限问题 / D 内容审核
  ↓
C 类 → 立即停止（改了也没用）
其余 → 单次修复
  ↓
失败 → 停止 → 输出诊断 → 等人确认

管道模式的核心原则：不是让 Agent 更聪明地修复错误，而是限制 Agent 在错误上能够消耗的资源。 错误处理的预算应该和正常操作是同一个量级。如果正常发布需要 10 次工具调用、~50 万 token，报错后的处理也应该控制在这个范围——而不是飙到几百万。

---

五、每周维护清单

上下文监控。 重要任务前检查上下文使用率。超过 70% 就开新 session。

Session 清理。 每周检查 trajectory 文件大小，超过 5MB 备份后删除，保留最近 5 个。

配置复查。 contextWindow（128k）、reserveTokensFloor（12000）、memorySearch（关闭）。

Skill 活跃度检查。 看本周实际调用了哪几个 Skill，不活跃的移出 workspace/skills。

Memory 整洁度。 检查 MEMORY.md 里是否有操作步骤（应移到 SOP）、是否有工具参数（应移到 Skill）。

失败复盘。 如果有发布失败，在 memory/ 里记一笔，但别把诊断流程写进 SOUL。

导出 usage.json。 定期跑一次 openclaw usage export，看看工具调用分布和 token 时间线——数据会把你看不到的问题揪出来。

---

关键结论

1. OpenClaw 的三层架构： 物理层（workspace + config）、运行时层（引导文件注入 + session 管理）、记忆层（USER / MEMORY / daily notes）
2. 六个文件有明确的职责边界： SOUL 管性格、AGENTS 管规则、Skill 管能力、SOP 管流程、Memory 管经验、Session 管上下文。不要互相替代
3. 最大的坑： 把 SOUL 当操作手册写、把 Memory 当规则库用、让 Agent 现场推理而不是执行 SOP、49 个 Skill 全注入但只用 1 个
4. 上下文膨胀根因是 O(N²)： 20 步循环产生 21 万 token，不是单步的 2 万。加上 Context Rot 和 Lost in the Middle，长 session 的 Agent 会无声地变笨
5. 错误处理用管道模式而非自由修复模式： 错误分类 → C 类直接停 → 其余单次修复 → 失败停止
6. 核心铁律：不要让 Agent 记住流程，让它执行流程。看 usage.json 数据，不是凭感觉
7. 系统提示词里 43,240 字符的构成： 20K 引导文件 + 10K Skills + 19K 工具 Schema。每次请求都在交这笔"固定税"

参考来源

• OpenClaw 官方文档 — Agent Runtime、Agent Workspace、Skills、Memory 概述
• 7/29 usage.json 完整导出数据 — 239 次调用，29.18M token，system prompt 43,240 chars，49 skills 全量注入
• Zylos Research — Agent Context Compaction for Long-Running Sessions: Techniques and Tradeoffs（2026.4）
• Empromptu — The Context Rot Problem: Why AI Coding Agents Get Worse As They Work（2026.6）
• Blink.new — OpenClaw HEARTBEAT, SOUL, and Memory Files: The Complete Configuration Guide（2026.3）
• LaunchMyOpenClaw — AGENTS.md Guide: Define Your AI Agent’s Operating Contract（2026）
• Stack Junkie — How to Write AGENTS.md, SOUL.md, and TOOLS.md for OpenClaw（2026）
• Liu et al. — Lost in the Middle: How Language Models Use Long Contexts（ACL 2024）