月初看到账单的时候我差点以为后台被刷了。自用的 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 参数: opread / list / write / deletepath路径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_roundcurrent_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 消耗这件事说到底就是一个返璞归真的过程让每一轮请求都尽量只装必要的东西模型自然就便宜了。 
长河君 · 2026/10/21 7:02:41 · 阅读 1.2k OpenClaw 代理 Token 消耗暴涨三倍？三招优化砍回 60% 成本
月初看到账单的时候我差点以为后台被刷了。自用的 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 参数: opread / list / write / deletepath路径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_roundcurrent_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 消耗这件事说到底就是一个返璞归真的过程让每一轮请求都尽量只装必要的东西模型自然就便宜了。