Token、上下文与 Agent 调用成本计算¶

最后核验：2026-07-19

适合：使用按量 API、长对话、Claude Code、Codex CLI、RAG 或自动化工作流的用户

[!NOTE] 本文适用于任何符合对应协议的 API。还没有测试 Key 时，可查看教程配套 API。

需要先按实际记录核对 Codex 输入、输出和缓存命中时，可查看 NexoToken Codex Token 与缓存成本专题；本文继续保留通用计算方法。

API 账单最容易被低估的地方，不是模型单价，而是一次操作背后到底发出了多少 Token、多少轮模型调用。聊天框里只输入一句话，实际请求可能携带系统提示、历史消息、代码、工具定义和检索结果；Agent 还可能在后台连续调用多次。

本文不写死容易过期的模型价格，而是提供一套可以代入任何服务当前价格的计算方法。

1. Token 是什么¶

Token 是模型处理文本时使用的基本计量单位，不等同于字数、汉字数或字符数。分词结果会受语言、标点、空格、代码和模型所用 Tokenizer 影响。

一次请求中可能出现：

输入 Token： 系统提示、对话历史、本轮问题、文件内容、工具定义和工具结果；
输出 Token： 模型生成的正文、结构化内容或工具参数；
推理 Token： 部分推理模型内部使用并计入上下文或用量的 Token；
缓存创建 Token： 首次写入可复用前缀的内容；
缓存读取 Token： 后续命中相同前缀后读取的内容。

不能用“一个汉字固定等于一个 Token”做正式预算。最可靠的数据来自真实 API 响应的 usage 字段和服务控制台。

2. 基础计费公式¶

假设价格单位为“每 100 万 Token”：

输入费用 = 输入 Token ÷ 1,000,000 × 输入单价
输出费用 = 输出 Token ÷ 1,000,000 × 输出单价
总费用 = 输入费用 + 输出费用 + 缓存费用 + 其他工具费用

如果服务用人民币、美元或积分结算，必须统一单位后再相加。不要把美元单价与人民币余额直接计算，也不要把每 1K 和每 1M Token 混在一起。

假设示例¶

以下数字只演示算法，不代表任何实际模型价格：

输入：18,000 Token
输出：3,000 Token
假设输入价：¥2 / 1M Token
假设输出价：¥8 / 1M Token

输入费用 = 18,000 ÷ 1,000,000 × 2 = ¥0.036
输出费用 = 3,000 ÷ 1,000,000 × 8 = ¥0.024
总费用 = ¥0.060

真实计算时，以服务当天价格页为准，并记录日期。

3. 为什么长对话会越来越贵¶

无状态聊天接口通常需要在每一轮重新发送必要的历史。假设每轮新增 1,000 Token，忽略输出和系统提示：

轮次	本轮携带历史	本轮输入
1	0	1,000
2	1,000	2,000
3	2,000	3,000
4	3,000	4,000
5	4,000	5,000

五轮共发送 15,000 输入 Token，而不是 5,000。对话继续增长时，累计输入近似呈三角形增长。

实际产品可能使用服务端会话、缓存、摘要或压缩减少重复计算，但不要默认“历史只收费一次”。OpenAI 官方文档明确说明，即使通过 previous_response_id 串联 Responses，链路中的先前输入 Token 仍会作为输入计费。

4. 上下文窗口不是免费存储空间¶

上下文窗口是单次模型调用能处理的总工作区，通常包含输入、输出，以及部分模型的推理内容。窗口很大只代表上限更高，不代表应该把所有资料都塞进去。

过长上下文会带来：

更高输入费用；
更慢的首 Token 时间；
更容易触碰窗口上限；
重要信息被大量无关内容淹没；
截断、摘要或压缩后出现信息损失；
缓存前缀变化导致命中率降低。

更好的上下文策略¶

只附与当前任务相关的文件和片段；
长文档先检索，再发送命中的段落；
对话阶段结束后创建结构化摘要；
稳定规则放前面，动态问题放后面；
工具定义只暴露本轮可能使用的工具；
定期检查客户端是否重复注入相同内容。

5. Agent 为什么比聊天更容易放大费用¶

一次聊天通常是一轮请求；一次 Agent 任务可能是一个循环：

读取任务
  → 模型制定计划
  → 调用搜索或读文件工具
  → 把工具结果发回模型
  → 模型决定继续调用工具
  → 执行修改或命令
  → 再次检查结果
  → 生成最终回答

假设一次任务平均发生 6 次模型调用，每次平均输入 20,000、输出 2,000 Token：

任务输入 = 6 × 20,000 = 120,000 Token
任务输出 = 6 × 2,000 = 12,000 Token

用户只看到了一个最终回答，但账单包含了整个推理和工具循环。

Agent 成本估算式¶

每日成本 ≈ 每日任务数
         × 每任务平均模型轮次
         ×（每轮平均输入费用 + 每轮平均输出费用）
         + 工具或其他服务费用

需要分别统计简单任务与复杂任务，不能用一次短问答推断整月 Agent 费用。

6. 工具调用的隐藏增量¶

Function Calling 本身不是模型替你执行函数。标准流程通常是：

把工具 Schema 与问题发给模型；
模型返回工具名称和参数；
应用执行工具；
把工具结果再次发送给模型；
模型生成最终答案，或继续调用工具。

成本可能来自：

每轮重复发送的工具定义；
模型生成的工具参数；
文件、搜索或数据库返回的大段结果；
多工具循环；
失败后的重试；
外部搜索、向量库或沙箱本身的费用。

工具结果应裁剪为模型需要的字段。不要把完整数据库行、全部日志或整个网页无条件发回。

7. RAG 成本应该分开算¶

一次知识库问答可能包含：

文档导入：切分 + Embedding
用户提问：问题 Embedding
检索：向量数据库查询
可选：Rerank
生成：问题 + 检索片段 + 对话历史 → 聊天模型

建库成本¶

建库成本 ≈ 文档总 Token ÷ 1,000,000 × Embedding 单价

还要考虑解析、OCR、向量数据库和重建索引。更换 Embedding 模型或向量维度后，通常需要重新生成向量。

每次问答成本¶

单次 RAG 成本 = 问题 Embedding
              + Rerank（如有）
              + 检索片段输入
              + 模型输出

top_k 越大不一定越好。过多低相关片段会增加成本，也可能降低回答质量。

8. Prompt Caching 能省什么¶

缓存通常适合长且重复的前缀，例如：

稳定的系统提示；
大段固定参考资料；
不常变化的工具定义；
多次请求共享的示例；
长对话中重复携带的前缀。

但缓存不是“开启后所有输入自动打一折”：

不同服务的最低长度、有效时间和价格不同；
前缀内容或顺序改变可能无法命中；
动态内容放在前面会破坏共享前缀；
缓存创建与缓存读取可能采用不同价格；
缓存通常不改变上下文窗口占用；
是否命中应以 usage 中的缓存字段为准。

优化前先记录 cached_tokens、cache_read_input_tokens 或服务定义的对应字段，不能仅凭响应变快判断命中。

9. 预算表怎么做¶

建议至少记录一周真实样本：

日期	场景	任务数	模型调用数
7/19	普通聊天	10	10
7/19	编程 Agent	3
7/19	RAG	20

然后计算：

平均单任务成本 = 总费用 ÷ 任务数
预计月成本 = 平均日成本 × 实际工作日
峰值月成本 = 高峰日成本 × 预计高峰天数 + 普通日成本 × 其他天数

不要只用平均值。生产环境还应考虑峰值、重试、异常循环和流量增长。

10. 防止意外消耗¶

账号和服务侧¶

设置余额提醒、项目预算或支出上限；
不同应用使用不同 Key；
定期查看按模型、Key 和项目拆分的用量；
为测试环境使用低额度 Key；
异常时先撤销 Key，再排查代码。

应用侧¶

设置每分钟请求数和并发上限；
Agent 设置最大轮数、最大工具调用数和总超时；
限制单次输入、检索片段和最大输出；
重试只覆盖暂时性错误，并设置总次数；
为用户或租户设置每日配额；
对重复请求使用幂等键或去重；
记录请求 ID、Token 和成本，但不记录完整 Key。

Agent 的安全阀示例¶

单任务最多模型轮次：8
单任务最多工具调用：12
单工具超时：30 秒
任务总超时：10 分钟
最大输入上下文：按模型与任务设置
最大输出：按步骤设置，不一味拉满
达到预算：停止并返回当前进度

11. 发现费用异常时怎么查¶

按顺序排查：

对比异常开始时间与代码发布、配置修改；
按 Key、模型、项目或用户拆分用量；
检查 Agent 是否出现循环或重复工具调用；
检查队列任务是否重复消费；
检查重试是否对 4xx 或长超时无限执行；
检查上下文是否重复拼接；
检查缓存命中是否突然下降；
检查 Key 是否泄露或被非预期设备使用；
先限制流量或撤销相关 Key；
保存请求 ID 和时间范围联系服务支持。

12. 上线前成本检查表¶

13. 官方参考¶

下一步：按照兼容 API 验收清单核对真实用量；需要测试流式、工具与长上下文时，继续阅读完整能力测试。