上下文窗口(Context Window)

上下文窗口不是模型的大脑容量，也不是训练语料的总和。Anthropic 将它说明为模型生成回应时可引用的全部文本，包括回应本身，因此更接近一次任务中的工作记忆。模型能否引用某个事实，取决于它是否仍在这次请求的上下文中，以及该资料是否真的适用于当前问题。

参考：Claude Platform Docs

窗口大小是模型规格的一部分。OpenAI 的模型文档分别列出上下文窗口与最大输出 token；不同模型和接口的上限不同。选模型时只看一个“长上下文”数字不够，还要问：本轮要输入多少已批准材料、预期产物有多长，以及是否有工具或历史消息同时占用空间。

参考：OpenAI API

一次请求的输入可包括系统规则、对话历史、用户问题、检索片段、工具定义、工具结果、图片和文档；本轮生成的回答也会占用窗口。若只计算上传文件而没有为回答留出空间，模型可能无法完成预期格式，或请求在发送前就超过限制。Anthropic 的文档明确提示，所有这些组成部分都计入窗口。

参考：Claude Platform Docs

需要处理大量材料时，Google 将长上下文作为一种能力：模型可以接受更大的文本、文件或多模态输入。但容量不是资料质量规则；团队仍要按当前问题选择片段、说明来源，并检查模型与接口的实际限制。

参考：Google AI for Developers

把全部资料放进上下文，会同时带入过期参数、重复说法和不适用市场的信息。窗口只说明模型可以看到什么，不说明它应当相信什么。对外内容应优先放入经确认的事实、问题相关的片段和可见的来源；不确定的内容改为待确认项，而不是让模型用相邻文本补全。

更多上下文也不自动带来更好的回忆或判断。Anthropic 在其上下文管理说明中提示，随着 token 增多，准确性和回忆可能下降；因此需要管理历史内容，而非仅追求最大容量。对团队来说，这意味着每轮都应判断哪些内容仍有用，而不是把一次失败归因于“窗口不够大”。

参考：Claude Platform Docs

上下文窗口回答“模型此刻能看到多少”，知识检索回答“应从资料中找回哪些候选内容”，提示词工程回答“要完成什么任务、受哪些约束”。三者不能互相替代：检索找回的片段仍需选择进入窗口，提示词仍需说明输出与例外，关键事实仍由拥有业务信息的人确认。

当任务扩展为可调用工具的智能体时，工具定义、调用结果和会话历史也会消耗预算。应将每次工具返回限制为后续判断真正需要的字段，并在连续任务中检查旧结果是否还适用。这样既保留可追溯依据，也避免无关历史挤占当前对买家问题的回答空间。

参考：Claude Platform Docs

窗口管理的完成标准不是“塞进最多文件”，而是审核者能看出本次回答依据了哪些当前资料、哪些信息被标为待确认，以及模型是否仍有足够空间按约定格式交付。