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

前沿模型如今宣传的上下文窗口动辄 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 会话具有重要的架构意义——你获得推理收益而无需承担积累成本。

分配比例取决于你的任务类型。代码 agent 会话需要更多对话历史（引用早期代码）。文档分析流水线需要更多检索上下文。关键是使分配明确而非自然涌现。

执行：硬限制与软压缩

明确的分配需要执行。有两种模式：

Token 预算注入（显式，模型侧）：关于 Token 预算感知 LLM 推理（TALE）的研究表明，将预算直接注入提示——"在大约 500 个 token 内完成此任务"——在保持有竞争力的性能的同时，输出 token 减少 67%，成本降低 59%。模型在有可见预算时会自我调节。Anthropic 的上下文感知 API 将这一点正式化：Claude 4.5+ 模型可以在每次工具调用后接收注入的实时 token 计数器，让模型随会话进展调整冗长程度。

压缩（显式，基础设施侧）：当上下文越过阈值——通常约为窗口容量的 80-85%——结构化摘要传递将原始历史替换为压缩表示。关键实现细节是锚定迭代摘要：不是每次都压缩整个历史，而是维护一个运行中的结构化摘要，仅在截断触发时压缩新丢弃的片段。这避免了指数级计算成本并保留了早期决策的结构。

压缩中关键的未解决问题是制品追踪。2025 年对八个 agent 框架的评估发现，所有框架在跨压缩边界可靠记忆哪些文件已被修改方面的得分在 2.19 到 2.45 之间（满分 5.0）。当 agent 的工作记忆被压缩时，"我已经改了什么？"成为不可靠的答案。对于代码 agent，这是在长时间会话中导致重复编辑、丢失修改和矛盾代码变更的具体失败模式。

KV 缓存与预算设计耦合

上下文的物理基底是键值缓存：在推理过程中，每个 token 的注意力矩阵被计算并存储在 GPU 内存中。当提示共享公共前缀时，提供商侧的提示缓存会重用这些预计算的张量。Anthropic 对缓存读取收取基础输入价格的 10%（90% 折扣）；Google 对 Gemini 2.5+ 缓存 token 收取标准输入的 10%。

由此产生的预算设计约束：静态内容必须置于提示开头，并且必须在请求间保持稳定。2026 年的一项研究发现，向静态前缀添加单个 token 可能导致会话中所有后续请求的缓存命中率降至零。你的系统提示和工具模式是你的缓存锚点。如果它们在轮次间发生变化，你为每个请求支付全价。

对分配的含义是，你的第一层内容不仅关乎正确性——它是你的主要成本杠杆。一个结构良好、稳定的 15K token 系统提示在每次请求开头保持不变，其成本在会话中大量摊销。一个 50K 的系统提示在请求间移动则会破坏缓存，按比例推高每次请求的成本。

子 Agent 模式作为上下文防火墙

对于多 agent 架构，解决上下文积累最有效的结构性方案是在架构层面阻止它。子 agent 处理专注的任务并将压缩摘要（通常 1,000-2,000 token）返回给协调者，而不是将完整的工具输出链传递回层级体系。

这种模式防止了朴素 agent 循环特有的指数级上下文增长：每个子 agent 获得一个新鲜的上下文窗口，完成其工作，并返回摘要。协调者从不看到子 agent 的工具调用历史。整个系统的成本和性能特征得到改善，因为每个 agent 都在其上下文窗口的早期高性能部分运行——而不是在退化的尾部。

权衡是摘要保真度：重要细节可能在子 agent 的摘要中丢失。缓解措施是为子 agent 响应指定结构化输出格式，精确规定必须保留哪些字段（已更改的文件、已做的决策、当前状态、阻碍因素），而不是要求子 agent 自由形式地摘要。

使其可操作

从将上下文视为"可用空间"转变为将其视为显式预算，需要一些具体实践：

• 按组件检测 token 使用情况。在每次请求之前，了解你的系统提示、工具模式、检索文档和历史各消耗多少 token。这是基本要求。
• 设置每层软限制。当检索上下文超过其分配时，先压缩再注入。当对话历史达到其限制时，触发摘要。
• 在上下文容量下测试，而不仅仅是在标称负载下。一个运行 50 轮并积极使用工具的会话将具有与 3 轮测试用例根本不同的上下文特征。你的评估套件应包括施压上下文限制的长时间运行场景。
• 为 token 效率设计工具输出。一个在相关答案只有 200 token 时返回 20K token 原始 JSON 的工具是上下文预算的负担。用薄层包装外部 API，返回结构化的最小响应。
• 显式追踪制品状态，而不是通过历史回忆。对于代码 agent 和文档编辑 agent，在上下文窗口之外维护一个显式状态存储（已更改的文件、已做的决策、当前任务状态），并在每个主要轮次开始时将其作为结构化上下文注入。

1M token 上下文窗口是能力上限，而非运营基线。实际在该规模下运行的模型是例外。对于大多数生产 agent，有效工作预算要小得多——而将其视为如此的系统才是在长期任务中保持可靠的系统。

上下文管理不是你后来添加的功能。它是你从一开始就设计的基础。