从"买模型"到"按 token 计费"，还差一步
先说判断：按 token 计费本身不是范式转移，它只是把模型能力变成了水电表。 真正的范式转移是第二步——当计价单位足够细，账就会从"买了个东西"变成"每一度电花在哪、值不值"，于是冒出三类生意：卖电表的人、省电的人、用电干活的人。
2026 年 8 月 26 日，深圳 AGIC 大会专门开了一场 Token 经济发展大会。艾氪智能讲《从 Human API 到 JovaAI Nomos：集群智慧正在走向分布式 AGI》，浪潮信息讲《从算力到生产力：打造 Agent 时代的基础设施体系》，还有"少吃 Token 多干活""词元出海与跨境金融基建"这类题目。光看题目就知道，token 已经从开发者的技术参数，变成了产业讨论的计价单元。同期发布的旗舰模型把每百万 token 的输入/输出价格直接摆在官网上（如 GPT-6 Astra 约 $10/$50 每百万 token），定价透明得像电价表。
但企业端的现实是：模型越强，账单越看不懂。钱花在哪、哪次调用在烧钱、为什么同样的活这个月比上个月贵——多数团队答不上来。这说明 token 经济还停在"有计量、无核算"的阶段。
Token 账单里，钱到底花在哪
把一次真实的 Agent 调用拆开，成本不是"输入价 + 输出价"这么简单。按我维护企业 AI 系统（XEAOS，30 多个自动化任务每天在跑）的经验，一份 token 账单通常由四块构成：
成本项 来源 最容易失控的点
输入 token prompt、知识库检索结果、工具返回 把整库文档塞进上下文
输出 token 模型生成内容 一次任务反复试错重写
缓存命中 相同前缀命中的上下文缓存 没开缓存，或 prompt 每次都在变
失败重试 超时、格式错、质量门不过 无重试上限的 while 循环
行业里已经有人把这个账算明白了：独立评测机构 Runta 用同一模型跑 9 款 Agent 外壳做相同任务，成本最高差 17.5 倍——修同一个 bug，最省的外壳花约 2.5 美元，最贵的花约 64 美元。同一模型，差出 25 倍，差的不是模型，是外壳怎么调度、怎么重试、怎么裁剪上下文。换句话说：选模型决定单价，编排层决定总价。
决定 token 成本的不是模型，是路由和缓存
所以省 token 的正确姿势不是"换更便宜的模型"，而是先管住编排层。最朴素也最有效的一招是分级路由：简单任务走小模型，只有难度够高的任务才上旗舰。下面是一段可直接跑的成本核算脚本（单价为示意值，思路可直接移植）：
MODEL = {class="tok-str">"flash": {class="tok-str">"in": 2, class="tok-str">"out": 8}, class="tok-str">"pro": {class="tok-str">"in": 20, class="tok-str">"out": 100}} # 单价:元/百万 token,示意价
CACHE_HIT, CACHE_DISC = 0.6, 0.25 # 上下文缓存命中率、缓存读取折扣
def cost(model, tin, tout): # 单任务成本:输入按缓存折算 + 输出
p = MODEL[model]
eff_in = tin * (1 – CACHE_HIT) + tin * CACHE_HIT * CACHE_DISC
return (eff_in * p[class="tok-str">"in"] + tout * p[class="tok-str">"out"]) / 1e6
def run(jobs, all_pro=False): # 全旗舰 vs 难度≥3 才上旗舰的分级路由
return sum(cost(class="tok-str">"pro" if (all_pro or d >= 3) else class="tok-str">"flash", i, o) for d, i, o in jobs)
jobs = [(d, 5000 + 4000 * d, 1000 + 300 * d) for d in (1, 1, 2, 2, 2, 3, 3, 3, 4, 4, 5)]
total_all, total_route = run(jobs, True), run(jobs)
print(fclass="tok-str">"全旗舰 {total_all:.2f} 元 vs 分级路由 {total_route:.2f} 元，省 {(total_all – total_route) / total_all:.0%}")
同一批 11 个任务，全旗舰和分级路由的真实运行结果：
全旗舰 3.92 元 vs 分级路由 2.68 元，省 32%
这只是"按难度分两档"，还没用上质量门和评审回退。把这两样加上，省的比例还能往上走——GitHub 的 HydraFusion 实验里，靠"便宜模型先写、质量门不过再升级旗舰 + 异厂评审"，质量分数不降反升，成本预估降约 67%。方向是一致的：把旗舰 token 留给真正的难任务。
企业把 token 算清楚的四件事
落到自己的系统上，按顺序做这四件事，账单就能从"糊涂账"变成"可优化项"：
给任务分级：把系统里的调用按"难度 + 失败代价"分成两到三档，定好每档用什么模型。判断标准就一条——这单活错了，重来一次的成本是多少。
开上下文缓存，且让前缀稳定：同一套系统提示词、知识库前缀别每次拼接出不同顺序，缓存命中率上不去，省 token 就是空谈。
给重试设上限并加质量门：规定"最多重试几次、什么算通过"，而不是让 Agent 无限自我纠错。质量门不过就换档或换人，别在同一个档位上死磕。
按"单任务总价"记账，不按 token 单价记账：把每次业务动作（写一篇文章、回一条客诉、跑一次复盘）的 token 成本累计起来看，你才会知道哪个流程在偷偷烧钱。
总结一句本质
Token 经济的商业模式会分成三层：模型厂商赚"计量费"（按 token 收钱，越来越像收电费）；编排与路由层赚"效率费"（帮你把每个 token 花得更值，这是 Agent 基础设施最肥的一段）；应用层赚"结果费"（客户不为 token 买单，为"少 Token 多干活"的结果买单）。我自己做企业 AI 系统这几年最大的体会是：客户从不过问 token 单价，只问"这个结果多少钱、多久能出"。谁先把 token 变成能核算、能优化的成本项，谁就站在了新范式这一侧。
一句话收尾：Token 经济的本质不是给 token 定价，而是给"每个 token 换回来的业务结果"定价。
评论区聊聊：你们系统的 token 账单，是笔糊涂账还是已经能按任务核算了？
