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

过去两年，「RAG已死」的论调每隔几个月就会刷屏一轮。理由听起来很直白：上下文窗口已经扩展到百万token级别，何必再做检索，把东西全塞进去不就完了？但这是一个误解，而且是成本高昂的那种。RAG没有死，它只是从技术的「C位」退下来，变成了Agent记忆系统中的一个组成层级。真正的问题从来不是「要不要检索」，而是四个更底层的问题：什么该进上下文、什么不该进、什么时候清理、清丢了如何恢复。这四个问题的答案，构成了Agent记忆系统的完整图景。

三桶法则与落盘纪律

关于记忆的分层，业界已给出相当清晰的工程切分：记忆分为四层，越往下越稳定、越持久、越需要人工确认。第一层是工作上下文（Working context），承载当前请求中的对话、工具结果与推理过程，压缩和清理只作用于这一层；第二层是会话产物（Session artifacts），包括进度文件、待办清单、设计文档和代码提交，跟随任务生命周期，是跨阶段交接的主力；第三层是项目记忆（Project memory），如AGENTS.md、CLAUDE.md这类约定文件，每次会话开头加载，压缩后会重新注入，社区共识是控制在200行以内，只放长期稳定的规则；第四层是个人记忆，跨项目沉淀偏好与习惯，只做索引，详情按需读取。

这个分层的核心价值，在于把两个经常被混淆的问题彻底拆开：压缩（compaction）解决的是「现在装不装得下」，是工作台的整洁问题；记忆（memory）解决的是「下次还记不记得」，是仓库的盘点问题。拿压缩这种工作台的手段，去解决跨会话遗忘这种仓库的问题，注定两头不讨好。用一个工程类比来说明：工作上下文像栈帧，方法结束即销毁；会话产物像堆内存，跟随任务生命周期；项目记忆像元空间，常驻但只存放「类」级别的稳定内容。栈里塞再多数据，也替代不了堆和元空间的分工。

从多年企业级Agent落地经验来看，上下文退化是一个必须正视的物理规律。Anthropic将其命名为Context Rot（上下文腐烂）：模型的注意力存在预算，token之间两两关联，上下文越长，注意力摊得越薄，召回越容易遗漏。关键在于，这是斜坡而非悬崖——模型不会在某个长度突然崩溃，而是越往后走、遗漏概率越大。有实测数据显示，8k上下文时召回率96%，128k时跌至34%，256k时仅剩14.7%，退化从三分之一窗口处就已开始。独立测试也印证了这一点：同一个30轮编码任务中，直接清空最省钱但关键事实早早丢失；摘要压缩能保住事实却只省10%成本，因为压缩调用本身就要读一遍近乎全文；裁剪与卸载有条件依赖；子Agent隔离保住了事实但token开销巨大。没有银弹，但有可复用的组合拳：入口处工具结果先落盘、关键事实写进钉住块或记忆文件、设置阈值兜底、只有「长输出、短答案」的子任务才交给子Agent。

压缩策略的失败模式在生产环境中反复出现，值得逐条对照。一是丢失决策与约束：会话开头强调的规则，几十轮后在摘要中只剩一行甚至消失，对策是把重要规则写入项目记忆文件，压缩后重新注入；二是细节被摘要掉：模型执行压缩的那一刻，恰是其状态最差的Context Rot峰值时刻，因此不要等自动压缩，应主动压缩并明确告知模型接下来要做什么、什么必须留下；三是反复压缩漂移：摘要的摘要的摘要，十几次后意图早已偏离，想用「更好的摘要」修复「坏摘要」多半行不通；四是压缩不免费：它是一次模型调用，触发点不能顶着窗口上限，压得太频繁又会反复破坏缓存——实测显示入口处改一次配置可保住93%缓存命中，而压缩和清空会把缓存命中率打到86.9%和88.2%。正确姿势是三桶法则：丢了不心疼的先扔（Drop），只在本会话有用的做摘要（Summarize），丢了会出事、跨会话还要用的一律落盘（Write to file）。核心就一句话：重要的东西，别让它只活在上下文里。

RAG没有死，它只是从「C位」变成了记忆系统里负责「需要时把外部知识捞进来」的那个零件。喊「RAG已死」的人，错把「窗口变大」当成了「记忆问题消失」。窗口是工作台，不是仓库；工作台再大，不收拾也会乱。四层架构、三桶法则、一份落盘清单，就是收拾它的完整方法。