从 Token 到 Agent 成本设计

看懂 AI 账单，构建不烧上下文的工作流

一篇关于 Token 作为 AI 工作流中成本、上下文、推理、输出和返工的第一性原理笔记。

日期： 2026-05-15

分类： 技术博客

标签： Tokens / Agent Cost / OpenAI / DeepSeek

这篇文章源于我在学习 OpenAI 和 DeepSeek 如何按 Token 收费、缓存如何运作、推理 Token 的行为机制、JSON schema 和 tool schema 为何重要，以及不同模型应如何在 Agent 工作流中分工时问自己的一系列问题。目标不是记住一张价格表，而是建立可迁移的判断力。

更新日期： 2026-05-15

参考文献

OpenAI API Pricing
📷https://openai.com/api/pricing/

OpenAI GPT-5.5 Model
https://developers.openai.com/api/docs/models/gpt-5.5

OpenAI Prompt Caching
https://developers.openai.com/api/docs/guides/prompt-caching

OpenAI Reasoning Models
https://developers.openai.com/api/docs/guides/reasoning

OpenAI Structured Outputs
https://developers.openai.com/api/docs/guides/structured-outputs

OpenAI Function Calling
https://developers.openai.com/api/docs/guides/function-calling

DeepSeek Pricing
https://api-docs.deepseek.com/quick\_start/pricing

DeepSeek Token Usage
https://api-docs.deepseek.com/quick\_start/token\_usage

DeepSeek Context Caching
https://api-docs.deepseek.com/guides/kv\_cache

DeepSeek JSON Output
https://api-docs.deepseek.com/guides/json\_mode/

DeepSeek Thinking Mode
https://api-docs.deepseek.com/guides/thinking\_mode

1. 这篇文章真正讨论的是什么

很多人都知道 Token 是计费单位，但真的看到 API 账单时依然茫然。

他们知道输入、输出、缓存输入和推理 Token 都很重要，但还没搞清这些类别如何影响系统设计。

他们知道 JSON mode、structured outputs、tool calls 和 prompt caching 很重要，但不知道这些东西在 prompt 里该放在哪里。

他们知道 DeepSeek 更便宜、GPT 类模型更强，但不知道一个模糊的产品想法应该先交给便宜模型还是先交给强模型。

所以真正的问题不是：

什么是 Token？

更好的问题是：

一个人应该怎样理解 Token，将其作为 AI 系统中成本、上下文、推理、输出和返工的综合衡量指标？

如果只记价格，得到的只是零散信息。

如果理解机制，就能开始设计 Agent 工作流。

2. 第一性原理：Token 不是字符数

简单的定义是：

Token 是模型用来表示和处理文本的基本单元，也是 API 计费的基本单元。

但更有工程意义的版本是：

Token 是模型读取、计算、注意力、推理和生成的最小工作单元。

人理解一个橙子，依赖颜色、气味、果皮、果肉、味道和记忆。

模型看到 "orange" 这个词时，路径不同：

text -> tokenizer -> token id -> embedding vector -> 与上下文中其他 token 的关系

Token id 只是入口。模型有意义的 "理解" 来自训练数据和当前上下文中习得的关系。

这就是为什么模型能把 "orange" 与水果、柑橘、维生素 C、果皮、果汁、甜和酸联系起来，尽管它没有像人一样尝过橙子。

3. 一次 API 调用就是一张 Token 收据

一次 API 调用大致是这样的：

输入文本
-> tokenizer 将其拆分为 token
-> 模型读取输入 token
-> 模型可能消耗推理/思考 token
-> 模型生成可见输出 token
-> 用量记录可计费单元
-> 供应商按模型价格收费

成本不只是基于你输入了多少个单词。

它更接近：

成本 =
未缓存输入 token * 输入价格

缓存输入 token * 缓存输入价格
可见输出 token * 输出价格
推理 token * 输出侧价格
工具调用 / 工具结果成本

不同供应商使用的字段名称不同，但计费逻辑相似。

4. 一个具体的 GPT-5.5 成本示例

截至 2026-05-15，OpenAI 定价页面显示 GPT-5.5 标准价格为：

输入：$5.00 / 1M tokens
缓存输入：$0.50 / 1M tokens
输出：$30.00 / 1M tokens

这意味着：

输出是输入的 6 倍
输入是缓存输入的 10 倍
输出是缓存输入的 60 倍

假设一次请求使用：

总输入：10,000 tokens
缓存输入：8,000 tokens
未缓存输入：2,000 tokens

可见答案：800 tokens
推理 tokens：1,200 tokens
输出侧总计：2,000 tokens

粗略成本：

未缓存输入：
2,000 * 5 / 1,000,000 = $0.010

缓存输入：
8,000 * 0.5 / 1,000,000 = $0.004

输出 + 推理：
2,000 * 30 / 1,000,000 = $0.060

总计：
$0.074

如果不使用缓存：

10,000 * 5 / 1,000,000 + 2,000 * 30 / 1,000,000
= $0.050 + $0.060
= $0.110

经验教训不只是缓存能省钱。

更深层的教训是：

强模型不应该用来搬运信息。

强模型应该读取干净的证据并产出高价值的判断。

5. 四种主要的 Token 类别

输入 Token

输入 Token 是模型读取的所有内容：

system 和 developer 指令
user prompt
对话历史
文件
网页
搜索结果
工具 schema
JSON schema
结构化输出 schema
图片中的视觉 token

输入 token 提供事实、规则、约束和上下文。

缓存输入 Token

缓存输入 token 是与之前可复用的 prompt 前缀相匹配的输入 token。

它们仍然算作 token，但费用更低，因为提供商可以复用部分之前的计算。

好的缓存候选：

稳定的身份
项目规则
固定的输出格式
固定的工具定义
固定的 JSON schema
稳定的项目背景

输出 Token

输出 token 是模型写出的可见答案。

它们通常更贵，因为生成是顺序的。每个生成的 token 会影响下一个。

输出应当服务于具体目的：

判断
结论
解释
报告
代码
交接

不要让模型在没人会用的过程叙述上花费昂贵的输出 token。

推理 / 思考 Token

推理 token 是模型在最终答案之前的思考预算。

它们对以下场景有用：

架构决策
困难调试
多约束产品设计
安全审查
业务权衡
长 Agent 工作流

它们通常对以下场景浪费：

简单分类
字段提取
翻译
格式转换
固定模板生成

规则：

不要用深度推理来做简单的机械工作。

6. DeepSeek 定价：便宜也需要设计

截至 2026-05-15，DeepSeek 的定价页面显示了缓存命中输入、缓存未命中输入和输出的不同费率。具体数字可能变化，请以官方页面为准。

关键的设计经验是稳定的：

当稳定前缀命中缓存时，DeepSeek 变得便宜很多。
相对于缓存命中输入，输出仍然昂贵。
对于简单任务，应关闭或降低思考。

所以不要把“便宜模型”当作把一切扔进上下文的许可证。

便宜模型仍然需要清晰的上下文边界。

7. 缓存不是魔法：先稳定前缀，后动态内容

Prompt 缓存依赖于重复的前缀。

缓存友好的 prompt 顺序如下：

稳定的身份 / 角色
稳定的项目规则
稳定的输出格式
稳定的工具 schema
稳定的 JSON schema
今天的任务
今天的文件 / 网页
今天的证据

缓存不友好的顺序如下：

今天的任务
临时文件内容
随机的用户添加
稳定规则
输出 schema
项目背景

为什么第二个顺序不好？

因为开头每次都在变。如果前缀变了，后面的稳定内容对缓存复用就没那么有用了。

8. 工具 Schema 与 JSON Schema

最简单的区别：

工具 schema = 模型可以调用的动作的使用说明书
JSON schema = 模型必须填写的答案模板

工具 Schema

一个工具 schema 告诉模型：

存在什么工具
工具叫什么名字
何时使用它
它需要哪些参数
哪些参数是必需的
哪些额外参数是禁止的

示例：

{
  "type": "function",
  "name": "search_notes",
  "description": "Search local notes by keyword.",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "The keyword or question to search for."
      },
      "limit": {
        "type": "integer",
        "minimum": 1,
        "maximum": 10
      }
    },
    "required": ["query"],
    "additionalProperties": false
  }
}

JSON Schema

一个 JSON schema 告诉模型最终答案必须是什么样的形状。

示例：

{
  "type": "object",
  "properties": {
    "summary": {
      "type": "string"
    },
    "risks": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "confidence": {
      "type": "string",
      "enum": ["low", "medium", "high"]
    }
  },
  "required": ["summary", "risks", "confidence"],
  "additionalProperties": false
}

期望的答案形状如下：

{
  "summary": "One-sentence summary",
  "risks": ["Evidence is incomplete", "Cost may be high"],
  "confidence": "medium"
}

比喻：

工具 schema = 遥控器说明书
JSON schema = 作业表单

9. JSON 会消耗更多 Token 吗

对于单次调用，是的，通常如此。

你需要把 schema 或示例放进 prompt，并且输出包含字段名、引号、花括号和逗号。

但整个系统的成本仍可能下降，因为结构化输出减少了：

重试
手动清理
解析失败
下游 bug
返工沟通

更好的公式是：

真实成本 = 单次调用 token 成本 × 重试次数 + 解析失败成本 + 人工修复成本

在关键流程中使用结构化输出。

不要每个随意的草稿都用 JSON 过度设计。

10. 如果你还不理解任务，如何选择模型

不要立即猜测。

使用一个探针。

探针不是为了解决任务，而是为了决定任务应该如何解决。

示例探针：

You are a task router. Do not solve the task. Only choose the processing route.

Input:
{user_idea_or_task}

Return JSON:
{
"task_type": "extract|translate|classify|brainstorm|plan|research|code|decision|unknown",
"ambiguity": "low|medium|high",
"needs_first_hand_sources": true,
"needs_reasoning": "none|low|medium|high",
"risk_level": "low|medium|high",
"suggested_model": "cheap|strong|strong_reasoning",
"next_step": "ask_clarifying_question|make_receipt|retrieve_sources|draft_plan|execute",
"why": "one-sentence explanation"
}

规则：

不要扩展答案。
不要解决用户的问题。
如果任务是格式转换、提取或翻译，needs_reasoning = none。
如果目标模糊且价值判断重要，suggested_model = strong。
如果必须筛选大量源材料，先检索源。

对于一个模糊的想法，比如：

I want to build an AI companion knowledge base that helps me learn, start projects, reflect, and generate action plans.

探针可能会说：

11. DeepSeek 与 GPT 类模型如何分工

我目前的规则：

wild idea -> 先用强模型做框架
large source pile -> 先用 DeepSeek 做证据收据
final judgment -> 再用强模型

不要把"便宜"理解为"永远先用"。

如果第一刀切错了，后面所有步骤都可能变成便宜的错误。

更好的循环：

user -> 强模型：
把混乱意图转化为任务地图、边界和假设

强模型 -> DeepSeek：
提取、分类、扩展、总结来源，构建竞品对比表

DeepSeek -> 强模型：
返回证据收据；强模型压缩、判断、决策

DeepSeek 先用的情况：

你已明确知道要提取什么。
任务是批量提取、分类、翻译或格式化。
不需要高价值判断。
源文本量大，但只需要证据片段。

强模型先用的情况：

你还不清楚自己真正想要什么。
任务涉及产品方向、业务判断或架构设计。
来源信息相互矛盾。
方向一旦错误，后续步骤会浪费大量成本。

一句话总结：

DeepSeek 适合做证据处理员和初级规划师。
强模型更适合做总架构师和终审人。

12. 真正的 Token 节省来自上下文控制

很多人以为节省 token 就是：

写更短的提示词

这只对了一半。

真正的规则是：

不要把不必要的内容塞进上下文。

不要给模型喂完整版：

原始 HTML
完整测试日志
完整 git diff
完整聊天记录
完整仓库目录
完整文档库

正确做法：

把完整材料留在磁盘上
给模型提供：
路径
哈希值
exit_code
关键摘录
摘要
未解决的问题

这就是收据的思路。

一份精简收据可以长这样：

目标：
已知事实：
决策边界：
下一步动作：
停止条件：
完整日志：

它的作用是用一个简短、可验证的状态包替代冗长的历史记录。

13. 可复用的提示词结构

对于 Agent 工作流，使用：

静态前缀：
稳定的身份设定
稳定的项目规则
稳定的输出格式
固定的工具 schema
固定的 JSON schema

动态任务：
今日目标
允许的范围
需要读取的文件/URL

证据尾部：
最新证据摘要
测试 exit code
diff 摘要
源文件路径
未解决的问题

这种结构的好处：

提高缓存命中率
减少上下文浪费
便于切换模型或 Agent

14. 最小化 Token 任务卡

为每个 AI 任务编写类似内容：

{
"task\_id": "token-study-001",
"model": "gpt-5.5 | gpt-5.4-mini | deepseek-v4-flash | deepseek-v4-pro",
"reasoning\_effort": "none | low | medium | high",
"input\_policy": {
"static\_prefix": [],
"dynamic\_task": [],
"evidence\_tail": []
},
"output\_policy": {
"max\_output\_tokens": 800,
"format": "markdown | json | schema",
"must\_include": ["verdict", "evidence", "next\_action"],
"must\_not\_include": ["long process narration", "full logs"]
},
"cache\_policy": {
"stable\_prefix\_first": true,
"track\_cached\_tokens": true,
"deepseek\_track": ["prompt\_cache\_hit\_tokens", "prompt\_cache\_miss\_tokens"],
"openai\_track": ["cached\_tokens", "reasoning\_tokens"]
},
"verdict": "continue | split | compact | stop"
}

重点不是这张卡看起来整齐。

重点是它迫使你思考这些问题：

模型到底应该读什么？
它应该输出什么？
哪些内容足够稳定可以缓存？
哪些证据必须保留？
这个任务真的需要推理吗？
能否用收据替代完整历史？

15. 核心原则

Token 是 AI 系统中计算、上下文、注意力、推理、输出和返工的统一度量单位。

节省 token 不是少说话。

而是：

让每个 token 服务于决策、执行、验证或交接

对于 AI 构建者来说，关键问题变成了：

什么应该交给强模型？
什么应该交给便宜模型？
什么属于稳定的缓存前缀？
什么需要 schema？
什么应该留在磁盘上？
什么应该变成收据？
什么应该被终止？

这就是从提示词使用者到 Agent 系统设计者的跨越。

16. 我基于这套思维构建的三件套工具

这篇文章不应停留在概念层面。

我把这套关于 token、上下文、模型路由和审计的思考，转化成了三个可组合的 Codex 技能 / Agent 工具。

agent-cost-router
= 在执行前决定最便宜且最安全的路径
= 选择模型、上下文预算、探测需求和技能路径
https://github.com/aDragon0707/agent-cost-router

token-prompt-compiler
= 在开始工作前把混乱的人类请求编译成可执行的任务包
= 生成 Tiny Packet / Standard Packet / Worker Packet / Micro Receipt
https://github.com/aDragon0707/token-prompt-compiler

audit-evolution
= 在工作完成后进行轻量级审查和连续性检查
= 生成 Tiny Audit / Evidence Receipt / Clean-State Packet
目前是本地技能，尚未作为独立 GitHub 仓库上传
C:\\Users\\86181.codex\\skills\\audit-evolution

最简单的工作流：

agent-cost-router

选择路线：如何节省 token、使用哪个模型、阅读多少内容
https://github.com/aDragon0707/agent-cost-router

token-prompt-compiler

编译任务：将请求转化为最小的有效任务包
https://github.com/aDragon0707/token-prompt-compiler

audit-evolution

闭环：记录证据、经验教训和下一步
本地路径：C:\\Users\\86181.codex\\skills\\audit-evolution