Everything You Need to Know about AI Tokens

省下的 token，可能是最贵的决策

Nofar Gaspar 是本期 Operator's Cut 的嘉宾。她自称 AI expert，和主持人共同开发过“AI Summer Adventure”课程；更重要的是，她不是站在预算表外谈成本的人：她亲自用 Anthropic API 跑过一个 OpenClaw chief of staff，也亲手收到了那张两周 1,500 美元的意外账单。这期谈的不是“token 怎么少花一点”，而是怎样判断：哪些智能投入正在产出，哪些正在后台悄悄漏钱。

这期回答了 7 个问题：

1. 为什么模型的每百万 token 单价，几乎不能告诉你真实成本？
2. 为什么更贵的模型，反而可能让一项任务更便宜？
3. 怎样用 5 到 10 个任务，测出团队真正该用的模型和工具？
4. 什么样的自动化正在悄悄烧钱，却没有产出？
5. 哪些 token 看似没有交付物，却必须坚决保留？
6. 模型路由器能替人决定该用哪个模型吗？
7. 企业怎样限额，才不会逼最强员工退回低价值 AI 用法？

被问到为什么不能只盯着“每百万 token 单价”时，Nofar 先把 token 拉回它最朴素的定义：它是模型读写文本的切分单位，通常比一个词小、比一个字符大。问题在于，每家模型实验室都有自己的 tokenizer，也就是切分文本的规则；账单上的“每百万 token”，并不是同一种标准重量单位。英文里一页文本大约是 1,000 token，但非拉丁语文本可能为同样内容带来 2 到 5 倍 token。代码里的缩进、括号和空格也会被计入。

Opus 4.7 是一个更直接的例子。它在 4 月上线时，价格表与前代相同，但新 tokenizer 让同一文本产生约 30% 更多 token。针对超过 100 万次请求的独立分析发现，原生 token 计数增加约 32% 到 45%；缓存吸收了一部分差额后，真实账单仍增加约 12% 到 27%。Simon Wilson 测自己的一个 prompt，token 消耗接近原来的 1.5 倍。"The per token price is kind of the sticker, but the cost per accepted task is the operating metric."（每 token 的价格有点像标价牌，但每个被接受任务的成本，才是运营指标。）

这意味着，采购模型不能只比“百万 token 多少钱”，而要追踪同一业务任务最终被接受时花了多少钱。一次任务的成本包含输入、模型内部推理、输出、重试和人工修正；其中推理 token 往往看不见，却可能按更高的输出价格计费。tokenizer 调整未必是变相涨价，它可能有技术上的合理性；但对企业而言，单位产出成本确实会在供应商不改标价时发生变化。

讲到“token 并不等价于任务成本”时，Nofar 给出的证据不是抽象 benchmark，而是 Databricks 在自己代码库里做的真实工程任务测试。测试对象是 coding agents，也就是能读取代码、调用工具、反复修改并验证结果的编程代理。按单个 token 的价格看，Sonnet 5 比 Opus 4.8 便宜 1.7 倍，照常识应该更省钱；但按每项任务的总成本算，Sonnet 约为 2.09 美元，Opus 则是 1.94 美元。

差额出在“到达同一结果之前走了多少弯路”。Sonnet 为获得相同质量，需要更多迭代和推理，累计 token 反而更多。模型单价像出租车起步价，任务成本更像从公司到机场的最终车费：起步便宜，不代表路线更短，更不代表不会绕路。"overall Opus, which is significantly on paper more expensive model, it was cheaper to operate"（总体而言，账面上贵得多的 Opus，运营起来反而更便宜。）

这意味着，复杂任务里的模型选择，应从“谁最便宜”改成“谁能以最少返工交出合格结果”。一个高单价模型如果一次完成，可能比低价模型多轮修补更便宜，也更快。这里的边界同样重要：Databricks 测的是其代码库中的真实工程任务，不是邮件撰写、网页搜索或所有知识工作。不能因此得出“贵模型永远划算”，只能得出一个更严格的结论：每种工作流，都该单独算每个可接受结果的成本。

被问到团队究竟该怎样比较模型和工具时，Nofar 给了一个不需要大规模采购项目就能开始的方法：拿出 5 到 10 个有代表性的真实任务，分别交给多个模型或工具重复执行。任务必须来自团队真正要做的工作，例如整理一份固定结构的研究材料、修复一个具体 bug、从指定数据库检索答案，而不是泛泛地问“谁更聪明”。

测试时要锁住两件事：输入一致，质量门槛一致。然后看四个数：首次成功率，也就是第一次是否达到可用标准；人工修正量；完成耗时；以及总成本。总成本不能只看模型返回的文字，还要把失败后重跑、人工接手和额外工具调用算进去。"The winner is the stack that gets your actual work done reliably."（赢家是那个能可靠完成你实际工作的技术栈。）

这意味着，团队最终需要的不是一个“公司默认模型”，而是一张按任务分类的使用规范。研究可能适合一种模型和检索方式；编码可能适合另一种模型和 agent harness，也就是包住模型、决定它读什么上下文和怎样调用工具的执行框架。模型与工具迭代很快，这张表也不能一测定终身，应该定期重做。反面是，若团队说不清“什么叫可接受结果”，测试再精确也没有意义：有人接受八成正确，有人要求能直接交付，最后比较到的只会是不同人的宽严标准。

解释什么是应被消灭的“tokens that spin”时，Nofar 讲了自己的事故。她把一个名为 Chloe 的 OpenClaw chief of staff 接在 Anthropic API 上，API 自动续费，账单又发到她不常查看的第二邮箱。旅行期间，她没有使用这个 agent，却发现费用持续出现。打开 dashboard 后，她看到两周花了 1,500 美元；更离谱的是，近 4 亿 input tokens 几乎没有对应 output tokens，输入输出比接近 3,000 比 1。

继续排查后，原因浮出来了：OpenClaw 给自己创建了一批 cron jobs，也就是按固定时间自动运行的定时任务。其中一个 compaction job 本该压缩上下文，却每 30 分钟在空 session 上跑一次，而且消耗还在上升。"I spent in 2 weeks $1,500 on an agent that I was not using."（我在两周里为一个根本没在用的 agent 花了 1,500 美元。）

这意味着，agent 成本管理不能只审查员工发出的 prompt，还要审计后台机制：闲置 agent、过于频繁的任务、永不结束的长对话、无人阅读的日报、每次都带上的超长系统提示词，都可能变成持续扣费的水龙头。最难抓的 spin 不一定是程序报错。有些自动化完全按设计运行，只是它的产出已不值得继续付费。一个实用判断是：某自动化连续一两周没人使用其输出，或输出价值明显低于月度账单，就该停掉，而不是让它“先跑着”。

把 token 分为“teach、produce、spin”三类时，Nofar 特意为第一类辩护。tokens that teach，是用来学习的 token：试三种不同工作流、用多个模型跑同一任务、尝试一个失败的自动化，或者为 AI 准备 identity files、curated context、knowledge packs 和 memory。前几项是在让人知道什么方法有效；后几项是在教 AI 理解使用者是谁、团队怎样工作、哪些资料才可信。

这些消耗在仪表盘上很难看。它们常常没有一个立刻“交付”的文档、代码或报告，于是很容易被归入浪费。但 Nofar 的判断是："a failed experiment is as important as a successful experiment."（一次失败的实验和一次成功的实验同样重要。） 她还提到一项覆盖 2 万名开发者的研究：最重度的 AI 使用者，交付的 production code 数量约为其他人的两倍。这里的 production code 指真正进入生产环境、承担实际业务功能的代码，而非练习或草稿。

这意味着，企业若把一切没有即时交付物的 token 都砍掉，最先消失的会是试错、上下文建设和可复用能力，员工则更可能退回让 AI 写邮件、翻译文本这类低风险用法。边界在于，teach 不是给无目标试验开无限账单。它必须能带来方法、上下文或能力的积累；真正的 spin 则是机器反复运行，既没有交付，也没有留下可用于下一次的学习。

讨论自动模型路由能否解决选模型难题时，主持人指出，市场上已经出现大量 model routing 方案，企业也在自建路由系统，让任务在定制模型与顶级模型之间分配。路由器的理想状态很诱人：简单问题自动走便宜模型，复杂问题再升级到强模型，人不必每次手选。但 Nofar 和主持人都给这件事泼了盆冷水。

软件工程可能较早形成路由规范，因为它的结果更容易验证：测试是否通过、代码是否编译、bug 是否复现，信号相对明确。广义知识工作却没有这么整齐。一次市场分析、管理层备忘录或研究结论，可能在事实正确之外，还涉及表达风格、论证深度、组织语境和个人偏好。Nofar 提到 GPT-5 的自动路由体验：不少 super users 和高频用户对 auto mode 的结果感到沮丧。"there's no one clear approach yet"（目前还没有一种清晰统一的方法。）

这意味着，路由器短期更像副驾驶，不是替代判断的自动驾驶。组织仍要训练员工知道不同模型的能力边界，并保留人工选择权：什么时候要更强的推理，什么时候低成本模型已足够，什么时候该停止一条明显跑偏的链路。嘉宾也承认，路由还处于早期；即便未来出现某些通用模式，也不保证适合每家公司、每种任务，或每个人对输出风格的要求。

讨论 token-maxing 反弹为 token-anxious 后，Nofar 描述了一个很具体的组织心理变化：员工开始自我审查，不敢使用昂贵模型，担心一条雄心勃勃的 prompt 就耗尽整周额度。Meta 曾从内部 AI 使用排行榜转向发送限制使用的 memo；Uber 则把员工额度限制在 1,500。此前，过度追求使用量确实造成过浪费，但钟摆如果从“拼命用”摆到“不敢用”，最先被压缩的恰恰是高难度探索。

Nofar 的判断很锋利："the most expensive token is the one that your best person is afraid to spend."（最昂贵的 token，是你最优秀的人不敢花出去的那一个。） 她建议预算按工作负载和个人角色分配。一个人在为全团队构建 skills、context 和 reusable capabilities，也就是可复用的技能、组织语境和工作能力，他消耗的 token 可能会让许多人以后少走弯路；这与把工具当成“扩展版 Google”的零散查询，不该拿同一把尺子限额。

这意味着，治理应从统一额度改成分层授权：生产任务、探索实验、团队能力建设分别有不同预算与审计方式；使用情况应当可见，但目标不是逼每个人花得最少，而是教大家“聪明地花”。这并不是为无限制消耗辩护。组织仍应先清掉第 4 节所说的 spin，设置异常提醒和上限；只是上限不能把真正创造业务价值、也在为团队积累能力的人，一并逼回低价值用法。

“模型不涨价，也能让你的实际账单暴涨”和“更便宜的模型，可能让每项任务更贵”，共同拆掉了一个直觉：token 单价不是成本本身。真正要看的，是同一项工作以可接受质量完成时，花了多少模型调用、多少返工、多少人工修正，以及多久才能交付。

“最危险的浪费，不是模型犯错，而是机器默默自转”和“没有交付物的 token，反而可能是未来产出的学费”，则要求管理者做另一个更难的区分。不能因为 dashboard 上没有即时产物，就把所有消耗都判成浪费。无人读取的定时简报、空会话里的 compaction job 是 spin，应当果断清除；试验工作流、建立知识包、训练团队知道何时该用强模型，则是 teach，可能暂时没有交付物，却在降低未来每项任务的成本。

所以，token 管理不是财务部门要求“把账单压下来”的单一动作，而是以业务结果为单位配置智能的运营能力。对读者自己而言，最实际的起点不是立刻换一个更便宜的模型，而是列出手上 5 到 10 个真实任务，记录哪些任务一次完成、哪些总在返工；再翻一遍自己和团队的自动化，找出那些持续扣费却没人看结果的机器。账单里省下来的空间，才应该留给真正需要思考、试错和建设的工作。