Agent长期记忆怎么做：RAG与文件式记忆对比

作者：da吃一鲸8862026.11.04 12:21浏览量：0

简介：上下文窗口有限，Agent的长任务记忆该怎么建？本文对比RAG式检索记忆与文件式结构化记忆两类主流方案，从信息进入上下文的方式、占用与密度、接入与运维成本、规模上限等维度拆解差异，说明长任务场景为何更推荐文件式记忆，并给出分层组合的选型思路与迁移注意事项，帮助开发者快速做出适配自身场景的技术决策。

一、对比背景：窗口写满之后，记忆放在哪里

上下文窗口是Agent体系中最稀缺的资源之一。一个持续数十轮对话的长任务，很容易产生数以万计的token。窗口内部最常见的处理思路是三板斧：扔掉、压缩、落盘。

  • 扔掉：把最早的对话移出窗口，只保留最近上下文。实现最简单，但关键信息会随窗口滚动而遗失——被推翻的旧实现、项目总体愿景、关键技术约束和决策理由一旦丢失，模型就会“失忆”：忘了自己在做什么、为什么这么做，后续产出随之跑偏。
  • 压缩：对历史对话做摘要，保留关键决策及其理由（为什么选方案B而不是方案A）、未完成事项及其状态（某模块完成70%，卡在子逻辑上）、中间结论（测试环境已配好，跑通了3个用例）；扔掉工具原始输出（报错堆栈、终端刷屏）、琐碎过程（改了几版、错了几次）和客套话（“好的”“明白了”“我来修改”）。一个五万token的长对话，压缩后可能只需数百token的关键摘要，上下文占用能下降99%左右，且信息质量更高——全是决策与结论，没有噪音。
  • 落盘：把状态写到上下文外部，需要时再取回。

扔和压属于窗口内策略，解决的是“留下什么”；但当任务足够长、信息足够多时，窗口内策略存在天花板，必须走向“在上下文外部建立记忆”。外部记忆有两种常见实现路径，这正是本文要对比的两个对象。

二、对象定义：两种外部记忆方案

方案A：RAG式检索记忆。 将历史对话、文档、中间产物切分后存入向量库等索引结构，Agent工作时按语义相似度“按需检索”相关片段，拼回上下文。它是“外部记忆+检索”的经典组合。

方案B：文件式结构化记忆。 Agent直接在文件系统里维护人类可读的结构化笔记文件，例如一份todo清单（每完成一项勾掉一项）、一份决策记录（为什么这么做）、一份状态说明（当前正在处理哪个任务、接下来做什么）。现代编码类Agent普遍采用以Markdown为代表的文本文件作为记忆载体。

两者的共同母题一致：把装不下的信息挪到窗口外，再想办法取回来。差异在于“怎么存、怎么取”。

三、相同点：它们共享的底层逻辑

  1. 目标一致：都在窗口稀缺的前提下保留长期信息，避免“失忆”导致产出偏移。
  2. 都必须与窗口压缩配合：取回的内容仍要占窗口，无论检索还是读文件，取回后都需要筛选与摘要，不能整段塞入。
  3. 都依赖同一套信息筛选标准：值得长期保存的是决策与理由、未完成事项与状态、中间结论；应当丢弃的是工具原始输出、琐碎过程、客套话。这套标准对两种方案同样适用。
  4. 都不会自动发生：记忆需要Agent在工作流中主动写入、主动更新，提示词设计与工程约定缺一不可。

四、核心差异：优劣从何而来

1. 信息进入上下文的方式：语义召回 vs 主动读取

RAG靠语义相似度召回片段，优势是能从海量信息中自动找出相关内容；代价是引入了“检索质量决定一切”的风险——检错了、检漏了，上下文就不完整，而Agent对残缺上下文毫无感知，会在错误前提下继续推理，误差沿任务链路被放大。

文件式记忆中，读哪个文件、读哪一段由Agent自己决定，取回的是它自己写下的、结构完整的信息，不存在“召回率”这一不确定性来源。

2. 上下文占用：检回即占窗 vs 天然高密度

RAG即使检对了，检回来的一大段原文照样占窗口；长任务中反复检索，窗口很快再次被塞满，又回到压缩—腾挪的循环。文件式记忆保存的本身就是高密度摘要——全是状态、决策、待办，没有过程噪音，读入即用，占用小。

3. 架构与接入复杂度

RAG链路长：文档切分策略、向量化、索引存储、检索排序，每一环都影响最终效果，调优需要持续投入。文件式几乎零基础设施：具备文件读写能力即可起步，主要成本在于设计好记忆文件的目录结构与读写约定（何时读、何时写、何时归档）。

4. 规模上限

RAG天然面向海量非结构化信息，规模天花板高。文件式适合“状态型”信息，规模可控；一旦面对成千上万份历史文档，纯靠Agent翻文件会力不从心。

5. 调试与运维

RAG的效果不直观，bad case需要沿切分→向量化→排序整条链路排查。文件式记忆人类可读可查，调试直观，还能复用通用的版本管理习惯。

6. 成本结构

RAG前期建设与调优的人力成本高，运行时有向量化与检索的计算开销；文件式实现成本低，但依赖提示词约束模型行为（先读记忆再干活、干完活更新记忆），工程约定的维护是隐性成本。

五、对比表格

维度 RAG式检索记忆 文件式结构化记忆
核心机制 外部记忆+语义检索按需召回 文件系统+结构化笔记主动读写
信息形态 原始内容切分后的片段 压缩后的决策/状态/待办
上下文占用 检回内容较大，需二次压缩 天然高密度摘要，占用小
确定性 依赖检索质量，存在检错检漏风险 Agent自读自写，确定性高
接入复杂度 高（切分、向量化、索引、排序） 低（文件读写即可起步）
规模上限 高，适合海量信息 中，适合状态型信息
调试运维 链路长，排查成本高 直观可读，易于维护
典型场景 海量文档问答、知识库助手 长任务编码Agent、状态跟踪

六、典型场景选择

  • 长任务编码、多步骤执行：文件式优先。todo清单逐项勾选、决策落盘，任务状态随时可恢复。
  • 海量文档问答、知识库助手：RAG优先，信息规模已超出维护结构化文件的能力范围。
  • 复杂长程Agent：分层组合——文件式承载“工作状态”，RAG承载“海量参考资料”，窗口压缩兜底。

七、选型建议

  • 核心诉求是“跨长任务不丢工作状态”→ 文件式结构化记忆是当前更主流的实践；
  • 核心诉求是“在海量历史信息中找到相关片段”→ RAG仍不可替代；
  • 团队工程能力有限、希望快速落地 → 文件式起步成本更低；
  • 两者并非互斥，按信息形态分层组合，通常优于二选一。

落地时无论选择哪种方案，都可以使用通用云组件搭建，例如以对象存储保存记忆文件、以向量检索服务支撑RAG链路——百度智能云等平台均提供此类基础能力，选型时建议关注能力与场景的匹配度，而非单一组件绑定。

八、迁移与使用注意事项

  1. 从RAG转向文件式：需重新设计提示词，明确Agent何时读写记忆文件；存量历史信息应整理为结构化笔记，避免“裸迁移”导致记忆真空。
  2. 从文件式扩展RAG：注意记忆文件的切分粒度与索引更新时机，保证检索结果与最新状态一致。
  3. 通用注意事项：控制写回频率，避免频繁读写拖慢执行；设计归档与清理机制，防止记忆文件自身膨胀成新的“窗口”；记忆内容若含敏感信息，需做好权限控制与数据隔离。

示意性伪代码（通用示例）：

  1. # Agent 工作循环中的记忆读写约定（伪代码）
  2. memory = read("MEMORY.md")          # 开工先读长期记忆
  3. todo   = read("TODO.md")            # 读取任务状态
  4. while not task.done():
  5.     step = llm(system_prompt, memory, todo, recent_window)
  6.     if step.has_decision:
  7.         append("MEMORY.md", step.decision_summary)  # 决策落盘
  8.     if step.has_status_change:
  9.         update("TODO.md", step.new_status)          # 状态更新
  10. archive(compress(recent_window))    # 收尾时压缩归档

九、总结

Agent记忆管理的完整图景是“扔、压、外置”三件套：扔掉噪音、压缩关键信息是窗口内的基本功；任务够长时，外部记忆是必需品。RAG只是外部记忆“按需检索”的一种实现方式，并非长任务记忆的默认最优解——检索质量风险与回填占窗是它的两块短板；文件式结构化记忆以高密度、高确定性、低接入成本的优势，成为长任务状态管理的当前主流实践。选型的关键不在“哪个更好”，而在“信息是什么形态”：状态型信息交给文件，海量知识交给检索，再以窗口压缩兜底，才是稳健的组合。

最热文章