05 · 上下文——最贵的资源

——翔宇

要点速览

• AI 的上下文窗口是有限的——200K token 听起来很多，但系统占用后留给你的对话空间远没有那么大
• 你发的一句话只占整个上下文的千分之一——其余 99% 是系统提示、工具定义、workspace 文件
• Compaction（压缩）= 把旧对话缩成一页纲要；Pruning（剪枝）= 把工具结果的附录撕掉
• 90% 的 Agent「失忆」是因为重要规则只在聊天里说过，没写进 SOUL.md，压缩时丢了
• safeguard 模式和 aggressive 模式是「安全」和「空间」的权衡

1. 一个好问题

Claude 的上下文窗口是 200K token。GPT-5 是 256K。听起来很大。

但你的对话空间真的有 200K 吗？

错误直觉

「200K 上下文窗口 = 我可以聊 200K 的内容。」

不是的。让我们算一笔账。

2. 算一笔账：你的对话空间有多少

一个典型的 OpenClaw Agent 启动后，上下文窗口的分配大致是这样的：

┌────────────────────────────────────────────┐
│           200,000 token 总预算              │
│                                            │
│  ██████████ System Prompt      ~10,000     │
│  ██████    Workspace 文件       ~3,000     │
│  ████      工具定义 (Schema)    ~4,000     │
│  ██        记忆日志             ~1,000     │
│  █         Skills 列表          ~500      │
│  █         运行时信息            ~500      │
│                                            │
│  ░░░░░░░░░░░░░░░░░░ 对话历史   ~181,000   │
│                                            │
│  你的最新消息                     ~50      │
└────────────────────────────────────────────┘

💬 说人话

你还没开口，AI 就已经「读了」一本小册子——安全规则、工具清单、人设卡、用户档案、记忆日志……你的那句「帮我查一下服务器状态」可能只有 50 token，但 LLM（大语言模型）实际处理的是将近 20,000 token 的「前置信息」加上你的消息。

181,000 token 听起来还是很多？

别急。对话 30 轮后，每轮平均 3,000 token（你的消息 + Agent 的回复 + 工具调用结果），对话历史就已经 90,000 token 了。60 轮后直接逼近上限。

而工具调用结果尤其吃空间——Agent 读了一个 500 行的文件，那就是好几千 token。

🔑 关键点

上下文不是只属于你的。系统、工具、记忆都要占座。你的对话空间，是总窗口减去所有固定占用后的余量。

2.1 一天的上下文演化

让我们跟踪一个 Agent 从早到晚的上下文变化：

💬 说人话

上下文就像一个不断填满的沙漏。早上是空的，聊着聊着越来越满。快满的时候系统自动「倒转」——先抢救重要信息（memoryFlush），再压缩旧对话（Compaction），腾出空间继续聊。

📌 记住这点

11:00 那次 Agent 读了一个 800 行文件——一次操作就吃掉了 13,000 token。这就是为什么工具调用结果是上下文的最大消耗者，也是剪枝（Pruning）重点处理的目标。

3. 如果不管会怎样

假设 OpenClaw 不做任何上下文管理。会发生什么？

场景一：对话太长

你和 Agent 聊了 3 小时，累积了 200 轮对话。上下文超过窗口上限。

结果：API 直接报错——模型拒绝处理。Agent 彻底卡住。

场景二：工具结果太大

Agent 读了一个 10,000 行的日志文件。整个文件内容被塞进上下文。

结果：一次工具调用就吃掉了整个窗口的 30%。再加上对话历史，上下文瞬间爆满。

场景三：不清理旧信息

Agent 早上 9 点开始工作，到下午 5 点。期间所有对话、所有工具调用结果、所有中间思考过程都保留在上下文里。

结果：到下午 3 点左右，上下文已经满了，Agent 开始报错或丢失早期信息。

🧠 底层逻辑

上下文管理不是优化，是必需。没有它，Agent 活不过一个下午。

4. OpenClaw 的两把刷子：压缩和剪枝

OpenClaw 用两种机制管理上下文，它们解决不同的问题。

4.1 Compaction（压缩）——做会议纪要

当对话历史接近窗口上限时，自动将旧对话总结为紧凑摘要。

🎯 打个比方

你和同事开了 3 小时的会。不可能把所有发言逐字记录——你写一份会议纪要：「讨论了 A、决定了 B、下一步做 C」。50 轮对话 → 1 段摘要，节省 95% 的空间，但关键决策保留了。

压缩前后对比：

手动触发：在聊天中发 /compact，后面可以加提示告诉 Agent 重点保留什么。

/compact 保留所有关于部署方案的决策和待办事项

🔍 深入一步

压缩的质量取决于做摘要的模型。OpenClaw 支持通过 compaction.model 指定专用的压缩模型——比如你的主模型是便宜的 Haiku，但压缩摘要用 Sonnet 来做，这样既省日常成本又保证摘要质量。未设置时，默认用 Agent 的主模型。

4.2 Pruning（剪枝）——撕掉附录

每次调用 LLM 之前，OpenClaw 会检查旧的工具结果（Tool Result），对过大的结果进行修剪。

🎯 打个比方

压缩是「把一本书缩成一页纲要」，剪枝是「把书里的附录撕掉」。两个都是为了腾空间，但方式不同。

两种剪枝力度：

💡 划重点

用户说的话和 Agent 的回复永远不会被剪枝。只有工具调用结果（Tool Result）才会被动刀。这保证了对话的连贯性——你说过的话 Agent 不会「选择性遗忘」。

4.3 压缩 vs 剪枝：一张表搞清楚

4.4 压缩的具体过程

Compaction 不是随便删东西。它的过程比你想象的更精细：

1. 检测到上下文接近窗口上限
  ↓
2. 触发 memoryFlush（如果启用）
   Agent 在后台静默保存重要信息到 memory/
  ↓
3. 选择要压缩的范围
   通常是最早的 N 轮对话（保留最近的对话不动）
  ↓
4. 调用 LLM 生成摘要
   把被选中的对话交给模型，让它写一段浓缩摘要
  ↓
5. 用摘要替换原始对话
   被压缩的轮次消失，取而代之的是一段摘要文本
  ↓
6. 摘要写入会话文件（JSONL，逐行JSON格式）
   持久化保存，下次加载时用摘要恢复

🧠 底层逻辑

压缩本质上是「用 AI 做会议纪要」——让 LLM 自己决定哪些内容值得保留。这意味着压缩的质量取决于模型的理解能力。强模型（Opus）的压缩摘要比弱模型（Haiku）更准确，丢失的关键信息更少。

4.5 手动压缩的技巧

自动压缩让模型自己决定保留什么。但你可以手动触发并指定方向：

💡 划重点

如果你知道接下来还需要用到某些信息，在自动压缩触发之前手动压缩并指定保留方向，效果比被动等自动压缩好得多。

4.6 优化上下文使用的 5 个实践

5. Agent「失忆」了？根因分析

错误直觉

「Agent 突然忘了之前的决策，一定是记忆系统坏了。」

90% 的情况不是记忆系统的问题，而是压缩导致的。

5.1 根因：规则没「毕业」

最常见的场景：

1. 你在聊天中说了一条重要规则：「以后所有文件名用小写加横杠」
2. 这条规则只存在于对话历史（Context）中
3. 对话太长，Compaction 触发
4. 旧对话被压缩成摘要，你的那条规则因为不够「关键」被摘要丢掉了
5. Agent 下次不再遵守这条规则——它不是故意忘的，是真的不知道了

🔑 关键点

重要规则必须从聊天「毕业」到 SOUL.md 或 AGENTS.md 里。这些文件永远不会被压缩——它们是 System Prompt 的一部分，每次对话都会完整加载。

5.2 5 步快速恢复

如果 Agent 表现异常，按这个顺序排查：

⚡ 速记

90% 的失忆 = Compaction + 规则没写进 SOUL.md。先查这两个。

6. 上下文管理的关键参数

理解了原理，再看参数就不会觉得抽象了。

6.1 剪枝参数

6.2 压缩参数

6.3 safeguard vs aggressive：两种哲学

🧠 底层逻辑

这是一个经典的工程权衡——「保留更多信息」和「留出更多空间」不可兼得。safeguard 选择「宁可空间紧也不轻易丢」，适合大部分个人使用场景。如果你的 Agent 做客服要同时处理很多短对话，aggressive 可能更合适。

7. System Prompt 组装：你的消息只是冰山一角

理解上下文管理，有一个前提——你得知道 LLM 实际收到了什么。

当你发了一句「帮我查一下服务器状态」，LLM 实际收到的是一个巨大的输入包：

💬 说人话

你说了 10 个字的话，LLM 处理了 2-6 万 token 的输入。你的消息占总输入的千分之一。

这就是为什么上下文管理如此重要——不是因为你话太多，而是因为系统本身就很「话多」。

7.1 提示词模式

💡 划重点

子 Agent 默认用 minimal 模式——因为子 Agent 只执行具体任务，不需要完整的安全规则和工具清单。这一个优化就省了 7,000 token。

7.2 查看当前上下文的命令

📌 记住这点

跑通 OpenClaw 后，第一件事就是发 /context list。你会对实际注入量感到惊讶——光 System Prompt 就可能占了 10,000 token，还没算 Workspace 文件和工具定义。

7.3 成本感知：Token 不只是空间，也是钱

上下文不只是「空间」问题，也是「成本」问题。

💬 说人话

如果你的 System Prompt 是 10,000 token，每次 Agent 回复都要处理这 10,000 token 的输入。用 Opus 的话，光 System Prompt 每次就花 $0.15。一天 50 次对话，System Prompt 的成本就是 $7.5——什么都没做，光「读手册」就花了这么多。

这就是为什么上下文优化不只是技术问题，也是经济问题。精简 SOUL.md、禁用不需要的工具组、子 Agent 用 minimal 模式——每一个优化都在省钱。

8. 设计权衡

设计权衡

一句话检验

• 上下文窗口真的有 200K 可用吗？ → 不是。系统提示、工具、workspace 文件固定占用 ~15,000-20,000 token，剩下的才是你的对话空间
• Compaction 和 Pruning 的区别？ → 压缩是做会议纪要（整段对话→摘要），剪枝是撕附录（只动工具结果）
• Agent 为什么失忆？ → 90% 是 Compaction 触发 + 重要规则只在聊天说过没写进 SOUL.md
• safeguard 是什么？ → 「宁可空间紧也不轻易丢信息」的保守压缩策略

CC 提示词

🚀 对 Claude Code 说 帮我分析 OpenClaw Agent 的上下文使用情况： - 在 OpenClaw 聊天中发送 /status，截取上下文窗口使用率

• 发送 /context list，看 System Prompt 里注入了哪些文件及大小

• 计算固定占用（System Prompt + Workspace 文件 + 工具定义）占总窗口的百分比

• 估算按当前对话速度，大约多少轮对话后会触发第一次 Compaction

• 给出优化建议——哪些 workspace 文件可以精简以腾出更多对话空间

🚀 对 Claude Code 说 帮我检查 SOUL.md 的 token 占用是否合理： - 读取 /你的路径/.openclaw/workspace/SOUL.md

• 用 tiktoken 或估算方法计算 token 数

• 如果超过 500 token，分析哪些内容可以精简

• 检查是否有「身份描述」可以转化为「行为决策规则」——后者更有效且更短

• 输出优化后的 SOUL.md 建议版本

延伸阅读

• 翔宇版 04《核心概念深度解析》— Context / Compaction / System Prompt 全节
• 翔宇版 05《Gateway 配置大全》— 剪枝和压缩的完整参数手册
• 翔宇版 11《系统参数深度解读》— 150+ 参数中上下文管理相关的调优故事
• 深度教程-04《记忆——AI 怎么记住你》— Context 和 Memory 的区别在那一篇有更深入的解释