AI Agent 的 Token 计费与缓存机制

从原理到 99% 命中率实战

作为 AI Agent 的重度用户，你是否遇到过这样的困惑：明明只是简单对话，为什么 Token 消耗却高得惊人？为什么有些 Agent 能做到 99% 缓存命中率，大幅降低使用成本？本文将从底层原理出发，深入剖析 Token 计费机制，并揭秘 DeepSeek Reasonix 实现 99% 缓存命中率的架构设计。

一、Token 计费基础：你的钱都花在哪了？

1.1 输入 vs 输出 Token

一次 API 调用中，Token 消耗分为两大块：

输入 Token（Input） 包括：

• 系统提示（System Prompt）
• 历史对话记录
• 当前用户输入
• 工具定义（Tools Schema）
• 工具执行结果（Observation）

输出 Token（Output） 包括：

• 模型生成的回复文字
• 工具调用指令（tool_calls）

1.2 为什么输入比输出还多？

以一个典型的部署博客任务为例（第5轮对话）：

输入组成:
├─ System Prompt: 500 tokens
├─ 历史对话 (4轮): 3000 tokens
├─ 工具定义: 800 tokens
├─ 上一轮工具返回结果 (npm install 输出): 2000 tokens
└─ 当前用户指令: 50 tokens
总计输入: ~6350 tokens

模型输出:
└─ "npm install 完成，现在创建配置文件..." + tool_calls: 150 tokens

核心发现：多轮对话场景下，历史记录和工具结果会累积成巨大的输入开销。

二、缓存机制：省钱的秘密武器

2.1 什么是 Prompt Caching？

痛点：每轮对话都要把完整历史发一遍，系统提示和工具定义每次都不变，重复算钱不合理！

解决方案：模型服务器会缓存请求的前缀部分。当后续请求的前缀匹配缓存时，这部分 Token 按折扣价计费（通常只需原价的 10%）。

第一轮:
├─ 系统提示 │
├─ 工具定义 │ → 写入缓存
├─ 历史1    │
└─ 用户输入1 │

第二轮:
├─ 系统提示 ────────→ 缓存命中！（90% 折扣）
├─ 工具定义 ────────→ 缓存命中！
├─ 历史1
├─ 助手回复1
└─ 用户输入2 → 新增部分正常计费

2.2 主流模型计费结构对比

OpenAI（不显示缓存统计）：

{
  "usage": {
    "prompt_tokens": 1000,
    "completion_tokens": 150
  }
}

缓存收益仅体现在速度上，官方不单独披露。

Anthropic Claude（原生支持缓存）：

{
  "usage": {
    "input_tokens": 10000,
    "output_tokens": 500,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 8000
  }
}

cache_read_input_tokens 表示从缓存读取的部分，享受低价。

DeepSeek（Prefix Cache）：

三、普通 Agent 缓存命中的陷阱

3.1 为什么缓存命中率往往很低？

3.2 缓存破坏的根源

字节级匹配要求：DeepSeek 等平台从前缀字节 0 开始计算指纹。一旦某个字节不同，之后的内容全部不命中！

第一轮系统提示: "你是一个编程助手。时间是: 10:00"
第二轮系统提示: "你是一个编程助手。时间是: 10:01"
                              ↑ 这里不同！
                              ↓
         整个前缀都不匹配，缓存完全失效

四、Reasonix 的三区隔离架构

DeepSeek Reasonix 是一款专为 DeepSeek 优化的编码 Agent，它实现了 99.82% 的缓存命中率，单日处理 435M Token 仅花费约 $12（无缓存则需 $61）。其核心设计理念是：

"Cache stability isn't a feature you turn on; it's an invariant the loop is designed around"
（缓存稳定性不是开关，而是整个架构设计的核心原则）

4.1 核心架构：三区隔离

┌─────────────────────────────────────────┐
│         IMMUTABLE PREFIX                │  ← 固定前缀区
│  ├─ system prompt (系统提示)            │
│  ├─ tool_specs (工具定义)               │
│  └─ few_shots (示例)                    │
│                                          │
│  🔥 整个会话期间只计算一次，完全不变      │
│  🔥 缓存命中的主要贡献区域                │
├─────────────────────────────────────────┤
│         APPEND-ONLY LOG                 │  ← 只追加日志区
│  ├─ [assistant_message_1]               │
│  ├─ [tool_result_1]                     │
│  ├─ [assistant_message_2]               │
│  ├─ [tool_result_2]                     │
│  │  ... 持续增长                         │
│  │                                       │
│  🔥 从不修改历史，只追加新内容            │
│  🔥 保持前缀与上一轮完全一致              │
├─────────────────────────────────────────┤
│         VOLATILE SCRATCH                │  ← 临时草稿区
│  ├─ R1 reasoning_content                │
│  ├─ transient plan state                │
│  │                                       │
│  🔥 每轮重置，从不发送到上游 API          │
│  🔥 防止思考过程污染缓存前缀              │
└─────────────────────────────────────────┘

4.2 四个关键不变式

五、实战：成本计算与优化技巧

5.1 一次部署网站的成本估算

5.2 主流模型价格对比

5.3 缓存友好的 vs 破坏缓存的操作

六、核心启示：缓存优化的三个层次

Level 1: 使用技巧（配置层面）
  - 开启成本显示、减少 reset
  - 效果有限，依赖用户自觉

Level 2: 架构适配（设计层面）
  - Anthropic 的 cache_control
  - 需要模型 API 原生支持

Level 3: 不变式设计（哲学层面）⭐
  - 如 Reasonix 的"三区隔离"
  - 从架构层面保证缓存稳定性
  - 牺牲通用性换取极致优化

核心洞察：
"Cache stability is an invariant, not a feature"

七、实用建议

如果你是 DeepSeek 重度用户

Reasonix 适合的场景：

• ✅ 长期运行的编码会话
• ✅ 对成本敏感的生产环境
• ✅ 需要 90%+ 的缓存命中率

如果你需要多模型支持

通用 Agent（如 Hermes）的缓存优化技巧：

1. 减少不必要的 /reset — 每次清空历史都会重置缓存
2. 避免在 System Prompt 放动态内容 — 时间戳、随机数会立即破坏缓存
3. 批量请求，减少轮次 — 一次性把需求说清楚
4. 开启成本显示 — display.show_cost: true 实时监控缓存率

八、总结

Token 计费与缓存机制是 AI Agent 使用成本的核心决定因素。理解缓存的工作原理，并通过三区隔离架构实现 99% 的命中率，可以在保证体验的同时将成本降低 5 倍以上。

对于普通用户，最基本的原则是：保持系统提示稳定、减少对话轮次、选择支持缓存的模型。对于开发者，从架构层面将缓存稳定性作为不变式设计，才是达到极致优化的关键。

本文基于 DeepSeek Reasonix v0.45.1 及主流模型 API 分析 | 分析时间：2026年5月