Flowise 的记忆系统设计：13 种记忆后端

学习目标

• 理解 Flowise 记忆系统的统一抽象：FlowiseMemory 接口
• 掌握 13 种记忆后端的分类与适用场景
• 学会在 Flowise 画布中配置和使用记忆节点

前置知识

本章涉及记忆系统的通用原理，建议先阅读：

• 记忆系统

下文假设你已理解短期记忆、长期记忆、会话管理等通用概念，直接聚焦 Flowise 的具体实现。

---

项目实践

FlowiseMemory 统一接口

Flowise 所有记忆节点实现统一的 FlowiseMemory 接口：

interface FlowiseMemory {
    getChatMessages(): Promise<IMessage[]>
    addChatMessages(message: string, type: string, id?: string): Promise<void>
    getChatHistory(): IMessage[]
    clear(): Promise<void>
}

每个记忆节点（如 BufferMemory、RedisBackedChatMemory）都实现这个接口，使得 Flowise 在执行引擎中可以统一调用。

13 种记忆后端分类

类别	记忆后端	存储介质	适用场景
内存缓冲	Buffer Memory	内存	开发测试，不持久化
窗口缓冲	Buffer Window Memory	内存	仅保留最近 N 轮对话
摘要	Conversation Summary Memory	内存 + LLM 摘要	长对话的压缩总结
摘要缓冲	Conversation Summary Buffer Memory	内存 + LLM	摘要 + 最近 N 轮混合
Redis	RedisBackedChatMemory	Redis	生产环境，分布式部署
Upstash Redis	UpstashRedisBackedChatMemory	Upstash Redis	Serverless 部署
MongoDB	MongoDBMemory	MongoDB	已有 MongoDB 基础设施
DynamoDB	DynamoDb	AWS DynamoDB	AWS 生态
Zep	ZepMemory	Zep 服务	专用记忆管理
Zep Cloud	ZepMemoryCloud	Zep Cloud	云端记忆服务
Mem0	Mem0	Mem0 服务	AI 智能记忆层

记忆节点的配置与注入

在 Flowise 画布中：

1. 添加记忆节点（如 Buffer Memory）
2. 连接到 Chat Model 或 Agent 节点的 Agent Memory 输入
3. 配置记忆参数（如 memoryKey、windowSize）

会话 ID 管理：

Flowise 通过 getMemorySessionId 函数确定 sessionId：

// 优先使用 API 传入的 sessionId
// 否则使用 chatId
// 内部/外部 API 使用不同的 fallback 策略

{{chat_history}} 变量自动填充：

当流程执行时，getSessionChatHistory 函数会：

1. 找到记忆节点
2. 调用 getChatMessages() 获取历史消息
3. 将历史消息格式化为 IMessage[] 数组
4. 填充到 {{chat_history}} 变量中

LangGraph CheckpointSaver 集成

对于 AgentGraph 模式（基于 LangGraph），记忆通过 BaseCheckpointSaver 接口集成：

Agent → Agent Memory → Buffer Memory / Redis / MongoDB

CheckpointSaver 不仅保存对话历史，还保存 Agent 的中间状态（工具调用、中间结果等）。

---

问题与规避

多 Memory Node 冲突

问题：同一 Flow 中存在多个记忆节点时，哪个负责会话历史？

对策：Flowise 的 findMemoryNode 函数只返回找到的第一个记忆节点。建议在每个 Flow 中只配置一个记忆节点。

Token 限制与摘要丢失

问题：Summary Memory 在长对话中会丢失早期细节。

对策：

• 使用 Conversation Summary Buffer Memory：保留最近 N 轮的完整对话 + 更早对话的摘要
• 调整摘要提示词，要求保留关键信息
• 对于需要完整历史的场景，使用 Buffer Window Memory 并设置足够大的窗口

Redis 过期导致会话丢失

问题：Redis 默认无 TTL，但如果配置了过期策略，长期不活跃的会话会被清除。

对策：

• 根据业务需求设置合理的 Redis TTL
• 在应用层实现会话恢复逻辑（通过数据库恢复历史）
• 对于需要永久保留的会话，使用数据库后端（MongoDB、DynamoDB）

---

设计取舍

为什么提供 13 种记忆后端？

方案	优势	代价
只支持 2-3 种	维护简单、代码质量高	用户受限
广泛支持 13+ 种	覆盖几乎所有部署场景	每种后端的边界情况需要单独测试

Flowise 选择广泛支持，因为：

• 不同用户的部署环境差异巨大（已有 Redis 的用户不需要 MongoDB）
• 每种记忆后端的代码量相对固定（配置表单 + CRUD 逻辑）
• 社区贡献者可以轻松添加新的记忆后端

内存记忆 vs 持久化记忆

维度	内存记忆（Buffer/Summary）	持久化记忆（Redis/MongoDB）
性能	最快（无 I/O）	受网络/磁盘延迟影响
持久化	进程重启丢失	跨进程/跨实例保留
分布式	不支持	多实例共享
适用环境	开发/测试	生产环境

Flowise 同时提供内存和持久化记忆，让用户在不同环境中选择最合适的方案。开发阶段使用 Buffer Memory 快速迭代，生产环境切换到 Redis 或 MongoDB。

---

参考来源

• Flowise 官方文档 - Memory
• LangChain Memory 文档