Token 预算作为产品约束：围绕上下文限制进行设计，而不是假装它们不存在

大多数 AI 产品将上下文限制视为一个对用户隐藏的实现细节。这种决定在演示中看起来很简洁，但在生产环境中却是灾难性的。当用户在执行任务中途达到上限时，通常会发生以下三件事之一：请求抛出硬错误；模型因为丢失了关键的早期上下文而悄悄开始产生幻觉；或者产品重置会话并销毁所有积累的状态。对于一个你要求人们在实际工作中信任的产品来说，这些结果都是不可接受的。

Token 预算并不是一个可以敷衍了事的怪癖。它是一个核心产品约束，应该像内存限制在系统编程中那样，被纳入你的设计流程。交付可靠 AI 功能的团队已经不再假装这个天花板不存在了。

你可能没有在衡量的失败模式

上下文失效具有欺骗性，因为它们看起来往往像是模型质量问题。当一个多步 Agent 在执行长任务的中途开始做出错误决策时，通常的假设是出现了幻觉或提示词写得不好。但实际发生的情况往往更简单：早期的工具执行结果或用户指令已从上下文中丢失，而模型正在基于残缺的信息完成任务。

这就是级联失效模式。Agent 流水线中的每一步都依赖于前面步骤积累的状态。当旧的条目为了给新条目腾出空间而被移出上下文窗口时，后续步骤就会基于不完整的画面做出决策。输出看起来依然连贯——模型并不会提示它缺失了信息——但它是基于过时或缺失的上下文生成的。

“迷失在中间”（lost in the middle）的研究证实了一个相关问题：甚至在达到硬性 Token 限制之前，模型性能就会随着输入长度的增加而下降。注意力集中在上下文窗口的开头和结尾。处于长对话中间的信息获得的处理可靠性较低。即使你在 Token 限制之内，也可能正在经历由上下文驱动的质量下降。

静默退化是最危险的失败模式，因为如果不进行专门的埋点监控，你就无法观察到它。使用短输入的测试环境运行良好。而生产环境的输入——长邮件链、多文件代码库、长时间对话——会触发悄然发生的失效，这些失效表现为输出质量的不稳定，而不是明确的错误。

优雅降级真正需要的是什么

优雅降级并不等同于压缩。压缩是管理上下文压力的一种策略。优雅降级是更广泛的设计目标：确保随着可用上下文的缩小，产品的行为以一种可预测、可恢复且用户可见的方式降级，而不是静默失效或导致灾难性后果。

渐进式截断是最常用的方法，它有三种形式，各有优劣：

滑动窗口保留最近的 N 次交互并丢弃旧的。它实现简单且行为可预测。其失效模式是丢失关键的早期上下文——用户的原始任务说明、对话开始时确立的关键约束，或者后续步骤所依赖的早期工具结果。语义相似性变体通过保留与当前上下文最相关的交互（而不仅仅是最近的交互）来改进这一点。

摘要通过 LLM 调用将较旧的对话历史转换为压缩摘要，然后用摘要替换原始历史。这比滑动窗口保留了更多的语义内容，但引入了延迟（每次出现上下文压力时都需要额外的 LLM 调用）和保真度损失——摘要会丢失以后可能很重要的具体细节。ConversationSummaryBufferMemory 结合了两者，它保留最近的交互原文，仅对超过阈值的部分进行摘要，这对大多数用例来说比单纯的摘要更实用。

选择性丢弃保留系统提示词和最高优先级的内容，同时丢弃优先级较低的材料——通常是那些最不可能被未来推理所需要的最近助手消息。这需要明确的优先级逻辑，并根据你的具体工作负载仔细思考“优先级”的含义。

没有任何策略能保留所有信息。每种策略都涉及有原则的有损权衡。正确的选择取决于你的工作负载是对丢失早期上下文（规格、约束）还是近期上下文（工具输出、积累状态）更敏感。

将上下文压力作为 UI 信号呈现

大多数产品只在特定时刻呈现上下文限制：当错误发生时。那是糟糕的时机。到那时，用户的上下文中工作可能已经无法挽回——你无法重建刚刚被截断的对话历史。

更好的设计模式是带有分级升级机制的持续压力信号。Claude Code 的实现提供了一个参考点：它在整个会话过程中呈现 Token 预算状态，而不仅仅是在达到限制时。在可用预算约 70% 时发出第一次警告。85% 时发出第二次警告。90% 时，它要么触发自动压缩，要么干净利落地停止并发送消息，给用户留出保存状态的时间。

这种模式之所以奏效，是因为它在危机发生前赋予了用户自主权。看到 70% 警告的用户可以决定结束当前的对话链、在后续消息中总结进度，或者使用聚焦的延续提示词开启新会话。而遇到硬重置的用户则没有这些选择。

UI 不需要展示原始的 Token 计数。大多数用户对“87,000 个 Token”在对话中意味着什么没有精准的概念。他们能够理解的是功能容量：他们还可以添加多少个文件，在大约多少次交互后需要开启新对话，当前的上下文是否包含他们在会话开始时指定的信息。用功能性术语而不是原始数字来展示约束，可以为用户提供一个可行的心理模型，而不会产生认知负荷。

仪表盘式的监控对于在 AI API 上构建应用的运营者和开发者非常有用。跟踪每个请求、每个用户和每个工作流的 Token 消耗可以识别成本瓶颈，并发现产品的哪些部分产生了最大的上下文压力。这与面向用户的信号不同，但两者都很重要。推理前 Token 计数——通过 Amazon Bedrock 的 CountTokens 端点等 API 提供——可以实现成本预测，并在请求到达推理服务器之前进行主动的频率限制管理。

隐藏还是展示的抉择

在产品设计中，经常会有一个争论：是否应该向用户展示限制。支持隐藏的观点认为：这可以降低认知负荷，减少决策点，并营造出系统能力更强大的错觉。让产品感觉像魔法一样。

反对的观点则认为：隐藏限制并不会让它们消失。它只会让故障在变得灾难性之前处于不可见状态，阻碍用户建立对系统能力的准确心理模型，并在魔法最终破灭时侵蚀信任——而这总会发生，因为每个系统都有极限。

在实践中行之有效的解决方案是策略性暴露：隐藏实现细节，暴露功能约束。不要展示 token 计数。但要在系统接近某个有意义的限制时予以展示，说明达到限制后会发生什么，以及用户可以做些什么。

这与存储系统的工作原理类似。你的手机不会将“剩余字节数”作为主要信号。它会显示“已使用 12 GB 存储空间，剩余 3 GB 可用”，并在空间不足时发出警告，并提供清理空间的清晰路径。底层实现被隐藏了；功能约束则是可见且可操作的。

最糟糕的情况是两者皆非——产品隐藏限制直到引发错误，然后弹出一个没有任何上下文且没有恢复路径的原始错误消息。这是当今 AI 产品中最常见的模式。

长上下文模型改变了局面吗？

上下文窗口经历了戏剧性的增长：2020 年左右约为 2K token，2023 年 GPT-4 达到了 32K，2024 年 Claude 模型达到了 200K，而 2025 年一些供应商声称拥有数百万 token 的窗口。一个合理的问题是，这些规模的增加是否让上下文预算管理变得过时了。

研究表明并非如此——它们只是转移了问题。宣称的最大上下文窗口与最大“有效”上下文窗口之间存在巨大差距，且取决于具体任务。在复杂的多步推理任务中，某些评估显示有效上下文可能会降至宣称限制的 1% 以下。GPT-4o 在 LongProc 基准测试中表现出，准确率从短上下文时的 94.8% 完全匹配下降到 8K token 时的 38.1%。对于原本应该是适度的 16 倍输入增加，准确率下降了 57 个百分点。

长上下文性能的约束不再主要是物理上的。在实践中，用户很少触碰到硬性的 token 限制。相反，他们触碰的是：

• 可靠性下降：随着上下文长度的增加，准确率会下降，这与硬性限制无关
• 成本爆炸：上下文窗口增加 10 倍，推理成本会增加 5–10 倍
• 延迟：更长的上下文意味着更慢的推理；首字延迟随输入长度增长
• 干扰项干扰：语义相似但无关的内容会主动降低模型性能——并非所有 token 都是平等的

产品约束已从“我们能塞下这些吗？”转变为“模型能否以可接受的成本和延迟正确地使用这些信息？”第二个问题更难设计，因为它没有硬性阈值——它是一条随任务类型而变化的连续退化曲线。

针对约束进行设计

一些在生产环境中经得起考验的具体模式：

预检 token 计数。 在发送请求之前，估算 token 数量，如果它会使你的工作负载进入可靠性下降区，则拒绝请求或发出警告。这比推理后再处理错误成本更低，并能防止多步智能体中的级联故障。

显式的上下文管理界面。 对于在你的 AI 产品中进行长时间工作的进阶用户，给他们控制上下文内容的权利。“清除上下文”是一项核心操作。“将此文件置顶于上下文中”是一个核心概念。理解约束的用户可以管理它；不理解的用户则会在本该管理会话时去责怪模型。

设计可恢复性。 达到上下文限制的会话不应该是损失。设计对话状态，使其可以被摘要并继续：在对话历史之外保留用户的原始任务说明，使其可以轻松地带着进度摘要开始一个新的、专注的后续会话，并且永远不要让上下文溢出破坏未保存的工作。

使用真实的输入长度进行测试。 与上下文相关的生产故障最常见的来源是：在短输入下测试，然后在长输入下部署。在有效上下文限制的 50%、80% 和 95% 处进行显式测试，可以在用户发现故障模式之前将其揭示。

监测静默退化。 在推理时，按上下文长度对请求进行分桶，并跟踪输出质量指标。如果即使限制是 200K，质量指标在 60K token 时就已下降，那么你就找到了有效的工程极限。显式地对此进行埋点监测，而不是通过用户投诉来发现它。

那些发布可靠 AI 产品的团队并不是解决了上下文限制问题的团队。他们是那些不再将其视为需要隐藏之物的团队。