把上下文窗口当预算：Token分配与检索策略

每个模型调用中，上下文窗口都是一种稀缺资源。钱、延迟和注意力成本都会随输入token增长。更大的窗口只是提高上限，并不改变任务本质：每轮都要发送让模型正确回答所需的最小token集合。

为什么上下文窗口需要预算思维

开发者常把窗口视为可无限填充的容器，结果上下文膨胀、成本上升、回答质量下降。核心认识是：每个输入token都会在三个方面产生成本——金钱（按token计费）、延迟（token越多响应越慢）和模型注意力（关键信息被稀释）。

预算思维要求先算账再选择上下文。作者用假想的8,192 token窗口演示了这种算术：预留1,024给答案、512给消息框架和估算误差，输入额度为6,656；指令占700、工具schema占1,000、当前任务200、状态500，这样在证据和历史之前已花掉2,400，剩余4,256。

这个算术的价值不在于具体数字，而在于暴露矛盾：例如六段各800 token的证据需要4,800，超出544；五段只需4,000，能放下但可能丢掉关键例外。

上下文窗口（context window）指模型单次调用能接收的最大 token 数，涵盖输入（系统提示、工具定义、对话历史、检索内容等）与输出。超出窗口的输入会被截断或导致请求失败。不同模型的窗口大小差异很大，从数千到数十万 token 不等。窗口大小决定了单次调用可容纳的信息上限，但不改变「每轮只发送必要 token」的工程原则：窗口越大，越需要主动管理，否则容易因堆砌无关内容而稀释注意力、推高成本。

五条预算线与常见陷阱

按文章表格，上下文预算可分五条线：

• 系统提示：随策略和操作指令增长。应精确、版本化，并在支持缓存处保持稳定。
• 工具schema：随暴露能力增长。应按任务暴露工具，或让agent渐进发现。
• 对话状态：随原始轮次、摘要和持久事实增长。应压缩并只检索当前决策所需状态。
• 检索上下文：随chunk数×chunk大小增长。应重排序，保持数量少而精确。
• 长期记忆：随每轮拉入量增长。应只检索少量相关记忆，而非整个档案。

其中两条最容易被低估。第一，运行时若每轮发送所有已注册工具，无关schema会占用输入token，并干扰正确工具选择。第二，回放全部原始对话会无限增长，除非应用压缩、摘要或按需检索。

工具 schema 是描述工具名称、功能、参数及类型的结构化定义（通常为 JSON Schema），模型据此决定是否调用及如何传参。每轮请求若携带全部已注册工具的 schema，会占用可观的输入 token，并可能干扰模型对当前任务相关工具的判断。按任务动态暴露工具、或让 agent 逐步发现工具，能显著压缩这部分开销，同时提升工具选择的准确性。

按证据束（bundle）检索，而非按片段填满

作者指出常见错误：取前五个chunk只因五个放得下。第六个可能是前五个规则的例外，只含规则不含例外的提示会输出自信但错误的答案。正确做法是排序完整证据束（规则连同例外），整束包含或整束放弃；若所需束放不下，应报告上下文不足，而非用部分证据作答。

这个原则与检索经验一致：少量高度相关的chunk胜过大量堆砌。它适用于整个会话——每条预算线都在争夺同一个窗口。

检索增强生成（RAG）中，系统按查询从外部知识库召回文本片段（chunk）并拼入上下文。常见误区是按相似度取「放得下的前 k 个 chunk」，但相关片段可能分散且不完整——例如只召回规则却漏掉例外。证据束（bundle）思路要求把逻辑上相互依赖的片段（规则+例外、条件+后果）视为不可分割的最小单元，整束纳入或整束放弃，从而避免模型基于残缺证据给出自信但错误的回答。

实践建议

• 用服务商精确的token计数，包括推理和输出限制；粗略计数器只是估计。
• 先预留输出和框架开销，再分配输入。
• 按任务暴露工具，避免全量schema。
• 压缩对话状态，按需检索长期记忆。
• 定义证据束边界（规则+例外），整束纳入或整束排除。

上下文窗口不是仓库，而是每轮都要重新编排的预算表。