AI上下文管理史

一、在介绍之前，我先说说AI为什么一定要进行上下文管理？

1.根据自注意力机制（Self-Attention），模型在理解一句话的时候，会对每一个token进行一次对上下文中其他所有token的相关度计算，上下文越多，计算量会平方级的爆炸（2*2是1*1的四倍）。

2.大模型的本质是，就是及其庞大的矩阵加乘（因为进行的是加权运算），运行时会有几百上千亿个参数在运算。这种运算，在如今传统电脑结构下，这些运算只适合在GPU（由上万个简单计算单元组成，很适配大模型的运算）上运行。而为了减少大量的重复运算，GPU会缓存运算结果在容量小的GPU显存（GPU的结构使它容量极小）上，这个大小是有限度的。

这就是为什么现在显卡炒上天价的原因了，因为显卡的核心部件是GPU，而现在全世界只有英伟达做得好，他们有定价权，自然要炒上天。

有的人会说，硬盘价格翻了一倍，和这个有关系吗，我的个人拙见是没有的，这个只是正常的价格周期。

即使我们有无限的算力，并且开发了一个内存超级大的GPU，仍然还存在如下问题。

3.研究表明，大模型对上下文的开头（Prompt 顶部）和结尾（最新提问）注意力最集中，而对于堆积在长长中间部分的内容，注意力权重会断崖式下跌，这就是迷失在中间效应（Lost in the Middle）。

举个经典的人类语言例子：

“动物没穿过马路，因为它太累了。”

“动物没穿过马路，因为它太宽了。”

第一句里的“它”指的是“动物”；第二句里的“它”指的是“马路”。人类不需要学语法就能秒懂，但 AI 怎么判断？

在 Transformer 内部，每个词都会向其他所有词“看一眼”，并计算一个关联度分数（注意力权重）：

第一阶段在gpt-3，gpt-3.5刚出来的时候（2020-2022）

上下文窗口只有可怜的2k-4k这么多token，随便聊几轮窗口直接撑爆了。

这时候人们使用的是最朴素的代码层面机械裁剪，也就是FIFO（First-In, First-Out），他会暴力砍掉最早的一部分，包括系统提示词。

后面也有打补丁形成滑动窗口（sliding windows）：保留System Prompt（人设与核心规则）的暴力砍掉。

这样的后果是AI 聊着聊着就会完全忘记核心约束和前因后果，甚至开始前后自相矛盾。

第二阶段：RAG时代（2023）

人们提出了新的想法：不把完整的历史一股脑塞进 Prompt（提示词） 里，而是把过去的对话、文档切成文本块（chunk），算成向量（Embedding）存进向量数据库。

embedding模型是什么？举个二维向量例子，假如有个平面，横轴值（x轴）：离可爱动物有多近；纵轴值（y轴）：离危险武器有多近。

那么在embedding模型中，小狗为（0.9,0.1），手榴弹为（0.02,0.98），所以模型判断小狗大概率为可爱动物，手榴弹大概率为危险武器。

举个现实生活例子：用户在对话框里提问：“我刚买的东西不想要了，怎么退？”

但是！因为切法是数着token硬切，所以因果链会破坏；因为ai不会找最新最正确的答案，只会匹配最相似的答案，所以时序逻辑会断裂。

第三阶段：（2023 - 2024）

人们开始思考：人脑是怎么记事的？人脑也不会逐字背诵过去一个星期的对话，而是自动在脑海里形成摘要。

于是递归摘要（Recursive Summarization）出现了：

系统时刻监控 Token 数量。一旦历史达到阈值（例如用了 80%），后台就自动发起一个看不见的 Prompt：“请扮演速记员，把上面那几十轮对话提炼为 200 字的关键备忘录”。

但是会产生两个问题：

1.摘要税（Summary Tax）：为了压缩，必须频繁额外调用大模型来写摘要，白白增加了延迟和 5%~10% 的 API 账单。

2.传话游戏效应（Information Drift）：模型自己写的摘要经常遗漏关键的技术细节（如端口号、变量名），或者在反复“摘要旧摘要”的过程中产生滚雪球式的幻觉。

所以，在少数使用情况中，仍然对模型没有有效的提升。

第四阶段：（2024 - 2025）

随着 Agent（智能体）走入代码编写、终端操作等场景，工程师们突然发现了一个盲区：“智能体的上下文里，80% 以上的内容根本不是人在聊天，也不是思考过程，而是工具吐出的海量废话！（比如 cat 一个大文件的全文、npm install 吐出的一千行日志、测试框架跑出来的长篇 Traceback）”

于是工程师们在后台写了几行死板的 Python 脚本，在把历史送给大模型之前，直接机械执行了文字替换：

保留智能体做的决定、敲的命令（Actions），对于几步之前的命令返回结果（Observations），直接把它替换为 [输出内容已省略]。

零模型调用、零延迟、纯靠几行正则表达式就完成了极大比例的压缩。

但是也产生了问题：丢了具体报错细节后，AI 容易在后面迷航，不得不重新执行命令去查，拉长了解决任务的总步数，这个叫做轨迹延长（Trajectory Elongation）。

第五阶段：架构级隔离（2025-？）

随着单智能体在线性上下文中越陷越深，人类终于在系统架构上顿悟了：为什么非得在同一个上下文（Context Thread）里又干脏活、又做压缩呢？

人们发明了隔离（Context Isolation），具体为：

主 LLM 接收主任务（Task）：

比如：“请帮我把这个项目中的支付超时 Bug 修好”。

派生子代理（Spawn Subagent）：

主 LLM 不需要自己亲自去翻代码、跑测试。它调用一条 spawn 类似的操作，启动一个 Subagent（子进程/子智能体），把局部子任务（subtask，交给它。

于是，Subagent 在它自己独立、全新、干净的上下文空间里运行。它在自己的空间里疯狂调用工具都没关系，因为子代理的运行数据会在完成任务时自动被删除，最终只向主 LLM 提交一份干净干练的最终报告。

这样的话，主 LLM 的主干上下文永远保持极短、极干净、高信息密度。

这完美模拟了人类社会的组织架构：CEO（主 LLM）从来不会去看程序员修 Bug 时翻阅的 200 页 API 手册，他只需要部门主管（Subagent）汇报一句“已搞定，原因在第 48 行”。

而现在一些底层学术前沿也有新的发现，不过这里就不详细说明了。