Agent 执行器如何维护上下文？上下文管理如何保证连续性？

当你的 Agent 突然“失忆”，问题可能出在上下文没管好

上周，一位做跨境电商的朋友半夜给我发消息：“Dr.n8n，我的自动客服 Agent 在第三次对话时突然回复‘我不记得您之前问过什么’，客户直接骂我系统智障！”——这其实不是 AI 模型的问题，而是上下文管理断链了。就像你刚跟朋友聊完周末计划，转身他就问你“刚才说去哪？”——这不是健忘，是信息没接住。

上下文不是“聊天记录”，而是动态的内存池

很多初学者误以为上下文就是“把历史对话塞进 prompt”，但真正的上下文管理是一套精密的状态机。它要解决三个核心问题：数据从哪来？存在哪？怎么传下去？

我在帮某电商客户搭建退货处理 Agent 时发现：如果只靠前端传参维持上下文，用户中途刷新页面或跳转链接，整个流程就会重置。后来我们改用 Redis + SessionID 双保险，才实现“断点续聊”。

实战三板斧：变量传递、状态存储、生命周期控制

第一板斧：节点间变量接力（适合短流程）
在 n8n 中，你可以通过 Set Node 或 Function Node 把关键信息写入 $workflow.context，后续节点直接读取。比如用户首次输入订单号，你就把它存进 context.orderId，后面查物流、退换货都靠它。

// 在 Function Node 中设置上下文
$workflow.context.orderId = $input.item.json.orderId;
return $input.item;

第二板斧：外部状态存储（适合长流程/跨会话）
当流程超过 5 步或需要跨设备延续时，必须引入数据库或缓存。我推荐用 Airtable 或 Supabase 存储会话状态，Key 是 SessionID，Value 是 JSON 格式的上下文快照。每次用户交互，先读状态，再更新，最后写回。

第三板斧：生命周期钩子（优雅清理无用上下文）
别让僵尸上下文吃掉你的内存！设置 TTL（Time To Live）或在用户明确结束对话后触发 Cleanup Node。例如，30 分钟无操作自动清空该 SessionID 对应的数据。

一个类比让你彻底开窍：上下文 = 餐厅服务员的记忆本

想象你在一家高级餐厅：

• 你第一次说“不要香菜”，服务员记在小本子上 → 这是 变量存储；
• 你换桌了，经理把小本子递到新桌服务员手里 → 这是 状态传递；
• 你吃完离店，经理把本子归档或销毁 → 这是 生命周期管理。

如果服务员每道菜都重新问你“要不要香菜”，那不是他笨，是餐厅没设计好信息流转机制。

总结：上下文连续性 = 存得下 + 取得到 + 清得掉

Agent 不是魔法盒子，它的“记忆能力”完全依赖你设计的信息管道。记住这个黄金三角：短流程用内置变量，长流程用外部存储，所有流程设清理机制。下次再遇到“失忆”报错，先别骂模型，检查你的上下文流水线是否断了。

你在搭建 Agent 时踩过哪些上下文的坑？或者有什么奇葩的“失忆”案例？欢迎在评论区甩出来，我来帮你诊断！