03. Provider 与成本：从烧钱到精打细算

> 第一周花的钱比我预期多了 10 倍。然后我学会了怎么省。

## 初始配置：单 Provider 的蜜月期

刚装好 OpenClaw 时，我只配了一个 provider——provider-a，走的是 relay-a.example.com 中转。模型选了 Claude Opus，因为它最聪明。

蜜月期大概持续了两天。

## 第一次故障：502

2/18，relay-a.example.com 开始间歇性返回 502。上游故障，我这边什么都做不了，只能等它恢复。

这暴露了单 provider 的致命问题：**单点故障**。你的 AI 管家的可用性，取决于一个你无法控制的中转服务。

## 搭建 Fallback Chain

解决方案是多 provider + fallback chain。OpenClaw 原生支持这个——请求失败时自动切到下一个 provider。

我最终的 fallback chain：

```
provider-a (relay-a.example.com)
  → provider-b (relay-b.example.com)
    → provider-c
      → provider-d
```

### provider-b 接入

provider-b 是另一个 API 中转，走 `relay-b.example.com`。接入后发现一个有趣的特性：它支持通过 `metadata.user_id` 触发服务端缓存。

```json
{
  "provider-b": {
    "baseUrl": "https://relay-b.example.com/claude/droid",
    "models": {
      "claude-opus-4-6": {
        "params": {
          "metadata": { "user_id": "your-user-id" }
        }
      }
    }
  }
}
```

加了这个之后，重复的 system prompt 部分会被缓存，省了不少 token 费用。

## 第二次故障：Opus 额度耗尽

2/21，更严重的事情发生了。所有 provider 的 Opus 额度都耗尽了，返回 401。Gateway 在跑，但无法响应任何消息。

这不是某个 provider 的问题——是 Opus 太贵，额度消耗太快。

### 从 Opus 降到 Sonnet

这次故障逼我做了一个早该做的决定：**把默认模型从 Opus 降到 Sonnet**。

Sonnet 4.6 的能力已经很强了。对于日常对话、文件操作、脚本执行这些任务，Sonnet 和 Opus 的差距几乎感觉不到。Opus 的优势在长链推理和复杂分析——但这些任务占比不到 10%。

用 90% 的钱买 10% 的提升，不划算。

改完之后，只有 main 和 analyst 保留 Opus（需要复杂推理时），其他 agent 全部用 Sonnet。

## contextPruning：最有效的省钱手段

降模型省的是单价，但真正的大头是**对话历史**。

我做了一次 API payload 分析，结果触目惊心：

- 每次 API 调用 ~100k token
- 其中 85% 是对话历史（~85k）
- 15% 是 system prompt（~15k）
- 工具返回结果是历史膨胀的主因（config.patch 返回完整 JSON、web_fetch 返回整页等）

也就是说，你和 AI 聊得越久，每条消息的成本越高——因为每次调用都要把完整历史发过去。

OpenClaw 的 contextPruning 解决了这个问题（配置路径为 `agent.contextPruning`）：

```json5
{
  "agent": {
    "contextPruning": {
      "mode": "cache-ttl",
      "ttl": "30m",
      "keepLastAssistants": 3
    }
  }
}
```

`cache-ttl` 模式的逻辑：超过 30 分钟没被引用的旧工具结果会被裁剪，但始终保留最近 3 条 assistant 回复。这样既控制了上下文长度，又不会丢失最近的对话连贯性。

> 注意：contextPruning 只裁剪工具结果（toolResult），不修改用户和 assistant 消息。详见第三篇。

### contextTokens

另一个关键配置是 `contextTokens`——限制发送给模型的最大 token 数：

```json
{
  "agents": {
    "defaults": {
      "contextTokens": 120000
    }
  }
}
```

之前部分 provider 配了过大的上下文窗口，导致 compaction 触发过晚，对话历史无限膨胀。统一降到 120k 后，token 消耗明显下降。

## 模型精简

provider-d 渠道最初注册了 12 个模型，实际常用的只有几个。精简到 7 个（GPT 3 个 + Gemini 4 个），减少了配置复杂度和潜在的路由错误。

## 每日 Token 报告

为了持续监控成本，我创建了一个每天 8:00 跑的 cron job，生成 token 使用报告：

```bash
# ~/scripts/token-daily-report.sh
# 统计前一天的 API 调用次数、token 消耗、模型分布
```

有了数据才能优化。第一份报告就发现：Opus 占了 97% 的 input token，虽然调用次数不多，但每次调用的历史都很长。

## 成本优化总结

按效果排序：

1. **contextPruning**（效果最大）：控制对话历史长度，直接减少每次调用的 token 数
2. **模型降级**（效果显著）：Opus → Sonnet，单价降 80%，体验损失 <10%
3. **contextTokens 限制**（效果中等）：防止上下文无限膨胀
4. **多 provider fallback**（保可用性）：不直接省钱，但避免故障时的损失
5. **provider-b 缓存**（锦上添花）：metadata.user_id 触发缓存，减少重复 token
6. **模型精简**（减少复杂度）：少配几个模型，少几个出错的可能

最终效果：从最初的"用着用着额度就没了"，到现在稳定运行一周，成本可控。

## 一个反直觉的结论

省钱最有效的手段不是换便宜模型，而是**控制上下文长度**。一个用 Opus 但开了 contextPruning 的系统，可能比一个用 Sonnet 但上下文爆炸的系统更便宜。

当然，两个都做效果最好。

> 第一周花的钱比我预期多了 10 倍。然后我学会了怎么省。

## 初始配置：单 Provider 的蜜月期

刚装好 OpenClaw 时，我只配了一个 provider——provider-a，走的是 relay-a.example.com 中转。模型选了 Claude Opus，因为它最聪明。

蜜月期大概持续了两天。

## 第一次故障：502

2/18，relay-a.example.com 开始间歇性返回 502。上游故障，我这边什么都做不了，只能等它恢复。

这暴露了单 provider 的致命问题：**单点故障**。你的 AI 管家的可用性，取决于一个你无法控制的中转服务。

## 搭建 Fallback Chain

解决方案是多 provider + fallback chain。OpenClaw 原生支持这个——请求失败时自动切到下一个 provider。

我最终的 fallback chain：

```
provider-a (relay-a.example.com)
  → provider-b (relay-b.example.com)
    → provider-c
      → provider-d
```

### provider-b 接入

provider-b 是另一个 API 中转，走 `relay-b.example.com`。接入后发现一个有趣的特性：它支持通过 `metadata.user_id` 触发服务端缓存。

加了这个之后，重复的 system prompt 部分会被缓存，省了不少 token 费用。

## 第二次故障：Opus 额度耗尽

2/21，更严重的事情发生了。所有 provider 的 Opus 额度都耗尽了，返回 401。Gateway 在跑，但无法响应任何消息。

这不是某个 provider 的问题——是 Opus 太贵，额度消耗太快。

### 从 Opus 降到 Sonnet

这次故障逼我做了一个早该做的决定：**把默认模型从 Opus 降到 Sonnet**。

用 90% 的钱买 10% 的提升，不划算。

改完之后，只有 main 和 analyst 保留 Opus（需要复杂推理时），其他 agent 全部用 Sonnet。

## contextPruning：最有效的省钱手段

降模型省的是单价，但真正的大头是**对话历史**。

我做了一次 API payload 分析，结果触目惊心：

也就是说，你和 AI 聊得越久，每条消息的成本越高——因为每次调用都要把完整历史发过去。

OpenClaw 的 contextPruning 解决了这个问题（配置路径为 `agent.contextPruning`）：

```json5
{
  "agent": {
    "contextPruning": {
      "mode": "cache-ttl",
      "ttl": "30m",
      "keepLastAssistants": 3
    }
  }
}
```

> 注意：contextPruning 只裁剪工具结果（toolResult），不修改用户和 assistant 消息。详见第三篇。

### contextTokens

另一个关键配置是 `contextTokens`——限制发送给模型的最大 token 数：

```json
{
  "agents": {
    "defaults": {
      "contextTokens": 120000
    }
  }
}
```

之前部分 provider 配了过大的上下文窗口，导致 compaction 触发过晚，对话历史无限膨胀。统一降到 120k 后，token 消耗明显下降。

## 模型精简

provider-d 渠道最初注册了 12 个模型，实际常用的只有几个。精简到 7 个（GPT 3 个 + Gemini 4 个），减少了配置复杂度和潜在的路由错误。

## 每日 Token 报告

为了持续监控成本，我创建了一个每天 8:00 跑的 cron job，生成 token 使用报告：

```bash
# ~/scripts/token-daily-report.sh
# 统计前一天的 API 调用次数、token 消耗、模型分布
```

有了数据才能优化。第一份报告就发现：Opus 占了 97% 的 input token，虽然调用次数不多，但每次调用的历史都很长。

## 成本优化总结

按效果排序：

最终效果：从最初的"用着用着额度就没了"，到现在稳定运行一周，成本可控。

## 一个反直觉的结论

省钱最有效的手段不是换便宜模型，而是**控制上下文长度**。一个用 Opus 但开了 contextPruning 的系统，可能比一个用 Sonnet 但上下文爆炸的系统更便宜。

当然，两个都做效果最好。

最后修改：2026 年 02 月 24 日

如果觉得我的文章对你有用，请随意赞赏

03. Provider 与成本：从烧钱到精打细算

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

基于思源笔记的写作、管理和分发流程

2024年计划与达成情况概览【更新至四月底】

【减脂漫谈】减脂45kg的思考和行动计划

基于Kindle、纸间书摘、思源笔记的全平台同步阅读及闪卡流程

08.老婆生日、半马完结

成都博物馆小游

2024年计划与达成情况概览【更新至四月底】

离奇的梦-校园里的凶杀案

人间在世--写于我的三十岁生日

《海上钢琴师》每个人的心中都有一个1900

03. Provider 与成本：从烧钱到精打细算

发表评论 取消回复 使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

03. Provider 与成本：从烧钱到精打细算

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款