为什么你应该烧掉更多 Token

原文：https://every.to/context-window/why-you-should-burn-more-tokens

Every 的 CEO Dan Shipper 消耗的 token 是公司里第二高用户的三倍还多。这个差距让他感到不安：我们其他人是不是因为想得太小，才把 AI 账单压得这么低？

Dan 说，低 token 消耗本身不一定是问题，“但它应该是一个烟雾信号，尤其是在工程团队里——它提醒我们：‘也许我们这里还能做更多的事。’”

Every 的 OpenAI token 排行榜。（截图由 Laura Entis 提供。）

目标并不是 tokenmaxxing——为烧 token 而烧 token，把它当成运动项目。Dan 想做的，是给人们空间去尝试激进的新策略和工作方式；这些尝试一旦跑通，带来的生产力提升将远远超过 token 成本。

在与平台负责人 Willie Williams 的一次对话中，他们定下了一个具体的起点：先找出工程团队的主要瓶颈，看看 AI 能否消除它们，然后才做成本收益分析。

Inside Every

前沿团队里的 token 预算

Dan 不为实验设定统一的支出上限。相反，在一次昂贵的运行之后，他期望团队自问：这次结果值得花的钱吗？下次能不能用更低的成本得到相近的结果？一次昂贵的实验，如果揭示了有用的新能力或新限制，那就是值得的；而收益平平的实验，只有在能以更低成本复现时，才值得继续投入。

运营负责人 Arielle Shipper 把这套理念转化为支出决策。目前，她对昂贵运行逐案评估，用结果来决定是继续资助这项工作，还是调整方向。

她的预警系统是公司信用卡。她把 ChatGPT 的自动充值金额维持在 500 美元——每次卡被充值，她都会收到一条 Slack 推送通知，而一天里这种情况会出现多次。如果扣款异常密集地接连发生，就说明有人正在搭建或测试一个大项目，这促使她去查看用量排行榜，并联系排在最前面的那几个人。

“然后 Dan 总会回复说，‘是我在跑 Ultra，’”她说。这也解释了为什么他稳居排行榜榜首。

常见的一幕。（截图由 Laura Entis 提供。）

她想要三个问题的答案：这次运行花了多少钱？给我们换来了什么？我们又学到了什么？

Every 正在把这些问题嵌入自己的基础设施。团队正在开发一项技能，让员工能够创建并分享自己的 AI 支出损益表；而评估负责人 Mike Taylor 正在为每位员工创建个人基准测试，用来显示哪些模型——包括那些不那么流行、更便宜的模型——能够处理我们许多重复性任务。目标是在不打击雄心勃勃的实验的前提下，让支出和模型选择变得更加透明。

团队里很多人已经在主动回答这些问题了。在一连串 Astra 实验烧掉数十亿 token 之后，视频负责人 Randy Counsman 给 Arielle 发了消息，详细说明哪些行得通、哪些行不通、他学到了什么——而学到的非常多。

数据点

45 亿

这是 Randy 为了用 Astra 给他自己的脸做一个 3D 模型而烧掉的 OpenAI token 数量。

这个项目一开始相当无害：受社交媒体上那些用免费 3D 工具 Blender 制作的炫酷 AI 生成演示的启发，他也想自己做一个 3D 模型。毕竟，试验 AI 是他工作的重要一部分。

他使用X 上分享的策略，搭建了一个负责维护计划的编排 agent、一个负责任务分配的实现 agent，以及负责执行任务的子 agent，并指示 Codex 不断改进模型，直到它“完成得极好”，Randy 说。回过头看，“这是一个模糊的目标。”这是他当时的 prompt：

    Prompt

    你是一个管理者 agent。创建一份详细的待办清单。把这份清单交给实现 agent。部署一个实现 agent，其 /目标 是在 Blender 中极好地重现这张图片，然后它应该接着部署子 agent，其 /目标 是检查各项单独任务。
    我想要一个头部/肩部的模型，用四种截然不同的着色器渲染——spiderverse、照片级写实、复古黑色电影（vintage noir）和双色调（duotone）。在开始实现任何着色器之前，先部署一个 agent 去研究相关信息。边做边沉淀知识——这个任务的一部分使命，就是在该 repo 中沉淀知识，包括着色器风格方面。
    还应该部署一个评判 agent，根据需要把修改/反馈发回给管理者 agent。管理者随后按需把新任务发给实现 agent，直到完成得极好。

然后他就让模型跑了起来。跑啊。跑啊。跑啊。

等他暂停这个项目时，它已经跑了一天半，烧掉了数十亿 token。结果，用他的话说，“非常粗糙（very janky）”。

输出结果，用四种着色器渲染。（图片由 Randy Counsman 提供。）

对他 Codex 会话做的一次 AI 审计显示，他的设置制造了一个极度消耗算力的“无序 agent 群（unruly swarm）”。Randy 让编排 agent“按需”部署 agent，却没有限制数量，还加了一个实现 agent 来给子 agent 分配工作。随着运行继续，这些层级之间来回传递着越来越多的上下文——哪怕只是简单的状态检查，比如确认某个子 agent 是否完成了任务——把 token 烧在了协调上。

Randy 此后重塑了他用于复杂项目的设置。他彻底去掉了实现 agent，把编排 agent 限制为最多五个 Sol 子 agent 以控制成本，现在还会告诉编排 agent 何时暂停并征求他的反馈。在最近的一个项目里，他还生成了自己想要的设计图，这样评判 agent 就能拿模型的工作与一个具体目标对照，而不是遵循那种“不断改进”的开放式指令。

如果一个失败的实验能显示 AI 系统的短板，它仍然是一笔好投资。Randy 现在有了一个可以用来测试新模型的基准——它们能把人物、动物和角色的 2D 图像多好地转成 3D 模型——以及一套更精简的设置，用更少的 token 拿到更好的结果。

在不知不觉中因实验而大量消耗 token，是 Every 的一种成人礼。（截图由 Laura Entis 提供。）

**你也来试试：**挑一个消耗 token 超出预期的 AI 任务，把下面这段粘贴到你选择的 agent 里：

    Prompt

    查看 [任务/项目] 在 [日期范围] 内可用的会话历史和 token 使用记录，包括任何子 agent 会话。
    我当时想做 [目标]。结果是 [实际发生了什么]。帮我理解 token 都花到哪去了，以及下次我可以怎么做不一样。
    在记录允许的范围内，按活动和模型拆解使用情况。
    寻找重复劳动、不必要的状态检查，以及 agent 之间传递的大量上下文。给出具体例子。
    区分必要工作和可能的浪费。不要想当然地认为高用量或缓存输入就是浪费。
    针对我的指令、模型选择或 agent 设置，推荐三个最有用的改动。
    如果你无法访问需要的记录，告诉我需要提供什么。

偷走这套工作流

别拿 Fable 去做 Sonnet 的活

Spiral 总经理 Marcus Moretti 的 token 支出策略很直接：把自己的 Claude Code Max 套餐控制在每周用量限额之内。

这是一个简单目标，但需要主动管理；Marcus 会把工作有选择地分配给 Fable 5.1 或更便宜的模型。

第 1 步：了解每个模型擅长什么。 Marcus 使用 Anthropic 的模型已经足够久，能判断一项工作到底需要 Sonnet、Opus 还是 Fable 级别的智能。

第 2 步：把模型和任务匹配起来。 基础任务——比如分析数据检查——交给 Sonnet。目标清晰的工作，比如范围明确的产品改动，交给 Opus。对于更大的功能（比如他正在做的新计费实现），Marcus 用 Fable 5.1 来明确要构建什么、以及它该如何运作。

第 3 步：对于复杂工作，让模型去委派。 计划一旦就绪，Marcus 会加上下面这条指令——这是他在独立开发者 Simon Willison 发帖谈到之后开始使用的 prompt：

    Prompt

    “开始吧，对于所有编码任务，用你的判断决定是否委派给更低一级的模型。”

Fable 把任务分配给 Opus 和 Sonnet，然后检查它们的工作。这让最强的模型管理项目，而不必亲自执行每一项任务。

**这周就试试：**选一个重复性任务，用一个比你平时更便宜的模型来跑。在把更便宜的模型设为该任务的默认之前，先检查结果是否满足你的需求。

日常主力

团队这周在用的模型：

• Douglas Brundage，市场负责人：更多地把 Fable 5.1 用于视觉工作，另外用 Grok Bot 监控社交媒体，并构建一个做视觉的工具。

• Randy：复杂工作用 Astra（high），基础任务用 medium；语音模式编排用 Sol（extra high），因为他觉得“Astra 对我来说太慢、太蛮力了”。代码相关规划用 Fable，Astra token 用完时用 Opus。

• Kieran Klaassen，Cora 总经理：编码和知识工作用 Fable 5.1（extra high，100 万上下文），部分研究和写作切换到 Astra。

• Tyler Nishida，设计工程师：在 Cursor 中用 Fable 5.1（high）作为项目的协调-编排者，配 Grok 4.6（extra high）子 agent。个人项目用 Astra（ultra）。“它不是一个模型，但 Cursor 项目作为你偏好模型的日常主力非常棒。我的侧边栏非常干净，管理工作也容易多了。”

Tyler 的 Cursor 设置。（图片由 Tyler Nishida 提供。）

• Katie Parrott，特约撰稿人：“Astra 的热度对我来说已经退了，”她说。如今她回到 Sol（high）做任务管理，并切换到 Claude 模型来写作，因为她觉得 Sol 和 Astra“太平——它们只是陈述事实，而不是塑造一个能把读者带进去的叙事。”

• Natalia Quintero，咨询负责人：Astra（medium）。

• Yash Poojary，增长工程师：Astra（high）和 Fable 5.1。

• Arielle：Sol（medium）。“Sol 永远。SOLoyalist，”她说。

• Loren Stewart，工程师：为了降低成本，编码从 Astra 降级到 Sol（medium），效果不错。Fable 5.1“依然是最佳思考伙伴”。

Laura Entis 是 Every 的特约撰稿人。想读更多这样的文章，请订阅 Every，并在 X 上关注 @every，在 LinkedIn 上关注我们。

核心启示：低 token 消耗本身不一定是问题，但它是一个“烟雾信号”，提醒你别因为想得太小而错失机会；真正的目标不是为烧而烧，而是通过有策略的实验去发现 AI 能消除的瓶颈——只要你能对每次昂贵运行回答“花了多少钱、换来了什么、学到了什么”，那么即便结果失败，它也可能是一笔划算的投资。