上下文窗口
大模型在单次推理中能够接收和处理的最大信息量限制，以Token数量衡量，决定了Agent可注入历史信息的上限，是影响长对话连贯性的核心约束。
核心事实
时间轴 (近 90 天)
上下文窗口是模型单次能读入的token总数上限。
长对话越到后面越贵，因为每发一句话，模型都会把前面的全部内容从头读一遍，读过的部分算缓存命中（价格低），没读过的按原价计。
大语言模型是无状态的，每次生成回复都要把当前对话的全部历史作为输入重新读一遍，这个最大长度叫上下文窗口，通常以 token 计量。
UP主建议将上下文窗口设置为一万左右，超出部分自动压缩成日记形式。
RAG还涉及上下文窗口约束：生成模型能接收的token数有限，召回文档过多会挤占空间并引入噪声，因此检索数量与重排精度需要与上下文预算联合调优。
传统聊天式 Agent 中，历史消息全部塞入上下文窗口，导致 token 数随轮次线性增长，推高显存占用（KV Cache 膨胀）并拖慢推理速度。
在代理产品中，一次会话通常对应一段独立的上下文窗口，包含用户指令、工具调用记录与中间结果。
工业故障排查往往需要同时参考设备日志、工艺参数、维修手册和物料批次等多源长文本，很容易超出上下文窗口，导致关键信息被截断或模型“遗忘”早期内容。
多智能体分工是缓解上下文窗口限制的工程手段：每个专用智能体只处理与本职责相关的片段，经理智能体汇总的是经过压缩的结论而非原始数据。
17GB 的权重文件序列化为文本后，token 数量远超当前主流模型的上下文窗口上限（通常为 128K 到 1M token）。
还有 40 条时间轴事件
全部知识事实 (20)
上下文窗口是指模型在单次对话中能处理的最大文本量，早期模型仅有4K Token，现代模型已扩展至数十万Token
90%已验证大语言模型的上下文窗口决定了模型在单次推理中能处理的信息量上限
90%已验证AI Agent 相比传统脚本具有不可预测性，存在幻觉、误解上下文、遭受 prompt 注入攻击等固有风险
80%已验证上下文长度与计算量呈近似平方级增长关系，受注意力机制影响
80%已验证研究表明当上下文过长时，模型对中间部分信息的注意力会显著下降，即"Lost in the Middle"现象
80%已验证长期记忆Agent通常基于RAG（检索增强生成）技术构建，通过向量数据库将信息转化为高维向量并持久化存储
80%已验证大语言模型在长时间对话中会因上下文窗口限制而丢失早期信息
80%已验证在大语言模型的对话架构中，System Prompt具有最高优先级，能够持续影响模型在整个会话中的行为边界
80%已验证当新信息与旧记忆冲突时，记忆层必须能够识别并更新，而非固守过时认知
80%已验证KV cache 占用的显存随上下文长度和对话轮次增长，是长上下文部署中显存与延迟的主要来源。
75%已验证上下文窗口指模型单次推理能够看到的 token 总量，包含输入与输出；注意力机制计算量随序列长度呈平方级增长。
75%已验证上下文窗口指模型单次推理能容纳的输入token上限，系统提示、用户消息、工具结果和对话历史共享这一预算，超出后要么截断要么报错。
75%已验证上下文窗口决定模型单次推理能看到的最大Token数量，当项目文件超出窗口后模型会遗忘早期内容，导致前后不一致的代码甚至报错
75%已验证上下文窗口指模型一次能读取的输入总量，输出窗口指模型一次能连续生成的文本上限
75%已验证大语言模型的计费单位通常以token计量，token是模型处理文本的基本单元
75%已验证主流技能包执行方式是将技能指令加载到智能体的上下文窗口中，依赖智能体自身理解并遵循这些指令
75%已验证上下文窗口扩展会带来计算成本的平方级增长，超长上下文存在'中间遗忘'问题
75%已验证在AI工具普及的时代，人类记忆作为信息存储介质的功能价值发生了根本性贬值
75%已验证In large language models, a Token is the smallest unit of text that a model processes
75%已验证过度的提前思考会带来延迟和计算成本的上升，在追求响应速度的场景中未必合算
75%