上下文窗口是什么：为什么聊到一半它开始忘事

聊到中途，模型突然忘了前面说过的设定，或者直接抛一个 context length exceeded，再或者什么都没变账单却往上跳——这三件事背后往往是同一个原因：上下文窗口被塞满了。这篇不重复 Token 和计费的基础概念，只讲怎么估算自己离上限还有多远、怎么把长对话治理住，以及什么任务到底需要多大的窗口。

聊到中途，模型突然忘了前面说过的设定；或者你刚发出去，它直接抛一个 context length exceeded；再或者什么都没改，账单却比前几天高了一截。这三件事看起来不像一回事，背后往往是同一个原因：上下文窗口被塞满了。

这篇不重复 Token 和计费的基础概念，只解决三个实操问题：怎么估自己离上限还有多远、长对话怎么治理、什么任务到底需要多大的窗口。顺手给一套自查步骤和出问题时的排查顺序。

先认症状：聊到一半开始忘事是什么体验

超限的表现其实分三类，而且长得完全不像。分清是哪一类，后面的排查方向才不会跑偏。最怕的是把「装不下」当成「模型变笨」，然后反复换模型，问题一个都没解决。

区分「模型能力不足」和「上下文被挤掉」有个简单办法：前者从第一轮开始就答不好，后者是聊到某一轮之后才开始退化。把退化出现的那一轮记下来，那个位置大概率就是窗口的临界点。

• 把当前会话的消息条数和大概字数记下来，这是后面估算的起点
• 回忆退化是从第几轮开始出现的，临界点比总数更有参考价值
• 确认最近有没有往里塞过长文档、长代码或搜索结果，它们通常是压垮窗口的最后一根稻草
• 看一眼报错原文，注意是状态码报错还是 error code 文本报错，两者排查线完全不同

窗口里到底装了什么：四块内容抢同一个额度

很多人把窗口理解成「我能输入多少字」，其实它是四块内容共享的一笔总额度。任何一块失控，都会挤压另外三块——被挤掉的那块，就是你觉得「它怎么忘了」的地方。

系统提示

角色设定、格式要求、工具说明，通常每一轮都被完整重发，属于固定成本

对话历史

用户与模型往来的全部轮次，只增不减，是增长最快的一块

检索片段或附件

塞进来的文档、代码、搜索结果，往往一次就占掉大半个窗口

输出预留

必须留给模型回答的空间，留少了会被截断或直接报错

把这四块摆在一起，结论就很清楚了：真正能用到的空间，等于窗口总量减去另外三项和输出预留。系统提示和历史是可控的，检索片段是可以挪出去的，输出预留是可以提前约定的——所以窗口不够用时，能动的地方其实不少。

顺手记一个判断标准：系统提示是固定成本，历史是可变成本。只有后者能通过治理压下来，所以看到成本一直涨，先怀疑历史，而不是先去改系统提示。

怎么估算自己离上限还有多远

估算不需要精确到个位，只需要知道「大概用了多少、还剩多少」就够了。中文大致按字数估、英文按词数估，代码和 JSON 比自然语言更费额度，混排内容要往上加余量。

1. 拆四块挑一轮最长的请求，把系统提示、历史、检索片段、预期输出四段分别估一遍
2. 相加四段相加得到这一轮的大致占用，再和窗口规格比一下，看余量在哪个量级
3. 定位增长源对比第一轮和当前轮，看是哪一块涨得最快——通常答案就是历史或检索片段
4. 核对口径拿不准具体换算倍数时，到 Token 单价换算（/tools/token-price-calculator） 和 基础概念词典（/ai-dict/category/basics） 核对当前口径，不要凭记忆下结论

不适用的情况要提前说清楚：多模态输入（图片、音频）不能按字数估，得查对应模型规格页的说明；另外流式输出和结构化输出对输出预留的要求也不一样，不能套同一套系数。

长对话的三种治理做法，怎么选怎么用

治理长对话就三招：滚动摘要、分段新开会话、外置记忆与检索。三招不是互斥的，大部分长期任务最后是组合使用。

• 先判断任务有没有清晰阶段——有就分段，最省事
• 再看设定是否需要长期保持一致——需要就上滚动摘要
• 最后看资料量是不是远超窗口——是就把资料挪出去做外置检索
• 三招可以叠加：分段之后每段内部再上摘要，摘要之外再挂检索
• 具体检索方案怎么做，见 RAG 与检索（/rag-retrieval）

一个常见误判：有人觉得摘要一定比原文省，其实摘要写得太细反而更占额度，写得太粗又会丢关键约束。判断标准是——摘要里应该只有「后续步骤会用到的信息」，纯过程性的寒暄和试错都不该进摘要。

每次开会话前的清理清单

治理是长期动作，清理是每次开工前的动作。下面这几条做完，能砍掉相当一部分无效占用，而且不需要改任何架构。

• 清掉调试期间留下的试错轮次，它们只增不减地占额度
• 把示例和参考资料按需裁剪，只留当前这一步真正用得上的部分
• 长文档改成先定位再取片段，不要整篇贴进来
• 在系统提示里写明输出格式和长度上限，避免模型自由发挥把输出预留撑爆
• 同一任务换新会话时，只带摘要和三五行关键结论，不要整段复制旧对话
• 新会话第一次交互先做小样本验证，确认它能记住你的设定再往下聊

这里有个例外：如果任务是「必须逐字保留原文」的校对或合规审查，就不能随便裁剪，宁可分段也别删——这时候该换的是工作方式，不是清理力度。

什么任务需要多大窗口：按任务类型对照

窗口不是越大越好，大了可能更贵、也不解决定位问题。下面按任务类型给方向，具体规格数字请到站内页面核对当时的标注。

拿具体窗口规格时，到 模型资料库（/models） 和 Anthropic 官方价格与规格（/official-api/providers/anthropic-claude-api） 看当时标注的数字，本表只负责告诉你往哪个方向选。

超限的报错长什么样，以及为什么突然变贵

报错排查先看文本，不要只看状态码。出现 context length、too many tokens、maximum context 这类字样的，先怀疑窗口，而不是网络或密钥。

这类报错和 报错速查表（/api-errors） 里按状态码分类的问题不是一回事：状态码告诉你「请求有没有被受理」，error code 文本才告诉你「受理了但为什么被拒绝」。混在一起查，很容易查错方向。

变贵的机制其实很直白：窗口内每一轮都要把历史重发一遍，轮次越多，单次成本越高；系统提示属于固定重复支出，每一轮都在付。所以「什么都没改但账单涨了」，最常见的原因就是对话变长了。

• 减少无效轮次：能一次说清的需求别拆成五轮来回
• 把固定内容交给缓存，别每轮重发，具体见 缓存到底省了多少（/prompt-caching-cost-guide）
• 把长资料挪出窗口，按需取片段
• 系统提示写紧一点，去掉没人看的示例和说明
• 账单对不上预估时，先看历史长度，再看缓存命中，见 账单为什么和预估不一样（/token-cost）

出问题时的排查顺序

把上面几节合成一条可执行的排查线。核心原则是逐级加码，不要一上来就换模型——换模型最贵，而且经常解决不了定位问题。

1. 先分类确认是报错还是退化：报错去查 error code 文本，退化去数历史条数和退化出现的轮次
2. 再估算按四块内容估一遍占比，找出谁在挤谁——是历史太长，还是检索片段一次塞太多
3. 逐级治理按「清历史 → 上摘要 → 切分段 → 外置检索」的顺序逐级加码，每一步做完复测一次再决定要不要加码
4. 最后看规格前面都做了还是不行，再去 模型资料库（/models） 比一遍，确认是不是模型本身的窗口规格选小了

不适用的情况：如果是并发太高导致的限流，那是另一条排查线，和窗口没关系。判断方法很简单——限流通常和请求节奏相关，窗口问题和单次请求的内容长度相关。

大部分「模型变笨」的现场，其实是窗口被塞满了：先量余量，再动手治理，最后才考虑换模型。