你的龙虾 AI 怎么这么费钱？拆解 OpenClaw 源码帮你省钱。

Hi，我是洛小山，你学习 AI 的搭子。

最近在研究 OpenClaw，这个工具的火热程度不用再赘述。

这是一个两周冲上 GitHub 全球第一的开源 AI 助理框架。

我打算写一个硬核系列，从源码层面拆解 🦞 的工程设计。

这是第一篇，聚焦费用：最近很多人在吐槽 OpenClaw 这么烧 Token，那它到底是怎么烧的呢？带着这份好奇，我直接读了源码，把钱到底花在哪里这件事彻底搞清楚了。

你的钱到底花在哪里、默认配置为什么这么贵、怎么省？

分享出来，希望能帮到你。

四篇基本写完了，节奏大概是这样：

一、配置篇：你的钱到底花在哪里、默认配置为什么这么贵、怎么省

二、上下文：Compaction、历史截断、transcript 持久化

三、记忆系统：长期记忆、session 隔离、跨会话召回

四、提示词工程：system prompt 结构、工具注入、缓存策略

那么，我们开始吧。

01｜为什么都说 OpenClaw 这么烧 Token？

假设你要让龙虾处理一次「帮我整理投标方案」的请求，同样的任务，配置不同，成本差多少？

不过，这个只是推测，实际上差距可能会比 3.8 倍还高不少。

虽然用户体感上只有一句对话，然后 AI 一直在回复。但幕后多出来的 $1.55，很难查清楚花在了哪里（就算看 API 后台也不一定能看出来）。

经过排查，我发现这是系统默认值叠加出来的结果。拆开来看，有九个地方在悄悄花钱。

02｜首先，系统默默用了最贵的模型

先来看这行代码：

OpenClaw 开箱就跑 claude-opus-4-6，这是 Anthropic 的顶配模型了…

但我想问，这真的是最优解吗？

我用我们 XSCT-A（Agentic 评测） 跑了一遍，不过这个平台还在建设中，仅供参考。

我专门针对 OpenClaw 的七个核心场景设计用例，包括 Agent 编排、渠道接入、文件操作、Gateway 配置、Plugin 开发、网页生成、Slides 生成，比之前的 L 通用语言基准更贴近实际使用。

XSCT-A 综合排名（来源：xsct.ai）：

两个值得关注的发现：

第一，Gemini 3 Flash Preview（$0.5/$3.0）以接近 Opus 的分数排第 3，价格只有 Opus 的 1/8。

第二，Claude Sonnet 4.6 排第 5，分数 56.6。

很多人习惯「Opus 太贵就换 Sonnet」，但在 OpenClaw 的 Agentic 场景下，Sonnet 比 Opus 低 5.4 分，定价却是 $3/$15，也就是说比 GPT-5.2 还贵，分数还更低。

再看维度细节，问题会更明显一些。

Opus 默认模型，但它在 OpenClaw 里的复杂场景其实很拉跨：

Gateway 困难级，Opus 只有 37.3，天花板 1。

Plugin 困难级只有 16.6。但这正好是高级用户最常用的场景。

怎么选更合适呢？

我建议分层调度，不要一个模型走天下。

• 复杂 Agentic 任务（Plugin 开发、Gateway 调试、多工具编排）→ GPT-5.2，比 Opus 便宜约 2 倍，XSCT-A 综合分仅仅差了 0.7
• 性价比主力（日常对话、文件操作、AgentOrchestration）→ Gemini 3 Flash Preview，$0.5/M input，分数只比第一名低 1 分
• 轻量 Fallback（纯问答、摘要、翻译）→ GPT-5 Nano，或者 Gemini 3.1 Flash，$0.05/M input，综合分只比 Opus 低 5.8 分，价格差距是 100 倍

OpenClaw 的 model-fallback.ts 里有主备模型切换的逻辑，理论上可以支持这套分层配置。

不过…我自己还没实际跑通过，只是看到代码有这个能力。

如果有大佬已经配起来了，欢迎评论区分享一下配置方式。

不过也要澄先清一下。

XSCT-A 这个虽然是基于龙虾的 System Prompt + 模拟的对话，但本质上还是一个静态 benchmark。

所以有它的局限：

1.测试用例相对固定，真实需求，某个模型在 benchmark 上的优势不一定能复现到你的任务。

2.静态的评价体系没法很好评估模型应变能力。Claude Opus 4.6 在真实复杂推理上可能更强，长文档深度理解、多步骤模糊推理、边界情况处理，这些其实是很难量化的，但你就是「感觉它更稳定」。

3.这个榜单的会随着用例迭代而漂移，今天的数据只能代表当下的用例效果。

XSCT 回答的是各应用场景下的成本决策问题，并不论证「哪个模型技术性能更强」。

举个具体数字。每天 50 条对话，平均每条 8,000 input + 1,000 output tokens，一个月下来：

即使你认为 Opus 比 Gemini Flash 真实能力强 20%（远超 benchmark 差距），Gemini Flash 月费仍然只有 Opus 的 1/8。

这个成本差距大到很难靠「可能更聪明」来抵消。

03｜你看不到 AI 的「内部思考」，但按最贵的价格计费

OpenClaw 对 thinking 的默认值取决于模型（代码片段）。

代码复杂的话，就看这张图把。

它默认跑 claude-opus-4-6，thinking 默认就是自适应，模型自己决定要不要深度思考、思考多少。

Thinking 阶段是模型正式回答之前的内部推理，用户其实看不到，不出现在对话里，但但按 output 价格计费。

这就取决于任务复杂度了，一次自适应 thinking 可能产生 几千或者上万个 thinking tokens。

根据 Claude 模型文档，输出好像是 6.4W Token 上限。

一个 3 轮 ReAct 任务的 thinking 成本：

$0.42 的 thinking 成本，加上 3 轮 input（约 178,500 tokens × $3/M = $0.54），thinking 占了整个 ReAct 阶段成本的 43%。

而你（用户）完全看不见它。

自适应其实是比较好的，简单任务可能只用几百 tokens，复杂任务可能用几万，性价比相对比较合适。

但如果你自己觉得任务可以不需要思考环节，或者就想锁定成本，可以在配置里显式设为 off 或 low。

我更推荐后者，主动设置 Low，避免自适应浪费太多钱。

04｜ReAct 循环：每个工具调用，都是一次完整 API 调用

ReAct（Reasoning + Acting）是现代 AI Agent 的核心执行模式：

关键点在于：每一轮 Think + Act 都是一次完整的模型 API 调用，携带截至当前的全部历史。

每轮 input 在上一轮基础上累加，3 轮下来总 input 约 209,700 tokens，而实际用户消息只有 1,200 tokens。

不过，也不用太担心，OpenClaw 对 ReAct 循环做了三层防护。

防护一：ToolResultContextGuard，就是说单条工具结果不能撑爆 context

每轮工具结果进入 context 之前都会过这个 guard：

单条超了长度就直接截断，全局超限从最老的工具结果开始压缩。

给我们的启发：

你需要识别你用小龙虾的场景，如果大部分时间是对话和文本润色，那上下文短一点也还行，但最好要要用 200k+ 上下文的大模型。

防护二：Tool Loop Detection，防止 AI 陷入无效循环

这个工具调用的检测分成三种死循环模式：

genericRepeat：一直死循环调用同一工具 + 同参数，结果也没变化，达到一个阈值触发全局熔断；

knownPollNoProgress：专门针对 command_status、process poll、process log 等轮询类工具，相同参数调用结果一直不变：

pingPong：A 工具和 B 工具交替调用（A→B→A→B...），且两边结果都没变化，然后 AI 在来回摇摆，没有任何进展：

系统对这些循环调用都做了一个熔断，达到 30 次就直接挂掉。

这个主要还是用来兜底，关键点在于你需要找一个逻辑推理能力强的 AI 模型。

防护三：dropThinkingBlocks，防止 thinking 在多轮间指数膨胀

如果不处理，第 1 轮的 10,000 thinking tokens 会进入第 2 轮的 input，

三轮下来 thinking 历史就是 30,000 tokens 的额外负担。

OpenClaw 在每轮发给 API 之前把历史里所有的 thinking blocks 清掉。

thinking 是「一次性消耗品」，用完即丢。

不过这个没啥好说的，因为 DeepSeek 提出的标准做法就是这样的。

05｜Prompt KV Cache的插曲

你可能会说，上下文长又怎么样，现在很多模型都支持 KV Cache 了。

于是我顺着扒了一下他们的系统提示词。

有个好玩的给你分享一下。

现在的版本，OpenClaw 的 system prompt 只注入时区，不注入精确时间。

但是！测试文件里写了一条注释，然后下面还加了个 ASSERT。

笑死，为什么？难道有人在系统提示词里埋💩？

于是我 Blame 了一下，发现，1 月 15 号，Peter Steinberger 提交 feat(date-time)，把精确时间拼进了 system prompt，还专门写了文档。

原来是大佬亲自埋💩。

起因有很多人说 AI 有幻觉，不知道今天是星期几。

于是大佬就直接在系统提示词里加了时间。

于是，用户们：？

Anthropic：6

KV Cache 直接秒级失效。

然后 9 天后…还是 Peter，提交 perf: stabilize system prompt time，把这个时间整个删掉了。

自己加的，自己删的 🤣。

删掉之后，🦞 就不知道今天是星期几了。然后用户开始提 issue：

• #1897：「AI 说今天是周六，其实是周日」
• #1928：「只有时区不够，要加完整日期」
• #2108：「AI 非常自信地说错了星期几」

又过了四天，Conroy 大佬提交了修复：加一行提示，让 🦞 自己去调 session_status 自己查时间。

cache 稳定性保住了，🦞 也重新有了时间感知。

大佬后面还顺手加了这个ASSERT，主动把 userTime: "Monday, January 5th, 2026 — 3:26 PM"传进去，然后断言它不应该出现在输出里。

这个断言现在永远通过，但一旦有人手滑把 userTime 重新接回来，测试立刻挂掉。

可能是防着一些精神小伙炸 System Prompt 吧…

然后把精确的时间移到 user message 里，system prompt 只留时区，cache 才能把把稳定命中。

但还有一个隐患没解决。

# Project Context直接拼进了 workspace 文件内容

AGENTS.md、SOUL.md 等等 bootstrap 文件的完整内容直接拼进 system prompt。

只要你编辑了这些文件，system prompt 就变了，cache 全部失效。

所以，如果你频繁修改 workspace 文件，cache 命中率会很低。

这里也扩展一下，学术界有篇 paper："Don't Break the Cache"（arXiv 2601.06007）在 500 个 agent session 上测了三种 prompt caching 策略。

结论是 prompt caching 可降低 API 成本 41–80%，破坏 cache 最常见的原因主要是「静态的提示词加入了动态部分」。

时间戳这个坑已经兜兜转转填掉了，但 workspace 文件内容注入是不好处理的事情。

06｜你没说话的时候，AI 心跳也在烧钱

这有点神奇，因为 🦞 设计上是 7 × 24 小时待命的 Agent。

所以他有一个心跳机制：即使你没有发任何消息，它也会定期叫醒 AI，读一下 HEARTBEAT.md，看看有没有需要主动处理的任务。

现在是每 30 分钟触发一次完整的 LLM API 调用。

携带完整 system prompt + 历史 context，和正常对话没有区别…该花的钱一分不少。

如果你的 gateway 全天运行（24 小时），每天触发 48 次心跳。

以 Opus 4.6 为例：

一天就是 8 刀…

一个月就是…240 刀（1,680 元）

用顶配模型，光心跳这一项，你一个月就要交 1700.

而且大多数场景下，HEARTBEAT.md 是空的，或者根本不存在。

OpenClaw 对空文件做了优化，如果文件内容判定为「无可操作任务」，会跳过这次 API 调用。

这里还有一个容易踩的坑：如果你为了节省资源一删了事，当文件不存在时，content 是 undefined，函数返回 false，优化是不会生效的，而且每次都调用。

这个是 🦞 的设计，文件不存在时，🦞 会自己决定有没有事情要做，也就是每次都调用。

所以如果你不用心跳，最直接的办法是关掉。

如果你需要用心跳但想压低成本，那你需要在 workspace 根目录建一个只有标题行的 HEARTBEAT.md，这样 isHeartbeatContentEffectivelyEmpty 返回 true，没有任务时自动跳过调用。

后面你想交代任务了，再往里面写具体内容；

任务完成后删掉内容，下次心跳又恢复回来静默模式。

07｜Compaction：历史压缩又是新的吞金兽。

上面说到 ReAct 循环会累积 input tokens，OpenClaw 通过发起一条新消息来解决。

也就是说，一旦对话历史超过阈值，自动压缩成摘要，释放 context 空间。

当对话历史超过阈值，自动把历史压缩成摘要，释放 context 空间。

乍一听很合理，就该压缩提示词省成本。

但我扒了一下压缩的实现，发现成本可能会比想象的更高。

第一层：generateSummary 内部强制使用 reasoning: "high"

代码注释直接写了：generateSummary 内部用的是 reasoning: "high"…

extended thinking 最高一档。

然后，这还是底层 SDK 函数，没有参数可以关掉。

也就是说，每次对话完，🦞 都悄悄产生一批按 output 价格计费的搞一把 带 Thinking 的压缩，然后用户完全不知道。

芜湖。

第二层：长对话触发 summarizeInStages，最多 3 次 API 调用

对话历史特别长的时候，龙虾不会只做一次压缩，流程是这样的：

1. 把历史分成 2 段，然后各调用一次 generateSummary（含 high reasoning）
2. 用第 3 次 generateSummary 合并上面两端摘要。

一次压缩 = 最多 3 次完整 API 调用，全部含 high reasoning。

还有重试 3 次的设定），如果 API 临时出错的话，最坏情况 9 次调用。

我用 xsct 的模型评估 AI 算了一下。

接近 5 块钱，压缩一次上下文…

而且这个没有配置开关，DEFAULT_PARTS = 2 是硬编码…

如果…重试了 9 次…

那…超长上下文 + 极端情况下…

就是 45 块钱，压缩一次上下文…

要不还是考虑一下这个吧…

08｜消息连发：🦞 会等你说完再开始处理

你快速连发了 3 条消息——「等等」、「我补充一下」、「其实是这个意思」…

AI 第一条还没回完，全进来了。

OpenClaw 对这个场景有完整的处理机制，策略会分两层。

理解这两层，你就能知道：窗口期多长、连发怎么连、超出窗口会怎样。

第一层，AI 空闲的时候，走合并逻辑

AI 空闲时你连发消息，走的是这一层。

同一个发送者的连续消息进入一个滑动窗口缓冲器，每来一条新消息就重置计时，等到你真的「停下来」才整批开始处理。

不过，默认窗口窗口是 0 毫秒，默认关闭。

你需要手动配置才能生效。

在这个窗口之内的多条对话会被 \n 拼接成一条消息交给 AI，AI 看到的是完整语义，不是碎片。

连发技巧：只要在窗口时间内持续发，窗口就会一直往后推。

比如设了 2s，你每隔 1.9s 发一条，可以无限串联。但你一旦停下来超过 2s，就开始处理。所以你可以设置成 5 秒，这样给自己一些从容的时间。

第二层：AI 正在回复时你连发，走待处理队列

AI 忙着回上一条时，新消息不会打断它，而是进入 followup queue 等待。这一层有两个关键行为：

1、合并等待窗口：AI 回复完毕，准备处理队列前，会先等你停下来，默认 1 秒：

这里同样是滑动窗口，只要 1 秒内还有新消息进来，🦞就继续等。

2、合并：等待结束之后，队列里积压的所有消息合并成一个 prompt 一次性交给 AI。

你可能会问，那这个队列有没有上限呢？

有的兄弟，有的。

队列有容量上限，默认 20 条，超出后的消息默认走 summarize 策略。

被挤掉的消息不会消失，而是提炼成摘要附在下一次处理的 prompt 里，AI 知道「有消息被压缩了」。

你也可以配置成 old（丢弃最早的）或 new（直接丢弃新来的）。

所以：不要叨叨叨，一直说一直说。发起的消息一定要控制在 20 条以内，不然又要白花钱。

09｜历史没有默认上限，越聊越贵

我们一起来看下输入  Token 的构成。

input tokens = system prompt + 全部对话历史 + 当前消息

这里的「全部对话历史」是没有默认上限的。

limit 不传或传 0，直接 return messages，全量历史进去。

这就意味着：如果你用了可能是三个月的 session，每次发消息都把三个月的历史带进去。

三个月可能是几十万 tokens。

最新的一条消息，撬动的是整块历史的计费。

你可能会说：山佬你不是说大模型会压缩吗？压缩过的历史会小很多吧？

对没错，但大模型消息压缩的是旧消息，压缩结果（摘要）本身还是要带进去的，而且摘要会随着对话继续累积。

大模型压缩只是减缓了增长，并没有消除增长。

这里有两个配置项，对应两种场景：

dmHistoryLimit 是在大模型消息之上的硬截断：不管摘要多大，只取最近 50 轮，其余抛掉。

这两个相互配合，才能真正把 input 长度压住。

不设这个配置，就等于任由历史滚雪球。

10｜Subagent：每个子 Agent 都带着 thinking，成本悄悄翻倍

当你问 AI 一个复杂问题，OpenClaw 处理复杂任务时会启动子 Agent 来并行处理子任务。

每个子 Agent 都是独立的 Agent 实例，有自己的上下文、自己的调用链、自己的 thinking。

有个关键点：子 Agent 的 thinking 级别不继承父 Agent，而是由子会话自己解析。

没有显式配置的情况下，thinkingOverride 是 undefined，子会话自己走模型默认值。

claude-4 系列默认自适应，于是父 Agent 在 thinking，每个子 Agent 也在 thinking，全部按 output 价格计费，全部对用户不可见。

子 Agent 做的事往往比较具体：查文件、调工具、聚合数据。

这类任务大概率不需要 thinking，我觉得关掉就行。

一行配置，就把所有子 Agent 的 thinking 全部关掉。

父 Agent 该思考还是思考，子任务纯执行，能省点钱。

终｜把这些加在一起

一次「普通」的活跃会话，成本构成大概是这样：

理想账单五毛五，实际账单四块五。

差距来自几个默认值的叠加：最贵的旗舰模型、adaptive thinking 全开、心跳全天不停、历史无上限、子 Agent thinking 没关。

有一说一，🦞 本身已经做了很多防护了，比如ReAct 循环的三层限制（工具结果截断、循环检测、thinking 历史清理）、两层消息合并（入站缓冲 + 待处理队列 collect 模式）…

这些设置，在正确的配置下可以主动减少 API 调用次数。

但这些防护大多需要主动配置才有用，不配等于白给。

所以，这些动作，你可以立刻做一下。

或者尝试让 🦞 给你改。

省钱立竿见影：

1、关掉心跳或拉长间隔：agents.defaults.heartbeat.target: none

2、给消息历史设上限：私聊 dmHistoryLimit: 50，群组 historyLimit: 30

3、关掉子 Agent thinking：agents.defaults.subagents.thinking: "off"

减少不必要的 API 调用：

1、开启入站合并缓冲：messages.inbound.debounceMs: 2000（默认关闭，连发消息合并为 1 次调用）

2、待处理队列默认已是 collect 模式，AI 忙时积压的多条消息会合并处理，无需额外配置

保住 cache 命中率：

3、workspace 文件（AGENTS.md、SOUL.md）尽量保持稳定；频繁修改期间 cache 基本失效，system prompt 每次全价计费。

好啦，省钱篇到此就告一段落了，如果你对后续的上下文篇、记忆篇、提示词工程篇感兴趣，欢迎关注。

文章来自于“洛小山”，作者 “洛小山”。