对话内容或文件长度超出当前模型最大上下文长度

你多半遇到过这种场面：一份长文档丢进去，或者聊到几十轮之后，界面直接报「超出最大上下文长度」，前半段内容像没被看见过。这篇不绕原理，按排查顺序讲：先分清是输入太长还是输出预留不够，再决定是切分、压缩、还是换个上下文更宽的模型。

你先别急着怀疑模型坏了。这个报错说的是一件很窄的事：这一次请求里，输入加输出要用的位置总量，超过了模型能容纳的上限。它跟「模型变笨」「接口挂了」没关系，是纯粹的容量问题。好消息是它几乎总有办法绕过去，坏消息是绕法有好几种，选错会让你白干半天。

下面按排查顺序讲：先判断是哪种超限，再决定调输出、切内容、还是干脆换个上下文更宽的模型。每一节都给能直接动手的动作，你照着走一遍，基本能把任务跑完，而不是停在报错上。

先搞清报错到底在说什么

上下文长度是一个共享的桶，输入和输出都从里面取位置，不是只算你贴进去的正文。很多接口会预留一段给输出，这部分被占掉后，输入能用的量就少了一截。所以出现「我明明只贴了半份文档」的情况，往往是输出预留把那半份挤掉了。

另一个常见误区是多轮对话。历史消息每轮都会被重新带上，聊得越久，桶里被旧内容占的位置越多，某一次提问就突然爆了。文件类任务相反，是一口气把全文塞满，第一次就报错。两种场景的处理方式不一样。

按这个顺序排查，别一上来就切文件

• 先看请求里最大输出设成了多少。它设得高，输入可用量就少，很多人调低一档立刻就通了。
• 再把三类内容分开估：系统提示、历史消息、文件正文。找出谁是占位置的大头，别盲目压缩正文。
• 判断任务类型。总结、对比、全局审校这类要前后贯通的，不能随便切；抽取、翻译、逐段问答这类每块能独立跑的，才适合切。
• 如果换过多轮工具、系统提示很长，先把系统提示精简一遍，收益往往比切文档快。
• 以上都试过还爆，说明窗口和任务体量不匹配，进入换模型的判断流程。

这一步的目的不是马上解决问题，而是把「是谁在占位置」定位清楚。定位对了，后面的动作才有针对性；定位错了，你可能删了半天正文，结果大头是历史消息。

切分与压缩的具体做法

切分最重要的一条是按语义边界切，别按固定字数硬切。章节、标题、函数、对话轮次这些天然断点，切在那里上下文不容易断；硬切最容易把一句结论劈成两半，模型两遍都读不懂。

1. 先按结构切打开文档看目录或标题层级，按章节、函数、发言轮次切成若干块，每块单独跑一遍，确认每块自己讲得通。
2. 两段式处理第一遍对每块出摘要或要点，第二遍把要点合并成一份短材料，用它做最终的问答或总结。代价是多一次调用，换来的是不丢全局。
3. 压缩优先删冗余重复的格式符号、整段没被问到的背景、历史里已经结论化的中间讨论，都可以删。删之前问一句：删了之后这个问题还答得出来吗。
4. 跨块保留重叠需要跨块引用时，让相邻两块留一小段头尾重叠，避免答案正好卡在两块交界处谁也答不上。
5. 验证切分效果拿几个你已知答案的问题分别测切分前后的结果，明显变差说明切错了位置，回到第一步换边界。

什么时候该换模型而不是硬压

判断标准很简单：切分之后，关键问题答不对、或者要多轮拼接才能拼出结论，说明问题不在内容组织，而在窗口本身不够用。这时候换一个上下文更宽的模型，比继续压缩省事得多。

• 要全局长逻辑的任务，切完质量明显下降，优先考虑换模型。
• 换之前先到站内模型库核对候选模型的上下文规格和计价口径，别只看宣传语。
• 窗口越大通常单价越高、首字更慢，短任务用大窗口是浪费，按任务体量选。
• 换模型可能涉及工具链或 SDK 改动，先小流量验证，别直接切生产。
• 换完仍要跑一遍回归用例，确认不是「窗口大了但效果没变好」。

成本和延迟这块，具体数字会变，别记死。到站内价格追踪和模型库页面核对当时的数字，再决定值不值得为大窗口多付那部分。