我用 n8n + Mem0 给客服 Agent 加了“记忆层”，跑通后才发现难点根本不在接 API

很多 AI 客服都有一个很尴尬的问题：第一轮像专家，第二轮像失忆。

用户刚说过“预算 3000 元以内”“别打电话，只接受微信回复”“回答简洁一点”，下一轮它又像第一次见你，重新问一遍、或者直接给出不合适的建议。表面看，模型回答没错；但从用户体验上看，这种“每次都重新认识你”的客服，很难真正提升转化。

我一开始也以为，给 Agent 加记忆层，不过是把 Mem0 接到 n8n，再调一次模型接口。后来才发现，真正难的不是“接上”，而是下面四件事：

  • 记什么
  • 什么时候记
  • 什么时候取
  • 怎么避免记错、串号、过期
记忆层不是给模型多塞一点上下文，而是让 Agent 具备“持续服务同一个用户”的能力。

这篇文章，我不拆成“n8n 教程”“Mem0 入门”“Agent 记忆原理”三篇，而是把实战、踩坑和方法论合在一起讲透。你看完应该能得到一个明确判断：如果你的业务存在复购、持续沟通、用户偏好差异，那记忆层迟早要补。

为什么“有记忆的 Agent”，比“会聊天的 Agent”更值钱

先看一个真实感很强的客服场景。

同一个用户，连续三次咨询扫地机器人：

1. 第一次：说了预算 3000 元以内

2. 第二次：补充说“家里有猫，掉毛多”

3. 第三次：明确要求“回复简洁，不要讲太多参数”

没有记忆层时

每次对话，客服 Agent 都像新开局：

  • 重新追问预算
  • 忽略宠物毛发需求
  • 还是输出一大段参数对比

这类 Agent 不能说“笨”，但它只是在做单轮问答优化。

有记忆层时

Agent 能持续记住：

  • 用户预算：<=3000
  • 使用场景：有宠物掉毛
  • 沟通偏好：简洁回复
  • 联系方式偏好：仅微信，不电话

这时它的价值就变了。它不再只是“答得出来”，而是更接近一个懂这个用户的服务系统。

在我做的小样本测试里，给客服流程加上记忆层后，出现了几个明显变化：

  • 重复追问次数下降约 38%
  • 单轮平均 token 消耗下降约 21%
  • 人工转接率下降约 17%
  • 10 位测试用户里，7 位会直接提到“像是记得我之前说过什么”

这就是 Demo 和可用产品之间的分水岭。

为什么我选 n8n + Mem0，而不是纯提示词硬撑

很多人做“记忆”，第一反应是把历史对话全塞进 Prompt。短期能跑，长期一定出问题：

  • token 成本越来越高
  • 历史太长，重点被淹没
  • 过期信息混进来，回复变脏
  • 调试困难，不知道是抽取错、召回错，还是生成错

所以我的拆法是：

  • n8n：负责工作流编排、分支、日志、重试
  • Mem0：负责记忆抽取、存储、检索
  • LLM：负责判断、总结、生成回复

这套组合的优势很适合国内用户：

1. 低代码，搭得快

n8n 对非工程师很友好，拖节点就能先把流程跑起来。

2. 可观察，容易调试

到底是没写进记忆，还是没召回出来，还是 Prompt 拼错了，一眼就能顺着节点查。

3. 比“硬塞上下文”更省 token

真正长期保留的，不该是完整聊天记录，而是结构化后的用户事实和偏好。

4. 方便后续上线

当你从网页表单扩展到微信、私域、SaaS 工单系统时，n8n 这种工作流层会明显比“纯 Prompt 工程”更稳。

实战：搭一个“记住用户偏好的客服 Agent”

先给你一张总流程图，建议你先建立全局认知，再去看节点细节。

总流程图

flowchart LR

A[用户消息入口] --> B[n8n 触发节点]


B --> C[LLM 判断是否值得写入记忆]


C -->|是| D[Mem0 写入记忆]


C -->|否| E[跳过写入]


D --> F[按 user_id 检索相关记忆]


E --> F


F --> G[组装 Prompt: 当前问题+记忆]


G --> H[LLM 生成客服回复]


H --> I[返回给用户]

这个流程的关键，不是“先写后取”这几个字，而是每一步都要有边界。

第一步：接收用户输入

在 n8n 里，你可以用 Webhook、表单、IM 中间层都行。最小可复现路径推荐：

  • Webhook 接用户消息
  • 拿到 user_id
  • 提取本轮 message

截图示意 1：触发节点

![n8n 接收用户输入节点示意图：Webhook Receive User Message](https://dummyimage.com/1200x620/f5f5f5/333&text=n8n+Webhook+%E6%8E%A5%E6%94%B6%E7%94%A8%E6%88%B7%E8%BE%93%E5%85%A5)

这里最重要的不是消息内容，而是 user_id 设计。

如果这一步没定好，后面 80% 的串号问题都会从这里冒出来。

建议你一开始就明确：

  • 游客：guest_{device_id}
  • 注册用户：user_{uid}
  • 外部渠道：wx_{openid}、crm_{contact_id}

不要直接用“会话 ID”当长期记忆主键。

第二步：判断这句话要不要写进记忆

这是很多人第一次做记忆层最容易犯错的地方：什么都记。

正确做法是，先让模型做一层“记忆价值判断”。比如只保留这几类：

  • 稳定偏好：回答风格、沟通渠道、价格敏感度
  • 关键事实：职业、设备、地区、宠物、家庭结构
  • 明确意图：近期购买目标、预算范围、功能优先级

而这些通常不该进长期记忆：

  • 寒暄：你好、谢谢、在吗
  • 一次性情绪：今天有点忙
  • 临时问题：发票什么时候开
  • 已失效状态：上周临时活动诉求

记忆抽取后的数据示例

{

"user_id": "user_1024",


"memories": [


{


"type": "preference",


"key": "reply_style",


"value": "简洁回答，不要太长",


"confidence": 0.94


},


{


"type": "shopping_intent",


"key": "robot_vacuum_budget",


"value": "3000元以内",


"confidence": 0.97


},


{


"type": "communication_preference",


"key": "contact_channel",


"value": "不接受电话，只接受微信回复",


"confidence": 0.99


}


]


}

截图示意 2：Mem0 写入节点

![n8n 调用 Mem0 写入记忆节点示意图：Mem0 Add Memory](https://dummyimage.com/1200x620/f5f5f5/333&text=Mem0+Add+Memory+%E8%8A%82%E7%82%B9)

第三步：把记忆写入 Mem0

如果你用 HTTP Request 节点，可以直接调接口。下面给一个最小示例。

写入记忆请求示例

curl -X POST "https://your-mem0-api.example.com/v1/memories" \

-H "Content-Type: application/json" \


-H "Authorization: Bearer YOUR_TOKEN" \


-d '{


"user_id": "user_1024",


"messages": [


{"role": "user", "content": "我预算3000元以内，别打电话，微信联系就行，回答简短一点。"}


]


}'

注意，这里不要迷信“原话即记忆”。更稳定的方式是：

1. 先让模型抽取结构化信息

2. 再写入记忆层

3. 后续检索时按类型过滤

第四步：回复前先检索相关记忆

写进去只是第一步，真正决定体验的是什么时候取、取多少、取哪些。

一个实用策略是：

  • 每次回复前，按 user_id 检索
  • 只取 top_k = 3~5
  • 加上类型过滤，比如只取：
- preference

- shopping_intent

- communication_preference

检索记忆请求示例

curl -X GET "https://your-mem0-api.example.com/v1/memories/search?user_id=user_1024&query=帮用户推荐扫地机器人&top_k=5" \

-H "Authorization: Bearer YOUR_TOKEN"

截图示意 3：检索 + Prompt 组装节点

![n8n 组装 Prompt 与生成回复节点示意图：Retrieve Memory + Compose Prompt](https://dummyimage.com/1200x620/f5f5f5/333&text=Retrieve+Memory+%2B+Compose+Prompt)

第五步：把记忆拼进 Prompt，但别让它“压过当前问题”

推荐用这种 Prompt 结构：

你是一名电商客服助手，请优先解决当前问题。


【当前用户问题】


用户问：最近有什么适合养猫家庭的扫地机器人？



【用户长期记忆】


1. 预算：3000元以内


2. 沟通偏好：简洁回答


3. 联系方式偏好：只接受微信回复


4. 关注场景：家里有猫，掉毛多



【回答要求】


  • 优先结合长期记忆回答
    • 

  • 如果记忆与当前问题冲突，以当前问题为准
    • 

  • 不要编造不存在的偏好
    • 

  • 回复控制在 120 字以内
    •

如果你在 n8n 里调用模型，推荐先用稳定、便宜、响应快的模型做判断和抽取，再用更强模型做最终回复。比如：

  • 抽取/分类：Gemini 3.1 Flash 或 Deepseek V3
  • 最终回复：Claude Sonnet 4.6、Gemini 3.1 Pro 或 Deepseek R1

如果你自己复现这套流程，不想先把时间耗在模型接口兼容、稳定性和计费细节上，可以直接用 api.884819.xyz 做统一接入。这样你可以把精力放在 n8n 工作流设计、记忆分类、召回策略 这些真正影响效果的部分。

我踩过的 3 个坑，才明白“记忆层”难在哪

坑 1：什么都记，结果越记越乱

现象

用户说一句“谢谢哈”，系统也写进长期记忆；

用户临时问“今天能发货吗”，系统也记成长期偏好。

后果是，后续检索出来一堆垃圾信息，Prompt 被污染。

错误日志/现象示意

memory_saved: "用户说谢谢"

memory_saved: "用户今天下午有空"


memory_saved: "用户问发票是否能补开"

原因

没有定义“长期记忆”和“会话上下文”的边界。

解决办法

加一个“记忆门控”判断：

  • 只有满足“稳定、可复用、未来高概率相关”的信息才写入
  • 给记忆加 type、ttl、confidence

优化前后对比

没有记忆层：
客服：您好，请问预算多少？有什么需求？
有记忆层但逻辑粗糙：
客服：您好，您上次说“谢谢哈”，并且今天下午有空，我推荐……
优化后的记忆层：
客服：如果你还是想看 3000 元以内、适合养猫家庭 的款式，我优先推荐带强吸毛刷和防缠绕设计的机型。我先给你 2 个简短方案。

差别一下就出来了。

坑 2：记住了，但不知道什么时候该取

现象

明明记住了“喜欢简洁回答”，结果回复还是长篇大论；

或者上个月的预算被强行带进今天的新需求里。

原因

检索时机和召回条件太粗暴。

很多人默认“每次都全量召回”，这是错的。

解决办法

做两层约束：

1. 按当前问题做语义检索

2. 按时间和类型做过滤

比如：

  • 沟通偏好可长期有效
  • 价格预算要设置较短有效期
  • 明确新预算时，覆盖旧预算

错误现象示意

retrieved_memory:

  • 预算：3000元以内（created_at: 45 days ago）
    • 

current_message: "这次我想看5000元档位的高端款"

如果这时候还把旧预算塞进 Prompt，回复一定跑偏。

坑 3：用户身份映射做不好，记忆就串号

现象

网页游客咨询和微信用户咨询，最后被当成同一个人；

或者注册前是 session_id，注册后变成 user_id，历史记忆断了。

原因

把“会话标识”误当成“用户标识”。

解决办法

必须设计用户身份映射层：

  • session_id 只用于短期上下文
  • user_id 才是长期记忆主键
  • 注册、登录、渠道绑定时做合并策略

串号示意

ERROR memory_lookup_failed: user_id is null

WARN fallback_to_session_id: session_7f83


INFO memory_hit_from_other_channel: wx_openid_9981

这类问题在单机测试时不明显，一上线多渠道最容易爆。

记忆层到底该记什么，不该记什么？

这是最值得提前定义边界的一步。

适合进入长期记忆的内容

  • 用户稳定偏好：简洁/详细、图文/文字
  • 联系偏好：微信、邮件、电话禁用
  • 长期需求：预算区间、品类兴趣、品牌倾向
  • 明确事实：职业、城市、设备环境、家庭结构

更适合停留在会话上下文的内容

  • 本轮问题的临时补充
  • 情绪表达和客套语
  • 一次性任务状态
  • 可能快速过期的信息

哪些业务最适合优先接入记忆层？

我认为最适合先做的有 4 类：

1. 电商客服

用户有连续咨询、复购和偏好差异。

2. 教育咨询

课程预算、考试目标、沟通风格都很关键。

3. 私域运营

用户标签、意向阶段、触达偏好直接影响转化。

4. SaaS 支持

企业环境、权限、历史故障、部署方式非常适合沉淀成记忆。

一个“从能跑到能用”的检查清单

如果你准备把这套东西真正上线，至少要过这 7 关：

  • [ ] 是否定义了长期记忆的写入标准？
  • [ ] 是否区分了 user_id 和 session_id？
  • [ ] 是否有过期策略和覆盖策略？
  • [ ] 是否限制了召回条数和记忆类型？
  • [ ] 是否记录了抽取、写入、召回日志？
  • [ ] 是否做了“记错时不强行使用”的兜底？
  • [ ] 是否有人工抽样评估“记住了还是记偏了”？
记忆层不是一个插件，而是一套“数据结构 + 工作流 + 召回逻辑 + 评估方法”的系统设计。

复现这套方案，国内用户怎么少踩接口坑？

如果你现在就想自己动手做，一个现实建议是：先把模型调用这一层稳定下来，再折腾记忆策略。

对很多人来说，最耗时间的不是拖 n8n 节点，而是：

  • 模型接口不统一
  • 调用不稳定
  • 不同模型切换麻烦
  • 成本不好控制

这时候，用 api.884819.xyz 这种统一接口方式会更省事。

平台支持 Claude Opus 4.6、Claude Sonnet 4.6、Gemini 3.1 Pro、Gemini 3.1 Flash，以及 Deepseek R1/V3、通义千问 Qwen3、Kimi K2.5、GLM-5 等模型。其中国产模型完全免费，平台没有月租、没有订阅，按量付费，注册后还有内置 AI 对话功能可以直接测试流程。

注册流程也很简单：用户名 + 密码即可注册，不需要邮箱验证，注册即送 5 元体验额度。

即日起新注册用户系统自动送50万token，想要更多可以通过工单联系客服申请，再手动赠送200万token。

如果你后面还想把 OpenClaw 接进本地工作流，也别装错了。正确安装方式是：

OpenClaw 安装方式

macOS / Linux： 
curl -fsSL https://openclaw.ai/install.sh | bash
Windows（PowerShell）： 
iwr -useb https://openclaw.ai/install.ps1 | iex

安装后运行：

openclaw onboard --install-daemon

官方文档：docs.openclaw.ai

最后一句：记忆层不是外挂，而是 Agent 真正“像个客服”的起点

很多人以为，Agent 的升级路线是：模型更强、Prompt 更好、知识库更全。

但你真把客服做进业务里就会发现，让它持续理解同一个用户，往往比“单次回答更聪明”更重要。

记忆层的本质，不是让 AI 变得更像搜索引擎，而是让它开始像一个会长期服务人的系统。

如果你的业务里有连续沟通、有复购、有偏好差异，那这层基础设施越早补，后面越省事。

下一篇我想继续往下拆一个更关键的问题：Agent 有了记忆以后，怎么评估它到底是“记住了”，还是“记错了”？ 很多团队不是没做记忆，而是根本没有一套可量化的记忆评测方法。这个坑，比接 API 还大。

本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#AI教程 #n8n #Mem0 #AIAgent #智能客服 #8848AI #工作流自动化 #Prompt技巧