「RAG已死」是最大误解：拆解Agent记忆系统的四层架构与实战策略

近两年，「RAG已死」的说法每隔几个月就会在技术圈流传一轮。理由看似直白：既然上下文窗口已经扩展到百万token级别，为什么还要费劲做检索，把所有内容直接塞进去不就行了？这是一个误解，而且是成本很高的那种。事实上，RAG并未消亡，它只是从架构的核心位置退下来，成为Agent记忆系统中的一个组成层级。真正需要回答的问题从来不是「要不要检索」，而是四个更底层的命题：什么该进上下文、什么不该进、什么时候清理、清丢了如何恢复。

记忆不是一块，是四层

记忆系统并非铁板一块，业界最新的工程实践给出了一个清晰的四层切分：工作上下文（Working Context）承载当前请求中的对话、工具结果与推理过程，压缩与清理只作用于这一层；会话产物（Session Artifacts）包括进度文件、任务清单、设计文档与代码提交，跟随任务生命周期，是跨会话交接的主力；项目记忆（Project Memory）如AGENTS.md等约定文件，存放构建命令、代码规范与踩坑记录，每次会话开头加载，社区共识是控制在200行以内；个人记忆（Personal Memory）则记录跨项目的偏好习惯，只做索引，详情按需读取。

上下文腐烂是斜坡不是悬崖

Anthropic在上下文工程指南中提出了「Context Rot（上下文腐烂）」概念：模型的注意力是有预算的，token之间两两关联，上下文越长，注意力摊得越薄，召回就越容易遗漏。关键在于，这种退化是斜坡而非悬崖——模型不会在某个长度突然崩溃，而是越往后走、漏掉关键信息的概率越大。独立测试也印证了这一点：8k上下文时召回率达96%，128k时降至34%，256k时仅剩14.7%，且退化从窗口三分之一处就开始了。因此「窗口大就不用管记忆」是错误的，窗口越大越要管理，只是手法不同。

30个产品实测：没有银弹

从多年产业实践经验来看，光讲理论远远不够，实测数据更有说服力。有开发者拿同一个30轮的编码工单——第3轮读到端口5433这个事实，第28轮才用到——在30个产品上测试了8种上下文策略。结果很有嚼头：直接清空最省钱，成本降到约五分之一，但关键事实在第17轮就丢了；摘要压缩保住了事实，却只省10%，因为压缩调用本身要读一遍近乎全文的上下文，一次就消耗10万token还吃不到缓存；裁剪与卸载能省到五分之一，但保住事实依赖运气条件；子Agent隔离保住了事实，代价却是5次调用加5万token。没有银弹，但存在一个值得直接借鉴的通用组合：入口处让工具结果先落盘、关键事实写入钉住区块或记忆文件、设置阈值兜底、只有「长输出短答案」的子任务才交给子Agent。此外还有一个容易被忽视的缓存教训：压缩省下的token，可能以缓存失效的形式又吐回去一部分。

三桶法则与写入门禁

压缩为什么会失败？生产环境踩出来的四种败因值得警惕：一是丢决策和约束，会话开头「别碰公共API」的规则几十轮后在摘要里消失，对策是重要规则写进项目记忆文件，压缩后重新注入；二是细节被摘要掉，且模型执行压缩时恰是它状态最差的时刻；三是反复压缩漂移，摘要的摘要十几次后意图早已偏移，用「更好的摘要」修「坏摘要」多半行不通；四是压缩本身不免费，它是一次模型调用，触发时机本身就是权衡。正确姿势是三桶法则：按「丢了会不会出事」把上下文内容分三桶——可随时重取的先清（Drop）、仅本会话有用的做摘要（Summarize）、丢失会出事的落盘到文件（Write to file）。开源产品agent-beacon也提供了现成范本：跨工具抓取会话历史提炼工作流模式，经人工审核门禁后再通过MCP与Skills按需复用，本地化存储，正是「记忆只做索引、详情按需读」的实践。

回到开头的误解：RAG没有死，它只是从核心位置变成了记忆系统中负责「需要时把外部知识捞进来」的那个零件。窗口是工作台，不是仓库；工作台再大，不收拾也会乱。四层架构、三个桶、一份清单，就是收拾它的完整方法论。