Token 经济学：从成本优化到思维方式革新

使用认知流水线，让调试更轻松

今天我看到一个视频，先是笑了出来，然后又有点担心。

那是一个看似玩笑、实则不完全是玩笑的段子，因为你已经可以想象，六个月后真会有某家公司这么做。视频里，一位经理基本上是在抱怨某位员工消耗的 AI token 不够多。token 不够多。仿佛 token 是健身追踪器上的步数。

“你今天才消耗了 2,000 个 token，Susan。你到底有没有在工作？”

这听起来很荒谬，但我们离这种情况并没有那么远。公司已经开始通过提示词数量、工具调用次数、输入 token、输出 token、单个用户成本、单个团队成本和单个工作流成本来衡量 AI 的采用情况。需要说明的是，我并不认为这样做必然是错的。衡量 token 使用量是合理的。token 意味着成本。token 意味着延迟。token 意味着上下文。它们也是人和系统如何使用 AI 的一种痕迹。

当我们混淆指标与目标时，问题就开始了。我们曾经用工作时长犯过这种错。曾经用已关闭的工单数犯过这种错。曾经用参加的会议数犯过这种错。也曾经用潜在客户数量犯过这种错：1,000 条未经筛选的潜在客户线索看起来比 10 次认真的沟通更漂亮，因为电子表格那天表现得非常出色，而没有人愿意拿现实去破坏气氛。

现在，我们可能会在 token 上重蹈覆辙。

token 更多并不意味着工作更好。token 更少也不意味着工作更聪明。真正值得关注的信号不是原始数量，而是你向模型输入了什么、要求它做什么，以及最终得到了什么，三者之间的关系。我认为，真正的 token 经济正是从这里开始的。它不应成为一种对节省成本的痴迷，而应成为一种架构信号。

token 不只是钱

人们谈论 token 时，首先想到的是成本，这完全可以理解。如果使用托管的 LLM API，token 与金钱之间几乎存在直接对应关系。输入 token 要花钱。输出 token 要花钱。更大的模型更贵。更长的上下文更贵。重试更贵。糟糕的提示词更贵。糟糕的架构则贵得多，只不过问题通常会在更晚的时候出现，并表现得像是可靠性问题。

因此，人们的第一反应是优化 token 消耗：压缩提示词、总结上下文、选择更便宜的模型、缓存响应、减少不必要的输出。这些做法都很有用，但我认为它们只触及了问题的浅层。

更值得探究的问题不是“这个任务消耗了多少 token？”，而是“这些 token 代表了什么认知操作？”

因为输入 token 和输出 token 并不是一回事。输入 token 通常用于购买上下文，也就是你要求模型查看的材料。输出 token 通常用于购买生成、解释、结构化、综合或行动。如果我向模型发送了 10,000 个输入 token，却只得到 10 个输出 token，这可能非常糟糕，也可能恰到好处。

如果任务是读取一份很长的错误日志，并判断故障是否由身份验证引起，那么极短的输出可能完全合理。如果任务是将一条产品评论分类为正面、中性或负面，那么简短的答案并不意味着失败，而正是任务的目标。如果任务是把一份 bug 报告分派到正确的工程队列，我不需要一部长篇小说，只需要正确的分派结果。

所以，高输入、低输出并不一定是坏事。但它是一种信号。而我认为，这种信号值得获得远比目前更多的关注。

平衡并不意味着对称

当我谈论 token 平衡时，并不是说输入 token 和输出 token 应该相等。那会是一个非常愚蠢的指标，而我们已经有太多愚蠢的指标在假扮管理科学了。

所谓平衡，是指输入规模、输出规模与最终决策价值之间的关系。大输入配小输出，通常意味着模型正在执行某种压缩、分类、提取、路由、过滤、审核、评分、验证或决策。小输入配大输出，通常意味着模型正在执行生成、扩展、解释、起草或构思。大输入配大输出，通常意味着综合、转换、总结、比较或多步推理。小输入配小输出，通常是一个范围狭窄的原子任务。

这些模式本身并无好坏之分。它们会告诉你工作的形态。有时，这种工作形态几乎是在尖叫。

想象一下，你发送了一段巨大的提示词，其中包含完整的会议记录、产品描述、使用日志、bug 报告、五个示例、一份 JSON schema、语气指南、安全说明，以及最后一句“保持简洁”——显然，我们很享受这种讽刺。然后，你要求模型返回：

{
  "priority": "high"
}

这或许没问题。这个分类可能确实需要所有这些上下文。但也有可能，你只是造了一台认知洗衣机，用来清洗一把勺子。

重点不在于 token 比率是错的，而在于这个比率会引出一些问题。这个任务真的需要所有这些上下文吗？能否更精准地检索上下文？能否将分类与提取拆开？能否让较小的模型完成部分工作？能否让确定性规则承担其中一部分？能否单独验证最终输出，而不是完全信任一次巨大的模型调用？

这正是 token 指标发挥价值的地方。它不是计分板，而是一种诊断工具。

真正的问题是认知过载

许多 AI 工作流成本高，并不是因为模型昂贵，而是因为任务设计混乱。我们要求一次模型调用同时完成太多事情，然后又在模型表现得像一个聪明绝顶的实习生时感到惊讶——这个实习生在一条消息里收到了八张相互矛盾的 Jira 工单。

阅读这段很长的输入。理解这个领域。提取二十个字段。将它们标准化。推断缺失值。遵守 schema。应用业务规则。避免幻觉。解释你的决定。保持简洁。保证确定性。另外，请在一次调用中全部完成，因为我们曾经看过一个演示，所以现在认为架构就是一份提示词模板。

事情正是在这里变得脆弱：一个巨大的提示词，一个巨大的模型，一份脆弱的 JSON 输出；失败后进入一个重试循环；凌晨 1:12，一位恼火的工程师盯着一个格式错误的逗号，开始怀疑自己当初为什么要学习数据结构。

问题不只是成本，而是推理表面太大了。每增加一条指令，都会增加模型的自由度。每加入一段无关的上下文，都会增加噪声。每多增加一个输出字段，格式漂移的概率就会提高。字段之间每多一项隐藏依赖，验证就会变得更加困难。而当输出失败时，你往往不知道原因。

是上下文太长吗？是指令有歧义吗？是 schema 太复杂吗？是任务在逻辑上过载了吗？是模型能力太弱吗？还是模型太有创造力了？是水星逆行了吗？到了某种程度，调试一个巨大的提示词开始像是在调试一场梦。

因此，我认为优化的基本单位不应该是提示词，而应该是认知任务。

不只是更便宜，而是思考得更小

人们听到“token 经济”时，往往会想到省钱。我认为这并不完整。更好的表述是：设计 AI 工作流时，应让每次模型调用都具有尽可能小且合理的认知表面。

不是最短的提示词。不是最便宜的模型。而是最小的认知表面。

当一个任务要求模型考虑一定数量的上下文、做出某种类型的判断并生成某种类型的输出时，它就具有一个认知表面。一个宽广的认知表面可能是这样的：阅读一段对话，推断用户的情绪状态，识别所有行动项，对销售机会进行分类，提取异议，评估紧迫性，总结通话内容，生成后续跟进邮件，并返回一个包含 28 个字段的完美 JSON 对象。

这不是一个任务。这是一座小村庄。

范围更窄的认知任务则有所不同。比如：给定产品反馈讨论中的这段内容，判断用户是否提到价格是一个阻碍因素，并返回 true 或 false。或者，只从这段文本中提取下次会议的日期，如果不存在则返回 null。又或者，给定这三个已经提取出的信号，从 low、medium 或 high 中选择优先级。

这些任务的输入更窄，输出也更窄。它们更容易验证，也更容易重试，通常还可以在更小的模型上运行。其中一些甚至可以由确定性代码替代。最重要的是，它们减少了歧义。

这才是关键所在。最好的 token 优化并不总是压缩。有时，最好的 token 优化是拆解。

20 字段 JSON 问题

举个简单的例子。你有一份很长的输入文档，需要输出包含 20 个值的结构化结果。显而易见的现代 AI 做法是：把整份文档发送给模型，让它将所有内容提取到一个 JSON 对象中。加上 schema，加上“不要产生幻觉”，加上“未知时使用 null”，也许再加三个示例，然后期待模型乖乖照做。

有时这确实有效。有时在演示中效果甚至非常好。然后，生产环境穿着靴子登场了。

模型漏掉了一个字段。它编造了一个值。它把两个字段混在一起。它返回了无效的 JSON。它遵循了 schema，却把错误的值放进了正确的位置——这反而更糟，因为看起来是对的。它还会在字段里解释自己的答案，仿佛 JSON 也需要表达情感。

于是你添加更多指令。然后使用更严格的 schema 表述。然后增加验证。然后增加重试。然后换成能力更强的模型。然后换成更昂贵的模型。接着有人说：“也许我们应该对它进行微调。”至此，你那条简单的提取流水线已经变成了一个小型国家基础设施项目。

另一种方法，是提出一个枯燥但有用的问题：这 20 个值真的属于同一个认知任务吗？

也许不是。可能有五个字段只需直接提取，三个字段需要分类，四个字段依赖日期，两个字段需要数值归一化，还有六个字段只有在前置条件为真时才有意义。如果是这样，一个大提示词并不更简单，它只是把复杂性藏进了模型调用里。

把字段按照语义依赖关系分组，可能会得到一个更好的系统。例如，直接标识符可以归为一组；日期和时间约束可以归为另一组；风险指标可以单独一组；义务和责任方也可以归为一组。只有在前面的信号都已得到之后，才构建最终的归一化摘要。

每一组都可以使用更短的提示词、更小的 schema 和范围更窄的验证规则。有些组可能根本不需要 LLM，可以使用正则表达式、解析器、查找表、嵌入或确定性检查。有些可以使用小型本地模型。只有真正困难的部分才需要昂贵的模型。

成本节省正是由此而来，但成本只是收益的一部分。你还能获得更好的可观测性。如果最终输出有误，可以检查究竟是哪个子任务失败了。你可以衡量字段级准确率，只重试失败的部分，在不影响其他部分的情况下替换某个阶段的模型，缓存中间输出，还可以在边界处加入确定性验证。

这才是真正的 token 经济。重点不是“使用更少的 token”，而是把 token 用在真正需要认知能力的地方。

更小的提示词可以降低波动

对于“确定性”这个词，我想谨慎一些。即便降低 temperature 并约束输出，LLM 在经典工程意义上也不是真正的确定性系统，而是概率系统。但是，工作流设计可以让它们的行为更加稳定、更可复现，也更可控。

目标更窄的较小提示词，通常能减少模型的自由度。如果模型只有一项任务、输出空间很小，并且有严格的 schema，那么它能够失败的方式就更少。如果模型有二十项任务、庞大的输入、相互冲突的指令、隐含的依赖关系以及复杂的 schema，那么当它偶尔决定像一张闹鬼的电子表格那样表达自己时，你不该感到意外。

这就是任务拆分能够提升一致性的原因。并不是小规模调用能神奇地让模型变得确定，而是因为小规模调用让模型周围的系统更容易控制。输出空间更窄，验证更简单，重试逻辑成本更低，失败模式更容易分类，模型选择也更加灵活，提示词也更容易测试。

而且，编排过程变得明确。

最后这一点非常重要。当一切都发生在一个提示词内部时，整个过程是不可见的。把工作拆分为多个阶段后，这个过程就变得可以检查。这就是期待模型正确思考，与设计一个每一步都可观察的系统之间的区别。

OrKa 在其中扮演的角色

这也是我一直在构建 OrKa 的原因之一。OrKa 是一个面向 AI 智能体和推理工作流的编排框架。OrKa 的目标并不是“因为智能体很酷，所以使用更多智能体”。坦白说，如果增加智能体让你的系统更难理解，那么恭喜你，你发明了分布式困惑。

真正的重点不同：让认知工作显式化。定义流程。把推理拆分成更小的单元。路由任务。记录执行过程。验证输出。控制记忆和上下文。让系统可以被检查，而不是对着一个庞大的提示词祈祷。

从这个角度看，LLM 并不是应用本身，而只是系统中的一个组件。有时 LLM 负责提取，有时负责分类，有时负责改写，有时负责评估，有时根本就不应该调用它。编排层负责决定工作如何在这些组件之间流转。

正是在这里，token 经济上升为架构问题。你不再只是询问如何把提示词缩短 20%，而是询问哪个认知步骤真正需要这些上下文。

这个问题会改变一切。也许第一次模型调用只需要用户消息。也许第二次只需要相关的日志片段。也许第三次只需要三个已提取的字段。也许最终的格式化程序根本不需要模型。如果你把完整上下文发送给每一个步骤，那就不是在设计 AI 系统，而是在复印整个宇宙，然后让模型从中找出发票编号。

它也许能工作，但这算不上策略。

Token 指标应该引发问题

那么，团队应该如何使用 token 指标？不要把它当作生产力监控工具。不要用它羞辱那些使用了太多或太少 token 的人。也不要把它变成排行榜，让提示词数量最多的人赢得某种被诅咒的办公室奖杯。

Token 指标应该引发工程问题。

当输入 token 非常多而输出 token 非常少时，要问这个任务究竟是有意进行信息压缩，还是无意中承载了过多内容。当输出 token 非常多时，要问模型是在生成有用的结构，还是只是在制造昂贵的迷雾。当相同的上下文被反复发送给多个调用时，要问检索、缓存或状态传递能否减少重复。当使用大型模型进行简单提取时，要问小型模型或确定性规则能否胜任。当重试消耗大量 token 时，要问是不是 schema、验证机制或任务边界出了问题。

这并不意味着拆分任务就一定更好。如果为了提取二十个字段，你把同一份包含 10,000 个 token 的输入发送二十次，那么系统可能变得更昂贵、更缓慢。你构建的不是架构，而是一种极其复杂的上下文复制方式。

只有把任务拆分和上下文收窄结合起来，才能真正获益。只提取一次相关片段，复用中间状态，把共享依赖关系的字段聚为一组，只路由必要的上下文，在局部进行验证，尽可能使用更小的模型。当代码能够完成工作时，就不要再调用模型。

这并不是反对 LLM，而是支持系统化设计。

一个简单的思维模型

这是我反复使用的思维模型：输入 token 是注意力预算，输出 token 是承诺面。

提供的输入越多，模型需要关注的内容就越多。要求的输出越多，模型发生偏移的机会就越多。当注意力预算和承诺面与实际认知任务相匹配时，工作流会更加稳定。

如果模型只需要对一件事进行分类，就不要同时要求它进行摘要、提取、解释、归一化和复杂对象格式化。如果模型需要生成一篇长回答，就不要向它塞入只会增加噪声的无关上下文。如果模型需要提取结构化字段，不要假设所有字段都应该放在同一次调用中。如果模型需要做出决策，就明确决策边界。

目标不是使用最少的 token，而是将不必要的认知降至最低。

这一区别非常重要。有些任务理应消耗大量 token。长篇研究综述可能需要大量上下文。技术事故摘要可能需要谨慎保留信息来源。产品比较可能需要很长的输入和输出。多文档比较的成本也可能本来就很高。

问题不在于花费 token，而在于你根本不知道花出去的 token 买到了什么。

这也是一个模型选择问题

一旦拆分了认知任务，模型选择就会变得有趣得多。在单一提示词架构中，通常会选择预算范围内能力最强的模型，因为任务本身非常混乱。模型必须处理所有事情：阅读长上下文、推理、提取、格式化、验证，还要从歧义中恢复。

但如果你将工作流分解，你可以为每个认知步骤选择不同的模型。小模型可以做简单分类。本地模型可以提取明显字段。确定性解析器可以规范化日期。规则引擎可以验证约束。更强大的模型可以处理真正模糊的推理。

这就是经济效益改变的地方。不是因为你乞求提示词变短，而是因为你改变了工作的形态。昂贵的模型变成了专家而不是垃圾填埋场。

我知道"垃圾填埋场"听起来很刺耳。但今天许多 AI 系统正是这样。它们把所有上下文扔到一个地方，希望最大的模型能把它回收利用成有用的东西。这种方法出奇地经常有效，这正是危险的地方。它足以发布演示版本。它足以在生产中给你惩罚。

令牌经济即可观察性

一个成熟的 AI 系统不仅应该记录最终响应。它应该记录工作流的令牌形状。

哪一步消耗了最多输入？哪一步产生了最多输出？哪一步重试最多？哪一步出现了最多 schema 错误？哪一步需要最强大的模型？哪一步可以被缓存？哪一步可以被代码替换？哪一步实际上改进了最终决策？

这不是会计。这是可观察性。

你不仅在追踪支出。你在追踪系统内的认知压力。输入令牌的突然增加可能意味着你的检索引入了过多上下文。输出令牌的突然增加可能意味着模型开始解释而不是结构化。高重试成本可能意味着你的 schema 太复杂或提示词模糊。低价值决策的高令牌成本可能意味着工作流需要分解。低令牌成本但质量差可能意味着你压缩掉了必要的上下文。

再次强调，指标不是答案。指标是信号。工程师仍然需要判断力，这很不方便。我们被承诺了自动化，但我们仍然需要思考。太粗鲁了。

不好的未来很容易想象。团队获得 AI 仪表板。经理看到每个员工的令牌使用量。人们被鼓励"更多地使用 AI"。令牌消耗成为采用的证明。员工学会生成更多提示词，因为仪表板奖励活动。每个人看起来都很高效，成本上升，质量却没有。

然后领导宣布了一项 AI 效率倡议。现在每个人都必须减少令牌使用。人们使用更小的提示词。质量下降。没人知道为什么。创建了另一个仪表板。出现了一个顾问。生命循环继续。

这就是当指标变成目标时会发生的事。令牌使用本身几乎不能告诉你任何关于质量的信息。一个伟大的工程师可能使用更少的令牌，因为他们正确分解了问题。另一个伟大的工程师可能使用更多的令牌，因为任务确实需要上下文。一个坏的工作流可能使用很少的令牌而产生垃圾。一个好的工作流可能使用很多令牌而产生高价值的决策。

所以测量令牌没有错。按原始令牌量判断工作是错误的。

更好的未来更乏味，在工程中通常是好兆头。团队将令牌指标视为工作流诊断。他们查看输入-输出模式。他们识别过载的提示词。他们在有意义的地方分解任务。他们更仔细地路由上下文。他们为较小的认知任务使用较小的模型。他们分别验证结构化输出。他们测量重试、漂移和故障模式。

他们不问"你用了多少 AI？"他们问"AI 实际上在哪里增加了决策价值？"

这就是思维转变。令牌不仅仅是账单。令牌是认知架构的痕迹。它们显示系统在哪里膨胀。它们显示上下文在哪里重复。它们显示输出在哪里过于雄心勃勃。它们显示模型在哪里被用作胶水，因为没有人想设计管道。是的，有时它们显示昂贵的模型实际上是合理的。

没关系。目标不是让一切都便宜。目标是让系统诚实。

我认为 AI 工程的下一个阶段不会是关于谁写了最聪明的提示词。它将是关于谁设计了最清晰的认知管道。

提示词不是架构单位。认知任务才是。

令牌平衡很重要，因为它给我们一种方式来检查该任务。不完美。不自动。不是作为惩罚或奖励人的 KPI。而是作为一个信号，说："也许这个工作流被过载了，也许这个上下文太宽泛了，也许这个输出试图做太多事，也许这个模型比需要的更强大，也许这个任务应该被分解，也许这个步骤根本不应该使用 LLM。"

这就是真正的令牌经济所在的地方。不在于花更少的令牌，而在于在需要关注的地方花费关注。

如果我们做得好，好处超越成本。更低的延迟。更小的模型。更清洁的验证。更少的格式漂移。更稳定的输出。更可检查的工作流。更接近工程的系统，更不接近对一个非常昂贵的自动完成机器倾诉愿望。

说句公道话，这仍然很有趣。

但也许不是我们应该建立生产系统的未来。