LLM Agent 上下文管理难吗？记忆机制如何实现？

作者： Dr.n8n 更新时间：2025-12-09 20:00:43 分类：n8n教程

“我刚说的你忘了吗？”——LLM Agent 的记忆困境

上周，一位做智能客服的朋友半夜给我发消息：“Dr. n8n，我的 LLM Agent 怎么像个金鱼？用户前一句问‘订单12345状态如何’，后一句问‘那能退款吗？’，它居然反问‘您说的是哪个订单？’……这用户体验直接崩了。”

这不是个例。LLM（大语言模型）天生是“无状态”的——每次对话都是独立事件，像一个没有短期记忆的实习生。而真正的业务场景中，上下文管理不是“锦上添花”，而是“生死线”。

我在帮某跨境电商搭建退货咨询 Agent 时发现：用户平均要交互 3.7 轮才能完成一次售后。如果每轮都要重复输入订单号、商品名，转化率直接腰斩。

记忆机制的本质：给 AI 装个“便利贴系统”

别被“记忆机制”这个词吓到。它不像人类大脑的海马体那么玄乎，本质上就是一套**结构化信息暂存 + 动态注入**的工程方案。你可以把它想象成：每次对话，AI 都从口袋里掏出一张写满关键信息的便利贴，边看边回答。

实现方式主要分三层：

会话层记忆（Session Memory）：记录单次对话中的关键实体（如订单号、用户ID）。像服务员记下你桌号后全程服务。
长期记忆（Long-term Memory）：存储跨会话的用户偏好或历史行为（如“这位用户总买有机食品”）。相当于餐厅的 VIP 档案。
外部知识库联动：实时查询数据库/CRM 补充上下文（如调取订单物流状态）。好比服务员随时查后台系统。

实战：用 n8n + Redis 打造“不健忘”的客服 Agent

下面以 n8n 工作流为例，演示如何用 3 个节点解决“订单状态追问”问题：

// 步骤1：用户首次提问时提取关键实体
{
  "node": "Extract Order ID",
  "type": "Code",
  "parameters": {
    "jsCode": "// 用正则从用户消息中抓取订单号nconst text = $input.item.json.message;nconst orderId = text.match(/订单[s]*([A-Z0-9]+)/)?.[1];nreturn { json: { orderId } };"
  }
}

// 步骤2：将订单号存入 Redis（设置10分钟过期）
{
  "node": "Save to Redis",
  "type": "Redis",
  "parameters": {
    "operation": "set",
    "key": "=sessionId_{{$json.sessionId}}",
    "value": "={{JSON.stringify({orderId: $json.orderId})}}",
    "expireTime": 600
  }
}

// 步骤3：后续提问自动注入上下文
{
  "node": "Inject Context",
  "type": "Redis",
  "parameters": {
    "operation": "get",
    "key": "=sessionId_{{$json.sessionId}}"
  }
}

当用户第二次问“能退款吗？”，工作流会自动把之前存储的 {"orderId": "ABX789"} 注入到 LLM 提示词中，生成类似这样的完整请求：

用户当前对话关联订单 ABX789（状态：已签收）。请基于此背景回答：“能退款吗？”

进阶技巧：动态记忆压缩与优先级排序

随着对话轮次增加，“便利贴”会越来越长。直接全塞给 LLM 不仅浪费 Token，还可能触发上下文长度限制。这时候需要两个策略：

策略	实现方式	类比
记忆摘要	用小型 LLM 压缩历史对话为关键点	会议纪要代替逐字稿
权重标记	给实体打标签（如 [核心]订单号 vs [次要]问候语）	文件柜里的彩色标签

在 n8n 中，你可以用 Function 节点实现简单的权重过滤：

// 只保留带 [核心] 标签的记忆片段
const memories = $input.all().map(item => item.json);
const coreMemories = memories.filter(m => m.tag === '[核心]');
return coreMemories.map(m => ({ json: m }));