OpenClaw Token 消耗降一半：上下文、工具与模型配置实战优化

三个月前我往 API 账户里充了一笔预算，本想着能撑过整个迭代周期，结果一个下午的重构任务就把余额烧掉一大截。那种看着 Token 消耗曲线往上飙又不知道砍哪儿的感觉，用 OpenClaw 的朋友应该都懂。

后来我把 OpenClaw 从模型配置到工具调用策略整体捋了一遍，没换更便宜的底层模型，也没降低任务复杂度，单纯靠配置调整就让同样强度的活省了差不多一半 Token。这篇文章把我实际验证过的配置和思路写出来，给正在被 Token 账单追着跑的朋友一个参考。内容不涉及玄学，全部是可复现的配置项和操作路径。

1. 摸清“隐形账单”到底在哪产生

1.1 上下文是重复计费的重灾区

很多人以为 Agent 烧 Token 是因为模型“想得太多”，实际上大头在上下文的重发。OpenClaw 这类 Agent 框架每执行一步工具调用，都要把系统提示、工具定义、历史消息、最新结果重新发给模型算一遍。只要会话没有压缩，历史内容就一遍又一遍地重复计费。

举个具体例子。假设某个任务触发 30 次工具调用，系统提示加工具定义约 4000 Token，平均每轮新增 1000 Token。那么第 30 轮请求的输入长度大约在 4000 + 29×1000 = 33000 Token。这轮请求本身不夸张，但问题在于前 29 轮也在发生类似请求，整个会话累计发送的输入 Token 大约为 30×4000 + (0+1+2+...+29)×1000 = 555000 Token。而模型真正输出的 Token 可能只有不到 3 万。输入侧和输出侧的差距就是隐形账单的来源。

所以省钱逻辑的第一步不是压输出，而是让输入侧的重复计算降下来。

1.2 工具回传和失败重试是第二桶金

OpenClaw 执行 shell 命令后会把 stdout、stderr、退出码全部拿回来。如果命令输出的是几百行编译日志或超长目录树，这些内容会被原封不动塞进上下文，成为后续所有轮次都要携带的“历史包袱”。我见过最长的一次，光一个 find 命令的输出就贡献了 1.8 万 Token，而且后面每轮请求都会重新算一次这些内容。

失败重试同样隐蔽。工具调用如果报错，Agent 会尝试换一种方式重新执行，有时连续四五次都在同一个问题上打转。每一次尝试都是完整的新请求，每次请求都会把已膨胀的上下文再送一遍。配置部分我会重点讲怎么限制工具回传体积、怎么减少无意义的失败循环。

为了更直观地理解成本构成，我把常见消耗点整理成了表格：

2. 第一刀：模型与请求级配置

2.1 给不同类型的任务挂不同的模型

在 OpenClaw 的配置里，模型不一定是全局固定的。很多版本支持配置多个模型档位，不同的任务类型走不同的模型。这个能力看着不起眼，实际却能省下非常可观的开销。

我的策略是：琐碎操作、文件读取、日志定位这类“跑腿型”任务，走便宜模型或响应更快的模型；只有方案设计、多文件重构、复杂 bug 分析这类“动脑型”任务，才让顶级模型上。

举个例子。我让 OpenClaw 批量重命名几十个文件并同步修改引用，这种任务根本不需要动用复杂推理，用便宜模型就能完成。要是全局绑定最强模型，相当于开着跑车去取快递，油钱全花在跑腿上了。

2.2 max_tokens、temperature、思考预算

三个参数值得单独说。

max_tokens 决定模型单次输出上限。我见过不少人在配置里把 max_tokens 设得特别