在工作流里读写长期记忆跨会话状态怎么保存写给已经会用工作流编排、正准备把「跨会话记忆」接进流程的开发者。本文不重复记忆库是什么只讲这两个节点怎么配、顺序怎么排、坑在哪。先说结论在编排里「记住用户」只有两个动作——写进去、捞出来对应「记忆库写入」和「记忆库检索」两个节点。节点本身的字段很少加起来只有六个真正决定成败的是三个节点之外的问题你要的是哪一层记忆、写入该排在检索前面还是后面、以及那条链路上「用户」这个身份到底是谁。我先给最省事的路径如果你只是想要跨会话记忆、不需要在流程里控制写入时机别搭工作流——在智能体配置里直接绑定长期记忆库就够了它默认每 3 轮对话自动写一次。工作流节点的价值在于「控制」什么时候写、写什么、标成什么角色、检索几条全都能自己定。一、先把三种「记忆」分开它们的生命周期差了几十倍这是我在实际配置里见过最多的误解把「带记忆的对话 API」当成「长期记忆库」把智能体的「记忆轮次」当成跨会话记忆。这三件事在文档里分属三个页面各自都写得不长所以特别容易串。先把它们摆在一起看层次官方叫什么由谁维护生命周期隔离维度第一层 · 对话上下文「带记忆的对话 API」平台按对话 ID维护跟随该对话 ID对话 ID第二层 · 短期记忆智能体的「记忆配置」智能体运行时轮次上限 保留时间上限 30 天会话第三层 · 长期记忆长期记忆库写入 / 检索节点或智能体绑定官方原文写入的内容会被长期保存用户维度1.1 第一层「带记忆的对话 API」管的是上下文不是记忆库渠道接入那一页里列了两个 API其中一个叫「带记忆的对话 API」官方说明是调用方传入对话 ID平台自动维护上下文记忆无需自行处理历史这里的「记忆」指的是这次对话的上下文——你不必自己把历史消息拼进请求里平台按对话 ID 帮你存着。它和你后面要配的长期记忆库没有任何关系一个是「这轮对话里聊过什么」一个是「这个用户上次来聊过什么」。判断标准很简单换个对话 ID 就全忘了的都属于第一层。1.2 第二层短期记忆有两个上限第二个很容易被忽略智能体的模型配置里有个「记忆」字段官方定义是智能体记忆设定的上下文轮次每轮由一条提问和一条回复组成超出该轮次的历史记忆将被自动清除完整的记忆配置是两个参数不是一个配置项范围说明记忆轮次0~50轮保留的对话轮数每轮包含一条提问和一条回复记忆保留时间0~43200分钟记忆数据的过期时间最长30天第二个参数是我觉得最值得单独拎出来说的一条轮次没超、但时间到了记忆照样被清掉。轮次和保留时间是「与」的关系两个都得满足才留得住。43200 分钟正好是 30 天也就是说无论轮次配多高短期记忆的天花板就是 30 天。1.3 第三层长期记忆库是唯一按「用户」隔离的一层长期记忆库页面把功能前提写得非常直接功能前提通过智能体或工作流的「记忆库写入」「记忆库检索」节点读写记忆而写入节点页给出了一句关键的边界写入记忆库的内容会被长期保存请确保写入逻辑准确避免存入无效或错误信息。注意这句和上面那句放在一起的后果短期记忆是「轮次或 30 天自动过期」长期记忆库是「长期保存、不会自己过期」。这意味着一处写错的信息会一直躺在那里被检索出来。它不是缓存你不能靠「反正过几天就没了」来兜底。本节结论选型时先问自己「我要的是这轮对话别断、还是这个人下次来我还认得」——前者调记忆轮次和保留时间就够后者才需要记忆库。把两者当成同一个东西配最典型的症状是「明明开了记忆隔天客户来还是不认识」。二、记忆库写入四个字段一个不看文档必踩的前提写入节点的能力表一共 5 行我抄一下官方的原话然后逐条拆能力官方说明用户维度存储写入内容与当前会话的用户或渠道客户自动绑定实现记忆隔离节点输入可引入前序节点输出作为待写入内容目标记忆库选择写入的目标记忆库动态写入工作流运行时实时写入支持渠道对话等场景持续沉淀用户记忆数据角色每条写入数据可标记「用户」「AI」角色区分真实数据与 AI 分析数据影响检索优先级2.1 目标记忆库库要先存在节点里才有的选官方在这一项下面的提示是需先在长期记忆库中创建记忆库此处才能选择。这条提示很短但它是部署顺序的前提如果你是从工作流这边开始搭的节点里那个下拉框会是空的而且不会给你任何「去创建」的引导。正确的顺序是——先在长期记忆库里建库再回工作流选库。一个容易忽略的推论记忆库既然是一个独立对象那么一个工作流里可以写多个库不同节点选不同库。什么时候需要多个库当你希望不同业务线的记忆互不干扰时。反过来如果两个节点选了不同的库检索节点只从自己那个库里召回——写进去却捞不出来是最难排查的一类问题。2.2 节点输入能拼接但有个连通性前提待写入内容支持两种形态选前序节点的输出或者把多个前序节点结果和自定义文本拼在一起。拼接这个能力容易被低估。它意味着你不需要为了写入而多插一个大模型节点——比如「用户这次说的偏好」「系统时间」「渠道来源」可以拼成一条带上下文的记忆比只存一句干巴巴的偏好信息有用得多。但同一段提示在两页里都出现了必须留意仅当本节点与开始节点存在直接或间接连通关系才能选用前序节点输出参数。这句话的实际含义是变量可选范围由「连线可达性」决定不是由「节点在画布上的位置」决定。所以有两种情况会踩到写入节点挂在某个分支的下游而这条分支没走到 —— 节点不执行本次不写写入节点压根没连在从开始节点出发的链路上比如只是拖到了画布上—— 下拉框里选不到任何前序输出。第二种情况在画布很大的时候特别容易出现因为节点摆在旁边看起来「就在那儿」。2.3 数据角色一个决定召回优先级的字段这是整套机制里设计得最巧的一处。官方给了一张角色对照表角色含义数据来源优先级用户用户的真实数据用户原始输入、明确陈述的信息高优先采用AIAI 对问题提炼、总结、理解、抽取的信息大模型分析结果低备用补充检索时的规则是检索召回时用户角色的真实数据优先级更高AI 角色的提炼信息作为补充备用。当两者同时存在时优先以用户真实数据为准。这套设计的实际价值是给「AI 记错」留了一条退路。大模型从对话里推断出来的结论一定会有偏差——用户说「最近在看新能源车」AI 总结成「用户打算买新能源车」这一步就把可能性升级成了意图。把前者标「用户」、后者标「AI」检索时真实数据优先推断只做补充偏差就不会被放大成事实。官方还给了正反例值得照着抄用户的明确陈述如「我喜欢科幻电影」→ 标记为「用户」角色大模型从对话中推断或总结的结论如「用户偏好科幻类内容」→ 标记为「AI」角色⚠️ 有个细节要看准「单次写入支持多条数据每条可独立设置角色」。也就是说角色是逐条标注的不是整个节点一个开关。如果你的写入节点只写一条拼好的大字符串那整条都是同一个角色——这等于放弃了这套优先级机制。想让机制起作用写入内容就得是可拆的多条。2.4 官方没说的三件事这三条写入节点页没给答案属于必须实测确认的项重复写入会不会去重。同一句话在多轮对话里反复被抽取、反复写入记忆库里是留一条还是留 N 条官方只说了「避免存入无效信息」没讲去重。这直接关系到库会不会随时间膨胀、检索里的噪声比例会不会越来越高。单次写入的条数上限。既然支持多条那上限是多少拼一个几十条的数组进去会不会截断。写入是否同步阻塞。写入放在主链路上如果它是同步的库大之后会不会拖慢整条流程的响应。实操建议不要每轮都写。在检索节点页的注意事项里官方反过来提醒了一句「请确保在检索前已通过记忆库写入节点或其他方式沉淀了足够的用户记忆」——但「足够」不等于「每次都写」。我倾向于只在两个时机写用户明确陈述了偏好或资料时、业务流程产生了一个需要跨会话记住的状态时比如「资料已提交待审核」。其余轮次的信息留在短期上下文里就够了。三、记忆库检索三个字段一个必须接的下游检索节点更简单配置项只有三个。3.1 记忆库和节点输入记忆库选择下面有一句限定检索范围仅限于该记忆库内当前用户的记忆内容。两个限定词都要看住「该记忆库」跨库不通和「当前用户」跨人不通。这也是为什么第二章说的「一个流程里写了多个库」会成为问题——检索节点不会帮你跨库找。节点输入就是检索条件query写法与写入节点完全一致可选前序输出也可拼接多源与自定义文本。query 写什么直接决定召回质量。我的做法是别用用户的原始提问直接当 query。用户问「那你们什么时候能上门」这句话里没有任何可用于匹配记忆的实体把它和「客户称呼」「当前业务环节」拼起来当 query命中率会明显不一样{{开始节点.question}} 当前环节售后跟进 客户称呼{{客户信息节点.称呼}}⚠️ 变量引用的具体写法以你在编排界面上看到的为准不同版本的字段命名会不一样关键是把 query 拼成一句带上下文的话而不是直接丢原始提问。3.2 返回条数默认 5这个数不是随便定的配置项默认值官方提醒返回条数5条不宜设置过高避免超出下游大模型的上下文上限5 条这个默认值配上「检索输出为字符串」就能算出一笔容量账5 条记忆 × 每条的长度 直接进入下游大模型的额外 Token。如果你写记忆的时候喜欢整段整段地存比如把一整轮对话原文写进去5 条就可能吃掉大半个上下文窗口而真正有用的信息可能只占其中两行。所以返回条数和写入形态是要一起调的写入写得精炼条数就能调高写入写得粗放条数必须压住。这两个参数分在两个节点里很容易被当成互不相关的设置各调各的。3.3 输出是字符串下游必须串大模型这是检索节点和数据库节点最大的差别。官方明写记忆库检索节点输出为召回的记忆内容字符串形式。字符串意味着下游拿不到结构化字段——你没法像数据库节点那样把某一列取出来直接做条件判断。官方给的建议也就顺理成章通常建议在下游串联大模型节点由大模型基于召回的记忆 当前提问生成个性化回复。换句话说检索节点的价值要靠大模型节点兑现。如果你的流程里检索节点下游直接接了结束节点那这些记忆就只是被打印出来了一点作用都没起。想让记忆参与判断比如「这位客户上次来是投诉这次要优先」得再串一个节点去解析模型输出。3.4 官方没说的两件事召回是向量检索还是混合检索。长期记忆库页面没有说明检索算法而这一点会直接影响「query 该怎么写」——纯向量检索对语义敏感、对关键词不敏感混合检索则相反。建议用你自己的业务数据实测一批 query看看召回的是不是你想要的那几条。返回条数的上限是多少。官方只给了默认值 5 和一句「不宜过高」没说最大值。四、两条写库路径自动还是手动同一件事往库里写平台给了两条路。这是我在实际配置里觉得最该提前想清楚的一个选择。4.1 路径 A智能体绑定每 3 轮自动写在智能体配置里开启长期记忆库后模块页面而不是节点页给出了这样一段说明在智能体配置中选择并开启长期记忆库后智能体会在对话过程中自动沉淀记忆默认每3轮对话触发一次写入将关键内容按用户维度存入所绑定的记忆库。它的配置项只有三个配置项说明长期记忆库选择绑定的长期记忆库记忆开关开启或关闭长期记忆写入触发轮次自动写入的对话轮次频率默认3轮/次这条路径的特点是零编排成本不用搭工作流勾上就有跨会话记忆。代价是写入内容由系统自动抽取、写入时机你控制不了也没法指定数据角色——而角色直接影响检索优先级。4.2 路径 B工作流节点手动写把写入节点插到流程里任意位置自己决定什么时候写、写什么、每条标什么角色。代价是要自己处理「写什么」这件事——通常得在写入节点前面加一个大模型节点做信息抽取见第五章的提示词。4.3 决策表你的需求建议路径只是想要跨会话记忆业务逻辑简单路径 A智能体绑定记忆必须是用户原话不能是 AI 推断路径 B——只有节点能逐条标角色需要控制写入时机如只在提交资料后写路径 B需要写多来源拼接的内容业务状态时间渠道路径 B流程里已经有一堆编排逻辑只想顺手加记忆路径 A先在智能体上验证效果再考虑迁到流程里需要按用户区分不同记忆库路径 B路径 A 只能绑一个库 官方在两个页面都提示了两者「可配合使用」——绑定智能体的自动写入负责兜底沉淀工作流节点负责关键时机的精确写入两者写进同一个库即可。但要注意重复如果节点已经精确写了自动写入又按 3 轮写一遍同一件事可能进库两次见 2.4 的去重问题。五、编排顺序为什么建议「先检索、后写入」5.1 顺序反了会怎样官方给的典型范式是「开始 → 大模型抽取→ 记忆库写入 → 结束」而检索节点的范式是「开始 → 记忆库检索 → 大模型 → 结束」。把两者合成一整条流程时一个绕不开的问题就出现了写入和检索谁在前面我的建议是先检索、后写入理由有三个避免当轮自我强化。如果先写后查本轮刚写进去的内容会立刻出现在召回结果里模型一边推断一边读到自己的推断容易把一次猜测滚成「事实」。刚写的内容本来就在上下文里。当前这一轮的信息还在短期记忆记忆轮次里没必要再从长期库里捞一遍——那是重复投喂只是多花 tokenn。让配额的 5 条留给真正久远的信息。召回条数有限把当轮内容挤进去等于挤掉了真正的历史记忆。5.2 一条推荐的骨架把两条官方范式合并之后我用的骨架是这样顺序节点作用1开始节点接收用户输入2记忆库检索按当前用户召回历史记忆query 用拼接写法3大模型节点结合召回记忆 当前提问生成回复4大模型节点从本轮对话里抽取值得长期记住的信息5记忆库写入写入抽取结果用户明确陈述的标「用户」角色6结束节点把回复返回用户注意第 3 和第 4 是两个不同的模型节点一个负责答一个负责记。把它们合成一个节点会让提示词很难写——既要它答得好又要它同时输出一份格式规整的待写入内容输出稳定性会明显下降。还有一个反直觉的地方要提醒结束节点取的是「结束节点前一节点」的输出。所以第 5 步的记忆库写入节点不能直接接在结束节点前面否则用户收到的回复会变成写入节点的输出而不是模型的回复。安全做法是让第 3 步的回复节点输出保持为「最后一跳」。5.3 写入前那一步的提示词怎么写抽取节点的提示词要解决两个问题只抽值得长期记的、并按角色拆成多条。示例如下按你的业务改字段你是信息抽取器。只输出 JSON不要任何解释。 从下面这段对话中抽取值得【长期记住】的用户信息分两类 - role: user —— 用户明确说过的原话或明确陈述如偏好、资料、联系方式、明确诉求 - role: ai —— 你从对话中推断出的结论如偏好归类、意图判断 规则 1. 只抽与业务长期相关的信息寒暄、一次性问答、情绪化表达都不抽。 2. 没有可抽取内容时输出 {items: []}。 3. 每条 value 不超过 50 字用陈述句不要添加原文没有的信息。 4. role 为 ai 的条目value 里必须保留推断依据如提到在看新能源车。 输出格式 {items: [{role: user, value: ...}, {role: ai, value: ...}]} 对话内容 {{开始节点.question}} {{上一轮回复节点.answer}}第 4 条规则是我加的一个自保机制让 AI 角色带上推断依据将来在管理界面里看到这条记忆时还能判断它靠不靠谱。长期记忆库里的内容不会自己过期写进去就得能读得懂、能追溯。六、最脆的一环「用户」到底是谁前面所有能力都建立在一个前提上**系统知道「当前用户」是谁。**两个节点页都给了同样的说明记忆库的用户身份由系统自动获取当前会话的用户或渠道客户无需手动配置。同一用户/渠道客户的历史记忆会自动归集到其名下不同用户之间彼此隔离。「无需手动配置」听起来很省事。但请注意这两个字——「或」「当前会话的用户或渠道客户」。也就是说身份来源有两种取哪一种取决于你的应用是怎么被调用的。6.1 我把渠道页翻完了没有找到「用户标识」的定义为了确认渠道场景下这个身份从哪来我把渠道管理那一页逐节看了一遍。结论是该页没有任何关于「用户标识」「用户 ID」「渠道客户」的定义或字段说明。渠道页关于用户的信息只有三条而且都不构成身份定义网页渠道的「欢迎语」默认值文案与身份无关API 接入里的「带记忆的对话 API调用方传入对话 ID」那是第一层的上下文记忆不是用户身份删除渠道时的提示——「关联的客户对话历史可能受影响」这意味着下面这件事官方没有给答案只能实测同一名客户从网站进来、再从公众号进来记忆库认不认得出是同一个人这个问题的答案会直接改变你的方案而且是两个完全不同的方向如果平台按渠道客户各自隔离 —— 那么「跨渠道记忆归集」就不会自动发生你要么接受每个渠道各记一套要么自己在流程里做一层身份映射如果能归集 —— 那就要额外想清楚一件事是不是所有渠道都该共享记忆。企业内部办公渠道钉钉、飞书和对外客服渠道公众号、网页混在一起会带来很奇怪的体验。6.2 必须实测的清单这一节我不给结论只给一份可以直接照着测的清单。这五条测完你才算真的知道自己的记忆是什么行为#测什么怎么测看什么1同一人换渠道记忆是否延续网页渠道说一句偏好再从公众号问同一件事检索是否召回网页那次的内容2同一渠道的匿名会话是否各自独立无痕窗口连开两次分别说不同偏好两个无痕窗口会不会互相看到对方的记忆3清掉会话后是否还是同一用户同一浏览器清 Cookie 或重开会话后再聊记忆是否还在4群聊场景下「用户」是谁在企微或钉钉群里 机器人说一句偏好记忆归到群还是归到个人5两个不同的人在同一台设备上聊同一浏览器切换不同业务账号记忆是否串了第 5 条是隐私风险最高的一条。如果你做的是对外开放的客服场景这一条必须在前置环节就测掉——记忆串用户比记不住用户严重得多。本节结论把「用户身份」当成一个必须先验证的前提而不是一个已经生效的默认能力。文档没写的地方就是你要多花半天测的地方。七、兼容性边界这些直觉在这里不适用把这一章单独列出来是因为下面几条都很容易被「其他模块的经验」带偏① 记忆库不是知识库写进去的是「谁的」不是「什么的」。知识库全库共享检索时所有人看到同样的内容记忆库按用户隔离同一个 query 不同的人召回不同结果。同一个业务问题不要既写知识库又写记忆库否则会出现「这个人知道、那个人不知道」的不一致。② 记忆库不会自动过期短期记忆会。三类记忆里只有长期记忆库是「长期保存」。前面说过一次这里是它的推论短期记忆出错可以等它自己过期长期记忆库出错只能人工去管理界面删。③ 检索输出是字符串不能当结构化字段用。数据库节点能给结构化结果记忆库检索不能。④ 变量可选范围由连线可达性决定不是画布位置。「间接连通」这四个字是硬条件。⑤ 智能体的记忆配置和长期记忆库是两个旋钮不互相替代。官方在两个页面上都专门写了这句区分说明混淆率确实高。短期记忆管「这轮聊得顺不顺」长期记忆管「下次还认不认得」。⑥ 角色是逐条标注的不是节点级开关。想用上优先级机制写入内容就得是可拆的多条。⑦ 版本边界以上四个页面长期记忆库、记忆库写入、记忆库检索、智能体官方均未标注版本要求。需要以你实际开通的版本为准不要从其他模块比如转人工是专业版及以上推断记忆库的版本归属。八、上线前检查清单按顺序过一遍每条都能直接操作配置阶段先在长期记忆库里把库建好再回工作流选库顺序反了会看到空的下拉框确认写入节点连在从开始节点出发的链路上不是只摆在画布上确认写入和检索两个节点选的是同一个记忆库写入节点的抽取提示词里明确要求「按角色拆成多条」不要输出单条大字符串检索节点的 query 用拼接写法原始提问 客户称呼 当前业务环节返回条数从默认 5 起步不要一上来就调高编排阶段检索放在写入前面避免当轮自我强化写入节点不要直接接在结束节点之前结束节点取的是前一节点的输出会把回复顶掉「答」和「记」用两个独立的大模型节点不要合并在分支结构里确认未走到的那条分支上的写入节点不会执行验证阶段走一遍 6.2 的五条实测换渠道、匿名会话、清会话、群聊、同设备换人写入一批记忆后用同一个 query 反复检索看召回结果是否稳定、是否符合预期故意写一条错误信息观察它会不会被检索到、会不会影响回复——长期记忆库不会自己过期这条必须测用一条长记忆内容压测看 5 条召回会不会把下游模型的上下文吃满确认记忆库的管理界面有人负责谁来删错误记忆、多久巡检一次第 13 条和第 15 条是两条容易被跳过、但代价最高的长期记忆库是一份不会自己清理的档案它的正确性靠的是写入时的谨慎和事后的巡检不是靠时间。写在最后这两个节点的配置项加起来只有六个但真正决定效果的是三件节点之外的事分得清哪一层记忆轮次和 30 天的保留时间只管短期、排的对写入与检索的顺序、测得准「用户」是谁。如果只记一句话别把长期记忆库当缓存用。缓存可以随便写、错了就过期长期记忆库写进去就一直在它是档案需要用档案的标准对待写入逻辑。需要提醒的是记忆库的检索算法、写入去重、渠道用户标识这几处官方文档没有展开文中相关部分我都明确标注为需要实测确认——参数与行为以你所用平台的最新文档和实际配置界面为准。相关文章零代码工作流引擎实战LangGraph 如何承载“画图即运行”不用写代码也能编排 AI 业务流程单节点运行和全流程试运行到底该先用哪个个【发布前自检 | 不要复制进正文】正文 9428 字不含代码块代码块 2 个表格 9 张8 节 写在最后 15 条清单去品牌化四条无平台名、无真实域名、无站外链接、无推广引导 —— 全绿所有引用官方原文处均为逐字引用官方未展开的三处检索算法、写入去重、渠道用户标识均明确标注「需实测」未做推断版本边界按来源表述记忆库相关四页官方均未标注版本未从其他模块推断