OpenClaw 龙虾模型为何消耗大量 Token

近期，许多开发者和技术团队在使用 OpenClaw 与爱马仕（Hermes）模型时，都遇到了一个普遍困惑：为什么实际消耗的 Token 数量常常超出预期？

问题的关键往往不在于用户单次输入的简短问题，而在于每一次交互背后，系统都会执行一整套完整的智能体（Agent）工作流程。本文将深入剖析 OpenClaw 智能体运行时的成本构成，帮助您理解 Token 消耗的具体去向。

智能体成本结构与普通聊天的本质差异

传统的对话式 AI 产品，其成本计算通常仅基于输入和输出的文本长度。然而，OpenClaw 作为智能体框架，采用了完全不同的运行机制。

在每一轮对话启动前，系统都需要动态构建一个完整的上下文环境。这个过程包括：重新组合系统提示词（System Prompt）、加载当前可用的工具列表、注入工作区引导文件、接入完整的会话历史记录。此外，上一轮的工具调用结果、用户上传的附件内容，甚至经过压缩的历史对话摘要，都可能被包含在内。

值得注意的是，即使是后台的心跳（Heartbeat）检查任务，也遵循同样完整的智能体运行流程，只是触发方并非用户。

因此，表面上您只是发送了一句话，但模型实际接收到的“信息包裹”却庞大得多。可以概括为：用户问题 + 系统提示 + 引导文件 + 技能元数据 + 工具列表 + 工具参数定义 + 会话历史 + 工具结果 = 模型实际处理的输入。

系统提示词与上下文构建成本

OpenClaw 的系统提示词并非简单的角色描述。从源码执行路径看，每次运行时都会重新解析并组装当前所需的所有组件。

其中，工作区引导文件的注入是最容易被忽视的成本项。默认情况下，诸如 AGENTS.md、SOUL.md 等定义核心行为与规则的文件，都会参与到提示词的组装过程中。

源码中关于上下文注入的默认配置明确如下：

agents:
  defaults:
    contextInjection: "continuation-skip"
    bootstrapMaxChars: 12000
    bootstrapTotalMaxChars: 60000

这里有两点至关重要：首先，contextInjection 设置为 “continuation-skip” 并不意味着完全懒加载，它只是在安全续写模式下减少部分注入。其次，bootstrapMaxChars 和 bootstrapTotalMaxChars 指的是“经过截断后，仍会进入提示词的总字符数上限”，而非超过此限制就完全不计算成本。这意味着，项目自带的说明文档越详细，默认的上下文负担就越重。

技能（Skill）上下文的开销解析

一个常见的误解是，OpenClaw 会将所有 SKILL.md 文件的全文都塞给模型。实际上，当前的实现机制并非如此。

默认会注入系统提示的，是一份技能目录的元数据清单，其中包含了技能名称、功能描述和存储位置等信息，格式大致如下：

  
    ...
    ...
    ...
  

模型首先通过这份清单知晓有哪些技能可用。只有当智能体决策需要调用某个具体技能时，才会去读取对应的 SKILL.md 文件内容。

但这并不代表没有成本。OpenClaw 对技能提示词有专门的预算控制，默认的 maxSkillsPromptChars 参数设置为 18000 字符。因此，技能确实会消耗 Token，但主要消耗在技能目录的元数据描述上，并非默认全量注入每个技能的详细正文。

工具参数定义的隐藏成本

工具（Tools）对上下文的消耗分为两个层面。第一层是工具列表及其功能描述，这部分相对直观。第二层则更为“沉重”：发送给模型的、用于定义工具调用规范的 JSON 参数结构（Schema）。

这部分成本在平时并不显眼，但源码中的计算链路非常清晰。在上下文详情的统计中，每个工具的参数定义都会被序列化成 JSON 字符串，并累加其字符数。

官方文档也已明确指出：工具的参数定义（以 JSON 格式）会计入上下文成本，只是通常不会像普通对话文本那样直接展示给用户。

有时您感觉只问了一句话，但账单却显示消耗巨大，问题往往就出在这里。若想精确排查，可以优先查看上下文详情（例如通过 /context detail 命令），很多时候消耗的大头并不在直观的聊天记录里。

会话历史与工具调用结果的累积成本

只要您在同一个会话（Session）中持续对话，所有的历史消息就会不断累积。同样，工具调用的完整过程及其返回的结果，也会被记录到对话转录（Transcript）中，后续的每一轮交互都需要重新携带这些信息。

OpenClaw 也意识到这可能导致上下文窗口膨胀，因此设置了多道防护机制，例如：

agents:
  defaults:
    contextLimits:
      toolResultMaxChars: 16000
    contextPruning:
      mode: "cache-ttl"
      ttl: "1h"

这里的 toolResultMaxChars 默认值为 16000 字符。这并非指工具输出超过此长度就被完全丢弃，而是在实时处理路径上会进行智能截断，以防止一条超长的命令输出直接挤占下一轮对话的提示词空间。

contextPruning.mode = "cache-ttl" 这个设置也非常关键，它清理的是内存中的上下文缓存，而非磁盘上完整的对话历史记录。

心跳（Heartbeat）机制的后台消耗

这一点极易被用户忽略，但它真实存在，且并非“象征性的微量消耗”，而是实打实的模型调用成本。

OpenClaw 的心跳机制并非传统的轻量级 Ping 检查，它每次执行的都是一个完整的智能体回合（Agent Turn）。最新文档明确说明：心跳运行的是完整的智能体流程，其间隔越短，产生的 Token 消耗就越高。

如果心跳任务复用主会话，它通常会携带：当前的系统提示、必要的引导文件、当前会话的上下文状态，在很多配置下，还包括主会话的历史记录。

因此，它消耗的不是某种特殊的“监控 Token”，而是与用户对话完全相同的输入和输出 Token。有人会疑惑：明明没有发送新消息，为什么使用量统计仍在增长？原因正是后台的智能体仍在按预定计划运行。

关于这部分，最新版本提供了两个关键的性能优化开关：

agents:
  defaults:
    heartbeat:
      every: "55m"
      lightContext: true
      isolatedSession: true

lightContext: true 意味着心跳将尽量使用轻量级上下文，可能只保留必要的 HEARTBEAT.md 引导文件。isolatedSession: true 则更为彻底，它让心跳在一个完全隔离的会话中运行，不再复用主会话的庞大历史。官方文档给出了直接的量级对比：启用这些优化后，单次心跳的消耗可以从大约 10 万 Token 级别，显著降低到 2 千至 5 千 Token 左右。

所以，“定时探活是否消耗 Token”这个问题的答案是：消耗，而且这很可能是后台最容易被忽视的一笔持续性成本。

压缩、缓存与心跳功能的成本权衡

许多用户一看到 /compact 命令、缓存（Cache）或心跳（Heartbeat）功能，便下意识地将其理解为“省钱按钮”。这种想法可能过于乐观。

压缩（Compaction）的逻辑是：先支付一次生成摘要的 Token 成本，将过长的历史对话压缩成精炼的摘要，以此来换取后续对话能在有限的上下文窗口内继续进行。配置项中的 reserveTokensFloor、keepRecentTokens 等，正是用于控制何时触发压缩、以及保留多少最近的原始对话。

心跳机制同理。它能帮助维持会话的活跃性、保持缓存热度、确保后台任务不中断，但这些功能带来的成本并不会消失，只是转化为了维持系统特定能力所必需的开销。

总结与优化建议

综上所述，OpenClaw 的 Token 消耗较高的原因已经清晰。

这不是单一环节的问题，而是多层设计叠加的结果：每一轮对话都需要重建完整的系统提示；技能目录和工具参数定义本身占据了可观的上下文空间；会话历史和工具结果会持续累积增加负担。此外，后台的心跳机制在持续产生消耗，而压缩和缓存等功能，更多是在成本转移或折中优化，而非彻底消除成本。

很多时候，高昂的成本可能不完全是模型本身定价所致，而在于这个“智能体”运行时，究竟携带了多少隐形的“行李”在同步前进。理解这些成本构成，是进行有效资源管理和性能优化的第一步。