先抛一个核心结论：在扣子平台中，要让智能体真正记住用户的偏好、历史选择以及当前对话流程，同时避免上下文过长导致模型发散或超出token限制，必须严格区分短期记忆与长期记忆——而且这一点非常关键——务必关闭“自动合并”选项。

简单来说，短期记忆就像你的工作台，存放最近几轮交互的核心信息，随取随用；长期记忆则像归档柜，实现跨会话复用，例如用户身份、常用城市、历史订单ID。两者各司其职，一旦混在一起，模型很快会被大量无意义的问候语和重复确认句搞晕。

启用并区分两种记忆类型

操作上并不复杂：进入智能体「设置」→「记忆」页签，确保将「短期记忆」和「长期记忆」两个开关都打开。短期记忆默认基于会话ID缓存最近5轮交互，不依赖外部存储；长期记忆则需要绑定Redis或平台内置数据库，用于跨会话复用关键信息，比如user_id、设备类型、历史订单ID。

必须关闭「自动合并短期与长期记忆」选项——否则系统会把所有历史信息无差别拼进Prompt，结果要么token被截断，要么语义混乱，模型会胡乱猜测“你好呀”是不是一个新意图。

配置短期记忆：控制滑动窗口与关键字段提取

在「短期记忆」设置区，将「携带上下文轮数」设为4，同时勾选「前缀缓存」以加快系统提示加载速度。

然后进入「高级设置」→「字段白名单」，只允许三类内容进入短期记忆：user_intent（用户当前意图）、selected_option（用户刚点选的按钮值）、confirmed_constraint（用户明确确认过的限制条件）。其余所有问候语、语气词、重复确认句统统过滤掉。

这一步能砍掉60%以上的噪声。如果放任所有消息涌入，模型会在第三轮开始反复纠结“你好呀”到底是不是一个新意图——这显然不是我们期望的结果。

部署长期记忆：定义可写入的实体槽位

有两种常见做法。

方法一：通过「数据源」绑定结构化数据库

在「数据源」中添加一张「用户画像表」，字段包含user_id（主键）、last_city、preferred_language、order_history_ids。在「长期记忆」设置中，将user_id映射为会话变量session.user_id，这样每次请求都能自动拉取对应的记录。

方法二：用「脚本节点」手动写入关键事实

举个例子，当用户说“我常住深圳”时，在响应后面接一个脚本节点，执行：

db.upsert("user_profile", { user_id: context.session_id, last_city: "深圳" })

注意：这个操作不可逆，写入即覆盖，所以务必先用db.get读取原值做比对，避免把一个已经确认过的城市给冲掉。

融合调用：在提示词中显式声明记忆层级

这才是落地的关键——光配置完还不够，你需要告诉模型如何利用这些记忆。

第一步：在系统提示词开头插入状态标记

[SESSION]当前会话ID：{{session.id}}｜[MEMORY_LEVEL]短期：已载入4轮｜长期：已加载用户画像｜

第二步：在每个Agent节点的提示词末尾追加记忆调用指令

例如：“请优先参考短期记忆中最近一轮的selected_option值；若该值为空，则查询长期记忆中的last_city作为默认城市。禁止自行猜测未出现过的城市名。”

第三步：对输出做记忆回写约束

“若本轮用户确认了新地址，请立即将其写入长期记忆last_city字段，并同步更新短期记忆变量confirmed_constraint为‘地址已锁定’。”

这样一来，短期记忆负责实时反映用户当下在做什么，长期记忆负责记住用户是谁、习惯什么，两者各司其职、相互配合，整个多轮对话的连贯性才会真正提升。