OpenClaw Token 优化实战：从配置到习惯，全面降低上下文消耗

用过 OpenClaw 的朋友大概都有一个共同的痛点——每次对话都会把完整的历史回答塞进上下文，聊着聊着 token 就飙上去了。一个稍微复杂点的任务，十几轮对话下来，单次请求可能就要吃掉数万 token，钱包和速度都遭不住。

这背后的原因其实不难理解：LLM API 本质上是无状态的。无论是 Anthropic 的 Messages API 还是 OpenAI 的 Chat Completions API，每次请求都需要发送完整的对话历史。OpenClaw 作为 Agent 框架，一个任务往往需要 5-10 次甚至更多的 API 调用，每次都携带完整上下文，消耗自然成倍增长。

本文将从配置优化和使用习惯两个维度，系统梳理降低 OpenClaw token 消耗的可行方案，并给出一份可直接落地的配置模板。

---

一、问题诊断：Token 都花在哪了？

在动手优化之前，先搞清楚 token 的主要消耗来源：

消耗来源	说明	占比估算
历史对话累积	每轮对话的 user/assistant 消息全量保留	30-40%
工具调用结果	文件读取、命令行输出等大块文本原样保留在上下文中	20-30%
工具 Schema 注入	50+ 工具的 JSON Schema 每次请求都随 tools 数组发送	10-15%
Thinking 输出	开启 reasoning 模式后，思维链本身也占用大量 token	10-50%（视模型而定）
子代理并发	多个子代理同时运行，各自维护独立上下文	视并发数而定

理解了消耗结构，下面逐个击破。

---

二、核心配置优化

2.1 Compaction（上下文压缩）

Compaction 是 OpenClaw 内置的上下文管理机制，它会将旧的对话历史重写为紧凑的摘要条目，同时保持近期消息完整。

OpenClaw 提供两种压缩模式：

模式	行为	适用场景
safeguard	仅在接近上下文窗口极限时才触发压缩	对上下文完整性要求极高的场景
default	在合理阈值主动触发压缩	大多数日常开发场景（推荐）

如果你当前使用的是 safeguard 模式，这很可能就是"完整回答始终留在上下文里"的直接原因——系统会尽可能保留原始历史，直到窗口快溢出才不得不压缩。

配置方式：

"compaction": {
  "mode": "default"
}

2.2 Context Pruning（上下文修剪）

这是很多用户容易忽略、但收益非常明显的一项配置。

Pruning 与 Compaction 的区别在于：

• Compaction 是永久性操作，会将对话重写为摘要并保存到 JSONL 文件；
• Pruning 是临时性操作，在每次请求构建时在内存中修剪工具结果和冗余输出，不修改存储记录。

两者并不冲突，建议同时启用。

配置方式：

"contextPruning": {
  "mode": "cache-ttl",
  "ttl": "4h",
  "keepLastAssistants": 3
}

参数说明：

参数	含义	建议值
mode	修剪策略，cache-ttl 基于时间过期	cache-ttl
ttl	超过该时间的工具输出会被修剪	4h - 6h
keepLastAssistants	始终保留最近 N 轮完整的 assistant 响应	3

小贴士： 没有配置 Pruning 的话，几个小时前读取的大文件内容会一直原样躺在上下文里，这笔开销其实完全没必要。

2.3 Memory Flush（记忆刷新）

积极压缩能省 token，但也带来一个隐患：压缩可能丢失重要信息。

Memory Flush 机制解决的就是这个矛盾——在 Compaction 触发前，先将关键信息持久化到本地记忆文件中。

触发流程如下：

上下文达到 softThresholdTokens
  → 自动触发 Memory Flush
  → Agent 提取关键决策、代码变更、阻塞项
  → 写入 memory/YYYY-MM-DD.md（每天一个文件）
  → 安全执行 Compaction
  → 上下文大幅缩小，重要信息不丢失

配置方式：

"compaction": {
  "mode": "default",
  "memoryFlush": {
    "enabled": true,
    "softThresholdTokens": 30000,
    "prompt": "将本次会话中的关键决策、代码变更、阻塞项提取到 memory/YYYY-MM-DD.md，如果没有值得保存的内容则输出 NO_FLUSH",
    "systemPrompt": "只提取值得记住的内容，不要冗余信息。使用中文。"
  }
}

softThresholdTokens 建议设置为上下文窗口的 30%-50%，给后续对话留出足够空间。对于 128K 窗口的模型，30000-40000 是比较合理的值。

2.4 子代理并发控制

子代理（Subagent）的每个实例都维护独立的上下文窗口。并发数越高，同一时刻消耗的 token 总量越大。

"subagents": {
  "maxConcurrent": 4
}

除非任务确实需要高并发（如批量文件处理），否则建议将 maxConcurrent 控制在 4 以内。

---

三、进阶优化策略

3.1 工具延迟加载（Tool Discovery）

默认情况下，OpenClaw 采用静态注入策略：每次请求都在 tools 数组中携带全部可用工具的 JSON Schema，50+ 个工具的描述可能就要占用数千 token。

Tool Discovery 模式的思路是：只在基础 tools 数组中保留一个元工具 search_available_tools(query: string)，Agent 需要特定能力时再按需加载对应工具的 Schema。

这种"懒加载"方式可以显著减少每次请求的固定开销。

3.2 Prompt Caching（提示缓存）

如果你使用的是 Anthropic 的 Claude 模型，可以利用其 Prompt Caching 机制：

• 将系统提示等静态内容始终放在消息数组的开头；
• 通过 cache_control 标记让 API 侧缓存这些内容（缓存生存期约 5 分钟）；
• 命中缓存时，cache_read token 的费用比正常输入 token 便宜约 90%。

对于系统提示较长、调用频率较高的场景，这项优化的成本收益非常可观。

3.3 按需切换模型

并非所有任务都需要最强的模型。一个务实的策略是：

任务类型	推荐模型选择	理由
复杂架构设计、疑难 Bug	高端模型（如 Claude Opus）	需要强推理能力
日常代码生成、简单修改	主力模型（如 glm-5）	性价比优先
文件整理、格式转换	轻量模型（如 MiniMax）	任务简单，无需大模型

在 OpenClaw 中可以通过 /model 命令随时切换。

3.4 禁用 Thinking 模式

部分模型的 Thinking/Reasoning 模式会产生大量思维链输出，token 消耗可能膨胀 10-50 倍。如果任务不需要深度推理，建议显式关闭：

"models": {
  "your-model-name": {
    "params": {
      "thinking": { "type": "disabled" }
    }
  }
}

---

四、落地配置模板

综合以上优化项，下面给出一份可直接使用的完整配置。已在原始配置基础上标注了所有变更点：

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "aliyun/glm-5",
        "fallbacks": [
          "aliyun/MiniMax-M2.5",
          "aliyun/kimi-k2.5"
        ]
      },
      "models": {
        "opencode/claude-opus-4-6": {
          "alias": "Opus"
        },
        "opencode/kimi-k2.5-free": {
          "alias": "Kimi"
        },
        "qwen-portal/vision-model": {},
        "opencode/minimax-m2.1-free": {},
        "qwen-portal/coder-model": {
          "alias": "qwen"
        }
      },
      "workspace": "/Users/pc/.openclaw/workspace",

      // [变更] compaction: safeguard → default，启用 memoryFlush
      "compaction": {
        "mode": "default",
        "memoryFlush": {
          "enabled": true,
          "softThresholdTokens": 30000,
          "prompt": "将本次会话中的关键决策、代码变更、阻塞项提取到 memory/YYYY-MM-DD.md，如果没有值得保存的内容则输出 NO_FLUSH",
          "systemPrompt": "只提取值得记住的内容，不要冗余信息。使用中文。"
        }
      },

      // [新增] 上下文修剪
      "contextPruning": {
        "mode": "cache-ttl",
        "ttl": "4h",
        "keepLastAssistants": 3
      },

      "maxConcurrent": 4,

      // [变更] 子代理并发: 8 → 4
      "subagents": {
        "maxConcurrent": 4
      }
    }
  }
}

---

五、使用习惯建议

配置只是一半，日常使用习惯同样重要：

1. 定期手动压缩：每 10-15 轮对话执行一次 /compact，不要完全依赖自动触发。
2. 任务切换时重置：开始新任务前执行 /reset，避免无关上下文污染新会话。
3. 善用子代理隔离：独立的子任务通过 /spawn 分发，避免主会话上下文膨胀。
4. 监控上下文用量：养成查看 /status 的习惯，了解当前 token 消耗情况。
5. 按需选择模型：简单任务用轻量模型，复杂任务再切换到高端模型。

---

六、预期收益

基于上述优化项的组合，预期 token 节省效果如下：

优化项	预计节省	风险
Compaction default 模式	30-40%	低，配合 memoryFlush 可避免信息丢失
Context Pruning	20-30%	低，仅修剪过期的工具输出
Memory Flush	间接收益	无，纯增益项
降低子代理并发	10-20%（并发场景）	低，可能略微降低并行任务速度
综合效果	约 50-70%	—

建议分步实施：先加上 contextPruning 和 compaction.mode: "default" 这两项，这是收益最大、风险最低的组合。观察几天运行效果后，再逐步调优 ttl 和 softThresholdTokens 的具体数值。

---

OpenClaw 的 token 消耗问题本质上是 LLM 无状态架构的固有代价。好在框架本身提供了 Compaction、Pruning、Memory Flush 等完善的上下文管理机制——只是默认配置偏保守，需要根据实际使用场景主动调优。

核心思路就一句话：让 Agent 记住该记住的，忘掉该忘掉的。