跳转到主要内容

Token 是有限资源:复杂 Agent 的上下文预算分配框架

阅读需 2 分钟Tian PanTian Pan

前沿模型如今宣传的上下文窗口动辄 200K、1M 乃至 2M token。工程团队将其视为已解决的问题而继续前行。数字如此之大,我们应该永远不会触及上限。

然而,在一个自主研究任务执行六小时后,agent 开始产生幻觉,对它三小时前编辑过的文件路径一无所知。一个代码 agent 自信地打开了它在第四轮已删除的函数。文档分析流水线开始与它之前从同一文档得出的结论相矛盾。这些不是模型失败——它们是上下文预算失败:可预测、可测量,而且只要将上下文窗口视为它实际所是的稀缺计算资源,几乎完全可以预防。

最大有效上下文窗口并非你所想象

2025 年对 18 个前沿模型(包括 GPT-4o、Claude Opus 和 Gemini 2.5)的分析发现,12 个模型中有 11 个在 32K token 时性能降至基线的 50% 以下。GPT-4o 在上下文填满时准确率从 99.3% 降至 69.7%。Claude 模型表现出更平缓的退化,但也未能幸免。

2025 年 9 月发表的研究引入了最大有效上下文窗口(MECW)概念:模型仍能可靠完成任务的最大上下文长度。MECW 远小于市场宣传的最大上下文窗口。对于某些任务,模型在上下文仅有 100 个 token 时就会失败。大多数模型在特定任务配置下到 1000 个 token 时就会出现严重退化。

基础机制已被充分理解。2024 年发表于《ACL 会刊》的论文《迷失在中间》(Liu 等人)展示了一个一致性发现:当相关信息位于上下文的开头或结尾时,模型性能最佳。在 20 篇文档中,当相关文档处于第 5-15 位时,准确率下降超过 30%。Transformer 将注意力分配给所有 token,随着上下文增长,任何特定信息的信噪比都会下降。

Chroma 2025 年的一项研究通过对照实验使这一点更加具体:即使将所有干扰 token 替换为空白符——给模型提供完美的检索条件——性能仍随长度退化。Llama-3.1-8B 在 30K token 时准确率下降高达 85%。Claude 3.5 在 30K token 时 MMLU 准确率下降 67.6%。长度本身就是问题所在,而非内容。

生产实践的含义:你不能依赖"模型会在大上下文中找到所需内容"。被动积累上下文的 agent 在运行过程中会持续退化。

上下文预算在实践中如何失败

当 agent 在任务中途耗尽上下文时,根据基础设施的不同,会出现三种截然不同的失败模式:

硬错误:较新的 Claude 模型(Sonnet 3.7+)在静默截断之前会返回验证错误。这实际上是最可恢复的失败模式——至少你知道出了问题。

静默截断:许多配置和旧模型在窗口填满时会丢弃最旧的消息而不发出警告。agent 继续运行,但工作记忆中存在空洞。旧的工具结果消失了。之前的决策不见了。agent 基于越来越残缺的历史版本进行推理。

上下文中毒:最危险的失败模式。当上下文接近容量时,模型难以追踪所有内容,产生的幻觉被附加到对话中并被视为事实。那个幻觉随后影响每一个后续轮次。2025 年一项关于 LLM agent 游戏的研究记录了这一现象:接近满载的上下文导致模型产生游戏状态的幻觉,随后被反馈到后续推理中,跨轮次累积,直到 agent 的世界模型与现实完全脱节。

总体代价相当显著。2025 年来自行业的数据将 65% 的企业 AI 流水线失败归因于多步推理过程中的上下文漂移或记忆丢失——不是原始上下文耗尽,而是上下文质量侵蚀导致的逐渐退化。

四层分配模型

将上下文视为预算意味着明确决定 token 如何在争夺空间的各组件间分配。来自生产部署的实践共识是一个优先级有序的四层分配:

第一层——静态锚点(永不驱逐):系统提示和工具模式。这些内容置于提示的开头,在请求间保持稳定,是最具缓存价值的内容。这些应消耗固定的、已知的预算份额——理想情况下不超过总上下文的 10-15%。如果你的系统提示有 40K token,在第一条用户消息到达之前就已消耗 200K 窗口的 20%。

第二层——活跃检索上下文:RAG 结果、注入的记忆和相关文档。这一层获得第二大分配。关键纪律是即时检索:不要预先将大型文档加载到上下文中。维护标识符并通过工具调用动态加载内容,只返回相关摘录。一个在 agent 剩余 22,000 token 时返回 20,000 token 原始 JSON 的工具调用会让任务停滞。

第三层——对话历史:这是大多数系统失败的地方。如果不加管理,历史会无限增长。正确的模型是滚动压缩:随着新内容到来,最旧的交换被摘要,而不是保留原始记录直到触及限制。

第四层——暂存空间:中间推理、思维链轨迹以及已处理的工具调用输出。这是最可牺牲的层。Claude 的 API 会自动从轮次间的上下文积累中去除扩展思维块,这对长时间 agent 会话具有重要的架构意义——你获得推理收益而无需承担积累成本。

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 10 分钟

大多数 Agent 路由器跳过的意图分类层

大多数 Agent 路由器在每次请求时都加载所有工具 Schema,让 LLM 自行决策。当工具数量达到 417 个时,这种方式的准确率会崩跌至 20%。本文解释意图分类层如何解决这一问题——以及跳过它如何在规模化后悄然损毁准确率和成本。

insider
ai-engineering
阅读需 11 分钟

边缘推理决策框架:何时在本地而非云端运行 AI 模型

为 AI 工程师提供的实用决策框架:分析在哪些情况下端侧和私有化部署的 LLM 推理优于云端 API,以及如何设计连接两者的混合架构。

insider
edge-inference
阅读需 9 分钟

脚手架审计:每一次模型发布都让你的部分开发框架变成累赘

重试机制编排、JSON 修复解析器以及强制思维链,都是为你不再运行的模型而构建的。这是一套在每次模型升级时,对过时的 LLM 脚手架进行标记、消融和删除的实用规范。

insider
ai-engineering
阅读需 10 分钟

被反向代理剥离的 SSE Keep-Alive,以及你支付了两次费用的 Prompt

LLM 流式响应看起来像是从模型到用户的通畅管道 —— 直到一次 35 秒的工具调用导致反向代理断开连接,你的客户端针对无状态 API 重试整个 Prompt,最终用户的账单为同一个响应支付了两次费用。

insider
ai-engineering
阅读需 12 分钟

擦除模型仍在读取的上下文:数据保留策略带来的隐患

一个每晚运行的删除作业正在清理你的提示词组装器在请求时读取的消息表。模型进入了一个被截断的对话,并自信地捏造了用户实际同意的 SLA。这个 Bug 存在于两个都认为自己拥有该表的团队之间。

insider
ai-engineering