写《AI 记忆栈》系列第一篇时,我明明想聊上下文窗口,结果写着写着就发现自己像一只在多个浏览器标签页之间反复横跳的仓鼠——一个标签里是“主权系统”术语表,另一个挂着《记忆即基础设施》的旧文,第三个是上下文水合笔记,旁边还有 SDK 规范页面、GitHub 仓库,以及几条架构决策记录。编辑器左边还躺着未完成的草稿。
单独看哪一份文件,都回答不了“下一步到底该怎么写”。可一旦把它们同时摊开在眼前,我的大脑就能开始比对、发现矛盾、产生新的判断。那堆文档并不是我的长期记忆,而是一套为这一次写作临时拼凑起来的“工作集”。
![]()
巧了,这正是现在所谓“智能体系统”里真实发生的事情。
很多人总觉得大模型一开始推理就得把所有东西一股脑塞进上下文窗口。但现实是:在模型收到第一个 token 之前,文档已经被检索过了,工具已经执行过了,状态已经恢复了,策略也评估完了,连各个接口返回的响应都已经被统一格式化。最后那个 prompt,通常是编排层一顿操作之后的最终产物,而不是起点。
这个组装出来的临时执行态,我把它叫做“主动工作记忆”。用计算机体系结构来类比:上下文窗口像是 CPU 缓存,速度快、专为当前运算而生,任务一结束就清空;但缓存不会自己填充——主动工作记忆就是填充缓存的那一层,像传统冯·诺依曼架构里的 RAM,负责在推理开始之前,把需要的信息组织好、摆到执行面上。
一张图就能说清这层关系:你看到的那些浏览器标签、文档工具、外部服务返回的数据,先汇集进主动工作记忆,再由主动工作记忆送入上下文窗口,最后才喂给模型用做推理。主动工作记忆与上下文窗口,虽然在概念上挨得很近,但承担的是完全不同的职责。
这种分工,意味着你不能把“该检索什么”“哪个工具的结果过期了”“哪一份 ADR 能指导本次改动”这类决定丢给模型本身去处理。模型不会去翻 Git 提交记录,也分不清工具响应的时效性。这些判别的活儿,必须在进入上下文窗口之前,由主动工作记忆这一层完成。
举个例子:你让一个智能体去更新某 Python SDK。它在构建 prompt 之前,会先拉取定义包边界的架构决策记录,加载“主动工作记忆”这个术语的当前定义,再扫一眼 GitHub 上最新的代码实现。这些材料全都拉到眼前之后,才开始着手拼装最终送给模型的那段 prompt。
换句话说,我们过去爱泛泛地讲“上下文窗口是 AI 的记忆”,这句话其实只描述了一半。真正的记忆栈至少还得再分出两层:一层是紧挨着推理、一闪即逝的上下文窗口,另一层则是在它上游负责组装、筛选、维持一致性状态的主动工作记忆。把这两层拆开,你才能解释为什么有些智能体在复杂任务里会反复横跳、自我打脸——不是模型菜,很可能是它的“RAM”里塞进了过期或矛盾的东西。
所以下次你对着一个智能体的拉胯表现叹气时,不妨先问问:它的主动工作记忆,到底组装了些什么玩意进去?
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.