# 上下文超限怎么办：先核算提示词，再决定重试

> 把历史、工具定义、检索片段和输出预留放进同一 token 预算，解决上下文超限，同时保留回答真正需要的证据。

_发布 2026-09-29 · 更新 2026-09-29 · [KeepRouter Editorial](https://keeprouter.com/editorial-policy#editorial-team) · 5 分钟阅读_

![包含输入预算、输出预留与检索检查的 Kimi K3 长上下文请求图](https://keeprouter.com/editorial/blog/kimi-k3-1m-context.png)

_核算实际请求上下文，并为生成预留空间。示意图，不代表某个型号的容量。_

上下文超限说明请求超过模型或端点限制。应统计序列化后的完整内容，包括指令、历史、工具定义与检索文本，再按型号规则为输出留空间。原样重试通常只会再次失败。

用户问题很短，不代表真实请求很短。长会话的主要消耗可能藏在应用自动拼接的历史和工具里。

## 区分不同限制

[Claude 上下文说明](https://platform.claude.com/docs/en/build-with-claude/context-windows)和 [Gemini token 文档](https://ai.google.dev/gemini-api/docs/tokens)描述各自的计算方式。

| 限制 | 意义 | 常见误解 |
| --- | --- | --- |
| 上下文窗口 | 请求与生成可使用的容量 | 全部都能当输入 |
| 输出上限 | 允许生成的数量 | 调大后输入也能更多 |
| 客户端预算 | 应用决定发多少内容 | 能改变上游模型规格 |
| 文件、媒体限制 | 特定操作限制 | 大窗口能绕过所有限制 |

按准确型号和线路核对，不用另一平台的同名模型规格代替。

## 建立 token 账本

假设可用窗口 16,000 token，指令与工具 2,000、历史 5,000、检索 6,000、问题 500，输入已达 13,500。再预留 2,000 输出和 1,000 余量，就超出 500。

```python
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，十段短文与十段长文并不等价。

## 有意识地压缩会话

摘要应保留已作决定、未解决问题、标识符、约束与来源。不要把建议压缩成已批准决定。权限、余额和业务状态应保存在应用数据里，不能只依赖模型摘要。

用后续问题验证摘要是否保留约束，例如“不能修改生成文件”。压缩后忘掉规则，不能算优化成功。

有工具时需保留合法调用与结果对应。只删除助手调用、留下工具结果，会引发另一种协议错误，见[工具调用指南](/zh/blog/llm-tool-calling-loop)。

## 确实需要时再扩大窗口

必要材料无法进一步缩减时，更大窗口有价值；持续重发冗余历史时则应先修应用。比较同一组证据上的正确率与成本，不能把窗口大小直接当质量。

长文本测试应覆盖开头、中间、结尾事实，冲突材料，以及没有答案的问题。“能放进去”不代表每项事实都能可靠找出。

## 把确定性错误变成可执行提示

超限时向用户提供明确的缩小范围、减少历史或更换型号路径，不进入临时错误的重试循环。用[模型目录](/models)确认限制，结合 [RAG 成本指南](/zh/blog/rag-api-cost-per-query)与[计算器](/tools/api-cost-calculator)决定预算，并保留能验证关键事实的小样本。

## 常见问题

### 提高输出上限能修复上下文超限吗？

通常不会增加输入容量，反而可能需要更多预留。应按型号规则缩减完整请求。

### 直接删除最旧消息可以吗？

必须保留重要约束和协议关系。保存必要事实与工具调用对应，并测试处理后的会话。

### 更大的窗口保证答案更好吗？

不保证。它增加容量，但仍需测试模型能否正确使用文档证据，包括冲突和缺失事实。

## 参考的一手资料

_本文最近复核 2026-09-29_

1. [Claude context windows](https://platform.claude.com/docs/en/build-with-claude/context-windows)
2. [Gemini token counting](https://ai.google.dev/gemini-api/docs/tokens)

## 继续阅读

- [KeepRouter 上的 Kimi K3：使用 1M token 上下文窗口](https://keeprouter.com/zh/blog/kimi-k3-1m-context.md)
- [RAG 每次查询多少钱：别只计算生成 token](https://keeprouter.com/zh/blog/rag-api-cost-per-query.md)
- [LLM 工具调用：实现完整的请求与结果循环](https://keeprouter.com/zh/blog/llm-tool-calling-loop.md)

## 找到适合任务的模型

选择服务或编写接入代码前，先确认型号可用性、输入类型与计价单位。

[比较模型与价格](https://keeprouter.com/models)

[创建 Key，测试免费模型](https://keeprouter.com/login?returnTo=%2Fconsole%2Fkeys%3Fmodel%3Dfree)

免费测试使用 free 模型；其他付费型号需要足够预付额度。

[全部文章](https://keeprouter.com/zh/blog.md) · [模型与价格](https://keeprouter.com/models.md)