为什么你的 n8n Agent 会遗忘
Simple Memory 是一个窗口，而且这个窗口很小
Simple Memory 节点的“上下文窗口长度”（Context Window Length）设置决定了要包含的历史交互次数，默认值为 5。一次交互代表一轮对话——即用户消息加上 Agent 的回复——因此默认设置大约保留最近的 10 条消息。更早的内容会静默地移出窗口。系统不会报错，Agent 只是单纯地不再引用同一对话中较早发生的内容，这就是为什么长对话的质量会逐渐下降而不是直接中断。
它存在于工作流数据中，因此无法持久保存
Simple Memory 将聊天历史记录存储在工作流自身的数据中，并绑定到一个会话密钥（session key）。这在编辑器中很方便，但在其他地方却非常脆弱：历史记录与实例的运行状态绑定，一旦重启或重新部署就会消失。这就是经典的“开发时正常，部署后全忘”的现象，而官方给出的标准建议——在上线前迁移到 Postgres 或 Redis 聊天记忆——也正是因为这个原因。
队列模式会直接导致其失效
n8n 的文档清楚地说明了这一限制：如果你的实例使用队列模式（queue mode），该节点在激活的生产工作流中将无法工作，因为无法保证记忆调用会被路由到同一个 worker。如果你对 n8n 进行了水平扩展，然后纳闷为什么记忆变得不稳定——时而记得，时而忘记——原因就在这里。请求落在了不同的 worker 上，而每个 worker 对之前说过的话都有不同的记录。
会话密钥决定了谁记住什么
记忆是按会话密钥（session key）分组的。使用 Chat Trigger 时，n8n 会从传入的 sessionId 中填充它，这通常符合预期。但有两种常见的错误配置会导致截然相反的症状：
- 硬编码的静态密钥意味着所有用户共享同一个记忆——Agent 会混淆对话并在不同用户之间泄露上下文。
- 每次执行都改变的密钥意味着每条消息都会开启一个新对话——尽管记忆功能在技术上正在运行，但 Agent 看起来就像失忆了一样。
记忆的作用域仅限于每个 Agent 节点、每个工作流
记忆节点连接到单个 AI Agent 节点。它不是跨自动化流程的共享存储。工作流 A 中的支持 Agent 对工作流 B 中的入职 Agent 昨天得出的结论一无所知（即使是针对同一个客户），而且两者都不知道你的团队在管理这两者的 SOP 中写了什么。如果你运行多个 Agent，这种碎片化会进一步加剧——这一普遍问题在 multi-agent memory 中有详细讨论。
团队通常会先尝试什么
增加上下文窗口长度
这是最显而易见的手段，而且短期内确实有帮助。但你必须为每次调用中保留的每条消息付费，窗口依然是有界的，而且依然是易失的。你只是让遗忘发生得更晚一些，并没有阻止它。
切换到 Postgres 或 Redis 聊天记忆
这是正确的生产环境做法，你也应该这样做：历史记录可以在重启后存活，并且能在队列模式下工作。不过，要清楚它能给你带来什么。它是一个由会话键控的持久聊天记录存储——它保存的是输入的内容，而不是你组织所掌握的知识。它不包含你的产品文档、价格规则、上季度的决策，或者该客户在三月份提交的工单解决方案。只要询问该会话消息之外的任何内容，它都一无所知。
将上下文塞进系统提示词（System Prompt）
团队会将政策、语气指南和常见问题解答粘贴到 Agent 的系统消息中。每次执行都要为这些 token 付费，文本会逐渐过时，而更新它意味着需要逐个编辑工作流。这在自动化领域相当于永远在 re-explaining context to your AI。
自建检索系统
下一步通常是向量数据库加上嵌入（embedding）流水线，再加上检索子工作流。这确实可行，但也是一个真正的工程项目：分块、嵌入刷新、排序、作用域划分、过期处理。而且它本身并不能解决记忆问题，原因值得阅读 why RAG isn't memory——检索寻找的是文档，而记忆保存的是结论。
解决方案：为你的 n8n Agent 赋予持久记忆层
聊天记忆（Chat memory）和记忆（Memory）是两项不同的工作。保留 Postgres 或 Redis 记忆节点以维持会话内的对话连贯性，并将持久知识放在一个不与工作流、worker 或会话密钥绑定的层中。这就是 MemoryLake 所扮演的角色：一个供你的 Agent 读取和写入的统一记忆库，可以通过 MCP 或 API 从你构建的任何工作流中访问。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出你的第一次请求。
步骤 2：上传你的第一批记忆
放入你的 Agent 持续需要的文档、图片和文件：产品文档、SOP、价格和政策规则、升级路径、先前的解决方案。这些是永远不应该放在聊天缓冲区中的知识。
步骤 3：连接你的 AI 和 Agent
通过 MCP 或 API 让 Claude、Codex、OpenClaw 以及你的 n8n Agent 访问该记忆——在工具支持的地方使用 MCP 连接，或者直接从工作流本身发起普通的 HTTP 请求。在任何 worker 上的每次执行都能访问相同的记忆。如果你还向 Agent 开放了自己的工具，adding memory to a custom MCP server 和 memory for stateless MCP servers 涵盖了这方面的内容。
这在实践中带来了什么改变
算一算你目前的工作流重复了多少内容。如果每次执行都携带 1,500 个 token 的粘贴政策和产品上下文，并且该工作流每天运行 500 次，那么每天就是 750,000 个 token——每月大约 2200 万个 token——都花在重新发送从未改变的文本上。而仅从记忆层检索相关的片段，其成本通常只是其中的一小部分。
更大的收获在于行为层面。一个能够看到客户早期工单的支持 Agent 不会再次询问账户 ID。一个与支持 Agent 读取相同记忆的入职 Agent 不会与其产生矛盾。当你下个季度重构工作流时，知识会保留在原处，而不是被困在你删除的版本中。
n8n Agent 记忆的最佳实践
将聊天记录和知识分开存放
使用聊天记忆节点来保留当前对话的最后几轮。使用记忆层来存放明天依然有效的任何内容。将它们混在一起会导致存储库既庞大得无法读取，又浅显地无法提供实质帮助。
将记忆键控到实体，而不是执行
会话密钥适用于对话。持久记忆应该键控到客户、项目或账户——这些在不同工作流和不同月份中代表相同含义的实体。这样才能让第二个工作流在第一个工作流停止的地方继续进行。
在运行结束时写回结论
添加最后一个步骤来存储该次运行所做出的决定：解决方案、授予的特例、用户声明的偏好。只读记忆的 Agent 永远不会变得更聪明；而向记忆中写入的 Agent 会不断积累。保持这些写入简短且符合事实，并且优先替换过时的事实，而不是在上面堆叠新的事实。
结论
你的 n8n Agent 并没有损坏。Simple Memory 正在准确地执行其文档中所说明的功能：在工作流数据中保留少数最近的交互，这就是为什么它在重启时会蒸发，并且在生产环境的队列模式下无法工作。迁移到 Postgres 或 Redis 解决了聊天记录的持久性问题——但留下了更大的空白，因为单个会话的聊天记录永远不等同于了解你的业务。
将这两项工作分开。对话的连贯性属于聊天记忆节点；机构知识则属于你的工作流通过 MCP 或 API 读取的记忆层。这样，你构建的下一个 Agent 就可以从上一个 Agent 学到的所有内容开始，而不是面对一个只有五次交互深度的空白窗口。