上下文窗口是智能体最重要的稀缺资源

我在 2024 年初第一次把一个 AI 编程助手塞进生产流水线里时，曾经以为自己最大的挑战是 prompt 写得好不好，或者模型选哪个版本。当时那段流水线的核心逻辑是靠一个 gpt-4-0125-preview 的 128K 上下文窗口来“记住”整个代码仓库的结构，我把三个核心模块的接口文档、历史变更记录、最近 10 条 issue 全拼接在一起，心想 128K 就是多到用不完，应该是数字游戏里最不必担心的一张牌。但两周之后，在一次合并请求里，它开始坚持要新建一个早就废弃的函数，而那个函数被标记“禁止使用”的注释就明明白白写在它的输入第 200 行，但那些文字，落到了它从未真正去看的盲区里。

那个时刻我意识到，我之前所有的优化，模型温度、工具选择、重试策略，其实都只是在岸边调整风帆，而上下文窗口才是我真正在航行的那艘船。它的上限，并不是一个可选的配置项，而是整个智能体系统的物理常量——对于运行在真实时间线上的智能体来说，上下文窗口的使用效率，比其他所有资源都更直接地决定了它能否完成任务。

当模型“忘记”时发生了什么

人们很容易把上下文窗口简单地理解成一个“能记住最近多少轮对话”的数字，但它的另一个名字是 “当前推理可触及的全部世界”。一个智能体在生成下一个 token 时，只能基于所有在这一窗口内还存活的内容来做决策。一旦一条信息从这个窗口里滑落出去，它对这个智能体而言，就等同于从未存在过。

这个现象在 2023 年的一次经典实验中被称作 “lost in the middle”：研究者发现，即使多模态或长文本模型声明了很大的上下文窗口，它们对中间部分信息的关注度依然会显著衰减，远不如对开头和结尾的内容敏感。我后来在一个自动化方案书生成器里亲眼看到这个现象：系统同时给出了 12 页用户需求、3 个竞品分析片段以及结构模板，模型在使用 gpt-3.5-turbo-0125 的 16K 窗口时，把竞品信息中排在最中间那段技术对比直接略过，最终生成的方案书里甚至重复了另外两个竞品的结论，唯独缺了中间那段最关键的性能参数。

来自开发者社区的大量案例也印证了这种“上下文损耗”不是偶发 bug，而是底层注意力机制带来的系统性问题。

经验框：上下文窗口不是摄影棚，而是手电筒

想象智能体在黑暗的仓库里举着手电筒看书架。书架上当然有 128,000 本或更多书，但手电筒的光每次只能照亮一小段。对于这一小段里的每一个字，光照是均匀的；但当书架长到一定程度时，中间区域会因为移动距离和视角变化变得模糊不清。这个手电筒光斑半径，就是模型真实有效的推理视野。模型提供商标称的 128K、200K “最大上下文” 是书架总长度，不是它能在推理时稳稳看透的距离。lost in the middle 是光的衰减，不是书的排列错误。

在实际开发中，上下文窗口耗尽有一个比“遗忘”更危险的形态：智能体不会报错，它只是开始做错决定。比如对于一个自动化运维智能体，当系统日志、报警上下文和历史决策链条把窗口挤压到极限后，它不会再触发超窗异常；它只是会坚定地建议重启一个在上下文已消失部分中被说明过“绝对不能重启”的核心服务——因为它已经看不见那条禁令了。这种不可见的、无预警的崩坏，远比一个直接返回“context length exceeded” 的 HTTP 400 错误更加致命。

对比表格：上下文窗口溢出信号 vs. 模型能力不足

解读这个表格的关键结论：上下文窗口耗尽的典型特征是既有的、本应在系统里的信息“消失”了，而模型自身的推理闭包并没有损坏。这意味着，当智能体违反了它“原本知道”的事时，你首先要怀疑的不是模型变笨了，而是上下文窗口替你动了手术。

上下文作为虚拟工作内存

如果把 AI 智能体类比为计算机系统，上下文窗口就是它的 RAM，而不是硬盘，更不是归档文件柜。LLM 本身是一个无状态的函数，它不记得上一次你调用了它什么参数，也不记得它在 30 秒前还下过一个坚定的结论。智能体的完整“意识”在执行过程中，全部取决于当前这串被塞进模型的输入 token——这里面可以包含对话历史、工具返回结果、参数记忆、规划步骤，但它必须被装载在上下文窗口的内部。

这引出了一个在技术讨论中容易被忽视的事实：上下文窗口的竞争，本质上是智能体不同记忆模块对同一片稀缺内存的竞争。

想象一个同时需要阅读长文档、调用工具链、并维持多轮谈判对话的采购代理智能体，它的上下文窗口需要同时容纳：

• 刚检索出的三份投标书全文，大约 45,000 tokens
• 谈判策略和角色指令，约 1,200 tokens
• 工具调用的 JSON 响应与状态码，约 2,000 tokens
• 过往五轮对话的完整历史，约 12,000 tokens
• 最终的格式化输出模板，1,500 tokens

如果这个智能体用的是 64K 上下文窗口，这一切看起来尚有富余；但实际体验中，随着投标书长度变动、工具返回的异常日志突然增多、或者谈判轮次多走了两回合，总 token 数会像倒水一样灌满整个窗口，而最先被挤出“手电筒光斑”的，通常是那些最早被写进去并且最不该被遗忘的东西：比如，“你是一个严格遵守价格上限的采购代理，绝不超过 48 万欧元”这个关键指令，可能躺在对话的最开头。

每一块新的输入、每一次工具返回、或每一条为了“连续性”而保留的历史记录，都在暗中从这同一个固定大小的池子里取水。因此，把上下文窗口称为智能体的虚拟工作内存，不只是比喻，而是精确的工程定位：这是一个不断更新的执行页面，其大小是硬性限制，其管理是架构决策。

核心建议框：对待上下文预算，像对待内存预算一样

在嵌入式系统里，你不会把一整个文件系统映射到内存；你会把当前任务所需的最小工作集加载进去。对于智能体系统，这个原则同样适用：不要把你手头有的所有信息塞给模型，只把当前决策必须的上下文交到它手上。这意味着一条让很多开发者不舒服的规矩：你必须在检索、记忆、工具之间做出有意识的取舍，而不是靠“把什么都放上去”来获得安全感。

治理目标：一致性、持久性与可扩展性

既然上下文窗口是一个固定的限制，而其内部承载的要素又在实时变化，那么一套治理上下文的方法论就必须回答三个核心问题：

• 一致性：在上下文窗口内容不断滚动的过程中，如何保证智能体始终做出一致的决策？更具体地说，当一段关键指令滑出手电筒光斑时，系统是否还有机制让它继续起作用？
• 持久性：上下文窗口天然是“会话级”的，一旦会话结束、窗口清空，智能体就彻底失忆。那么，什么工作记忆应该被刻意保留到下一次会话？什么又从设计上注定只能短暂存在？
• 可扩展性：当系统处理的任务越来越长、工具链路越来越深、多智能体协作时，每增加一个新组件都意味着对上下文窗口的额外消耗。怎样的窗口治理策略，能让智能体在面对更复杂任务时，不会因为内部竞争而直接跌入“滑落区”？

这三个问题不是并列的可选项，而是一条逻辑链。可以把它比喻成一个城市的地下管网：一致性是确保任何拧开水龙头的人都能喝到干净的水，不管这水是从城市那头的主管道流过来的，还是从靠近末端的蓄水池顶上去的。持久性是决定哪些管道是永久性基础设施，哪些只是工地的临时引水管。可扩展性是当城市扩张十倍的时候，这套管网不会在某个节点因压力过大而爆裂。

在很多实际的智能体架构设计中，反馈出问题的第一声警告很少是“我记不住细节了”，而是“它好像变了个人”。比如前面提到的采购代理，如果它在前五轮对话里始终坚持价格上限，到第六轮忽然接受一个高报价，这并不是模型忽然学会了妥协，而是那条“绝不超 48 万欧元”的指令要么被挤出窗口，要么落入了 lost in the middle 的注意力盲区。这是一致性问题。

持久性则是另一层挑战。开发者很容易迷恋“把完整对话历史存下来，下次再传给模型”这种做法，但这相当于把全部历史记忆永久锁定在上下文窗口内，导致每一次新的会话都背负着越来越重的包袱，直到触发超窗。而且，这些历史一旦被原封不动塞回去，就还要再次承受 lost in the middle 的影响，形成恶性堆叠。

可扩展性则指向多智能体或多步骤工作流：每一个子智能体的规划输出、工具结果、状态返回，都需要在“主控”智能体的窗口里分一杯羹。如果不对这些信息进行分类、分级和生命周期设定，上下文窗口很快就会变为垃圾邮件文件夹。

从当下一线框架设计的趋势来看（截至 2026 年初的公开项目资料），解决这三个问题的主流方向正在从“管理窗口内容”迁移到“让窗口之外的记忆机制与窗口内的执行页面协调配合”上。也就是说，上下文窗口治理的终极目标，不是把有限窗口塞得更满，而是让系统学会在窗口边界内外主动调度信息。这个方向上的探索，正是下一章将要讨论的从无状态调用到有状态智能体的范式迁移：因为只要智能体还是“一锤子买卖”的无状态调用，它的上下文治理本质上就只是一次性的手工清理；只有当智能体活得够长、任务够复杂时，一致性、持久性、可扩展性才会从纸面上的框架问题，变成日常调试中你每天都要接住的滚烫现实。