月初看到账单的时候，我差点以为后台被刷了。自用的 OpenClaw 代理跑了不到一个月，Token 消耗比预期翻了三倍，光是输入 Token 就把预算吃穿。刚开始我也像大多数玩家一样，把锅甩给“模型太贵”，后来把会话日志导出，按 token 分布一个个拆开看，才发现真正的大头根本不在模型价格上，而在我自己根本没意识到的三条消耗链路里。
这篇文章就把我的排查过程和最终落地的三招优化方案完整写出来，每一招都有实测数据、改动前后的对比，以及我踩过的坑。说句实话，跑个人 AI 代理项目的朋友，无论你用的是 OpenClaw 还是类似框架，这套思路基本都能直接用。
1. 先弄清一个事实：OpenClaw 的 Token 不是被“聊天”烧掉的
很多人以为 Token 消耗大是因为自己用得多，其实大部分项目打开日志会吓一跳：一次看起来很简单的人机对话，背后可能塞了几万 Token。要省钱，第一步不是急着改 Prompt，而是先把 OpenClaw 的消耗链路拆清楚。
1.1 三条消耗链路，多数人只盯着模型价格
我排查完发现，OpenClaw 的成本几乎由三部分构成：
- 固定开销：系统提示词、工具描述、参数定义、历史对话缓存。每轮请求都要重新发送一遍，只要不优化，它就一直烧。
- 历史堆积：多轮任务里，模型每一次工具调用返回的结果都被保留在上下文窗口里，尤其是抓网页、读文件、跑命令这种大输出，几轮下来就把上下文撑满。
- 无效调用：模型为完成一个本来一句话就能回答的问题，反复调用工具；或者工具报错后，模型在同一个上下文里重试两三次，每次都重新消费 Token。
这三条链路里，最容易被忽视的是第一条。我在默认配置下跑了一个“整理三十个文件信息”的任务，发现系统提示词加工具描述占了接近四千 Token，而真正干活的内容刚开始只有两千多。也就是说，一半以上的输入开销是在给模型做“入场准备”，和本次任务毫无关系。
1.2 先给上下文“称重”：一次调用实际塞进去多少内容
动手优化前，我建议你先做一个“称重”动作。OpenClaw 通常会在日志里输出每次请求的 token 明细，或者你可以用带审计信息的开发模式跑一天，把每次请求的 token 数按来源分类统计。
我的做法很简单：写了一个小脚本，读取 OpenClaw 会话日志，把每一次请求拆成 system、history、tool_result、user 四个字段分别统计 token 数，跑完一组任务后输出一个占比饼图（纯文本那种）。第一次统计结果就让我清醒了：
- system + tools 固定开销占比约 25%；
- 超过 10 轮的工具输出历史占比约 55%；
- 常规对话内容只占 20% 不到。
所以真正该动刀的方向很清楚：固定开销要压缩，历史堆积要治理，无效调用要拦截。下面三招就是这个思路的落地产物。
2. 第一招：压缩系统提示词与工具描述，把固定成本砍到原来的三分之一
这是我投入产出比最高的一招。OpenClaw 的默认配置为了适配各种任务，系统提示词和工具描述写得非常“周全”，但实际跑起来里面一半以上是模型用不到的废话。压缩系统提示词不是简单地把文字删短，而是重新设计信息结构。
2.1 系统提示词只保留“行为约束”，不留背景故事
默认的 system prompt 我见过最夸张的版本有上千 Token：会解释“你是一个强大的 AI 助手”，会说明“你应该在适当的时候使用工具”，会列举常见错误，还会写上“如果用户没有明确指示，请默认采取保守策略”这类模糊规则。
我把这些全部删掉，只保留三个必需的行为约束块：
- 角色与边界：一句话描述你是什么角色（例如“你是运行在 OpenClaw 里的自动化操作员”）；
- 决策规则：只在两种情况下需要写明——“何时必须调用工具”和“何时禁止调用工具”，其余靠模型本能；
- 输出格式：有明确结构化要求时写，没有就不写。
优化前某个项目的 system prompt 是 860 Token，优化后压到 140 Token。这个改动你不需要改 OpenClaw 源码，直接在配置里的 system_message 覆盖字段调整即可，生效即时。
2.2 工具描述统一用“一句话 + 必要参数 + 关键禁忌”模板
工具描述是固定开销里最大的隐藏杀手。默认配置里，每个工具的描述可能包括功能说明、使用场景、示例、参数详解、返回值说明、注意事项，二十个工具加起来轻松突破一万 Token。问题是这些描述在每一轮请求里都会原封不动发送，你越想“描述清楚”，模型每轮付的钱就越多。
我给自己定了工具描述模板，所有自定义工具都按这个来写：
工具名：一句话说明功能（不超过 20 字） 参数：逐个列出参数名、类型、是否必填、一句话含义 关键约束：只写“禁止用于 X”或“必须注意 Y”这类会导致错误的内容拿一个搜索工具举例，优化前描述 252 Token，优化后 58 Token：
优化前： 工具: web_search 描述: 使用该工具在互联网上进行搜索，输入关键词后返回搜索结果列表，包含标题、链接、摘要等信息。搜索是实时的，通常用于获取最新信息。一般建议以英文关键词搜索可获得更多结果，必要时将中文关键词翻译为英文。如果首次搜索没有结果，可以尝试换用同义词或者更泛化的关键词再次搜索。返回结果中可能包含广告，请忽略广告。注意结果中的时间信息，判断信息新鲜度。…… 优化后： 工具: web_search 描述: 实时搜索网页，返回标题、链接、摘要。 参数: q（关键词，必要时自动译为英文）；max（返回条数，默认 5） 约束: 结果已按时间降序，广告已过滤。一开始我很担心描述太短会让模型乱调用工具，实测跑了一周，工具误用率不但没有上升，反而因为描述里删掉了很多模棱两可的修饰词，模型选工具的路径更稳定了。
2.3 用“聚合工具”代替“工具全家桶”，减少工具数量
OpenClaw 这类代理框架支持注册几十个工具，但每多一个工具，模型在选择时就需要多处理一份描述，而且工具越多，选择错误的概率越高。我的做法是把同领域的操作聚合到一个工具里，用第一个参数作为操作类型。
例如原来有 file_read、file_list、file_write、file_delete 四个工具，合并成 file_ops 一个工具：
工具: file_ops 参数: op（read / list / write / delete）；path（路径）；content（仅 write 时需要） 约束: write 只允许写入工作目录。这样工具数量从二十个降到七八个，固定开销又砍掉一大截。模型选择工具的路径也简单了，几乎不会出现“想读文件却调了写文件”这种低级错误。
2.4 把“静态知识”从系统提示词里挪出去
系统提示词里还经常藏着大量不需要每轮重复发送的内容，比如文件路径说明、知识库摘要、预设格式模板。这些内容确实是任务需要的，但不应该放在 system prompt 里，而应该改为工具运行时按需返回。
例如你要让 OpenClaw 操作某个目录，不要在 system prompt 里写“工作目录在 /home/user/projects/xxx”，而是让文件系统工具返回路径信息，或者用环境变量注入。这样静态内容只在被调用那一刻出现一次，而不是伴随每一轮请求。
这一整套操作下来，我的项目固定输入开销从平均 3800 Token 降到 950 Token 左右，降幅约 75%。固定开销占比在总成本里可能不是最大的，但它是“每轮都交”的过路费，越长的任务这里省得越多。
3. 第二招：给上下文装上“闸门”：无关历史和工具结果别再全部入窗
如果说固定开销是小刀割肉，那历史堆积就是在放血。OpenClaw 的默认上下文组装策略是很朴素的“有多少塞多少”，多轮任务里，早期工具返回的大块文本会跟着模型走完全程，直到把上下文窗口挤满。我处理这个是第二个优化阶段的核心工作。
3.1 历史消息分三类处理：保留、摘要、丢弃
我开始改造上下文组装逻辑前，先梳理了 OpenClaw 历史消息的类型，把它们分成三类：
- 重要消息：用户最终目标、用户显式纠正、模型最终输出、任务关键节点，这些必须原样保留；
- 可压缩消息：工具调用结果、网页抓取正文、中间计算过程，转成摘要或只保留关键数字；
- 可丢弃消息：模型单步思考的过度展开、无效工具的重复返回、与最终输出无关的调试信息。
改造后，OpenClaw 的上下文组装规则变成：窗口只保留最近 3 轮完整消息，更早的历史统一浓缩成一条摘要消息，摘要默认保留结论、数字、动作项三类信息，其余细节丢弃。摘要每隔 6 轮生成一次，而不是每轮都生成——每轮生成摘要的 Token 成本会比省下的还多。
伪代码逻辑大致是这样：
history_keep = [msg for msg in history if msg.is_important or msg.round >= current_round - 3] summary_block = get_summary_cache(target_round=current_round - 6) context = assemble(system_prompt, summary_block, history_keep, active_tool_results)这里值得多说一句:摘要生成任务不要用你平时跑 OpenClaw 的最强模型，用一个中等规模的模型去干就够了。摘要只需要达到“关键信息不丢”的水平，不需要文采，用大模型反而浪费。
3.2 给工具结果加“过期时间”，短时效数据不再反复入窗
我观察到一个很有意思的现象：OpenClaw 多轮任务里，模型经常在第三轮和第四轮引用同一个网页抓取结果，而这个结果在第二轮就已经返回过了。为什么?因为它一直躺在历史里,模型没必要重新抓取。但另一方面，一个 5000 Token 的网页正文如果 20 轮都挂着,后面 17 轮就纯粹在浪费钱。
我的解决方案：给工具结果设置一个 TTL（生存时间）。OpenClaw 的上下文缓存区支持自定义生命周期，我把工具结果按类型分了三档：
- 全局信息（文件路径、配置项）：保留整个会话；
- 任务相关结果（网页正文、查询返回）：保留 10 轮或 30 分钟，超时自动归档成摘要；
- 一次性结果（命令执行输出、临时数据）：保留 3 轮，3 轮后直接丢弃。
这个改动实现起来需要翻一下 OpenClaw 的上下文管理器源码,但逻辑不复杂：在消息对象上增加一个 expires_at 字段，组装上下文时过滤掉过期消息。实测效果立竿见影：一个“抓 5 个网页输出对比报告”的任务，未优化时最终上下文 28k Token，优化后 9k Token，任务质量没有明显下降。
3.3 工具返回内容先“抽干水分”再入窗
比 TTL 更重要的是入口拦截：与其让 5000 Token 的网页正文先入窗再被摘要，不如在工具返回那一刻就先压缩。我给 OpenClaw 的网页抓取工具增加了一个后处理步骤，返回前先做两件事：
- 抽取正文主要内容，去掉导航、推荐位、页脚这些噪音；
- 如果正文超过 800 Token，只保留每个自然段的前两句和所有数字/引用内容。
一开始我做的是简单截断，结果模型经常遗漏关键信息，后来改成保留“每段首尾句 + 数字 + 引用”的策略，信息密度明显高了很多。用我自己维护的正文抽取脚本处理一个含广告的长网页，原始 HTML 转成纯文本约 6800 Token，抽取后只剩 1120 Token，直接省掉 83%。这一步不需要模型参与，纯正则和关键词权重就能完成，几乎零成本。
4. 第三招：拆掉“超大任务”，让 OpenClaw 从大模型循环变成小任务流水线
前面两招解决的是“每次请求塞了多少”，这一招解决的是“到底调用了多少次”。OpenClaw 默认的工作方式是用户扔一个大任务，模型在一个循环里反复思考、调用工具、读取结果，直到任务完成。大任务意味着大上下文，意味着每一轮都是高输入 Token，意味着任何一次工具失败都会带着整个上下文重复消费。这一招要做的就是一个字：拆。
4.1 让模型先出“任务拆解计划”，而不是直接执行
以前我会直接告诉 OpenClaw：“调研 A、B、C 三个方向，分别列出优劣势并给出建议，最后输出一份报告。”然后看着它疯狂抓取几十个网页，把中间结果全部堆在一个上下文里，最后生成报告时上下文已经快爆了。
现在的做法是：先让模型只输出一个拆解计划，这个计划用 JSON 格式返回，不让它执行。需要注意，在请求“拆解计划”这一步，系统提示词和工具描述照样会烧一笔 Token，但它的代价远小于一个大任务循环里反复重构上下文。
拆解计划的 Prompt 模板：
请把上述任务拆成不超过 5 个子任务。每个子任务必须满足： - 有明确的输入来源（抓哪个网页/读哪个文件/问哪类数据） - 有明确的输出产物（一段总结/一个表格/一个判断结论） - 不可再拆，必要时调用工具。 只输出 JSON，不要执行任何工具。拿到 JSON 后，我用一个外部调度脚本按顺序逐个发起任务。每个子任务完成后，把结果写入一个 notes 文件，而不是留在上下文里。等到所有子任务跑完，最后再发起一次生成请求，让模型只读 notes 文件内容，输出最终报告。
这个模式实施后，最大上下文从 34k Token 降到 12k Token 左右。模型不用再同时记住 A、B、C 三个方向的一切细节，只需要在最后一步读取汇总要点，反而报告结构更清晰。
4.2 结果缓存：同一个请求不要花两次钱
拆完任务后出现了一个新的问题：子任务之间经常有重叠。比如调研 A 方向时抓取的某个网页，B 方向可能也需要引用。默认情况下模型会重新抓取一遍，多花一次工具调用和一大笔返回 Token。
解决办法很粗暴：给工具调用加一个哈希缓存。OpenClaw 的每次工具调用都有参数，我把参数序列化后做一个 SHA256 哈希，如果同一会话内相同的调用出现过，直接返回上一次的结果。这个功能在配置最简单的情况下可以用一个全局 dict 实现，几行代码的事。
缓存命中率比我预想的高不少。在一个“对比五个开源项目”的任务里，三个项目主页有互相引用，同样的页面被抓了两三遍。加了缓存之后，重复抓取全部命中，总 Token 消耗又下降了约 18%。
4.3 失败重试要“降级重试”，不要“原样重试”
OpenClaw 遇到一个工具调用失败后，默认会把错误信息扔回给同一个模型，让它在同一个上下文里再试一次。这个重试逻辑看起来很自然，但副作用是：模型每次重试都会重新读取一遍全部历史，成本极高，而且如果问题是上下文太长导致的超限，原样重试只会无限失败。
我的策略是分三个等级处理失败：
- 第一次失败：检查是不是瞬时错误（超时、限流），如果是，直接等待 20 秒后重试原请求，不消耗模型调用；
- 第二次失败：把当前上下文压缩掉一半，丢弃过期工具结果和中间思考，再让模型重试；
- 第三次失败：切换更小的模型执行这次工具调用，毕竟很多失败不是模型能力问题，而是上下文太复杂导致选错了参数。
此外我还给每次工具调用的返回结果设置了一个硬上限，例如最长接受 1200 Token，超出部分截断。截断虽然会损失一些细节，但远比让模型在上下文里反复读取一段超长结果要划算。
5. 实测对比：三个典型任务优化前后到底差多少
前面说的是方法，这一节直接给数据。我把自己常用的三个任务跑了一遍，同一个 OpenClaw 配置、同一个模型、同一批输入材料，只是把优化前后的路由逻辑分别跑了一次。每个任务各执行三轮，取中位数。
5.1 场景一：抓取 5 个网页并输出对比报告
这是典型的长上下文场景。优化前模型会在一次大循环里抓完所有页面，然后基于全部正文生成报告。
- 优化前：输入 Token 176k，输出 Token 8.4k，总成本约 0.55 美元；
- 优化后：输入 Token 61k，输出 Token 7.9k，总成本约 0.21 美元。
降幅约 62%。节省主要来自第二招的工具结果 TTL 和正文抽取，上下文峰值从 31k 降到 11k，但报告质量没有明显变化。
5.2 场景二：整理本地 30 个文件的关键信息为表格
这个任务的特点是大量 read 工具调用，每次读文件都可能返回几百到几千 Token。
- 优化前：输入 Token 148k，输出 Token 3.2k，总成本约 0.41 美元；
- 优化后：输入 Token 52k，输出 Token 3.0k，总成本约 0.16 美元。
降幅约 61%。第三招的任务拆解起了主要作用：优化前模型把 30 个文件的读结果全部挂在上下文里，导致后面几轮读文件的成本急剧抬升；拆成 6 个子任务后，每个子任务只读 5 个文件，结果写完 notes 就归档。
5.3 场景三：两周的日常自动化对话，每天约 20 轮
这个场景模拟的是“让 OpenClaw 常驻后台，每天处理一些轻量操作”的用法。优化前每一轮请求都把前一天所有对话历史带上，到第二周时上下文已经非常臃肿。
- 优化前：总输入 Token 684k，总成本约 1.8 美元；
- 优化后：总输入 Token 209k，总成本约 0.58 美元。
降幅约 68%。为什么比前两个场景更猛?因为时间跨度长，摘要压缩的效果被放大了。优化后每日会话启动时只带一条前日摘要（大约 400 Token），而不是全部原始历史。
三个场景综合下来，总降幅确实落在 60% 上下。我自己的结论是：“60% 这个数字是可以复现的，但前提是你先愿意花半小时把日志拆开看。”
6. 优化后的副作用与几个必须避开的坑
数据好看不代表过程顺利。这三招改完，我也踩了几个不大不小的坑，这里统一写出来，免得你重复走。
6.1 系统提示词压太狠，模型开始“自由发挥”
第一次把系统提示词从 860 Token 压到 140 Token 后，模型确实变“省”了，但同时开始频繁跳过工具调用直接回答。原因是我删掉了一句“必须先使用工具获取信息再回答”的约束，当时觉得模型应该懂，结果它真不懂。
解决办法也很简单：系统提示词里的决策规则单独保留，压缩的是装饰性描述和重复示例，不是行为开关。如果你发现精简后模型行为态度明显变化，优先检查是不是把这类规则词删了。
6.2 摘要压缩丢掉了关键词，最终报告漏数据
摘要策略的坑发生在很细的地方：模型生成摘要时，觉得“某公司估值 30 亿”是一个普通数字，没有写进去，结果最终报告里这个关键数据丢了。我后来在摘要任务的 Prompt 里显式要求“所有金额、日期、百分比、人名、项目名必须原样保留”，问题才解决。
如果你也做摘要压缩，建议在摘要模板里加一条“禁止改写数字和专有名词”的规则。这个规则本身只有十几个 Token，但能保住的往往是最关键的信息。
6.3 工具结果 TTL 太短，模型反复重新抓取同一个页面
TTL 参数不是越小越好。我一开始把网页抓取结果的 TTL 设为 3 轮，结果模型在同一个任务里频繁重新抓取同一个页面，虽然每轮上下文小了，但总调用次数变多，成本反而回来了一部分。
优化后我根据实际日志调整为“任务相关结果保留 10 轮或 30 分钟”，在上下文体积和重复调用之间找到了平衡点。这个值在你自己的场景里可能需要调几次才能定下来，建议翻日志看同一个工具结果被重新调用的频率来决定。
6.4 三个容易忽略的隐藏开销
除了上面三招，还有三个很容易忽略的小点也分享一下：
- 并行工具调用不是免费的：OpenClaw 支持并行调用工具，并行看起来快，但下一轮模型需要把并行返回的全部结果都读一遍，Token 消耗是线性叠加的。我的策略是单次返回小于 800 Token 的结果可以并行，大结果一律串行。
- 日志别开 verbose 模式：我调试时开过一段时间的 debug 日志，每条日志会把完整上下文 dump 一遍。不是说日志本身烧 Token，而是 debug 模式容易让会话卡在很长的上下文里，间接推高成本。
- 模型切换也有隐藏成本：改用小模型跑摘要时，如果小模型的系统提示词和大模型不一致，它可能生成不符合要求的摘要。最好给不同模型单独配一套精简系统提示词，而不是直接复用。
这三招从固定开销、历史堆积、调用次数三条链路同时下手，组合起来才有 60% 的降幅，单用任何一招都很难达到这个数字。每个项目的配置、任务类型、模型价格都不一样，建议你先按 1.2 节的方法称重一次，看看自己的大头在哪条链路里，优先动那一块。
最后说一个我自己的土办法：每次改完配置，我都把优化前后的 Prompt 全文和工具清单导出来，diff 一下，写一行备注记录“这次删了什么、为什么删”。坚持两周之后，你对哪句话说出去是浪费、哪句话删了会出事，会形成非常准确的直觉。Token 消耗这件事，说到底就是一个返璞归真的过程：让每一轮请求都尽量只装必要的东西，模型自然就便宜了。
