从API Token失控到月省千元：OpenClaw智能体成本优化实战

如果你也跑过OpenClaw这类个人智能体平台，应该能理解月初看到账单时的表情——我第一次把OpenClaw完整接入工作流时，API Token消耗一度冲到每月1000多美元。不是模型选得不对，也不是功能写崩了，而是根本没人告诉我Token会以多快的速度从账户里消失。后来我把这套系统的月成本压到了20美元上下，功能基本没砍，跑的任务反而更多了。

这篇文章就把我这一路踩坑、记账、调参数、改架构的过程完整拆开，给正在被API账单折磨的人一条可复制的路子。它适合两类人：一类是刚把OpenClaw跑起来、每天被成本吓到的个人用户和小团队；另一类是准备在手机上用Termux部署OpenClaw、想少花钱多办事的折腾型玩家。下面讲的所有配置和思路，我都按“能直接抄作业”的标准来写，尽量不让你再交一次学费。

1. OpenClaw账单失控，先别急着怪模型贵

1.1 智能体调用模型的频率，和你想的完全不一样

我在排查自己账单的时候做过一次采样：某一个看似简单的“整理订单并生成回复”任务，最终在日志里留下了27次模型调用。每次调用的Token数量不大，但次数一多，成本就从“可以忽略”变成了“触目惊心”。

为什么会这样？OpenClaw这类智能体平台的核心逻辑是“技能链式调用”。一个用户指令进来，通常要先做意图识别、再拆解子任务、每个子任务又各自调用模型处理，最后还要汇总结果、做格式校验。任何一步出现JSON格式错误，或者结果不符合预期，又会触发重试。这些调用并不会全部显示在前端界面上，它们藏在任务编排层里，只有翻日志才能看清全貌。

这里有一个非常容易忽略的坑：人眼看到的是一个任务，底层其实是几十次模型请求。如果你按“任务数×单次输入Token”来估算成本，误差可能在一个数量级以上。正确的方式是按“模型调用次数×每次实际Token消耗”来建模。

1.2 上下文膨胀：你每轮都在为历史记忆付费

Token账单里最阴险的部分不是输出，而是输入。大多数模型API按输入和输出分别计费，而输入里绝大多数Token来自累积的对话历史、工具返回结果和系统提示词。

OpenClaw执行技能时，会把工具返回的原始数据直接塞进上下文。比如一次商品信息同步任务，拉回来的详情列表可能有几万Token，模型处理完、生成一句总结，这笔输入费用就已经扣掉了。如果还开着长期记忆功能，每一轮请求都会把历史记忆片段重新打包送进模型，Token消耗随轮数线性增长，甚至更夸张。

我做个类比：这就像你每次去便利店买瓶水，都要把家里的全部购物清单从头到尾念一遍给店员听。店员多花了时间听废话，你多付了“听废话”的钱。上下文膨胀的本质就是让模型反复阅读它根本不需要的垃圾信息。

1.3 全局一个模型：典型的高射炮打蚊子

我见过很多OpenClaw新手用户，包括最初的我自己，配置里所有任务都指向同一个最强旗舰模型。做意图识别用旗舰模型，做关键词抽取用旗舰模型，做SQL生成用旗舰模型，连给商品打标签都用旗舰模型。

这就好比家里每一盏灯都装100瓦的灯泡，哪怕只是半夜去趟卫生间。旗舰模型处理简单任务的输出质量，未必比小模型好多少，但价格可能是后者的几十倍。账单破千美元的用户，绝大多数不是任务太多，而是“路由策略几乎没有”，所有流量都涌向最贵的那条通道。

所以我在动手优化之前先想明白了一件事：成本失控的第一责任人不是模型厂商，而是我没有为OpenClaw建立任何分级机制。想省钱，不是少用，而是把每一次Token花在刀刃上。

2. 动手优化之前，先给Token消耗建模

2.1 把成本台账建起来，别拍脑袋省成本

任何不谈数据的优化都是耍流氓。我做的第一件事是开启OpenClaw的详细请求日志，把每次调用的模型名、输入Token、输出Token、缓存命中情况、耗时、所属任务全部记录下来，然后统一汇总统计。

如果你用的OpenClaw支持日志输出到文件或标准输出，可以直接接一段简单的统计脚本。我自己的做法是每天导出一份JSON日志，再用jq做聚合：

bash复制# 按模型统计当日Token消耗
cat openclaw_requests_$(date +%F).json \
  | jq -r 'group_by(.model)[] | "\(.[0].model) \(map(.input_tokens + .output_tokens) | add)"' \
  | sort -k2 -nr

输出结果会直接告诉我：哪个模型吃掉了大部分Token，哪个任务类型调用最频繁。这一页数据，比我后面所有优化动作加起来都重要，因为每一个优化决策都得从它出发，否则就是拍脑袋。

2.2 搞懂Token账单里的四个桶

OpenClaw的Token消耗通常可以拆成四个部分，每个部分的优化手段完全不同：

我见过最夸张的情况，是某个定时任务每天都把全量商品数据拉进上下文重新处理，一个月光这一个任务就烧掉几百美元。当时我把流水账拉出来一看，输入Token占比高达92%，输出反而没多少。方向一下子明确了：砍上下文，而不是砍功能。

顺带算一笔账：假设每天跑50个任务，每个任务平均产生15万Token，一个月就是2250万Token。按旗舰模型每百万Token几十美元的定价，破千美元确实是正常结果。知道了这个公式，你就明白省钱的核心只有两条路——要么降低单次Token消耗，要么把请求迁移到更便宜的模型路径上。

2.3 设定预算红线，给OpenClaw装个刹车

优化配置之前，我建议先给系统上一道保险。OpenClaw支持在配置里设置每日Token预算，超过阈值后可以自动切换到备用模型，或者直接拒绝非关键任务。这种机制不是为了限制功能，而是为了防止某个失控任务把整月预算烧光。

我当时给的配置类似这样：

yaml复制budget:
  daily_token_budget: 5000000
  weekly_token_budget: 30000000
  over_budget_action: switch_to_mini_model
  alert_webhook: "https://your-alert-endpoint"

阈值怎么定？拿你上一周的日均消耗做基准，砍掉一半作为第一周的目标。不要一上来就设一个极端值，否则关键任务会被误伤，最后你只能手忙脚乱地调策略。先有账本，再有红线，这是我从这次优化里学到的排序逻辑。

3. 从$1000到$20：六条亲测有效的Token优化实操

3.1 模型分层路由，让9成请求跑在小模型上

成本优化里杠杆最大的一步，是给OpenClaw建立模型路由表。核心思路很简单：不同难度的任务，用不同规格的模型处理。

Model:
routes:
- task_type: intent_detection
model: "qwen2.5:3b"
max_tokens: 300
- task_type: keyword_extract
model: "llama3.2:3b"
max_tokens: 200
- task_type: simple_reply
model: "gpt-4o-mini"
max_tokens: 500
- task_type: complex_reasoning
model: "gpt-4o"
max_tokens: 2000

code复制
我给配置加了备注，方便你知道为什么这样分：

| 任务类型 | 推荐模型 | 原因 |
| --- | --- | --- |
| 意图识别 | 本地3B小模型 | 分类任务，小模型足够，速度还快 |
| 关键词抽取 | 本地3B小模型 | 结构化输出稳定，几乎不出错 |
| 日常回复 | 云端性价比模型 | 需要一定语言质量，但不需要深度推理 |
| 复杂数据分析 | 旗舰模型 | 只有这类任务配得上它的价格 |

为什么这样分？因为OpenClaw日常请求里，真正需要旗舰模型深度推理的任务通常不到10%。意图识别、字段抽取、格式整理这类工作，3B小模型的表现和70B旗舰模型差距很小，价格却差几十倍。我实测下来，单纯这一步就让总成本下降了60%以上。

### 3.2 上下文瘦身：给每次请求做断舍离

路由解决的是“让谁算”的问题，上下文瘦身解决的是“算多少”的问题。我按三层来做裁剪，每一层都能砍掉大量输入Token。

第一层，精简系统提示词。OpenClaw默认模板里有很多解释性文字，比如“你是一个有用的助手，请以友好和专业的方式回复用户”。这些对模型能力几乎没有增益，却每轮都要付费。我的做法是保留角色和输出要求，删掉所有修饰性描述，尽量用动词开头写成一条指令。

第二层，历史消息截断与摘要化。对话超过一定轮数后，不再把原始消息全部塞进上下文，而是先把旧消息交给模型生成一段摘要，后续请求只携带摘要加上最近几轮原文。这个动作通常能让单次请求的输入Token减少50%以上。

第三层，限制工具返回内容。技能执行后产生的工具结果往往是Token大户。比如一条搜索返回200条结果，模型根本不需要全部看完。我在配置里做了截断处理：

```yaml
context:
  max_turns: 8
  tool_result_truncation:
    enabled: true
    max_items: 20
    max_chars_per_item: 500

按我的实测，系统提示词精简一次能省200-500 Token，历史摘要化能省几千到几万Token，工具截断能省一万以上。三项叠加，同样功能单次消耗能减少50%-80%。这不是魔法，只是把“让模型读废话”的陋习改掉罢了。

3.3 输出约束：让模型少说废话，少犯格式错

输出Token同样要钱，而且输出越长，超时和格式错误导致的重复请求概率越高。我给OpenClaw里每一类任务都强制指定了输出格式和长度上限。

具体来说：能输出JSON的就不要输出自然语言，能用固定模板的就不要自由发挥。配置里写上max_tokens是基础操作，更关键的是设置温度参数。

yaml复制generation:
  temperature: 0.2
  max_tokens:
    intent_detection: 50
    simple_reply: 500
    complex_analysis: 2000

温度调低之后，模型输出更容易稳定在预期格式内，重试次数大幅下降。我遇到过一个任务，因为没限制输出长度，模型每次生成一大段无关的客套话，输出Token比业务内容还多。加上max_tokens之后，成本直接砍半。

另外一个容易被忽略的地方：给模型写清“不要输出解释，只输出结果”，很多人觉得这是小事，但在高频调用下，一个“好的，我来帮你处理”的开场白都会累积成不小的账单。

3.4 缓存与复用：同样的活不要干两遍

OpenClaw很多任务每天都在跑类似甚至相同的内容。这些重复计算是最纯粹的浪费，完全可以用缓存消除。

第一层是API侧的Prompt Caching。现在主流模型API都支持相同前缀缓存，系统提示词和固定模板只要不改变，命中缓存后的输入价格会低一个量级。前面提到的精简系统提示词，在这里还有一个额外好处：提示词越短，缓存命中效率越高，缓存读取价格越低。

第二层是应用侧的结果缓存。对于“商品分类映射”“关键词标准化”这类结果长期稳定的子任务，我把模型输出存进本地KV存储，输入相同就直接返回缓存结果，不再发起新请求。OpenClaw的技能编排允许在子任务层面插入缓存检查，我改造之后，这类任务几乎不再消耗Token。

第三层是请求合并。OpenClaw经常会同时对一批相似对象做处理，如果逐个请求，每轮都要重复携带系统提示词和任务说明。合并成批量处理后，公共前缀只支付一次，边际成本大幅下降。我在配置里加了一个攒批策略，把同类型小任务攒够一定数量后统一执行，效率高了，账单也平缓了。

3.5 本地模型兜底：不是所有算力都得租云端

很多人问OpenClaw是不是只能用接入API的方式使用算力，答案是：不是。在OpenClaw的模型配置里直接指向本地Ollama服务，就能把一部分任务迁移到自己的设备上执行。

我现在是这样分配算力的：日常大量高重复、格式固定、不需要大量知识的任务，优先走本地Ollama小模型；需要高质量生成或深度推理的任务，才走云端API。本地模型没有按Token计费的概念，成本基本是电费。

OpenClaw配置本地模型的写法很简单，指到Ollama的API端口即可：

yaml复制model_providers:
  ollama_local:
    base_url: "http://127.0.0.1:11434/v1"
    models:
      - "qwen2.5:3b"
      - "llama3.2:3b"

本地模型适合什么任务，不适合什么任务，我列一个判断表：

别指望本地小模型能平替旗舰模型，它的定位是承接那些“不需要太多智慧，只是需要跑一趟”的任务。这部分任务往往占比最高，也最值得省钱。

3.6 调度节流：从随叫随到改成排队发车

OpenClaw默认每个任务的执行时机是“即时触发”，这会导致请求像潮水一样涌向API，不仅限流风险高，而且可能因并发配额产生额外费用。我的做法是给系统加上调度节流策略。

yaml复制scheduler:
  max_concurrency: 4
  rate_limit_per_minute: 30
  batch_window: 30s

限制的意义在于削峰填谷。很多任务其实是周期性任务或者后台同步任务，完全不差这几分钟。把它们排到低峰时段执行，体验几乎没变化，但单请求的稳定性和整体成本都更可控。我遇到过某天几个重任务同时触发，瞬时并发冲到40+，API侧直接开始按高配额计费，然后大量请求因为限流而重试。加了调度节流之后，这类问题基本绝迹。

4. 部署形态影响成本：云端API和本地算力怎么搭配才划算

4.1 一张表看懂三种算力来源的账

OpenClaw的部署方式会直接影响成本结构。这里把我实测后的三种算力路线放在一起对比：

如果你只在电脑上部署OpenClaw，本地Ollama用一台普通桌面机的CPU也能跑3B模型，速度能接受。如果你在手机上用Termux部署OpenClaw，也可以装Ollama跑更小的模型，但速度会受手机SoC限制，适合处理那些“不着急、量又大”的任务。

4.2 安卓Termux部署OpenClaw的现实情况

围绕OpenClaw的一个热词就是“安卓部署”。我在手机上用Termux跑通OpenClaw之后发现，这条路对成本控制其实很有帮助。手机端的价值不在于承担复杂任务，而在于提供一个永远在线、零额外费用的轻量算力节点。

比如每天定时抓取数据、做关键词分类、生成简单报表摘要，这类任务完全可以在手机本地跑。手机电量消耗可以忽略不计，关键是省掉了这部分请求的云端Token费用。实际使用时需要注意，Termux环境里的Ollama只能跑比较小的模型，比如2B到4B的量化版本，复杂推理质量确实不够，但用来做意图识别和JSON抽取是没问题的。

4.3 混合路由：让成本和质量动态平衡

在3.1的基础上，我更推荐给OpenClaw配置一条“默认走本地，复杂任务自动升级云端”的混合路由规则。这样既不用手动干预，又能保证成本和质量都在可接受范围。

yaml复制hybrid_routing:
  primary: ollama_local
  fallback: gpt-4o-mini
  upgrade_rules:
    - task_type: complex_reasoning
      use: gpt-4o
    - condition: local_model_confidence < 0.7
      use: gpt-4o-mini

前面提到5.1里说的“固定请求路由到本地系统服务”也是混合路由的一部分，具体的请求分类在配置里都可以定义。混合路由的最大价值在于：当本地小模型回答质量不够稳定时，自动把请求交给云端模型补位，既不会因为省钱牺牲体验，也不会因为追求质量无脑烧钱。

5. 常见问题与排查实录：账单异常急救指南

5.1 症状式排查手册，直接对照来找病根

我在优化过程中遇到的各种异常，整理成一个速查表，你可以直接对照自己的问题：

5.2 我踩过的几个坑，希望你别再踩

第一个坑是给一个定时任务设置了不合理的模型路由，所有商品数据被全量拉进上下文重新改写，一个月烧掉几百刀。这个教训让我明白：任何“全量同步”类任务都必须做字段过滤和分批处理。

第二个坑是默认开启了长期记忆。听起来很美，实际每轮请求都把历史记忆塞进提示词，输入Token直接翻了5倍。后来我改成“只记忆结论，不记忆过程”，成本立刻降下来。

第三个坑是重试策略。默认的重试参数是固定次数重试，一旦API出现短暂故障，几十个任务同时重试，瞬间产生大量无效请求。后来我改成指数退避，并把重试上限从5次降到了2次。

第四个坑比较反直觉：把任务全部迁到本地小模型后，输出质量变得不稳定。问题的根源不是模型不支持，而是我没给本地模型写充分的few-shot示例。补了几个示例后，格式稳定性和云端大模型基本一致。

5.3 防复发机制：把成本控制变成持续动作

成本控制不是一次性项目，而是伴随OpenClaw运行的持续机制。我最后建立了一套轻量级的防复发流程：

每周看一次Token趋势表，重点观察三类指标：单任务平均Token、缓存命中率、重试次数。任何一项连续三天偏离基准，就去翻日志找原因。另外，给预算红线设置了告警推送到手机，任何人触达红线都会第一时间收到通知。这学期观察下来，账单再也没出现过异常波动。

这里有一个关键认知：OpenClaw本身是高灵活性平台，既可以无脑烧钱，也可以精细省钱，差异全部藏在配置细节里。不要把成本控制交给“自觉”，要用日志、路由、缓存、预算红线去约束它。

我个人在实际操作中最深的体会是：省钱的杠杆其实不靠砍功能，而是靠把每一类任务的消耗看清楚，然后为它们分配合适的模型和路径。最后再分享一个小技巧：给重要任务加一条日志钩子，把每次请求的Token数写进本地SQLite，每周翻一遍。这相当于给系统做体检，很多异常在变成账单之前就能提前发现。