上下文不是越长越好：Token 预算、信息选择与排列

假设你已经取回 A1042 的订单、售后政策和二十轮聊天，现在遇到一个看似简单的问题：把它们拼起来，是否超过模型的上下文窗口？

这是必须回答的问题，但只回答它还不够。一个请求可以不超限，却把决定运费归属的适用条件删掉；也可以放进所有资料，却混入大量无关对话。容量约束决定能不能发送，信息选择决定这次发送的内容是否有用。

从一笔具体预算开始

下面全部使用十进制 Token 数字，32000 就是三万二千，避免把 K 的不同习惯混在一起。假设某模型接口允许本次输入与输出合计使用 32000 Token，预留输出 4000，误差和额外包装预留 1000，那么输入上限为 27000。

应用规则、工具定义和本轮问题共估算 5000，留给历史、证据、记忆与状态的空间就是 22000：

可用动态空间 = 32000 - 4000 - 1000 - 5000 = 22000

这里的等式建立在“输入输出共享这一窗口”的假设上。实际模型还可能有独立输入上限、输出上限和其他用量规则，适配器要分别检查。若接口同时要求输入不超过 25000，那么输入预算应取两个约束中较小的 25000，而不是继续使用 27000。

输出预留也不是“答案一定有这么长”。它让应用为允许生成的最长回答留出空间，实际消耗在返回后记录。隐藏推理用量、图片和工具协议如何计入，必须按所接接口核对，不要用一张所有模型通用的字符换算表。

候选阶段可以存一个便宜的长度估计，用来快速排除明显放不下的大块资料。真正发送前则要对最终消息、工具 Schema 和输出约束共同计数或校准。

例如每条证据的正文是 100 Token，十条合计 1000；加上引用 ID、标题、分隔符和 JSON 包装后，输入会更长。分段计数之和也未必严格等于拼接后的计数，因为分词结果可能受相邻字符影响。

最终输入由模型适配器提供计数接口。在不知道服务端全部包装细节时，这仍然是估算，应用需留余量，并利用实际 usage 持续校准。缓存命中的 Token 可能减少费用或重复计算，并不因此从上下文容量中消失。

budget_selection.py下载使用人工指定的成本解释选择算法；综合示例用字符数模拟容量。两者都不声称测到了真实模型 Token，生产适配器需要替换计数实现。

假设一个仅用于演示的小预算为 100 单位：

先保留 60 单位必需内容，还剩 40，完整政策可以放入。旧产品介绍排除不会改变运费结论。若总预算只有 80，应用必须承认当前组合放不下，不能只取政策最后一句“商家承担运费”凑成可发送请求。

“必需”由具体任务决定。通用政策介绍不一定需要订单详情；提交退款前却必须读取当前订单状态和授权事实。策略配置需要随任务变化，而不是把每类内容永久固定成一个优先级。

假设剩余预算 40，三个候选分别是：完整政策成本 35、价值 9；订单说明成本 20、价值 6；产品说明成本 20、价值 6。按单条价值排序会拿政策，示意总价值 9；拿两个说明则为 12。

这说明贪心算法不保证最大化人为设定的分数。但在本次运费问题里，没有政策的“12 分”可能根本无法回答。分数是否表达了任务目标，比求最优解更基础。

可以用约束优化的方式理解选择：每项成本为 c_i，是否选择为 x_i，预算为 B，要求 Σ c_i x_i ≤ B。若结论 A 依赖条件 B，还要有 x_A ≤ x_B；必需项的 x_i 固定为 1。这里的符号只是表达约束，不代表每次请求必须运行复杂求解器。

实际可从简单方案开始：先放必需项，再将条件与结论组成不可拆分的包，对可选包按任务价值排序。保留选择理由，积累失败样本后再改进策略。不要用一个未经校准的模型相关性分数掩盖缺少证据的问题。

用户先说“明天下午取件”，下一轮改成“改为后天上午”。只留第一轮会产生过时安排；把两轮都放进去但不说明哪次更新有效，也增加理解负担。任务状态应记录最新值以及变更来源，近期原文帮助解释语气和未解决问题。

工具交互则有协议依赖。一次 assistant 工具调用可能产生多个返回结果，保留孤立结果、删除对应调用，可能让接口拒绝请求，或让模型误解这是谁查到的。应按目标 API 的交互单元保留；若历史工具结果被摘要，重新构造合法的数据消息，不能伪造仍然存在的调用关系。

时间顺序也不是全部。十轮前的“只咨询，不要提交申请”可能仍然有效，最近五轮闲聊却与任务无关。结构化提取长期有效的约束，再保留最近完整交互，比单纯 messages[-10:] 更能表达任务现状。

可以把稳定的任务规则放在前面，把当前问题和直接相关证据放在容易对应的位置，将每条结论与条件相邻排列。这样的组织首先帮助模型辨认关系，也方便开发者审阅。

Lost in the Middle 在所研究的模型与任务中观察到证据位置影响结果，长上下文能力并不等于对任意位置同样可靠。这是需要评估排列策略的依据，不是所有模型都必须把答案放在第一段或最后一段的定律。

新增内容也不必然降低质量。完整合同对照可能需要长距离关联，删减会丢失定义和例外。应围绕任务比较结果，不能把“短”本身当成成功指标。

先移除确实重复、过期和不适用的信息，再考虑按问题检索更小的原文范围。大型表格可以先计算必要字段，大工具结果可以外置；旧对话可以生成任务快照，但压缩要有来源和恢复路径。

如果缺少的是不可分割的完整合同，可以分步阅读、扩大窗口或明确停止，而不是截掉合同后半部分继续给结论。多步调用会增加等待和协调成本，也要为各步安排预算。

最后观察“必要证据是否进入”和“任务是否完成”，再看 Token、首字延迟、总延迟与费用。减少一半输入却让用户多问三轮，不一定真的节省成本。预算策略优化的是整个任务，而不仅是某一次请求长度。

完整文件、依赖与运行边界见配套指南下载。