Everything You Need to Know About AI Tokens

今天的《AI Daily Brief》带来一期和 Nofar 一起录制的 Operator's Cut。

关于 AI tokens，你需要知道的一切。

《AI Daily Brief》是一档每天更新的播客和视频节目，专门聊 AI 领域最重要的新闻和讨论。

好，朋友们，在我们开始之前，先快速说几件事。

好了，朋友们。

今天 Nufar Gaspar 又回来做客了。最近这段时间，Nufar 和我一直在筹备很多新内容。

最近有很多人参加了我们的最新项目，也体验了这个项目：一场“自己选择冒险路线”风格的 AI Summer Adventure。

除此之外，我们还在准备一整套扩充版的教育资源，很快就会告诉大家详情。

不过，Nufar 和我最近面对的一个现实是，我们接触到的每家公司，都在处理同一类问题：AI tokens 和 token economics。

现在我们已经确确实实进入了 AI 的 agentic era。公司需要考虑的，不只是怎么让更多人采用 AI、怎么最大化 AI 的价值，还要考虑怎么做到这一点，同时又不至于让成本彻底失控，并且确保把合适的 intelligence 用在合适的问题上。

任何真正搭建过 agentic workflow 的人都可以告诉你，要让合适的模型按你的要求完成任务，又不让它陷入无休止的循环，需要认真做不少考量。

今天这期节目会作为一份关于 AI tokens 的终极入门指南：我们说 AI tokens 的时候究竟在说什么，有哪些新挑战，有哪些关键的坑需要避开，以及怎样最大限度地优化你和你的公司使用 AI tokens 的方式。

好，Nofar，欢迎回来参加新一期 Operator's Cut。今天我们要聊的是最近大家都在讨论、也都很关心的话题。

我们要聊的是 tokens。

你最近怎么样？

我挺好的。

我特别期待聊 tokens。

是啊，我觉得现在这个阶段特别有意思。我们已经从一开始面对新变化时抓耳挠腮、惊慌失措，慢慢进入了真正开始适应新战术、新策略的阶段。

我觉得今天的话题正好和这个阶段非常契合。

那你先跟我们说说，今天我们要聊些什么，然后我们就开始吧。

好。

我之所以想做这期节目，是因为最近我走进的每一个会议室，真的每一个，都会出现某种版本的同一场 token 讨论。

有些一线实践者在使用昂贵模型时，会觉得自己仿佛一直被人盯着。

普通用户会担心，一个野心勃勃的 prompt 会不会一下子用掉他们一周的额度；而管理层看到账单增长得比预期快，就开始提出一大堆问题：这些 tokens 到底有没有产出什么有用的东西？

所以我不知道你们现在处在什么位置，但现在围绕“是不是用了太多 intelligence”，确实出现了一种新的焦虑。首先，我想把这个讨论扭转一下，确保每个人都明白 tokens 是什么、账单到底意味着什么，然后再讲讲怎样明智地花费它们。

重点是花得明智，而不是一味节省。

这就是我今天来到这里的原因，也是我今天打算做的事情。

在这场讨论里，我发现自己经常处在这样一个位置：现在成本涨上来了，大家的反应非常强烈。

我更担心的是，人们会退回到那些已知的 ROI 偏见里，重新选择一些不算无聊、但最终风险很低的使用场景，而不是去尝试 AI 真正能做到的事情。

所以，和现在整体语气的转变相比，我发现自己反而需要为 token maxing 和 token leaderboards 这类做法辩护。

我觉得，今天我们显然会聊到这个话题更聪明的版本，所以我很期待。

没错。

好。

因为现在围绕这个问题的讨论越来越多了。我觉得，对于“tokens 不应该只是一种财务指标”这种感受，我们正在形成一种更准确、更好的表达方式。

就在最近，OpenAI 的 CFO 提出了一个评分卡，叫作“每一美元带来的有用智能”。

它围绕着一个问题展开：每一项成功完成的任务，实际成本是多少？

我觉得，这才是大家应该进行的讨论。

我也想帮你把整个故事理清楚。

tokens 到底是什么？

你的工作成本是多少，在哪些地方的使用创造了价值，又在哪些地方悄悄损耗了价值，而不是增加价值。

所以，先从我们是怎么走到今天这一步开始。我想带你了解 tokens 消耗的四个时代，你可能会发现自己正处在哪一个阶段。

最开始，我们基本上都对 tokens 毫无概念。

那是一个全包时代：模型公司补贴了使用成本，统一的订阅价格把计量表藏了起来。很多个人用户，包括现在依然处在这个阶段的用户，只看得到使用上限，而看不到按 token 计价的价格。

所以，我们就是从那里开始的。

然后，正如你刚才说的，我们进入了 tokens 最大化时代。

那是一个排行榜时代，使用量成了 AI 成熟度的徽章。

我们都记得当时围绕 Meta 的一些讨论。Meta 在内部排行榜上追踪员工使用 AI 的情况。

他们以前把它叫作……而且他们单个月大概用了六十万亿到七十四万亿个 tokens。

根据公开的数据，使用量最高的个人用户用了两千八百亿个 tokens。

为了让你直观感受一下这是多少，这大概相当于两百三十万本书的文字量。

如果你想象一下，那就相当于整整一个月里，每分钟连续读完五十本书。

这就是 Meta 的故事。

后来 Uber 也推出了一个采用率排行榜，结果大约四个月就烧光了整个二〇二六年的 AI 编程预算。

还有另一家公司，名字没有公开。不过据 TechCrunch 报道，他们在没有设置任何使用上限的情况下，累计产生了五亿美元的云账单。

所以在那个时代，使用量成了衡量指标，仪表盘测量的是活动量，却声称自己测量的是价值。

显然，这种做法是不可持续的。

我知道你对此有一些看法，也很想听听你的观点。

但我还想说，它实际上让我们又一次走得太远了。钟摆把我们推到了我所谓的“token 不公”时代，而我们现在就处在这个时代。

不过，如果你有什么想为排行榜辩护的，我愿意听听。

对。

你看，先说这个，我觉得排行榜这个概念本身是很不错的。

但它确实会带来一套我认为非常可预见的挑战。

其实，可预见到什么程度呢，我会说，人们老是在那儿纠结说会不会有人去钻空子，这件事一直让我觉得有点夸张。

当然了，只要你给一个系统设置了真实的利害关系，人们就一定会想办法钻规则空子，但这本来就是完全可以预料到的。

而且从第一性原理来想，你其实也能推导出很多应对这种情况的方法。

所以我觉得，第一，这件事被渲染过头了，那些为此特别紧张的人，反应都有点过度。

第二，我更大的观点是，现在一家公司不管是通过 token 排行榜还是别的什么方式，如果它大手大脚地多花了钱，我敢拿多少钱打赌，它最后都会比那些花得太保守、因为过度在意按年度周期去证明 ROI 之类事情的公司走得更靠前。

当然，最理想的 Goldilocks 场景，我觉得也就是你接下来要讲的，是既能够做实验、能够学习、能够搭建东西，也能够真正理解消耗情况，同时又不会因为这个而害怕。

但我同意，我觉得这个钟摆从 token maxing 和那种兴奋情绪，猛地、而且是猛得过头地，摆回到了 token anxious。

而这就是我们最近这几周、这几个月，不管你怎么算，一直身处的范式。

对。

好。

所以我觉得，你应该会很喜欢我这个关于如何明智使用 tokens 的模型。

但说到 token anxious，我现在在很多公司里看到的是，很多员工都在自我审查，本质上就是想尽量避免成本。

而且就算我们去看那些曾经在 token maxing 的公司也是一样。

比如 Meta，之前还在排行榜上，后来就发了一份 memo，开始限制 AI 的使用。

现在媒体都不叫它 token maxing 了，而是叫 token minimizing。

Uber 也把员工上限卡在了一千五百。

所以就连那些原本就在 token maxing 的公司，现在也都在明显地把这个规模缩短。

而当员工开始自我审查时，他们就会觉得每一个 prompt 都像是在做一次 ROI 讨论。

这不是我们想看到的。

而且我觉得这是一个非常糟糕的阶段，不应该停留太久，因为我相信，最昂贵的 token，就是那个你团队里最优秀的人都不敢花出去的 token。

所以这就是我想把大家带到的状态，我把它叫做 token smart 时代，也就是说，你需要花得明智，而不是花得吝啬；你要搞清楚什么会创造价值，以及使用会在哪些地方悄悄漏掉。

这基本上就是这一期节目的整体主题。

而我这一期、在这档播客里想讲的，是 token 到底由哪四个要素构成。

为什么 tokens 生来就不一样，怎么审计你自己的使用情况，以及怎么在公司内部更好地治理，或者把这件事做得更好。

我也在尽量让它对所有人都相关，不管你是具体执行的人，需要套用一些成本工程的 playbook，然后更聪明地处理这件事；还是管理层和管理员，需要更主动一点，避免在没有充分回应的情况下，就被迫和 CFO 进行一场很难的对话，比如对方一句“我们直接把账单砍掉吧”，却不去讨论背后的业务影响，就像你刚才说的那样。

所以这就是我们今天的计划。

那我想先从把 token 介绍给你开始，因为我感觉虽然它是 AI 里使用最频繁的术语，但真正理解它是什么的人其实并不算多；而每一张账单、每一个配额、每一个 rate limit，归根到底都是围绕 tokens 来算的。

所以简单来说，token 就是模型读取和写出的一个文本块。

它通常比一个字符大一点，但一般又比一个单词小一点。

如果你从来没见过 tokenizer，或者没看过 token 实际长什么样，OpenAI 有一个非常好的页面，所有人都能打开看，你可以直接去看看 token 到底是什么样子。

所以它看起来大概就是那样。

你可以把文本粘贴进去，然后你就会看到单词是怎么被切开的。

所以你会看到，有些词会保持成一个 token，而另外一些可能会被拆成多个 token。

而且很有意思的是，数字经常会从中间被切开，诸如此类。

所以我们会把它放到节目备注里，不过如果你以前没看过自己的文本会长什么样，这是个很有意思的小实验。

顺便一提，如果你粘贴的是非英语，或者非拉丁字母的语言，你会发现通常 token 的数量会比英语大很多。

所以这就是 OpenAI 的 tokenizer。

再补几个点，帮助大家彻底理解这个事。

一般来说，英语里的比例大概是每个 token 对应四分之三个单词，也就是说，如果你有一整页文本，差不多就是一千个 token。

而像 Hindi、Thai、Greek 这类语言，或者其他类似的语言，在同样内容下，token 数量可能会多出两到五倍。

而因为计费是按 token 来算的，所以有些问题如果你用其他语言去问，成本可能会高很多。

这有时候也会被叫做 AI 的 language tax。

代码也是一样，它又是另一种情况，有自己的一套方式。

缩进、括号，还有空白字符，都会变成 token。

现在也有一些更新的文本 tokenization 方式，会对代码更友好一些，不过数字依然是个很大的问题。

所以你已经看到了一、二、三、四、五这种数字会从中间被切开。

顺便说一句，这也是为什么大家老是在做 AI 的 strawberry test，而它在数 strawberry 这个词里有几个 R 的时候经常失败，在很多情况下，这其实只是 tokenization 的特性，不一定真的是模型失败了。

因为模型其实从来没有真正见过一个一个单独的字母。

它看到的只是 straw 和 berry 这两个分开的部分，所以它才会数错。

所以现代模型有各种变通办法，但很多那种“AI 太蠢了”的梗图，本质上真的就只是 tokenizer 的问题。

所以，这就是 token。

再说到日常工作的成本，我觉得这是个挺好的心智模型。

比如说，起草一封邮件大概就是五百到七百个 token。

一页文本，像刚才说的，大概是一千个 token。

你也能看出来，更长的文本当然可能会超过这个数。

如果你让一个模型或者工具去做类似 AI web search 这样的事，通常还会再增加几千个 token。

这是结果部分带来的，有时候甚至会多很多。

有意思的是，图片在很多情况下，按 token 数量来说其实没那么大。

大概在一千多个 token 左右。

有意思的是，深度研究很容易就会用到七万个，甚至几十万个 token。不过就在前几天，我们有一位课程学员遇到了一个只需要回答“是”或“否”的问题。结果他一不小心，没有要求针对这个问题进行网页搜索，而是让 agentic tool 去做深度研究。

这个工具启动了大约十万个 subagent 来做研究，最后，他这个只需要回答“是”或“否”的问题，光是得到答案就花掉了超过四百万个 token。

所以，token 数量很容易就会远远超过这个水平。

具体来说，还有几个地方也很容易出现 token 消耗特别大的工作负载。比如数据分析，一项任务很容易就会用到一百万甚至更多的 token；大量代码编写也可能消耗得非常厉害，很多 agentic workflow 也是一样。

我只是想让你大概了解一下它处在什么水平，也让这里的说法更具体一点。

就像你看到的，日常事务，比如处理邮件之类的，几乎不花什么钱。

大概也就半美分，所以没人应该为了省 token 而限制邮件的使用。

钱并不是花在这些地方的。

搜索和研究的 token 消耗，可能会在不知不觉中成倍增长。

所以，这可能是一个值得寻找效率提升空间的地方。

而到了最顶端，那完全是另一种情况了。

所以，如果把邮件和 agentic coding task 放在一起比较，token 消耗可能相差一千倍，甚至更多。

另外，你还需要注意一点：每一轮对话都会叠加。

模型并不会记住你之前发过的消息，所以在同一个 session 里，它会把之前的全部对话再次发回给模型。

所以，假设到了第十轮，它可能会在处理你的新消息时，同时处理前面大量的交流内容。这样一来，总消耗的增长速度会远远快于对话轮数表面上显示的速度。

而且这还没算 system prompt。我们后面会讲一些应对策略，但这就是为什么，仅仅是 session 太长，就很容易消耗掉大量 token。

我觉得，这也是为什么这个话题如此重要的原因之一。换句话说，越先进、最终价值越高的使用场景，消耗的 token 就越多。这一点其实很直观，因为面对更大的挑战，需要更强的智能。

但使用场景的发展方向，正在朝这个方向前进。

所以，如果不解决 token 焦虑，它之所以会带来问题，是因为它会激励人们一直停留在那些不够复杂的使用场景里。

所以，从减少 token 消耗的角度来看，这条发展轨迹是很清楚的。

作为领导团队，你们希望员工用 AI 做更多先进、更有用的事情。

问题只在于，怎样才能让他们把这些事情做好。

所以，在确实需要深度研究的地方，你希望他们去做深度研究；但对于一个一秒钟就能用 Google 查到的“是”或“否”问题，你当然不希望他们不小心也启动深度研究。

很好。

说到 agentic，或者说更先进的能力，这些功能会让 token 数量显著增加，因为 agents 会通过循环自主工作。

因此，根据业内广泛引用的估算，它们消耗的 token 数量，大约是简单聊天的五到三十倍。

而设计不佳的 agentic loop 或 agentic harness，消耗可能还会更糟。

因为一项典型任务通常会涉及十到二十次模型调用，每次调用都要携带指令、历史记录、工具定义以及之前的结果。

我记得根据 McKinsey 的估算，一项 agentic task 的成本，大约百分之六十都花在第一次响应之后的检查、完善和重新生成答案上。

所以，通常最贵的部分，是从得到答案到拿到被接受的结果这一步。

所以，这一点挺有意思的。

而现在事情变得更复杂了，因为 token 并不是生来就一样的。

顺便说一下，这里并不是说不要使用这些 agentic 工具，而是要知道，正如你刚才说的，智能是有成本的。

但事情还会变得更复杂，因为 token 并不是生来就一样的，而且每家模型实验室都有自己的 tokenizer。

你刚才看到的是 OpenAI 的 tokenizer，但不同的模型实验室使用的 tokenizer 也不一样。

比如，OpenAI 目前的 tokenizer 词汇表大约有二十万个 token。

Gemini 的大约有二十五万六千个。

Meta 的 LLaMA 大概只有它的一半。

而 Claude 的 tokenizer 没有公开。我们之所以都应该关心这一点，是因为每百万 token 的价格，都是按照各家实验室自己的 token 来计算的，而我们通常并不知道这些 token 的具体情况。同一份文档，在一家供应商那里可能会比在另一家多出百分之十到百分之二十的 token；对于代码和非英语文本，差距甚至还会更大。

所以，模型的行为会进一步拉大这个差距：一个模型可能一次就能回答，而另一个模型可能需要更长时间进行推理，写出更多内容，采取更多 agentic 步骤，或者需要重试。

而模型周围的工具，还会加入它自己的系统提示、上下文以及循环设计。

所以，两个技术栈即使做的是同一项任务，token 数量和完成率也可能不一样。

结果就是，账单可能完全不同。

所以，单个 token 的价格有点像商品标签上的标价，但每个被接受任务的成本才是运营指标。否则，你根本没办法比较不同的供应商和不同的工具。

好。

还有一个很重要、也能说明这个问题的例子：Opus 4.1 上线时发生了什么。它在底层基本上更换了 tokenizer，时间是在今年四月，而价格表和前一个模型完全一样，仍然是每百万 token 同样的美元价格。但这个模型搭载了一个新的 tokenizer，对于同样的文本，根据 Anthropic 自己的文档，产生的 token 大约多了百分之三十。他们并没有隐瞒这一点。

所以，有不少针对超过一百万次请求的独立分析发现，原生 token 数量大约增长了百分之三十二到百分之四十五，而实际账单增长了百分之十二到百分之二十七，因为其中一部分差异被缓存抵消了。

就连 Simon Willison 也测量了自己的一个提示词，发现 token 数量差不多多了百分之五十，也就是接近原来的一点五倍。

所以，尽管这件事有文档说明，但实际上，我们为同样的智能付了更多钱。

这就像缩水式通胀，对吧？

标价没变，但糖果棒变小了。

所以，没人会接受现在每一美元只能印出少百分之三十的文字，而这正是那次发生的情况。

所以，这种情况一直在变化。

每家实验室都会调整 tokenizer，而且通常都有充分的理由。但对运营人员来说，这里的经验是：我们必须讨论每项任务需要花多少美元，而不是每个 token 需要花多少美元，因为这个预算分母一直在变，单看 token 价格，没办法真正弄清楚最后要花多少钱。

我们来聊聊 AI 工具会把 token 用在什么地方。你需要明白，每次 AI 请求都有三层 token，而且它们的定价差别非常大。

第一层是输入 token。

也就是提示词、对话历史、文件、工具定义，以及输入中包含的所有其他内容。

这些是模型读取的内容，按每个 token 来算，它们最便宜，但累积得很快。因为如果对话历史每次都要重新发送，或者模型需要读取大量上下文，成本就可能相当高。

然后是推理 token。

这就是第二层。

这些 token 是模型在回答之前进行内部思考时用到的。

大多数情况下，你是看不到这部分的，但它会按照输出价格来计费，也就是说，按每个 token 的高价计费，而这可能会让每次请求的成本增加到原来的四到二十倍。

最后，我们还有输出。

也就是答案。

就是你实际看到的答案，而这部分通常比输入 token 的单价贵三到五倍。

我觉得，推理层是最容易让所有人感到意外的一层，因为你可能得到一个四百 token 的答案，但在底层，它可能实际上消耗了四千个思考 token，因为模型需要进行内部独白，经过大量思考，才能给你这个答案。

如果要打个比方，这就像餐厅账单里标着“厨房工时”的那一项。

所以你看不到它。

它不是菜的一部分，但你还是得为它支付不少钱。

而那些推理强度高的模型，消耗的 token 数量往往是低推理强度模型的二十倍。

同一个问题，价格可能会有非常大的差异，而且有时候，投入更多推理并不会带来更好的结果。

所以，有些指标甚至显示，对于简单问题，使用较低的推理强度反而更好，因为这样每项任务的总体成本会明显降低，而且在不让模型对所有事情都过度思考的情况下，质量还会提高。

所以，模型更聪明，或者花更多时间思考，并不总是能带来更好的结果。

好。

而且我觉得，在最前沿的模型中，输入和输出的定价差距还在不断扩大。

你看看 GPT-4.5，它大约是十美元，不，准确地说，是每一百万个输入 token 十美元，而每一百万个输出 token 是五十美元。

不过 GPT-4.6 的比例是六比一。

所以我们看到，这个差距还在进一步扩大。

另外还有推理强度等级，这也让事情变得更加复杂，因为这些前沿模型越来越允许你调节推理强度。

对。

推理强度。

推理强度越高，推理 token 就明显越多。相比模型本身，这可能是你更需要留意的调节项，因为从低或中等强度调到高或超高强度，token 数量很容易增加十到十二倍，成本也会随之上升。

好。

这里关于价格，还有 Databricks 做的那个实验值得说一下，因为更聪明的模型不一定总是比便宜的模型更贵。

Databricks 做的事情是，他们用自己代码库里的真实工程任务测试了 coding agent，当时使用的是 Sonnet 3.5。

它的 token 单价比 GPT-4o 便宜一点七倍。

不过，Sonnet 每项任务的成本大约是两美元，准确地说是两美元零九美分，而 4o 是一美元九十四美分。

这是因为 Sonnet 需要更多轮迭代和更多推理，才能达到同样的结果，所以消耗的 token 多得多。总体来看，Opus 虽然从标价上看贵得多，但实际运行成本反而更低。这意味着，我们不应该只去选择能找到的最便宜模型。

我们需要根据任务选择合适的模型。这并不容易，但确实是需要留意的一点。

还有一个会影响账单的因素，是工具本身。

所以 Databricks 在同一个实验里，用同一个模型、同样的 thinking effort，跑在不同的 agent harness 上，他们看到在质量相同的情况下，单个任务的成本差了两倍多。主要就是因为其中一个工具给模型喂的上下文，大约只有其他工具的三分之一，所以整体成本就更低。

所以这个账单非常难看懂，也非常难梳理，我会尽我所能帮你搞明白。

所以归根结底，我们要看的是每个任务的成本，而不是 tokens，不然我们根本没法真正 apples to apples 地比较。而且这个成本还得把重试、审核、每一次需要做的修正，以及每一次额外迭代都算进去，最后再除以被接受的结果数量。

这才是你每个被接受任务的成本。

这才是你应该瞄准、也应该优化的指标。这样一来，讨论也会更多回到投资回报和业务价值上，而不只是围着 tokens 打转。因为像你现在应该已经明白的那样，tokens 其实是很难准确计量的。

好。

你可以做的一项实际操作是，挑选五到十个能代表你日常工作的任务，用两个模型或者两种方案分别跑一遍。这样你才能更清楚地知道，在你的选项空间里该怎么选。输入条件和质量标准要尽量保持一致，然后比较首次通过率、人工修正量、耗时，以及总成本。最后胜出的，就是那个能稳定把你的真实工作完成掉的 stack。

我知道这听起来工作量不小，但如果你有一套为自己优化过的、清晰的 taxonomy，而且你知道对于你做的这类任务，哪些模型整体上能给你更好的结果，也许还会用更少的 tokens，或者你能替你的团队、你的公司做这件事，而且你还得持续反复去做，因为变化很快，那么至少你就可以教大家：如果你在做这类研究，当前推荐的模型是什么，它能在整体质量和单任务价值上给你最好的结果，诸如此类。

这就是我们现在所处的现实。

好，现在我想给你一套说法，帮助你看待你自己的 tokens。希望借助这个框架，你能分辨出哪些 tokens 是在创造价值，哪些其实没带来太多价值。

在我看来，你或者你的组织花掉的每一个 token，基本上都属于三种类型之一。

第一种，是我称之为会教学的 tokens，而且这是双向的。也就是说，你在教你自己，正如 Natalia 和 Daniel 前面说的，我们不想停止实验。

所以，这类 tokens 包括实验、本来就会失败的 workflow，还有“让我试试这三种不同的方法，这样我就能学到东西”这种过程。

所以这类 tokens 是值得花的，因为你能从中获得学习。你可以把它们看作学费。

顺便说一句，这里面也包括你在教 AI 了解你自己的那些部分。

所以这就包括 identity files、整理过的上下文，还有 knowledge packs。

memory 也可以算在这里面，因为让你的 AI 知道你是谁、你的上下文是什么，以及摸清楚 AI 对你来说什么方式有效，这对你继续往前走非常关键。

这些东西在 dashboard 上看起来有点像浪费，甚至看起来非常像浪费，因为没有任何可交付成果直接产出。但我的观点是，这些 tokens 是你必须毫不犹豫去捍卫的。因为如果你不捍卫它们，你很快就会退回到只让 AI 帮你写邮件、做语言翻译，而不是继续推进那些真正重要的 workflows。特别是如果你和你的公司在 AI 当前的发展水平上还有很多功课要补的时候，更是这样。

所以，我希望这些会教学的 tokens 能被保住，因为真正能推动事情向前的，正是它们，而不只是下一类我称为会生产的 tokens。

那很显然，会生产的 tokens 是最好辩护的一类，因为它们就是你拿来产出真正会交付的工作的 tokens。

比如最终提案、研究成果，或者代码。

很明显，这一类的 ROI 也最容易展示。

但最后，我们还有一类应该被消灭的 tokens，也就是我称为会空转的 tokens。

这可能是机器自己跟自己说话，或者一些自动化流程，根本没人看它们的输出；也可能是运行频率太低的自动化、闲置的 agents、臃肿的上下文、被错误使用的工具和上下文、用 Claude 去写一封邮件，也就是模型用错了，或者流程根本没优化，等等。

这些都属于有活动、但产出不足。

产出不足。

所以如果非要总结一个对 tokens 更聪明的做法，那就是：先砍掉那些空转的 tokens，再去调优生产环节，确保它有成本效益，同时保护好那些会教学的 tokens。

顺序就是这样。

也就是说，先去审计你的 spin tokens，嗯，然后再做后面的事。

我有一个非常尴尬的“tokens不断自我运转”的故事，等会儿我会分享给大家。

不过我也想特别说一下，从tokens这件事上我们能学到，失败的实验和成功的实验一样重要。

所以你一定要鼓励员工去失败、去尝试，因为不然的话，他们产生的tokens就不可能尽可能多地创造价值。

作为一个AI专家，讲这件事确实很尴尬。不过，我的OpenClaude曾经是一个chief of staff。之所以说“曾经”，是因为它现在已经被禁用了。这个chief of staff我叫它Chloe，它使用的是Anthropic API。

因为它用的是API，所以会一直自动续费，而账单都发到了一个备用收件箱里。

我当时其实没有认真监控这些账单，只是看到费用好像挺高的。但因为它确实给我带来了大量价值，而且我也没注意自己收到新账单的频率，所以一直没有发现问题。

后来到了六月初，我在出差，所以完全没有使用OpenClaude，但我还是看到账单不断寄过来。

我就想，怎么我还在收到这些账单？

于是我打开了dashboard，结果才发现，我在两周时间里，竟然花了一千五百美元，养了一个自己根本没在用的agent。

我打开dashboard，仔细看了两眼，才发现输入tokens差不多有四亿，而输出tokens几乎是零。

也就是说，输入和输出的比例差不多是三千比一。

这简直就是一台机器在和自己说话，然后让我为它和自己进行的内部独白买单。

继续往下查，我发现OpenClaude给自己创建了一大堆cron jobs。

其中有一个compaction job，每三十分钟就会在空会话上运行一次。

更糟的是，这个趋势还在不断上升。

所以我首先关掉了OpenClaw，之后得换一种方式对它进行优化。

但如果这种事会发生在我这个配置上，那它就真的可能发生在任何人身上。

尤其是当信用卡是公司持有的，而不是你自己的时候，你往往更不会注意，因为你根本看不到账单。

对。

而且你还有一大堆其他运行良好的东西，所以你可能会以为，费用是那些东西产生的。

所以关于支出，我还想补充一点：如果大家听到这里，很多人可能会把支出的来源理解成只有失误或错误，但情况并不总是这样。

比如刚才这个例子就有点介于两者之间。它不完全算是错误，因为它确实在做原本应该做的事情，只不过你没有真正关注它，所以它做得比实际需要的更多。

但我觉得很多时候，支出还可能只是因为你没有把一个自己确实想要的任务的参数定义清楚。

我就有一个这样的例子。

之前有一段时间，我让一个OpenClaw一直在研究AI领域的新数据源，帮助我们弄清楚某些采用率指标目前到底是什么状态，对吧？

每天都会有新的研究发布，去衡量这个或者那个指标，告诉你数据准备度、系统集成情况、使用场景之类的信息。

这些东西多到人类根本监控不过来，但agent特别擅长做这种事。

所以这个OpenClaw agent就像一个研究员，它唯一的工作就是根据heartbeat设定的时间表，出去检查有没有新的信息。

而且它本来就不是要停下来的。

它一直按照特定的时间表运行，基本上就是一个持续不断的研究流程，每天都在爬遍互联网的各个角落。

结果发现，它带来的价值根本不够抵消成本，但它确实完成了本来该完成的工作。

所以我觉得，审计支出的一部分，其实也是在弄清楚，哪些东西不知不觉变成了花费，哪怕它们一开始的方向是对的。

我觉得这也是为什么“审计”这个概念是个很好的框架，因为有时候，审计不只是为了发现错误，也包括更新或改进那些原本有价值的流程。

我同意。

而且我还发现，很多人会创建一些自动化，因为他们觉得这些自动化应该会有用。

比如说，哎呀，我根本看不过来。

我的 Slack 消息太多了。

那我干脆做一个 Slack miner，让它每小时运行一次，把我所有频道里的内容都读一遍。

这样很容易就会花掉一千美元的 tokens，而它做的事情，实际上对任何人都没有产生什么真正的影响。

或者说，你满怀热情地做了一个 morning brief，本来打算每天早上都读，但不知道为什么，你就是觉得它没什么价值，最后也根本不读。

所以，这些东西你一定要审计，然后停掉。

我的经验法则是：如果你创建了一个自动化，而且一两个星期下来，你一次都没有用过它的输出，那就应该马上停掉，因为按定义来说，它就是一笔支出。

或者，如果你确实在用这个自动化，但把所有 Slack 频道都总结一遍所带来的价值，和月底的账单相比，比例非常不划算，那我也会把它算作一笔支出。

而且现在大家在工作中基本都能用 Copilot 或 GPT-4，我觉得公司里这种情况会越来越多，因为创建这些自动化实在太容易了。可如果大家又不够了解怎样有效地使用 tokens，就会做出一大堆纸面上看起来不错的自动化，但月底对着账单看，就没那么好了。

好，那我来给你列一份“悄悄消耗 tokens 的嫌疑对象”清单。

首先，就是处于闲置状态的 agents，以及运行频率过高的 jobs。

这些东西要么是在没有任何有意义的输出或结果的情况下运行，要么就是运行得太频繁了，频繁到离谱。

另外，很多时候我们还会看到一些根本没人用的自动化。

比如每周报告，或者那个从来没人打开阅读的 dashboard。

还有一种额外的东西，我们经常把它叫作 pre-prompt 文本。

也就是说，模型在收到第一条 prompt 之前运行并读取的所有内容。

这包括始终开启的规则或指令、skill definition、tool definition，等等。

如果没有妥善组织，这些内容很容易在每次运行时就累积成几千甚至上万个 tokens，而且你一个字都还没输入。

所以这些成本加起来会非常可观。

很多人还会一直保持着一段“永生对话”，也就是说，他们会不断延续一个没完没了的 session，让旧的历史记录和旧的上下文一直被带进去，往往还会导致质量越来越差。

很多时候，我们也会看到用户从来不对数据检索进行过滤。

所以，他们不是只从数据库里取二十行数据，而是会拉取五百行；或者明明知道要找的邮件主题是什么，却把整个收件箱都处理一遍，只为了找出那一封邮件，诸如此类。

还有很多人会把上下文弄得到处都是。

这样一来，agent 就得读一大堆文档，才能搞清楚大家到底在说什么，以及这里的事实究竟是什么；另外，还有各种 rework loops，也就是反复返工的循环。

所以，只要你的 agent、skill，或者日常使用方式，让你为了得到同样的结果而反复做更多次迭代，

这就相当于白白花了更多 token。

所以，这些就是最直接可疑的地方。

接下来我想告诉你，怎么尝试判断你的系统是不是陷入了空转，或者 token 的空转与生产之比是不是设置得不合理。

问题在于，并不是所有人都能用同样的方式检测出来。

有些人手上有具体的指标。

通常是那些使用模型 API 版本的人。

他们可以使用 API console；如果他们是 Claude Code 或 Cursor 用户，也会有 usage view。

当然，拥有管理员权限的人还可以查看 admin dashboard。

所以，如果你属于这些人，可以做下面几件事。

有一件事你一定要做，那就是周末测试。也就是说，如果你什么 AI 任务都没做，但看账单时发现费用还在不断累积，那你就知道，有些东西正在没有产生任何价值的情况下增加你的账单。

我当时就是这种情况。

另外，还要留意极端的输入输出比例。

agentic 工作确实可能合理地出现很高的比例，但如果输入和输出达到了几千比一，很多时候那就是空循环。

以我的 OpenClaw 为例，这个比例是两千六百比一，实在太离谱了。

如果你发现花费一直在上涨，但你完成的工作量，或者获得的价值，却基本没有变化，这也可能说明你陷入了空转状态，需要进一步查清楚到底是怎么回事。

不过，很多人没有直接的计量数据，因为他们没在使用这些工具，或者没有管理员权限，而这可能才是大多数普通用户的情况。

对他们来说，可能就得使用一些间接指标。

你可以直接把自己负责的所有自动化任务和定时任务列出来，然后问问自己，其中哪些任务上周带来了业务价值。

如果你不知道，那它就是一个可疑对象。

另外，也要关注你的配额。

如果你每周的配额消耗得特别快，尤其是和同一套配置里的其他人，或者和类似岗位的人相比特别快，那可能说明这里有些地方做得不对。

如果你用的是企业版套餐，管理员至少可以看到你的消耗量，通常也能看到输入输出情况。

你直接问他们就行。

你可以查看的地方其实很多。

在 Claude Code 里，还有像 /context 和 /usage 这样的专用命令。

现在 Claude Code 和 Cursor 里也都有应用内可视化功能，你可以直接点击 usage meter，看看具体情况。

所以，不管这些信息对你来说有多明显，你都应该给自己的花费设一些上限，不要任由账单一直往上累积；如果消耗量突然大幅增加，也要设置提醒。

这可能说明你的系统出了什么问题。

以上就是识别空转的方法。

现在来说说我们都该养成哪些习惯，才能管好自己的 tokens。

这些都是任何人马上就能做的几件事，通常都能改善 token 消耗，而且不会降低业务价值。

新任务就开一个新 session。

这一点挺有意思的，因为我们等会儿也会聊到 model router，不过至少就现在来说，大多数情况下，你要有意识地决定什么任务该用什么 model。

有时候其实是要往上用到像 Opus，甚至 Sonnet 这一档的 model，因为它们一次就能把事做完，整体反而更省钱。

但另外一些情况下，就别用 Sonnet 去做 web search 了，而是换成 Haiku 或者更便宜的 models。

让你的 context 大小合适。

把 AI 需要知道的信息告诉它。

这就是很典型的 Goldilocks 原则，不要太多，也不要太少，而是要刚刚够，让它不用为了搞明白你在说什么，就陷入没完没了的内部 reasoning token 循环。

建立可复用的能力。

很多时候，我们只是随手跟 model 互动，临时拿来用，而不是坐下来认真做 skills、做合适的 automation、做合适的 agents，这样其实就是在浪费大量 tokens，因为你得一遍又一遍重新要求这些工具做同样的事。

所以，搭建并设定好合适的系统，往往是你最有效、也最值得用来精打细算 token 的杠杆之一。

还有，能过滤的都尽量先过滤。

告诉它数据在哪些表格行里，项目看板的哪些部分能找到这些数据，在哪些 Slack channels，诸如此类。

你越能把 model 指到正确的位置，最后拿到的结果通常就越好。

最后，还有很多时候，等它一开始干活，我们就会发现这个 model 完全跑偏了。

可能是 model 用错了，也可能是它缺了什么信息。

别让它一直空转。

直接尽早把这个 job 停掉，重新开始，同时搞清楚它到底在做什么。

而这正是那种去看 model reasoning 会特别有帮助的情况，因为这样你就能明白它是不是已经彻底朝错误方向跑了。

所以我的建议是，每次你让 model 开始做一件事的时候，尤其是工作量比较大的时候，都把 thinking 打开，看看它到底是怎么理解你交给它的任务的。

如果看起来它跑偏了，就停下来，把指令改好，而不是放任它继续……所以，这些就是适用于所有人的习惯。

所有人都适用。

还有另外两个你也该考虑的杠杆，而且其中有些还是很新的。

所以，如果你是 Claude Code 用户，你可以用 /doctor 命令。

这个命令基本上不光会检查你机器上过去安装占了多少空间，还会看你的 tokens 是怎么分配的，你有没有过期的 skills、过期的工具配置，以及你的整体 instructions 是不是过长或者彼此重叠。

所以这是 Claude Code 给我们做的一个非常不错的命令，如果你是 Claude 用户，可以直接去执行一下。

如果你不是 Claude 用户，也可以让你的 AI 工具去研究一下 /doctor 命令到底做了什么，然后基本上给你自己的工具照着重建一个，因为这并不算什么特别复杂的事。

它本质上就是替你审计所有系统，然后给你一份结构化报告，里面有明确建议，告诉你哪些东西因为很久没跑过可以删掉，或者哪些东西重复了、过期了、互相矛盾了，这些都可能帮你大幅精简。

至于 routing，现在行业里很多讨论，焦点都放在 model routing 上。

你刚才提到，我记得是今天还是前几天，关于模型路由领域有一些挺有意思的 M&A。

即使你可以使用像 Cursor 的自动路由器，或者其他一些正在出现的解决方案，选择正确的模型，仍然是能带来最高回报的事情之一。

因为即便你的后台有一个路由器，它也不一定总能像你自己那样准确地判断该用哪个模型。

而且很多时候，你现在用的工具里，可能还没有一个足够好的路由器，甚至根本就没有路由器。

对，我觉得我们现在还处在摸索模型路由正确模式的非常早期阶段。

显然，市场上会出现数不清的解决方案。

它们采取的方式都会有一些细微的不同。

企业也在独立进行各种实验，自己搭建系统，在他们训练的定制模型和顶尖模型之间进行路由。

所以现在还没有一种明确统一的方法。

即使之后开始出现一些明确的使用场景和模式，它们也未必适合每个人、每一种使用场景。

我觉得，如果某些软件工程类型的任务先形成了路由规范，那完全不会让我意外，因为这类任务更具确定性，也更清晰，你实际上更容易验证到底成功了没有。

但如果说到更广义的知识工作任务，情况就会复杂得多。尤其是因为，我们现在进行个人模型路由时，很多时候依据的并不是基准测试在测试中给出的结果，而是针对某个具体情境，我们更喜欢某一种回答的具体特点，而不是另一种回答。

所以我还是相信，理解不同模型的能力，并且形成自己的模型偏好，仍然是一件杠杆率非常高的事情，而且在相当长一段时间里都会如此。

我觉得最终的测试就是 GPT-5 自动帮我们路由的那次经历。当时我们这些超级用户，或者说所有不只是偶尔使用的人，都对自动模式给出的结果感到非常沮丧。

我觉得那就是最初的测试：我们想要控制权。即使将来有一个非常优秀的路由器，能处理很多事情，我们可能还是会坚持自己的判断，而且这样做是有道理的。

当然，对于那些也在自己搭建系统的人来说，他们显然还有更多可以调节的地方，比如可以增加缓存，等等。

但对他们来说，底层的运行规律还是差不多的。

也就是说，你拥有的控制权越多，就越能聪明地使用这些模型。

这就是额外的调节手段。

我们聊过那些能够教会模型的 tokens。

到目前为止，我们关注的主要还是如何降低账单。

但在这里，我想坚持做一件正确的事：我们应该保护这些 tokens，因为很多时候，正是你花费这些 tokens，才能换来高得多的回报。

这不只是要把账单往下压，更是要提高我们最终获得的回报。

而且很多时候，要提高回报，我们就需要增加那些能够教会模型的 tokens。

我们说的是两种情况。一种是你教会自己，也就是说，你用三个不同的模型执行同一个任务，从而逐渐形成判断，知道每种任务自己喜欢用哪个模型。另一种是，你用三种不同的方式尝试同一个任务，直到找到效果最好的方法；或者你试验一个新工具，尝试一项新技能或新的自动化，但它没有奏效，于是你再换一种方法。

所以，这些做法通常都会让你从 AI 得到整体好得多的结果。

因此，首先应该保护好这些 tokens。

另外，还有另一面：你在教 AI 了解你是谁，搭建系统，加入更多上下文，让它给出个性化程度高得多的结果，或者更了解组织情况的结果。这些做法几乎总是和你从 AI 得到的价值直接相关，数据也是一样。

我看过一项针对两万名开发者的研究，结果发现，AI 使用量最高的开发者，按最终发布的生产代码量计算，生产力大约是其他人的两倍。

所以很多时候，真正能让你得到更好结果的，恰恰是一个善于探索、聪明地使用工具的用户。

总结一下，你需要做的事情可以分成两方面。

对于个人用户来说，下面这些事情你一定要做。

去看看你是不是有一些不断空转的 tokens。

我敢肯定，我们所有人都有一些闲置的自动化流程。或者更糟的是，有些人可能正在花掉大量 tokens，却没有产生任何业务价值。

养成这六个习惯。

你甚至可以把它们写在便利贴上，提醒自己更高效地使用手头的 tokens。

一定要花时间投入到可复用的能力和更完善的上下文上，这样模型才能更有选择性，并且在真正重要的地方找到相关上下文。

我还希望你们定期审查这些东西。也就是说，要定期回到系统里看看，哪些内容现在已经过时了，或者哪些原本运行良好的自动化流程已经变得过时。

也许你需要改进上下文和指令。

也许你可以根据 Anthropic 最近提出的新建议，删掉一部分指令。现代模型需要的指令应该更少，而不是更多。同时，要确保你保护好学习预算；必要时，去和负责预算的人协商，确保分配给你的 tokens 不会被压缩到几乎没有探索空间。

对于组织来说，要让使用情况变得可见，然后培训员工。因为当管理者和员工看到自己的使用情况时，他们就会更聪明地使用这些工具。但要确保大家不是被鼓励着尽可能少花，而是要聪明地花；同时还要确保预算是按照工作负载和个人来分配的。

如果有人正在为整个团队构建技能、上下文和可复用的能力，那他得到的预算就应该明显高于那些只是把这个工具当成增强版 Google 来用的人。

而且我们一直都要确保预算是分层的。也就是说，在一些组织里，某些团队和个人可以得到明显更高的预算，而其他人可能少一些，不能整个组织搞一刀切。

还要确保每个人都听到类似的内容，或者组织内部培训，教大家如何聪明地使用 tokens，而不是教大家怎么尽可能少花 tokens。同时，也要让大家意识到投资回报率，努力把 tokens 用在那些真正能推动公司发展的事情上。

所以，这些就是给你和你的团队的具体行动建议。

太棒了。

你看，我觉得我们每次在这个节目里聊这些事情时，其实都还处在起点。不过这一次，我觉得尤其像是一个转折点。就姑且用一个不存在的词吧。

我们显然才刚刚开始弄清楚，应该如何组织人与他们将要消耗的算力和智能之间的关系。

而且这个过程一定会不断迭代，也会很混乱。所以我觉得，你刚才分享的很多想法，都是以框架、以可以进一步探索的模式来呈现的，对吧？

这是一套你可以采取的步骤，帮助自己掌握这些问题。但一开始，每个组织能不能解决这些问题，以及会用什么方式解决，都会各不相同。

所以，谢谢你分享这些起点。随着我们继续前进，这场对话也会不断发展。

谢谢。

毕竟，我们身边的工具也在不断变化。