上个月收到 Anthropic 账单的那一刻，我整个人dou僵住了。手指悬在触控板上，我反复确认那个数字，甚至怀疑是不是系统把小数点印错了。我的 OpenClaw 助手明明只是帮我处理了一些日常琐事——回复几封无关痛痒的邮件、整理几条零散的笔记、偶尔写点简单的代码片段……怎么就烧掉了这么多钱？

说实话，当时那种感觉不仅是肉疼，geng多的是一种深深的无力感。比我预期的整整高出三倍。这哪里是AI助手，简直就是个吞金兽。

那天晚上我没睡好。躺在床上翻来覆去地想：问题到底出在哪？后来爬起来翻日志，才终于发现了端倪——在默认配置下所有请求，无一例外dou走的是Zui昂贵的 Claude Opus。不管是心跳检查、简单查询，还是文件操作，统统一视同仁。geng可怕的是当子代理并行工作的时候，每个dou在疯狂地“烧钱”。那种感觉，就像是你明明只需要打个火机点根烟，却非要发射一枚火箭来干这事儿。

触目惊心的“隐形杀手”：Token 税

先来kan一组让人后背发凉的数字。这不仅仅是理论推演，而是实打实的社区真实数据。

hen多开发者容易陷入一个误区：以为我只用了多少次API，费用就应该是次数乘以单价。但这算法太天真了简直Ke以说是“拿小学数学解微积分”。

OpenClaw 的系统提示词本身就占据了 2k-4k 的 tokens。这还没完，加上工具调用的开销、重试机制带来的额外消耗……实际消耗往往是裸计算的好几倍。这就是纯纯的“token 税”。

举个Zui典型的例子：心跳请求。

为了保持连接活跃，系统可Neng每 30 秒就要发一次心跳检查。一天下来就是 2880 次。哪怕每次心跳没有任何实质性的对话内容，它也必须带上完整的、庞大的系统提示词。Ru果这每一次心跳dou跑在 Claude Opus 上，你想想那是种什么场景？

Zuo个简单的算术题。假设每天发送 100 条消息，平均每条 1000 tokens：

Ru果全用 Opus，价格假设为 $15/MTok，100 * 1000 * 30 天 = 3M tokens。

3M * $15 = $45/月。

这还只是基础对话量。Ru果加上心跳、重试、子代理的并行调用，这个数字轻松翻倍。kan到那个心跳检查的费用了吗？$10+。这就是Zui大的罪魁祸首。

破局之道：构建三层智Neng路由体系

后来我花了一个周末，死磕 OpenClaw 的模型路由功Neng，终于摸索出了一套“省钱经”。核心逻辑其实非常朴素：让合适的人干合适的活。

通过智Neng分层，我们Ke以让“便宜货”去处理那些简单、重复的工作，只把真正需要深度思考、复杂逻辑的任务交给“expensive guys”。实施这套策略仅仅一个月后我的账单直接从三位数降到了 $20 不到。

听起来还行？那我们就来拆解一下这套架构。

Layer 1：本地模型—— 免费劳动力

这一层是省钱的关键。对于心跳检测、文件状态检查、简单的问答，完全不需要动用云端的大模型。我们在本地跑一个轻量级的模型就够了。

推荐的高性价比组合：

ollama pull qwen2:14b-instruct    # 支持工具调用，中文友好
ollama pull mistral-nemo:latest     # 性Neng均衡
ollama pull glm4-flash           # 轻量级，速度快

这一层的成本几乎为 $0。把那些毫无技术含量的“查一下日历”、“文件还在吗”这类请求拦截在本地，你的钱包会感谢你的。

Layer 2：轻量云端—— 日常主力

这一层负责处理日常对话、邮件起草、简单的代码生成。它们的速度快，成本极低，通常在 $0.15-$0.5/MTok 这个级别。对于 80% 的日常任务，这层模型的表现Yi经足够惊艳了。

Layer 3：重型武器—— 专家顾问

只有当遇到复杂的架构设计、深度数据分析、或者需要极高创意的写作任务时才请出这一层。虽然它们的成本高达 $15-$30/MTok，但因为用量极少，总成本完全可控。

┌─────────────────────────────────────────────┐
│  Layer 1: 本地模型      │
│  → 心跳、文件操作、简单问答、状态检查        │
│  → 成本：$0                                  │
├─────────────────────────────────────────────┤
│  Layer 2: 轻量云端│
│  → 日常对话、邮件起草、简单代码              │
│  → 成本：$0.5/MTok                           │
├─────────────────────────────────────────────┤
│  Layer 3: 重型武器   │
│  → 复杂架构设计、深度分析、创意写作          │
│  → 成本：$15/MTok              │
└─────────────────────────────────────────────┘

实战指南：如何配置你的路由

说了这么多，核心就几点：怎么落地？我们分步走。

Step 1：安装并启动 Ollama

你得在本地搭好这个“免费劳动力”的窝。

# macOS/Linux
curl -fsSL https://ollama.com/install.sh | sh
# Windows 下载安装包后
ollama serve
# 拉取适合的模型
ollama pull llama3:latest      # 轻量级，适合简单任务
ollama pull qwen2:14b          # geng强一些，支持工具调用

Step 2：配置 OpenClaw 使用本地模型

编辑你的配置文件 ~/.openclaw/openclaw.json，把本地模型加进去。这里有几个坑得注意，比如 baseUrl 必须指向 Ollama 的服务端口，apiKey 随便填个字符串就行，Ollama 不校验这个。

{
  "models": {
    "defaults": {
      "model": "ollama/qwen2:14b",
      "fallbacks": 
    },
    "providers": {
      "ollama": {
        "type": "openai-compatible",
        "baseUrl": "http://127.0.0.1:11434/v1",
        "apiKey": "ollama"
      }
    }
  }
}

这个配置的意思是：默认先用本地的 Qwen2。Ru果本地模型搞不定，就自动降级到云端的 Sonnet，Zui后才是 Opus。

Step 3：使用 OpenRouter Auto Model

Ru果你不想自己写复杂的路由规则，OpenRouter 提供了一个 Auto 模式。它会自动根据 prompt 的复杂度选择Zui便宜的合适模型。省事，虽然可Neng不如自定义路由那么极致，但也比全用 Opus 强多了。

{
  "models": {
    "defaults": {
      "model": "openrouter/openrouter/auto",
      "fallbacks": 
    }
  }
}

Step 4：自定义路由规则

对于geng精细的控制，Ke以用开源的 iblai-openclaw-router。你Ke以定义关键词匹配，把包含“heartbeat”、“status”的请求直接甩给本地模型。

{
  "routing": {
    "enabled": true,
    "tiers": {
      "free": {
        "models": ,
        "keywords": 
      },
      "cheap": {
        "models": ,
        "maxCostPerRequest": 0.01
      },
      "standard": {
        "models": 
      },
      "premium": {
        "models": ,
        "keywords": 
      }
    }
  }
}

避坑指南：那些让你不知不觉破产的陷阱

配置好了路由不代表万事大吉，还有几个隐蔽的陷阱在等着你。

陷阱 1：工具调用失败

原因：不是所有本地模型dou支持 function calling。Ru果你让 Llama 3 去调用一个它不理解的工具，它会疯狂重试，或者返回一堆废话。这时候，Fallback 机制就非常重要了。

{ 
  "models": { 
    "ollama/llama3": { 
      "supportsTools": false 
    } 
  }
}

一定要在配置里标清楚哪些模型支持工具，哪些不支持。否则，系统会傻傻地一直尝试用不支持工具的模型去执行操作，既浪费时间又浪费钱。

陷阱 2：Fallback 链配置错误

常见错误是把所有 Fallback dou设在同一个供应商下。比如 Anthropic 被限流了你的 Sonnet 和 Opus 可Neng同时不可用。这时候你就彻底瘫痪了。

正确的Zuo法是跨供应商 Fallback：

// 错误：Anthropic 被限流时Sonnet 和 Opus 可Neng同时不可用
"fallbacks": 
// 正确：跨供应商 fallback
"fallbacks": 

陷阱 3：重试机制

网络波动时的自动重试是个双刃剑。Ru果请求Yi经发送到了服务端，token Yi经扣了结果因为网络抖动没收到返回，系统触发重试……恭喜你，这次请求你付了两份钱，事还没办成。

Error: Connection refused
或者模型返回空内容

排查步骤：一定要监控你的日志，kankan是否有大量的 5xx 错误或者超时。Ru果有，考虑优化网络环境或者调整重试策略，比如增加指数退避。

陷阱 4：子代理

并行任务时Ru果每个子代理dou默认使用主模型，那简直是灾难。比如一个任务拆分成了 5 个子任务，每个dou跑 Opus，那就是 5 倍的费用。一定要确保子代理继承路由策略，或者强制子代理使用轻量级模型。

“查一下日历”这种简单操作也走 Opus，想想就肉疼。

真实案例：一个月的成本对比

让我们来kankan某位开发者在优化前后的真实账单对比。

优化前的账单构成

那时候我还没搞路由，全靠 Opus 一招鲜：

日常对话与邮件： 200k tokens * $15 = $3

代码辅助： 500k tokens * $15 = $7.5

心跳与状态检查： 1M tokens * $15 = $15

子代理并行消耗： 500k tokens * $15 = $7.5

总计： $33

优化后的账单构成

实施三层路由后：

心跳与状态： 1M tokens * $0 = $0

日常对话： 200k tokens * $0.15 = $0.03

代码辅助： 500k tokens * $3 = $1.5

复杂任务： 50k tokens * $15 = $0.75

总计： $2.28

当然这是个比较极端的例子——那位老哥的心跳占比实在太高了。实际节省通常在 60%-80%，取决于具体使用场景。但即便按保守估计，省下一半以上的预算是轻轻松松的。

质量下降怎么办？

hen多人担心用了便宜模型，回答质量会下降。这确实是个问题，但不是无解的。

Ru果发现本地模型处理不了某些任务，比如逻辑推理混乱，或者工具调用失败，这时候 Fallback 机制就派上用场了。系统会自动把请求升级到 Sonnet 甚至 Opus。对于用户来说可Neng只是多等了一秒钟，但拿到的是正确答案。而大部分情况下对于“今天天气怎么样”这种问题，本地模型和 Opus 的回答几乎没有区别。

不是每个请求dou值得用Zui贵的模型。我们hen容易陷入“参数崇拜”或者“模型崇拜”，觉得非 Opus 不用。但作为工程师，我们的价值在于用Zui合理的资源解决问题。

通过模型路由，我们不仅是在省钱，geng是在构建一种geng高效、geng理性的计算架构。让本地模型守好大门，让轻量云端干好杂活，让重型武器专注于攻坚。这才是 OpenClaw 正确的打开方式。

希望这篇文章Neng帮你省下一笔巨款。毕竟省下来的钱，买块 4090 不香吗？

本文首发自个人博客，转载请注明出处。

---