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 提供——可以实现成本预测，并在请求到达推理服务器之前进行主动的频率限制管理。

加载中…