上下文窗口是什么？模型一次能处理的内容与遗忘边界
用多份合同问答解释上下文窗口，区分输入长度、输出上限和长期记忆，说明预算核算与长资料测试，避免把支持长度当成完整理解保证。
先理解这个概念
上下文窗口是模型一次处理所能容纳的词元范围，涉及当前请求使用的内容。系统指令与历史消息也可能占用预算，不同模型对输入、输出及思考词元的限制方式需要分别核对。窗口大不等于模型永久记住资料，也不保证能准确找出长文中的所有细节；超过限制可能报错或触发截断等处理。
先核对本次请求实际带入的内容
假设要比较三份合同，真正进入请求的可能包括文件正文和之前几轮讨论。界面仍显示旧聊天，不代表后台全部发送给模型；系统可能做过摘要或删除较早消息。判断回答遗漏时，应先检查实际输入，聊天记录长度不能替代这项核对。
窗口使用词元计算，不能用中文字符数或文件页数直接代替。图片等多模态输入也有对应的计算方式。使用目标模型的计数工具估算，再预留回答空间，才能更接近实际限制。本文不提供对所有模型通用的换算比例。
输出上限与上下文总量需要分开
有的模型让输入与输出共享总预算，有的还提供单独输入或输出限制。不能看到一个很大的窗口数字，就要求生成同样长度的回答。还应核对当前接口参数和模型版本，思考型模型可能另有预算与停止原因需要记录。
如果长合同占满输入，模型可能没有足够空间输出完整对照。可以先提取相关条款或分段处理，但分段以后要保留来源编号，防止把不同合同条件混在一起。减少无关内容属于输入设计，不能以删掉关键例外换取更短请求。
长窗口能力仍需用多处细节来检查
测试时不只问一处容易找到的句子，还可以检查分散在多页的例外条件。逐项对照原文，观察模型是否遗漏或混淆。Google长上下文资料也说明多处信息检索可能与单点查找表现不同，支持长度本身不是准确率承诺。
这里给出核查方法，没有上传合同或实测某款模型。若应用需要跨会话保存内容，应另行设计存储和检索，而不是依赖窗口无限扩展。保留摘要和原文的对应关系，才能在细节被压缩后找到证据恢复上下文。
核对来源
以下资料用于核对概念和方法。文中的示例与测试范围分别注明，实际使用时请核对所用工具的版本。