当Continue插件接入本地模型后，上下文窗口溢出通常表现为对话进行到中段时模型返回类似“maximum context length”的报错，或者回答被硬性截断。Continue本身会把会话历史和检索结果一并交给后端模型；当后端窗口有限而前端没有裁剪机制时，溢出只是时间问题。LlamaIndex可以放在Continue与模型之间作为上下文管理中间层，在请求到达模型之前先压缩和筛选上下文。

判断：如果溢出出现在Continue连接本地模型的链路上，修复方向是在LlamaIndex侧接管对话历史管理，用ChatMemoryBuffer限制送入模型的消息量，再对检索节点做长度和数量控制。需要先通过日志确认溢出发生在Continue配置层还是模型返回层；裁剪会丢失部分早期上下文，参数取值要靠实际任务效果去验证。

先确认溢出发生在哪一层

动手裁剪之前，先回答一个具体问题：报错是Continue保存会话时产生的，还是模型后端返回时产生的。Continue的日志通常位于~/.continue/logs目录，本地模型后端（例如通过Ollama或vLLM启动）通常会把“maximum context length”这类错误打到自身终端或日志文件。模型侧先报错，说明消息确实超出了模型窗口，优先调整LlamaIndex的裁剪参数；Continue侧先报错，说明Continue自己的上下文检查先于模型执行，需要同时看Continue配置里上下文长度字段的上限。

这个划分决定了改动位置。跳过这一步直接调参数，很可能出现Continue的长度检查仍然拦截请求，LlamaIndex侧怎么裁剪都到不了模型层。

用ChatMemoryBuffer控制送入模型的历史消息量

Continue的会话会持续累积历史消息。LlamaIndex里负责这类累积的是ChatMemoryBuffer，接入位置在LlamaIndex服务处理对话请求的入口处。适用场景是：Continue通过自定义API地址把补全请求转发到LlamaIndex服务，再由LlamaIndex把整理好的上下文发给本地模型。

from llama_index.core.memory import ChatMemoryBuffer

# token_limit替换为模型能承受的对话历史上限
memory = ChatMemoryBuffer.from_defaults(token_limit=3000)

token_limit控制的是对话历史的总token量，不包括检索文档。取值可以从模型上下文窗口的四分之一到一半开始观察，不要直接填满窗口，因为后续还要给检索结果和系统提示词留位置。验证方式是看LlamaIndex服务日志中记录的实际请求长度：如果模型收到这个请求且不再报错，说明历史量已被控制住。

对检索文档做长度和数量裁剪

如果上下文里包含从本地文档检索来的节点，节点的数量和节点长度同时影响窗口占用。LlamaIndex的TokenTextSplitter可以控制每段文本的大小，检索器返回的节点数量则需要限制。一个节点的chunk_size设置过大，单条内容就可能占满剩余窗口。

from llama_index.core.node_parser import TokenTextSplitter

# chunk_size决定每个节点的长度，chunk_overlap是相邻节点重叠部分
splitter = TokenTextSplitter(chunk_size=512, chunk_overlap=64)

这三个参数属于此消彼长的关系。先固定top_k在较小的数值，再根据实际报错调整chunk_size和token_limit，比同时改三个参数更容易定位问题。

修复后的验证步骤

1. 用之前触发过溢出的同一段长对话测试，保持相同提问方式。
2. 在LlamaIndex服务日志里确认请求实际携带的token长度落在模型窗口内。
3. 触发一次文档检索回答，确认返回结果没有被截断。
4. 回看Continue日志，确认上下文长度检查没有继续拦截。
5. 把对话继续推进到之前溢出的轮次之后，确认后续提问仍能正常返回。

裁剪策略的作用是让上下文长度可控，这属于可直接验证的项；对模型输出质量的影响则无法直接核验，只能通过实际任务效果判断。遇到回答质量明显下降时，优先略微调大token_limit，而不是一次性放宽所有参数。保留一部分余量始终是必要的。