跳转至

Token不经济

Ch01.726 Token不经济

📊 Level ⭐⭐ | 8.6KB | entities/token不经济.md

Token不经济

来源: 腾讯研究院

发布日期: 2026-06-29

原文链接: https://mp.weixin.qq.com/s/XN7L__mVssYFKioGQPDupA

摘要

"Token不经济"是腾讯研究院李刚提出的概念，指企业在大模型应用中的 token 消耗与实际产出不成比例的现象。微软收回内部 Claude Code 许可、Uber 仅 4 个月耗尽全年 AI 编程预算、Meta 撤下 Tokenmaxxing 排行榜——这些事件共同指向一个结构性困境：人人都在拥抱 AI，但只看到越来越长的账单，没看到对应的收益。Token 不经济是定价策略、Agent 架构损耗、应用场景局限三重因素叠加的结果。

核心要点

  • 定义：Token 消耗与实际产出不成比例，企业 AI 投入产出比失衡的结构性问题
  • 定价抬升：旗舰模型定价格局固化，次级/轻量模型价格中枢在过去两年悄然上移
  • Agent 架构损耗：上下文陷阱、分词器黑箱、技能冗余、多 Agent 沟通税、长程熵增构成结构性浪费
  • 应用端局限：token 的通用性有限，高度依赖数字化场景，物理世界落地困难
  • 技术平权问题：缺乏技术背景的普通企业用户无法理解 Agent 架构的成本动力学，处于结构性劣势

深度分析

Token 定价市场结构性抬升

大模型 token 市场正在经历一个全面的定价抬升过程。在旗舰层，Anthropic 凭借编程能力领先建立了行业最强的定价权，Opus 系列以 $15/$75（输入/输出百万 token 价格）锚定高端市场，Sonnet（$3/$15）覆盖日常编程，Haiku（$1/$5）面向轻量场景。这一分层策略使 Anthropic 的 ARR 从 2024 年底的约 10 亿美元飙升至 2026 年 5 月的约 450 亿美元。OpenAI 和 Google 在意识到编程是主战场后加速追赶，但短期内仍需以价换量。在次级/轻量层，与直觉相反，价格中枢在过去两年持续上移。Haiku 4.5 较 Haiku 3.5 上浮 20%，GPT mini 系列定价几乎翻番，Gemini Flash 系列百万 token 输出定价翻了 6 倍多。根本原因是经济型 token 消费量的爆炸式增长——日常编码、文档处理和自动化流程由大量次级/轻量模型承担，调用量激增使烧现金维持低价的游戏无法持续。

Agent 架构的五重系统性浪费

Token 不经济的内部技术根源来自 Agent 架构的五重结构性损耗。第一，上下文陷阱（Context Trap）：Agent 架构天然放大长文本问题，同一批信息被反复读取，同一任务被反复计费。Salim et al.（2026）对 ChatDev 的分析发现，代码审查阶段消耗的 token 平均占总消耗的 39.5%，近四成 token 花在 Agent 之间传递已有信息上。第二，分词器黑箱（Tokenizer Black Box）：闭源模型的分词器是黑箱，Anthropic 在 Opus 4.7 更换分词器后技术文档的平均膨胀率达到 1.47 倍，高分辨率图片的 token 膨胀高达 3.01 倍。第三，技能冗余（Skill Redundancy）：Gao et al.（2026）对 55,315 个公开技能的研究发现，26.4% 的技能没有路由描述，60% 以上内容不是可执行规则而是背景解释。Han et al.（2026）的 SWE-Skills-Bench 测试表明，79.6% 的技能未带来通过率提升，token 开销最高增加 451%。第四，多 Agent 沟通税（Communication Tax）：多 Agent 协作时机器之间也会开无效会议，反复重复已讨论过的结论和格式套话。第五，长程熵增（Entropy Drift）：长程任务容易跑偏，纠偏机制带来额外消耗，系统越复杂熵税增长越快。

Token 应用的结构性鸿沟

编程是大语言模型表现最好的应用场景，但它是具有通用性的特例。通用性在于编程输出可作为 Agent 的通用语言驱动多种任务；特例在于编程场景具备确定的信号反馈——编译器、解释器、单元测试能立刻给出结构化、无歧义的对错判断，可以高效形成自动后训练闭环。这种自主训练环境在编程之外的场景中很少见。法律审查的反馈成本远高于编程——Harvey AI 生成的合同草案仍需执业律师从头复核。到了物理世界，问题更加严峻：现实世界没有编译器，物理世界不接受迭代只接受验证，验证成本永远高于生成成本。Sim-to-Real Gap 使仿真训练的策略在真实部署中极其脆弱，OpenAI 解散机器人团队即是明证。

第 2 来源 — PointFive 成本归因测量（2026-08-12 merge）

PointFive 的实测数据为"上下文陷阱"提供了直接的量化证据：Agent 会话的 token 成本中，75% 来自框架自身的 system prompt 与工具定义，另外 19% 是模型的隐藏推理，压缩工具能触及的一切合计仅 6.0%。框架行李在每一轮都被重新发送和重新读取，任务贡献第一个词之前账单已经产生。

互补角度 3 条：

  1. 框架行李占比的实证锚点：腾讯研究院的"上下文陷阱"论述是定性分析（ChatDev 代码审查 39.5%），PointFive 给出整会话级的定量拆解——框架开销 75% + 隐藏推理 19%，且是在真实软件任务、按实际 provider 价格计费的模拟工程会话中测得。
  2. 对压缩降本路径的证伪：如果框架自身开销占 75%，则 token 压缩/精简工具即使理想工作也只能触及总成本的 6%——直接质疑"压缩即可降本"的主流工程假设，与分词器黑箱（1.47× 膨胀）形成互补：膨胀来自系统结构而非输入文本本身。
  3. 成本模型的层级归属：PointFive 的成本拆解表明 Token 不经济的治理重点应从"压缩输入"转向"精简框架"（system prompt / 工具定义瘦身、减少每轮重复注入），与 2026-07-03 圆桌"Token 成本治理三层架构"中的架构层/知识层主张互相印证。

实践启示

  1. 建立 token 消耗的可观测性。企业需要工具来追踪 token 的具体去向——哪些花在编码执行，哪些浪费在 Agent 间信息传递，哪些消耗在技能加载。没有可观测性就无法控制成本。

  2. 精简技能库，避免冗余调用。对团队维护的技能进行定期审计：每个技能是否有明确的路由描述，内容是否精简为可执行规则而非背景说明。移除或合并长期未被调用的技能。

  3. 关注分词器变更的隐形成本。闭源模型的分词器升级可能带来 token 计费膨胀。在评估新模型时，不仅要看 API 单价，还要实测同等工作负载下的 token 实际消耗量。

  4. 为长程 Agent 任务设置熵税预算。预期一个复杂任务的实际 token 消耗可能是理论最小值的 2-3 倍（因纠偏、摘要、协调等开销）。将此纳入成本模型，避免预算超支。

  5. 识别真提效场景，避免全面铺开。优先在数字化程度高、有确定反馈信号（如编程、数据分析）的场景部署 Agent，而非盲目推广到所有业务线。在数字化程度低的场景，先做数字化转型再做 AI 投入。

  6. 框架开销优先于输入压缩。PointFive 的 75% 归因表明：压缩输入 token 的边际收益上限约 6%，真正的降本杠杆在框架层——精简 system prompt 与工具定义、消除每轮重复注入，其次才是输入压缩。

相关实体

→ 原文存档 → PointFive 原文存档