Memory Enginnering, Dify在记忆工程上的探索

如果无法正常显示，请先停止浏览器的去广告插件。

1. Memory Engineering Dify 在记忆工程上的探索 Harry —— Backend Engineer @Dify.AI

2. 目录概览 01 02 为什么要有记忆管理工业界现状 Transformer 的根本限制应用层 vs 模型层 03 04 Dify 解决方案未来展望基于记忆架构的产品设计与实现关于 Memory 未来的思考

4. 为什么要有记忆管理？解决大模型"健忘"的根本问题

5. 大模型是无状态的 • LLM 的出现改变了 AI 的范式 • 但 Transformer 的设计让模型"没有记忆" • 每次调用都像重新认识世界，没有长期记忆

6. 模型没有"记忆"的代价 • 无法提炼出关键信息 • 无法判断哪些内容应该被遗忘 • 上下文越长，噪音越多，性能越差

7. 模型不知道"什么重要" 忘什么、记什么，这件事太主观模型本身也没和人类目标完全对齐就像人和人沟通常有偏差，模型也一样

8. 对话中的"目标偏移" • 一开始，用户让模型帮忙编写一个 API 文档。 • 随着对话深入，用户又询问了测试和部署的问题。 • 模型开始围绕新话题生成回答，逐渐忘记最初的任务目标。 • 最终输出的结果偏离了原意，这就是无状态模型的典型问题—— 它没有真正的任务记忆。

9. 无用信息拖慢模型 • 工具调用会返回大量数据 • 有用信息不到 10%，却占了 80% 的上下文 • 链接、图片地址等变成了"噪音" • 模型被这些冗余信息稀释了注意力

10. 无记忆模型的三大问题上下文稀释注意力退化性能问题重要信息被淹没在冗余中模型难以聚焦关键点上下文越长，速度越慢、成本越高

11. 重新审视上下文窗口并不应该把所有信息全部发给模型：将"上下文窗口"仅仅理解为容量大小是一种误导。它更应该被视为一个存在性能瓶颈的 "工作记忆"。

12. 第二部分工业界现状工程化 vs 模型内化的技术路径

13. 储存：文本 vs 张量文本记忆 (工程化方法) 张量记忆 (模型内化方法) • 人类可读、可审计、可编辑 • 高维、压缩的数学表示 • 高度的可移植性 • 对人类来说是不透明的表示 • 为 GPT-4 构建的记忆库可被 Claude 使用 • 难以直接编辑 • 系统具有可观测性 • 深度绑定于特定模型架构 • 易于调试和编辑 • 理论上具有更高效率 • 数据所有权清晰 • 与模型原生表示兼容

14. Memory 的两种实现路径模型内化记忆应用层工程化将 LLM 视为无状态的“处理单元”，在其外部构建完整的记忆从根本上改造 Transformer 架构，使其本身具备可读写的、持系统。开发者通过各种工程技术来管理和编排输入到模型上久化的内部状态。下文窗口中的信息。 • 学术研究的前沿方向 • 当前工业界主流方法 • 核心在于"改变模型" • 核心在于"管理上下文" • 记忆以张量形式存在 • 不改变底层模型

15. 类 RAG 记忆框架 Mem0 Zep LangGraph 提取对话关键信息 → 生成 • 把对话拆成结构化"知识图谱" • LangChain 出品 Embedding → 存入向量库 • 查询时按图谱关系检索 • 让模型自动生成知识节点（结构化 • 新版支持"图数据库"双存储 • 像AI的"脑图"，帮它理清人物与事 • 像是给模型加了个智能记事本 • 件信息） • 支持多会话共享记忆这三种方案都在"怎么记得更结构化"上下功夫。Mem0靠Embedding，Zep靠图谱，LangGraph让模型自己画知识图。这其实都还是数据数据库层的记忆。

16. Agent Memory：让模型'主动记' 自我判断与记忆选择核心决策机制迈向认知记忆模型开始具备自我判断与选择记忆的核心思路：让AI自己决定“要不要记”“ 虽然仍依赖提示工程，但更贴近“认知能力记什么”“怎么记” 记忆”

17. Agent 类记忆方案代表 Letta（MemGPT） • 模型自己判断重要信息并压缩存 SuperMemory • 储 • 类似"自我摘要"，实现模型可控记忆 • MemOS 通过特定提示语（"法咒"）让模 • 把记忆当作系统资源管理型更新记忆 • 分为短期（激活）、长期（参数实际仍是调用向量库，但用自然语言触发）、外部（知识库） • 像给AI装了个"记忆操作系统" 这些方案的想法都很有趣：Letta让模型自己写日记，SuperMemory靠提示更新记忆，而MemOS则是在构建一个AI的"记忆管理系统"，让模型能像人一样分类保存信息。

18. 各家应用层的核心科技：念法咒

19. 模型内化方法：在 Transformer 后引入记忆池概念与外部调整方案不同,模型内化方法旨在从根本上解决模型记忆问题,即让模型自身实现"有状态"记忆。这意味着记忆不再是外部管理的文本,而是模型内部参数的一部分,以张量 (tensors) 的形式存在。核心概念这类方法通常会在 Transformer 架构中引入一个额外的、可更新的"记忆池"(memory pool)。这个记忆池由一组专门的参数构成,可以在不进行完整模型再训练的情况下,被动态地读取和写入。

20. 代表性研究：MemoryLLM 与 M+ MemoryLLM M+：基于 MemoryLLM 的改进版本在 Llama 模型基础上增加了 10 亿参数的记忆池。这个记忆池引入专门的长期记忆机制和与模型协同训练的检索器，能够能够将过去的上下文信息压缩成一系列隐状态并存储起来。从记忆池中动态提取相关信息。 • • 它将 MemoryLLM 的有效知识保留范围从 MemoryLLM 的实验表明，当上下文长度超过 2 万个词元（tokens）时， MemoryLLM 的不足 2 万词元，大幅扩展到了超过 16 万词，MemoryLLM 的记忆保留能力会显著下降。万词元，并且没有显著增加 GPU 的开销。

21. MemoryLLM 记忆注入代码示例

22. MemoryLLM的记忆更新局限手动的记忆注入机制离散且非实时的更新 MemoryLLM 尽管实现了模型记忆的内化，但其记忆更新并这种更新机制是离散的、手动的，并且完全依赖外部操作触非自动发生在生成过程中。相反，它需要通过外部、手动的发。这意味着 MemoryLLM 无法像人类记忆一样在持续接收 inject_memory 函数调用来更新其记忆池。收新信息时自动、流畅地进行更新，限制了其在需要实时适应和持续学习场景中的应用。

23. 两种技术的优缺点工程化 Memory（外置型）模型内化 Memory（内置型）定义：外部存储 + 检索拼接定义：写入模型权重/激活优点：优点： • 易产品化迭代 • 真正内化理解 • 可追溯审计 • 泛化能力强 • 多租户友好缺点：缺点： • 难以追溯调试 • 检索误差影响质量 • 版本控制困难 • 维护成本高 • 多租户隔离复杂 • 模型不真正"理解" • 合规风险高

24. 现有应用层的通病：试图让 LLM 自主决定—— "什么是重要的？" "什么可以被遗忘？" "何时该更新记忆？" 模型主观性问题对问题复杂度的忽视 • 模型对"重要性"的判断主观且不可解释。 • 试图用封闭域解决开放域问题 • 记忆更新逻辑若交由模型，可能强化偏见或误删关键信 • 现实世界的记忆管理需规则、权限与共识。息。

25. 都在用封闭域的解决方案试图解决开放域的问题封闭域解决方案的特点开放域问题的复杂性 • 预设固定的规则和模式 • 用户需求千变万化，无法预设所有情况 • 适用于边界清晰、规则明确的场景 • 不同用户对"重要性"的定义完全不同 • 模型可以基于有限的选择做决策 • 上下文依赖性强，需要动态判断现有方案的局限为什么这种方法行不通 • Mem0、Zep 等试图用固定算法判断信息重要性 • 记忆的价值判断需要人类的价值观和目标导向 • 忽视了记忆管理本质上是个性化、主观的过程 • 不同应用场景需要不同的记忆策略 • 缺乏用户参与和控制机制 • 一刀切的解决方案无法满足多样化需求

26. Memory Orchestration 解决方案提供一种产品化的记忆调度方式，让模型能自主遗忘不重要的信息、只保留重要且相关的知识，同时让"什么是重要的"这类判断权交还给用户与系统设计者。开发者设定规则，模型自动执行选择权交给终端用户 • 模型根据策略自动删改记忆 • 用户决定记忆边界与准入规则 • 用户定义"重要性标准""更新频率""保留策略" • 模型只负责执行、压缩与检索解决主观偏差问题 • 避免模型在价值判断上自作主张，保持人机对齐实现真正的"可控记忆系统" • 可观察、可调度、可审计

27. Memory Orchestration Orchestration 把记忆选择权交给终端用户

28. 经典 3 节点 Chatflow • 因为模型不能一次性做对所有事，所以任何 workflow 类的产品逻辑都是在尝试针对特定问题，把 LLM 能生成的东西限定死。精髓就是细化，分治，以此来保证一个长期持续稳定的输出结果质量。

29.

30. 如何实现 Memory？在 LLM 节点编排页我们引入了四种不同的变量记忆类型 • Disabled：这种模式下，LLM 节点将不支持记忆，仅支持单轮对话 • Linear：传统的线性记忆，当记忆超出 window size 的限制以后将丢弃相对较老的聊天记录 • Memory Block：记忆将以文本的形式被储存在一个会话变量当中，这个个变量会随着聊天的进行被自动更新，仅保留与用户话题聊天主题相关的内容，最重要的是，用户可以自行决定模型应该记住什么忘记什么 • Auto：Agent 根据指令自行决定什么应该被记住什么应该忘掉

31. Disabled：无状态单轮对话模式适用场景（举例） • 一次性问答 / 工具直连：例如算账、翻译、查状态、跑脚本等，这些场景的上下文价值较低。 • 上下文隔离的 Sub Agent：如 Web Search 场景只需要结论，避免大量页面信息污染主 Agent 上下文 • 合规与隐私敏感场景：为避免任何跨轮或跨会话的数据留存。 • 性能/成本优先：追求极致的低延迟、低 Token 消耗，常用于做 A/B 测试的基线版本。 • 快速排障 / 冷启动 Demo：在初期阶段快速跑通最小闭环，后续再决定是否引入记忆功能。总结 • 此模式更适合“任务瞬时完成”的对话场景，而非需要“连续产出”的复杂对话。

32. Linear：轻量多轮，滑动窗口记忆适用场景（举例）： • 轻规划 / 头脑风暴：上下文短、对旧信息依赖弱的场景。 • 低轮次对话场景：不需要长期偏好记忆或复杂推理的短对话。 • 原型阶段：快速验证对话流程，后续根据需求评估是否升级为更复杂的记忆模式。工作原理： • 维护一个固定大小的对话缓冲区（例如，最多存储N轮对话）。 • 当有新消息（或新的对话轮次）进入时，它会被添加到缓冲区的末尾。 • 如果缓冲区已满，最旧的消息（即最先进入缓冲区的消息）将被自动移除，以腾出空间给新消息。 • 这类似于一个“先进先出”(FIFO)队列，确保只有最近的对话历史被保留。

33. 重头戏：Memory Block 记忆块/记忆模版

34.

35. 终端体验｜Memory Block 可见、可改、可回退的记忆侧栏 • 侧栏实时预览 Memory 状态，可成为会话"产出物"（如行程草案） • 支持用户修改并版本回退/切换（携带版本概念） • 示例：research_partner / code_partner 分阶段结果自动沉淀

36.

37. 多版本记忆管理

38. Memory as a variable • 将记忆结构化，作为一等公民供开发者编排 • 开发者决定记忆的 Schema 格式，类似关系型数据库的结构格式 • 开发者用提示词的形式决定什么时候更新记忆，记忆更新的逻辑。

39. • 在 LLM 节点或 Agent 节点工作时，将相关的记忆注入进上下文 • 左图是一个采访 Agent，可以将刚刚的用户画像作为 System Prompt 输入，让模型围绕该画像进行针对性提问 • 随着采访深入，模型也会进一步完善 "用户画像记忆快"

40. Memory Block 的更新机制：Auto 模式在 Auto 模型下，Agent 会根据上下文和 instruction 调用工具来自动更新Memory Block • 用户需要选择模型是通过 ReAct 策略还是 Function Call 策略发出信号

41. Memory Block 的更新机制：Every N turns • Every N turns：每经过 N 轮，系统会更新一次 Memory • N 可以自行调整，最大值为 200，最小为 3，默认为 20 • 根据对话而不是 Token 数量来更新 Memory • 保证了完整的上下文语义

42. 控制 MemoryBlock 可见性并不是所有的细节都应该暴露给终端用户，并不是所有的 MemoryBlock 都需要展示，因此 Dify 将这个开放给了用户，可以选择关闭 Editable in web app来将其从终端用户处屏蔽

43. Memory Block 的作用域与生命周期控制在终端用户处看到的 Memory 其实就是一个个具体的 MemoryBlock，在 Memory Block 模式下，我们引入了两种 Span 与两种 Term ， Term ，其决定了 M em o ry 的作用域与生命周期，但不论哪种配置，其基础作用范围都为 En d U ser，不同终端用户的 MemoryBlock 都是隔离的 Span / Scope • • Term Node：节点级别作用域，一个 LLM 节点完成一次与 LLM • Session：当用户新建会话以后，Memory 都会被遗忘的交互后，Dify 会开始更新 Memory 变量 • Persist：Memory 将永远保留，新建会话切换会话也仍然 App：在终端用户完成一次与 App 的对话后，Dify 会开始存在更新 Memory 变量这两种类型可以组合出四种不同的记忆储存逻辑，未来，我们将考虑引入 Workspace 级别的作用域，使得多个 App 之间可以共享 Memory 从而实现协作的基座能力

44. 为什么要这样做？核心思想 —— 选择权给用户不论模型的智能发展到何种程度，其与人类的认知对齐永远会成为黑洞这套产品设计寄希望于让开发者专注在具体的场景上的 Memory 编排除非脑机接口能够成为现实，为了避免这个结合场景用规则限定记住什么，忘掉什么，避 Gap，在通用的解决方案中，人类需要无数的免用封闭域方案解决开放域问题。 few shots 来解决一个又一个的 corner case。

45. 开放的 Memory 1 2 Persistent Memory Session Memory 对于 Term 为 Persist 的 Memory 对于 Term 为 S essio n 的 M em o ry，使用 G ET GET /memory/persist?user_id=? 即可获取该用户在该 App 下的 memory /memory/conversation_id?user_id=? 获取该用户在该 conversation 下的 memory 3 4 Conversation Variables Modification GET /memory/conversation_id/variables 同时，需要允许对 memory 的修改，因此上面对应的接口页获取 Term 为 Session 下的全部会话变量支持 PATCH 执行修改操作

46. Memory Block 思想的工程应用案例 Dify 插件自动化生成系统 —— FyGen • 目标：在聊天中持续对齐需求，Memory Block「Plugin PRD」滚动更新 → 生成不缺项的 Dify 插件 • 核心理念："让模型记住对的事，再让代码一次到位。" Chat 完整插件 Codegen PRD 测试随着聊天过程逐渐完善的 PRD，最后一键出插件。通过 Memory Block 持续记录和更新插件需求文档，确保最终生成的代码完整且符合符合用户真实需求。

47.

48. Coding Agent 中 Memory as Tool 设计 • 执行任务时会自己维护一个 Todo List，其背后是TODO(MemoryBlock)作为一个工具被 Agent 调用

49. 用户个性化语言习惯与个人信息消费倾向与价值观 • 语言偏好与表达习惯 • 购物偏好与品牌忠诚度 • 基本个人信息（如年龄段、职业） • 内容消费倾向（如阅读、影视） • 兴趣爱好与特长 • 饮食习惯与偏好 • 核心价值观与信念社交与人际信息学习与成长目标 • 社交网络与人际关系特点 • 学习领域与知识偏好 • 常用个人称谓与昵称 • 职业发展与成长目标 • 沟通风格与偏好 • 个人技能提升计划

50. 第四部分未来展望

51. 模型厂商下场做 Memory？尽管从技术上讲，模型提供商在模型层面实现原生的状态化服务具有潜在优势，但他们面临着显著的商业和技术挑战。隐私与数据主权成本与复杂性标准化的缺失用户的状态属于高度敏感的数据资产为全球海量用户提供有状态的 API 调即使某个厂商推出状态化 API，其状。企业用户普遍不愿将这些核心数据，将带来庞大的基础设施和运营成本态表示（很可能是专有的张量格式）以缺乏透明度的方式存储在第三方服。相比之下，当前无状态的服务模型也难以与其他模型兼容。这可能导致务器上。数据主权和隐私合规是重要在扩展性和成本效益上更具优势。厂商锁定，是开发者社区普遍希望避的考量因素。免的局面。

52. 创新者的机遇模型提供商的迟疑,为应用层开发者创造了一个独特的创业机遇。先发优势构建护城河 3-5 年的时间窗口 "状态"是用户价值沉淀的核心。通过为用户管理丰富、个性化的根据这件事的复杂度，能估算出一个大概的时间窗口。在此期间记忆库,应用可以构建起强大的、难以被竞争对手逾越的护城河。应用层将是记忆解决方案的核心创新领域。用户的记忆本身就成为了应用的资产和壁垒。

53. 记忆层 = AI 时代的数据库传统软件栈 AI Agent 技术栈 • 数据库是持久化基石 • 记忆框架承担同样角色 • 状态管理的核心 • 为 AI 状态构建专用数据库 • 应用的基础设施 • Zep、Mem0 等正在构建这意味着该领域的竞争将越来越像数据库市场的竞争:比拼的是性能、可扩展性、查询能力的复杂性(如图查询 vs. 向量搜索)以及开发者者体验。我们构建的不仅仅是一个功能,而是一个核心的基础设施。

54. 市场格局分化记忆即特性记忆即服务 Memory-as-a-Feature Memory-as-a-Service • LangGraph 等代表 • Zep、Mem0、SuperMemory 等提供 SaaS 的代表 • 记忆作为 SDK 的一部分 • 独立的、最佳的记忆层服务 • 提供集成解决方案 • 可被任何 Agent 框架集成这种“平台即服务”与“集成特性”的模式演变，预示着未来 Agent 架构将趋向“解耦”——开发者可根据需求独立选择合适的推理框架、记忆平台和基础模型。

55.