Uber 的 CTO 最近透露，公司仅 2026 年初几个月就耗尽了全年 AI 预算——AI 编码工具（尤其是 Claude Code）的使用量远超预期，迫使公司"回到绘图板"重新规划预算。
我不认为这是 Uber 特有的失败。我认为这是企业成本曲线的早期预演。
Tokenmaxxing：当 AI 使用量变成账单
工程领域只是账单最先变得可见的地方。编码智能体长时间运行，检查大型代码库，编辑文件，测试，审查，重试，有时还会生成其他智能体。同样的模式将蔓延到销售、支持、财务、法律、客户成功、招聘、运营——每一个智能体开始实际工作的流程。
这个词已经存在：Tokenmaxxing。
Built In 将其定义为：通过自主智能体最大化 AI 使用量，尽可能消耗更多 Token，尤其是围绕 Claude Code 和 Codex 等工具。
TechCrunch 提出了更尖锐的批评：Token 预算衡量的是输入，不是输出。将 Token 消耗视为生产力是一种奇怪的衡量工作方式。
我部分同意。燃烧 Token 不等于创造价值。但 Tokenmaxxing 并不愚蠢。它是对有用 AI 的第一个理性反应。如果工程师可以通过运行 Claude Code 更快交付，他们就会运行 Claude Code。如果支持代理可以通过 AI 解决更多工单，公司就会推动更多工单通过 AI。
Airbnb 表示其 AI 客户支持智能体解决了 40% 的问题而无需人工升级，Brian Chesky 将 AI 智能体描述为为公司提供了更多的软件构建能力。
所以我认为有用的答案不是"使用更少的 Token"。那感觉就像告诉 2012 年的公司少用云。在削减使用之前，先问问这些 Token 买到了什么。
好的燃烧 vs 坏的燃烧
一次好的运行将 Token 用于推理、写作、测试、审查和验证。一次坏的运行将 Token 用于重建组织已经拥有的上下文。
模型读取代码库以理解为什么存在某个迁移。它搜索工单以找到客户约束。它阅读 Slack 以重建争论。它扫描文档以发现决策。它重新阅读另一个智能体昨天阅读过的同一份转录文本，然后另一个智能体明天做同样的事情。
那是假装成智能的 Token 支出。模型在那个循环中没有变得更聪明。它在反复支付，以重建任务周围缺失的状态。这就是 Tokenmaxxing 的极限：你可以购买更多尝试，但你无法永远用蛮力绕过糟糕的上下文。
Contextmaxxing：从"用多少"到"给什么"
Contextmaxxing 从一个不同的问题出发。不是问可以使用多少 AI，而是问在 AI 行动前可以放置多少正确的上下文。
这很重要，因为 AI 系统的价值受其接收上下文质量的限制。一个拥有出色上下文的普通智能体，通常会击败一个拥有陈旧、部分或错误上下文的伟大智能体。
在公司内部，困难的部分很少是一般推理。困难的部分是了解组织的当前状态。
谁拥有决策权？向客户承诺了什么？哪种方法已经失败了？哪些文档已经过时？哪次会议改变了计划？哪些工单与路线图矛盾？哪些支持问题现在是续订风险？哪些代码路径存在是因为没有人记得的客户约束？
更多 Token 可以帮助模型搜索这些答案。更好的记忆在搜索开始前就给模型这些答案。
不是塞满，而是精准
Contextmaxxing 并不意味着塞满尽可能大的提示词。那只是穿着不同服装的 Tokenmaxxing。
Contextmaxxing 意味着最大化每个 AI 行动的相关、授权、有证据支持的上下文。
"相关"这个词很重要。正确的上下文不是一切。它是手头任务相关的先前决策、约束、所有者、失败尝试、开放问题、承诺、矛盾和有来源证据。有时那是 500 个 Token。有时是 5,000 个。有时是一个图查找、一个时间线、一个客户追踪、一个决策追踪，或一个智能体可以推理的紧凑状态对象。
记忆成为经济基础设施
在这个世界里，记忆成为经济基础设施。没有它，每个智能体从零开始。它燃烧 Token 询问公司是谁、知道什么、决定了什么，以及为什么当前任务重要。有了记忆，智能体从状态开始。它可以将 Token 用于判断、执行和验证，而不是重新发现。
Sentra 的语义文件系统正是为此而构建。我们不是试图创建更大的提示词。我们试图将公司的交互、文档、工单、会议、代码、客户对话和行动连接成一个语义层，可以为任务生成正确的上下文包。在早期工作流中，我们看到类似任务的上下文 Token 使用量下降了 50% 到 98%。在某些情况下，相关上下文可以用数百个 Token 而不是数万个来表示。
我不关心压缩本身。智能体不应该花费昂贵的认知去记住公司已经知道的东西。
文件记忆系统的浪潮
最近的文件记忆系统浪潮出于同样的原因而重要。
Andrej Karpathy 的 LLM Wiki 认为，LLM 不应该在查询时检索原始文档，而应该增量构建和维护一个随时间编译知识的持久 Wiki。
Garry Tan 的 GStack 将 GBrain 描述为 AI 智能体的持久知识库，一个智能体跨会话保持的记忆。
更广泛的第二大脑世界多年来一直围绕同样的直觉：Obsidian 围绕本地 Markdown 笔记、笔记之间的链接和图视图构建，帮助人们看到自己知识中的关系。
这些模式对个人来说非常出色。创始人、研究人员或工程师可以维护个人 Vault 并从中获得巨大价值。将这种模式扩展到企业是一个不同类别的问题。记忆不再是一个人的私人上下文。它必须在组织内共享，连接到实时系统，按角色授权，以来源为基础，随工作变化更新，并且对智能体读写安全。
从遗忘的几何学出发
我们从不同的方向得出了相同的结论。
在《遗忘的几何学》中，我们认为遗忘可以从基于相似性的检索的几何学本身产生，而不仅仅来自生物硬件。
在《意义的价格》中，我们认为语义记忆系统面临结构性权衡：按意义组织能够实现泛化，但它也会产生干扰、遗忘和错误回忆。
这些观点指向相同的架构：查询时的 RAG 是不够的。记忆必须被编译、结构化、维护、授权，并在智能体行动前可用。
讽刺的是，上下文窗口正在变大的同时，这变得更加紧迫。人们假设更大的上下文窗口解决了问题。它们没有。它们使向模型倾倒更多无关材料变得更容易。瓶颈从"我能装下吗？"转移到"什么属于这里？"
云的教训
云教会我们，更便宜的计算不会消除支出。它创造更多使用。Token 也会发生同样的事情。即使 Token 价格下降，智能体使用也会更快扩展。
出路不是更小的 AI。而是更好的上下文纪律。
下一个有用的指标不是使用的 Token。而是每个 Token 的有用上下文，或每个 Token 的验证结果/工作。学会这一点的公司不会简单地要求员工使用更多 AI。它们会构建系统，使每个 AI 行动更接近真相。
Tokenmaxxing 是 AI 原生工作的第一阶段。它证明了当 AI 有用时，人们会积极支出。Contextmaxxing 是下一阶段。它问这些 Token 是否指向正确的现实版本。
赢家不会是使用最多 Token 的公司。它们将是浪费最少 Token 去记住已经知道的东西的公司。