写在前面：Token 不是一个小数点后的计费细节
很多团队第一次做 AI 应用，最关心的问题通常是：
用哪个模型？ 模型单价是多少？ 回答质量够不够？ 上下文窗口有多大？这些问题当然重要，但真正上线后，你很快会发现另一个更现实的问题：
为什么试用时很便宜； 一接入知识库就变贵； 一加 Agent 就更贵； 一多人使用，账单开始不受控？原因往往不是“模型突然涨价”，而是你没有看见每一次请求背后到底塞了多少 token。
一个普通聊天请求，看起来只有一句话：
帮我总结一下这份客户投诉。但系统实际发给模型的内容，可能是：
系统提示词； 角色设定； 安全规则； 工具说明； 历史对话； 检索出来的文档片段； 用户当前问题； 输出格式约束； 失败重试时的补充上下文。用户看到的是一句话，账单看到的是几千、几万，甚至几十万 token。
所以，token 不只是一个计费单位。它更像 AI 应用里的“电表”：
你每塞一段上下文，电表就转一下； 你每让 Agent 多走一步，电表就再转一下； 你每返回一大段日志，电表也在转； 你每把历史对话完整带上，电表还在转。如果一个团队只盯着模型单价，而不管理 token，那么它做出来的不是 AI 应用，而是一个看不见功耗的机器。
本文实战口径
本文不讲“什么是 token”的教科书定义，而是按一个真实 AI 应用的成本链路来拆：
| 阶段 | 要解决的问题 |
|---|---|
| 识别 | 一次请求里的 token 到底从哪里来 |
| 计算 | 为什么 Agent 和 RAG 会让 token 成本放大 |
| 诊断 | 哪些上下文是真有用，哪些只是噪音 |
| 控制 | 怎么做 token budget，而不是事后看账单 |
| 优化 | 压缩、缓存、裁剪和分层模型怎么用 |
读完你应该能得到一个判断标准：
一个成熟的 AI 应用，不是只会调用模型，而是知道每一次调用为什么值得花这些 token。
一、模型看到的不是文字，而是 Token 流
OpenAI 的tiktoken项目里有一句非常关键的话：语言模型看到的不是我们眼里的文字，而是一串数字，也就是 token。
Byte Pair Encoding 这类 tokenizer 会把文本拆成可逆的 token 序列。它能处理任意文本，也能把常见片段压成更短的表示。项目 README 里提到一个经验值：平均来看，一个 token 大约对应 4 个字节。
这个细节听起来很底层，但它直接影响成本。
同样是“1000 字”，不同内容的 token 数可能完全不同：
普通中文段落； 英文技术文档； Markdown 表格； JSON； 代码； 日志； Base64； SQL； 混合中英文产品文档。它们在人眼里可能都是“一页内容”，在模型眼里却可能是完全不同的 token 压力。
这也是很多知识库项目容易踩坑的地方：团队只看文件数量和页数，不看 token 密度。
一个 20 页 PDF 也许没什么，但如果里面全是表格、合同条款、接口字段和嵌套 JSON，切成 chunks 后送进 RAG，token 成本会比你想象中高很多。
二、一次 AI 请求到底有哪些 Token
先看最简单的聊天应用。
你以为一次请求是：
用户问题 → 模型 → 回答真实情况更像：
系统提示词 + 开发者提示词 + 历史对话 + 用户问题 + 输出格式要求 + 安全策略 → 模型 → 回答如果是 RAG 应用，还要再加：
检索 query 改写； Embedding 检索； TopK 文档片段； 片段来源说明； 引用格式要求； 找不到答案时的拒答规则。如果是 Agent 应用，还要继续加：
工具列表； 工具 schema； 工具调用结果； 中间推理步骤； 失败后的重试上下文； 上一步执行日志； 下一步计划。这就是为什么 Agent 比普通聊天更容易烧 token。
普通聊天像一次对话。
Agent 更像一个反复读材料、查工具、看结果、再决定下一步的循环。
一次 Agent 任务如果走 5 步，每一步都把历史上下文、工具结果和部分日志重新发给模型，那么 token 成本就不是“一次请求的成本”，而是：
每一步上下文成本 × 步数这还没算失败重试。
三、RAG 最大的问题不是查不到，而是塞太多
很多团队做私有知识库，第一反应是：
多传资料； 多切 chunk； TopK 调大； 上下文窗口选大； 让模型尽量多看。这听起来稳妥，实际上很危险。
RAG 的目标不是把资料全部塞给模型，而是把最可能有用的证据送进去。TopK 越大，不一定越准，反而可能出现三类问题：
成本上升； 关键片段被噪音淹没； 模型在多个相似但冲突的片段之间摇摆。举个很常见的例子。
你问：
企业版客户退款规则是什么？检索系统如果把这些片段一起塞进去：
个人版退款规则； 企业版退款规则； 历史版本退款规则； 销售 FAQ； 客服话术； 一份过期合同； 一次内部讨论纪要。模型不一定会“更懂”，它可能只是更难判断哪个版本才是当前规则。
这时 token 花出去了，但没有换来更好的答案。
所以 RAG 的第一原则不是“多给”，而是“给对”。
四、Agent 的 Token 成本为什么会指数感变贵
Agent 应用里，token 成本有一个很隐蔽的放大器：上下文累积。
假设一个代码 Agent 执行任务：
读需求； 搜索文件； 打开代码； 运行测试； 看报错； 修改代码； 再运行测试； 总结结果。每一步都会产生上下文。
搜索结果是上下文。
文件内容是上下文。
测试输出是上下文。
报错堆栈是上下文。
模型自己的中间计划也是上下文。
如果系统没有做控制，它很容易把大量低价值内容带进后续步骤：
成功通过的测试日志； 重复的依赖下载输出； 完整 git diff； 过长的目录树； 无关文件内容； 多次重复出现的错误堆栈。这类内容对人来说只是“屏幕滚了一堆”，对模型来说却是实打实的 token。
更麻烦的是：这些噪音不只贵，还会影响判断。
一个模型在干净上下文里可能知道该改哪一行；在一堆日志、无关文件和历史尝试里，反而容易被带偏。
这就是 token 的第二层含义：
Token 不只是成本，也是一种注意力污染。
五、Token Budget：AI 应用应该先有预算，再有提示词
很多人写 prompt 的方式是：
想到什么就加什么； 怕模型不懂就多解释； 怕模型不听话就多写规则； 怕回答不准就多塞资料。这会让 prompt 越长越长，最后没人敢删。
更工程化的做法，是先做 token budget。
比如一次普通知识库问答，可以先定一个预算：
| 模块 | Token 预算 |
|---|---|
| 系统提示词 | 500 |
| 安全和拒答规则 | 300 |
| 历史对话 | 1000 |
| 检索文档片段 | 4000 |
| 用户问题 | 500 |
| 输出预留 | 1500 |
这个表不一定准确，但它会迫使团队回答几个关键问题：
系统提示词真的需要这么长吗？ 历史对话是否必须完整带上？ TopK 文档片段是否过多？ 输出是否需要限制结构？ 低价值上下文是否应该被摘要或丢弃？这比上线后看账单更主动。
成熟的 AI 系统应该在每次调用前就知道：
这次请求预计消耗多少 token； 哪些 token 是必要的； 哪些 token 可以压缩； 哪些 token 可以从缓存读取； 超过预算时优先删什么。六、不要只省 Token，要省低价值 Token
一提到 token 优化，很多人会走向一个误区：
能压就压； 能省就省； 越短越好。这不对。
AI 应用不是短信计费系统，不能为了省字数把关键证据删掉。好的 token 优化，不是把上下文变短，而是把低价值上下文删掉，把高价值证据留下。
可以按四类处理：
| 内容类型 | 处理方式 |
|---|---|
| 关键证据 | 保留原文，必要时带来源 |
| 重复内容 | 去重或合并 |
| 长日志 | 提取失败原因和关键行 |
| 历史对话 | 摘要成状态，而不是全文复读 |
比如客服知识库里，退款政策原文很重要，不能随便摘要；但用户前面寒暄了几轮，完全可以压成：
用户是企业版客户，正在咨询退款条件，已确认购买时间为 2026-05-20。这才是有价值的压缩。
七、Token 成本治理的 6 个动作
如果你现在已经有一个 AI 应用，建议从这 6 件事开始：
- 记录每次请求的输入和输出 token
不要只看总账单。至少按功能、用户、模型、场景拆开记录。
知识库问答平均多少 token； Agent 任务平均多少 token； 失败请求比成功请求贵多少； 哪个工具返回最吃 token。- 给每类任务设 token 上限
不是所有任务都配得上 100K 上下文。
简单分类任务：几百 token； 普通问答：几千 token； 复杂分析：几万 token； 长文档审阅：单独走批处理或分段流程。- 历史对话不要无限带
多轮对话应该保留状态，而不是保留所有原话。
- RAG 检索结果要重排和裁剪
TopK 不是越大越好。宁可给 5 段高质量证据，也不要给 20 段相似废话。
- 工具输出要过滤
尤其是命令行、测试日志、网页抓取、JSON 响应。模型通常不需要完整输出，只需要关键事实。
- 把稳定上下文缓存起来
产品说明、工具 schema、常用政策、固定系统提示词，如果平台支持缓存，就应该利用缓存机制降低重复成本。
八、一个简单的落地案例
假设你在做一个内部制度问答助手。
第一版常见做法：
系统提示词 2000 token； 历史对话 3000 token； TopK=10，每段 800 token； 用户问题 100 token； 输出 1000 token。一次请求大约：
2000 + 3000 + 8000 + 100 + 1000 = 14100 token如果每天 1000 次，就是 1410 万 token。
优化后：
系统提示词压到 800； 历史对话摘要到 600； TopK=5，每段 500； 用户问题 100； 输出限制到 800。一次请求变成：
800 + 600 + 2500 + 100 + 800 = 4800 token这不是少写几个字，而是系统结构变了。
关键是：如果检索质量更好，答案质量未必下降，甚至可能上升。因为模型看到的是更干净、更集中的证据。
九、最终评价：Token 是 AI 应用的工程边界
过去大家讨论 AI 应用，喜欢讲：
模型能力； Prompt 技巧； RAG 架构； Agent 框架； 向量数据库。这些都重要，但真正上线后，token 会把所有问题拉回现实。
它决定：
成本能不能接受； 延迟能不能控制； 上下文会不会溢出； 模型会不会被噪音干扰； 系统能不能规模化。所以，一个成熟的 AI 团队不应该只问：
这个模型聪不聪明？还应该问：
我们到底让它读了什么？ 这些内容值不值得读？ 哪些内容可以不读？ 哪些内容必须原文保留？ 哪些内容可以缓存、摘要或压缩？一句话总结：
Token 是 AI 应用的隐形电费。不会管理 token 的团队，迟早会被账单、延迟和噪音一起教育。
十、实战：给自己的文档算一笔 Token 账
这篇文章如果只停留在观点层，读者会觉得有道理，但不知道怎么动手。
最小实战可以很简单：选一份你准备放进知识库的文档，先算它到底会变成多少 token。
可以准备三类材料：
一份普通 Markdown 文档； 一份产品说明 PDF 转出来的文本； 一份接口返回 JSON 或测试日志。然后用 tokenizer 做统计。
如果用 Python，可以用tiktoken思路做一个最小脚本：
importtiktokenfrompathlibimportPath enc=tiktoken.get_encoding("cl100k_base")forfilein["doc.md","manual.txt","api.json"]:text=Path(file).read_text(encoding="utf-8")tokens=len(enc.encode(text))chars=len(text)print(file,"chars=",chars,"tokens=",tokens,"chars/token=",round(chars/tokens,2))这个实验不复杂，但非常有用。
你会很快发现几件事：
中文自然段不一定最贵； JSON、表格、日志经常更吃 token； 重复字段名会被反复计费； Markdown 里的表格和链接会增加 token； PDF 转文本如果格式混乱，token 浪费会更严重。做知识库之前先算一次，比上线后看账单更有价值。
因为它会逼你提前做决定：
哪些文件适合直接导入； 哪些文件需要清洗； 哪些内容应该拆成结构化字段； 哪些日志不应该进入知识库； 哪些资料需要先去重。十一、一个 Token 成本评估表
团队内部可以用一张很朴素的表来评估 AI 功能。
| 功能 | 平均输入 token | 平均输出 token | 日调用量 | 主要 token 来源 | 优化动作 |
|---|---|---|---|---|---|
| 内部制度问答 | 4800 | 800 | 1000 | RAG 片段 | 降低 TopK，文档去重 |
| 客服回复草稿 | 3200 | 600 | 3000 | 历史工单 | 历史摘要，模板缓存 |
| 代码修复 Agent | 18000 | 2500 | 200 | 日志和文件 | 压缩工具输出 |
| 合同审阅 | 40000 | 3000 | 50 | 合同原文 | 分段审阅，保留引用 |
这张表的重点不是精确到个位数，而是建立一种成本意识：
哪个功能调用量最大； 哪个功能单次最贵； 哪个功能最容易优化； 哪个功能不能轻易压缩； 哪个功能适合换小模型； 哪个功能应该异步处理。很多团队一开始会把所有任务都交给同一个强模型。
更成熟的做法是按任务分层：
| 任务 | 模型策略 |
|---|---|
| 分类、路由、意图识别 | 小模型或规则优先 |
| 简单 FAQ | 中等模型 + 短上下文 |
| 复杂文档问答 | 强模型 + 高质量 RAG |
| 合同、代码、安全审查 | 强模型 + 保守上下文 |
| 摘要和日志压缩 | 低成本模型或规则 |
这样做的好处是，token 成本不再是黑箱。
你不是每次都问“这次账单为什么高”，而是提前知道“这个功能本来就贵，贵在哪里，怎么控”。
十二、哪些 Token 不该省
写成本优化时，还有一个底线必须讲清楚：不是所有 token 都应该省。
这些内容通常不该轻易删：
合同里的限制条件； 政策里的例外条款； 代码里的类型定义； 测试里的断言； 安全审查里的输入来源； 财务和审计里的原始数值； 回答需要引用的原文证据。真正该省的是这些：
重复提示词； 重复历史对话； 无关检索片段； 成功日志； 进度条； 模板化废话； 旧版本文档； 工具返回里的无用字段。一个简单判断方法是：
如果删掉这段内容，答案是否仍然有证据？ 如果答案错了，能不能追溯原因？ 如果用户追问来源，能不能拿出原文？如果不能，就不要为了省 token 盲目压缩。
Token 成本治理的目标不是让 AI 少读，而是让 AI 不读废话。
