大模型提示上下文超限怎么办？输入预算、历史裁剪与分段处理指南

遇到“上下文超限”时，先不要直接删除整段历史。需要先确认错误类型：上下文窗口限制针对一次请求中可容纳的输入与输出总量；单次输出上限只限制模型本次生成的长度；账户限流则通常与请求频率、并发量或配额有关。三者的处理方式不同，不能混为一谈。

一、先确认超限发生在哪里

记录触发错误的请求结构，包括系统指令、用户消息、历史消息、工具定义、工具返回内容以及期望输出长度。若错误明确指出输入或上下文长度超过限制，重点检查消息累计长度；若请求本身较短却被拒绝，则应进一步查看输出上限、频率限制和账户配额。不要用“固定字数”推断Token数量，因为不同模型的分词规则不同，同一段中文、代码或混合文本的Token占用可能不同。

二、建立输入预算

一次请求的预算至少应包含以下部分：

• 系统指令，包括角色、格式要求和安全约束；
• 当前用户问题及其附带资料；
• 需要保留的历史消息；
• 工具定义、参数说明和工具调用结果；
• 为模型输出预留的空间。

实际计算应使用目标模型或服务提供的Token统计方式，而不是按字符数估算。可以先设定总预算，再扣除系统指令、工具定义和当前任务内容，剩余部分用于历史消息，并为输出保留明确余量。若工具返回内容经常占用大量空间，应把工具结果也纳入每轮预算，而不是只统计用户输入。

三、按信息价值裁剪历史

裁剪时优先处理重复内容和低价值内容。多轮代码问答中，如果每一轮都附加完整日志，历史会快速膨胀。更合适的做法是截取与当前错误相关的片段，同时保留文件路径、行号、错误类型、复现步骤和已经尝试过的修改。这样既减少重复文本，也保留后续排错所需的定位信息。

建议按以下顺序处理：

1. 删除已经重复出现的系统说明、完整日志和相同工具结果；
2. 压缩已解决的对话，只保留结论、变更点和可追溯标识；
3. 保留当前任务约束、未解决问题、关键事实及必要的原始证据；
4. 仍然超限时，再减少较早历史，并检查输出预留是否过大。

历史摘要可以节省空间，但会丢失细节。摘要中应保留来源、文件名、章节号、时间或消息标识，并将原始资料存放在可回查的位置。不要把摘要当成原文的完全替代品，尤其是涉及代码、数字、条件限制和引用内容时。

四、长文采用分段处理

处理长报告、规范或代码库时，可先制定分段规则，例如按章节、函数、文件或固定Token范围切分。每段都应携带文档名称、章节标识和顺序信息，避免单独处理后无法定位来源。

分段提取阶段只要求输出该段的事实、结论和疑点，并记录原文位置。合并阶段再依据章节标识整理主题、去除重复内容，不能假设分段后必然不会丢失信息。跨段信息应通过共享字段衔接，例如术语表、实体清单、前置结论和待确认问题。最终复核时，抽查原文与合并结果，确认数字、条件、例外情况和相互引用没有被遗漏或改变。

五、建立回归检查

修改预算策略后，使用一组已知会超限或接近上限的请求进行回归测试。检查请求是否仍包含当前约束、必要事实和工具结果，输出是否被过度截短，以及裁剪后模型是否误解任务。若业务允许，还应记录每部分Token占用和截取原因。这样可以区分是输入结构膨胀、输出预留不足，还是限流问题，并让后续调整有可验证依据。