上下文超限怎么办：先核算提示词，再决定重试
把历史、工具定义、检索片段和输出预留放进同一 token 预算，解决上下文超限，同时保留回答真正需要的证据。
发布 2026-09-29 · 更新 2026-09-29 · KeepRouter Editorial · 5 分钟阅读
上下文超限说明请求超过模型或端点限制。应统计序列化后的完整内容，包括指令、历史、工具定义与检索文本，再按型号规则为输出留空间。原样重试通常只会再次失败。
用户问题很短，不代表真实请求很短。长会话的主要消耗可能藏在应用自动拼接的历史和工具里。
区分不同限制
Claude 上下文说明和 Gemini token 文档描述各自的计算方式。
| 限制 | 意义 | 常见误解 |
|---|---|---|
| 上下文窗口 | 请求与生成可使用的容量 | 全部都能当输入 |
| 输出上限 | 允许生成的数量 | 调大后输入也能更多 |
| 客户端预算 | 应用决定发多少内容 | 能改变上游模型规格 |
| 文件、媒体限制 | 特定操作限制 | 大窗口能绕过所有限制 |
按准确型号和线路核对，不用另一平台的同名模型规格代替。
建立 token 账本
假设可用窗口 16,000 token，指令与工具 2,000、历史 5,000、检索 6,000、问题 500，输入已达 13,500。再预留 2,000 输出和 1,000 余量，就超出 500。
context_budget = 16_000
parts = {"instructions_tools": 2_000, "history": 5_000,
"retrieval": 6_000, "question": 500}
output_reserve = 2_000
headroom = 1_000
print(context_budget - sum(parts.values()) - output_reserve - headroom) # -500这是规划算例，不是 tokenizer 或型号规格。优先使用服务支持的计数方式，并注意图片与推理用量。字符数除以固定常数只能粗估，中文、代码与其他语言差异明显。
先去掉重复，再考虑缩减证据
检查重复系统指令、工具定义和重复检索片段。旧构建日志可能只需要保留关键错误与文件位置，而不必每轮全文发送。
当前任务真正需要的原文不能随便删。例如问题询问合同某条，应保留该条款和来源身份，不能只留下模糊摘要。检索既要限制片段数，也要限制总 token，十段短文与十段长文并不等价。
有意识地压缩会话
摘要应保留已作决定、未解决问题、标识符、约束与来源。不要把建议压缩成已批准决定。权限、余额和业务状态应保存在应用数据里，不能只依赖模型摘要。
用后续问题验证摘要是否保留约束，例如“不能修改生成文件”。压缩后忘掉规则，不能算优化成功。
有工具时需保留合法调用与结果对应。只删除助手调用、留下工具结果，会引发另一种协议错误，见工具调用指南。
确实需要时再扩大窗口
必要材料无法进一步缩减时，更大窗口有价值；持续重发冗余历史时则应先修应用。比较同一组证据上的正确率与成本，不能把窗口大小直接当质量。
长文本测试应覆盖开头、中间、结尾事实，冲突材料，以及没有答案的问题。“能放进去”不代表每项事实都能可靠找出。
把确定性错误变成可执行提示
超限时向用户提供明确的缩小范围、减少历史或更换型号路径，不进入临时错误的重试循环。用模型目录确认限制，结合 RAG 成本指南与计算器决定预算，并保留能验证关键事实的小样本。
常见问题
提高输出上限能修复上下文超限吗？
通常不会增加输入容量，反而可能需要更多预留。应按型号规则缩减完整请求。
直接删除最旧消息可以吗？
必须保留重要约束和协议关系。保存必要事实与工具调用对应，并测试处理后的会话。
更大的窗口保证答案更好吗？
不保证。它增加容量，但仍需测试模型能否正确使用文档证据，包括冲突和缺失事实。
参考的一手资料
本文最近复核 2026-09-29