在使用 Coze 搭建智能体时很多开发者和产品经理会发现一个典型问题用户对话到第二、三轮智能体就开始“失忆”用户不得不重复姓名、地点、偏好等基础信息。这正是缺少记忆功能导致的体验断层。Coze 平台提供的记忆功能可以把用户信息、上下文偏好、历史意图等内容在会话之间保留下来让智能体从“只能聊当前这一轮”变成“能记住用户是谁、之前聊过什么”。这篇文章会围绕 Coze 记忆功能讲清楚它的底层机制、配置方式、实战用法、验证方法和排查思路帮助你在不重写代码的情况下用平台能力提升智能体的个性化体验。不建议一上来就堆功能开关。先理解记忆功能解决什么问题再明确 Coze 里的记忆体系分成哪几层最后按“配置、写提示词、测试、上线、排查”的顺序落地。这样即使后续版本界面变化你也能知道该去哪里找、该看什么指标。1. Coze 记忆功能到底解决什么问题1.1 没有记忆的智能体会话像失忆大语言模型的本质是无状态函数。每一次对话请求都会携带完整的上下文窗口模型本身并不具备跨请求保存数据的能力。在没有额外记忆机制的情况下智能体每次收到消息都要重新从 prompt、知识库和当前对话历史里理解用户意图。这在很多场景里会造成糟糕的用户体验用户第一次说“我住在上海喜欢安静的环境”第二次问“推荐一个周末去处”时智能体完全不记得“上海”和“安静”这两个条件。用户在多轮交互中提供了邮箱、手机号、公司名称最后提交订单时智能体仍然要求逐项重新输入。用户上周已经反馈过某个产品故障这周再次咨询时智能体无法关联上次的问题和解决状态。Coze 记忆功能的目标是把这些关键信息从“单次对话上下文”中抽离出来以结构化或半结构化的方式保存在后续对话中自动注入回模型上下文从而让智能体具备连续的个性化服务能力。1.2 记忆功能的核心能力与工作方式Coze 记忆功能本质上是一套“抽取、存储、注入、更新”的机制。抽取从用户对话中识别需要记住的内容例如用户名、年龄、城市、偏好、任务状态、用户 ID 等。存储将抽取结果写入平台提供的记忆存储区区分用户级记忆和会话级记忆。注入在后续对话开始时把与当前用户相关的记忆内容拼接到 prompt 中让模型能够感知。更新当用户信息变化或模型发现新信息与旧信息冲突时写入新的记忆并覆盖旧值。在 Coze 平台中开发者不需要手动维护数据库表只需要在“记忆”配置面板中定义字段并为模型配置抽取提示词系统就会在对话过程中自动完成上述流程。本质是平台帮你封装了常见的记忆管理逻辑。1.3 记忆功能与普通上下文窗口的区别很多人会把记忆功能和上下文窗口混淆。它们的差别要注意。上下文窗口是模型单次推理时能看到的 token 范围包括系统提示词、历史对话、工具返回结果等。它的作用是“这次对话中能理解多少内容”但它会随着会话结束而消失也有长度上限。记忆功能则是把信息从上下文中持久化出来。即使会话结束下次新开会话智能体仍然能把上次记忆的用户偏好注入进来。维度普通上下文窗口Coze 记忆功能生命周期单次会话随会话结束而失效跨会话长期保存可按用户维度管理存储位置模型请求参数中内存态平台侧持久化存储可配置字段信息范围当前对话涉及的所有内容被识别为重要且需要长期保存的字段是否可检索一次性使用不可单独查询可在平台管理界面查看和修改对体验的影响换会话后失忆信息容易丢失换会话后仍可恢复个性化更强所以在实际项目中不要把记忆功能当成“无限上下文”。它更适合保存高频、稳定、跨会话需要复用的信息而临时对话内容仍应依赖普通上下文。2. 认识 Coze 记忆体系用户记忆、会话记忆与数据库记忆2.1 用户记忆是什么用户记忆是所有记忆类型中最核心的一层。它按照用户维度保存信息同一个用户在多次对话甚至多个智能体间可以共享且持久化的记忆。在 Coze 中用户记忆通常有一个明确的记忆字段列表。开发者可以定义字段名、字段描述、数据类型和是否必填。例如姓名用户如何称呼自己。所在城市用户当前所在城市或常用城市。联系方式用户主动提供的邮箱或电话。偏好风格用户希望回复使用简洁还是详细风格。模型会从对话中抽取这些字段并自动写入。用户在下一轮对话时智能体就能组合这些信息生成更贴切的回复。这里要注意一个区分Coze 平台下的“用户”应该以产品内的用户 ID 为准。如果智能体被嵌入到你的网站或 App应该通过用户标识传入 Coze确保不同设备同一个人能看到一致记忆。2.2 会话记忆的边界会话记忆指的是当前会话内的临时上下文。Coze 平台通常会保留一定轮次的对话历史让模型能理解“刚才聊到哪”。这部分不需要开发者额外配置属于模型上下文的基础能力。但它的边界很明显会话结束、超时关闭或手动清空后临时上下文就会丢失。所以如果某个信息需要长期使用就应该通过提示词或规则让模型把它写入用户记忆而不是只停留在会话记忆中。另一个常见误区是不要把所有对话历史都塞给模型。上下文越长推理延迟越高费用也越高。会话记忆只需要保留最近几轮有效信息即可长期信息交给用户记忆字段。2.3 数据库记忆用于长期结构化存储当用户记忆字段已经无法满足复杂数据时可以考虑使用 Coze 的变量或知识库能力配合数据库记忆来实现。例如一个任务型智能体需要记录用户多个订单的状态或者记录用户多个偏好项。此时可以在平台中创建“变量”使用变量存储 JSON 对象或通过外部数据库集成。Coze 平台也支持通过插件或工作流把数据写入第三方数据库再通过检索任务取回。实际项目中很常见的组合用户基本信息写入 Coze 用户记忆字段。订单列表、历史投诉、日程安排写入外部数据库通过 API 或插件查询。临时流程状态写入会话级变量在当前会话内使用。这种分层的好处是记忆功能负责高频小数据外部数据库负责大容量结构化数据两者互补而不是互斥。3. 在 Coze 平台上开启和配置记忆功能3.1 创建一个带记忆能力的智能体操作流程如下不同版本可能界面稍有差异但入口逻辑类似。第一步登录 Coze 平台创建一个智能体项目。第二步在智能体“设置”或“配置”页面中找到“记忆”相关选项通常会有“启用长期记忆”或“用户记忆”开关。第三步开启后进入记忆字段配置页面。开启后不要急着写提示词先把字段设计好。字段设计会直接影响模型抽取信息的准确度。命名要清晰描述要写清楚“从什么信息中抽取”例如“用户所在城市根据用户提到的地理位置信息提取如果没有提到不要猜测。”这个阶段的目标是让平台能识别出“该存什么、存到哪、怎么抽”。3.2 设置用户记忆字段与默认值在配置页面里常见的字段属性包括字段名称使用英文或拼音便于在变量中引用。字段别名中文描述用于让模型理解。数据类型字符串、数字、数组等。抽取指令告诉模型什么情况下需要写入该字段。默认值当没获取到信息时使用什么值。例如字段名称字段描述数据类型默认值抽取指令user_name用户姓名或昵称string未知当用户自我介绍时记录不要随意猜测city用户所在城市string未知从用户的表述中提取城市名称tone回复风格偏好string简洁当用户表达“要详细/太长/简洁”时更新order_times累计咨询次数number0每次用户咨询后加 1这里需要注意默认值不是简单的“初始值”。如果在用户记忆中没有读取到值模型会使用默认值作为兜底避免关键词为空报错。配置完成后保存并发布智能体记忆功能才会在线上接口中生效。在测试环境修改字段后需要重新发布到对应环境否则调试时可能仍然看不到记忆效果。3.3 让模型自动记忆与人工校验结合Coze 记忆功能默认依赖模型自动抽取信息。这种做法对简单字段有效但对复杂、敏感、易错的字段可能不够稳定。建议采用“自动 规则 人工”三层校验。自动层在记忆配置中打开关键字段的自动抽取如用户城市、偏好风格。规则层在业务环节中使用工作流或插件对特定输入做二次校验。例如用户输入手机号时可以先用正则校验格式再写入记忆字段而不是直接让模型存。人工层在产品后台增加“查看用户记忆”页面允许客服人员查看和修正记忆内容。Coze 平台的管理端如果支持修改用户记忆可直接修改如果暂不支持可以通过数据库工具或 API 修正。实际项目中建议先在对内测试环境中开启自动记忆通过多轮对话种子数据验证抽取准确率准确率达到预期后再全量开放。4. 通过提示词和变量写出“会记人”的对话逻辑4.1 使用记忆变量填充个性化回复开启记忆功能后你会得到可以引用的变量。在 Coze 的提示词编辑器中可以直接使用这些变量例如系统提示词 你是一个生活助手。请根据以下信息回复用户 用户昵称{user_name} 用户所在城市{city} 用户偏好表达风格{tone} 如果用户没有提供完整信息先询问缺失的关键项不要编造。这里的关键点是记忆变量必须正确拼写且要在发布前检查变量名是否存在。如果变量名写错模型不会报错但取不到值回复就会出现“空值”或不自然的兜底。实际使用中还可以用变量组合出更复杂的个性化逻辑。例如如果用户所在城市是北京回复时要优先推荐北京的线下门店 如果用户所在城市未知则提示“告诉我你的城市我可以推荐离你最近的服务点”。这样记忆就不是孤立的字段而是参与业务决策的重要输入。4.2 多轮对话中更新记忆的触发条件记忆不是一次写入后就永远不变。用户会改城市、换公司、更新偏好。所以要为更新设置触发条件。建议在系统提示词中明确写入更新规则例如记忆更新规则 1. 当用户直接说“我在上海”“我家在杭州”这类地点信息时更新 city 字段。 2. 当用户说“你以后说简单点”“能不能详细一点”时更新 tone 字段。 3. 不要因为用户举例、转述别人信息而更新记忆。 4. 如果用户纠正了之前的信息将旧值覆盖为新值。这些规则确保模型只在用户表达真实意图时更新记忆而不是把模拟、假设、玩笑都当成事实存进去。规则越具体误写率越低。4.3 记忆缺失时的兜底策略即便配置了记忆功能依然会出现记忆缺失的情况。例如新用户第一次访问没有任何历史记忆或者用户之前使用的是未开启记忆的旧版本会话。此时需要兜底策略。兜底策略的核心是“优雅地询问而不是假装记得”。示例提示词如果 memory 中没有用户姓名回复时不要使用空占位符而是说 “为了后续更方便地为您服务请问如何称呼您” 如果 memory 中没有城市回复时可以说 “您可以先告诉我所在城市我会按城市为您推荐。”这里特别注意不要使用{user_name}为空时仍然正常输出的写法因为模型可能会输出“你好{}”或“你好未知”。要让模型根据变量是否为空做分支处理。Coze 中可以通过条件判断插件或工作流节点来检查变量值但最简单的方式是让模型在提示词中学会判断。如果追求稳定建议用工作流做“变量值校验”后再决定如何回复。5. 验证记忆效果从测试到用户反馈5.1 在 Playground 中测试记忆是否写入Coze 智能体通常提供 Playground 测试窗。验证步骤可以这样进行。第一轮对话输入你好我叫李晨我在上海工作平时更喜欢详细一点的回答。查看回复是否符合预期然后打开“记忆”或“变量”面板检查是否已经写入user_name 李晨city 上海tone 详细如果在 Playground 中看不到记忆面板可以换一个办法发起第二段新的会话在第一轮之后隔几分钟再测试。第二段会话注意开始新对话而不是继续原会话输入你知道我在哪座城市吗预期回复能说出“你在上海”并自然使用“李晨”称呼你。如果回答“我无法记住”或“我不知道”说明记忆未写入或未注入需要进入排查流程。5.2 跨会话恢复记忆的验证步骤跨会话恢复是记忆功能的核心价值。建议按这个步骤验证会话 A用户提供姓名、城市、偏好结束会话。等待 30 秒以上确保存储延迟已过去。会话 B重新发起对话输入“我家在一个安静的地方推荐一个周末活动”。检查模型是否结合了“上海”和“安静”两个信息生成回复。如果模型没有调用历史信息检查系统提示词是否引用了记忆变量以及用户标识是否一致。这里有个常见问题如果使用匿名用户或不传用户 IDCoze 可能无法定位到同一个用户导致记忆无法关联。在集成到产品中时必须保证每次对话都携带同一个用户标识。5.3 记忆误写与隐私问题的观察点在验证时不要只看“记得住”还要看“记得对”和“不该记的不记”。重点观察以下场景用户说“我朋友在上海”时是否错误记忆成“用户所在城市上海”。用户开了个玩笑“我住在火星”是否真的写入 city火星。用户提供身份证号、银行卡号等敏感信息时是否被存入了普通记忆字段。用户明确说“不要记住我的信息”时模型是否仍然写入。如果发现误写一方面要调整提示词中的抽取规则另一方面要对敏感字段增加白名单校验。必要时可以关闭某些字段的自动记忆改为由工作流显式写入。6. 记忆功能常见问题排查6.1 为什么记忆没有保存出现“对话中说了信息但记忆字段仍然为空”的情况时按这个顺序检查问题现象可能原因检查方式处理建议记忆字段一直为空未开启记忆开关检查智能体配置中的记忆开关在配置页开启记忆能力用户说了信息但没写入抽取指令不够具体查看字段配置的抽取指令补充“当……时记录”的规则系统提示词未引用记忆变量模型没有感知记忆字段检查提示词中是否包含变量名在系统提示词中加入记忆变量用户 ID 不同跨会话时未传同一用户标识检查端侧传参和会话创建逻辑统一用户标识并在请求中传入存储延迟刚写入后立即查询未同步等待几秒后再次查询预留异步写延迟容忍时间6.2 为什么回复没有用到记忆即使记忆字段已经有值回复仍然可能没有使用它们。常见原因包括提示词里没有让模型“优先使用记忆”或者记忆值被业务逻辑覆盖。检查点是否在系统提示词中说明“你应该根据用户的记忆信息来回复”。是否在回复模板中显式使用了变量。是否因为用户的当前消息信息量更大模型选择了当前消息而忽略历史记忆。这时需要在提示词中明确“如果没有新的冲突信息优先使用记忆中保存的信息”。是否在工作流中强行覆盖了该字段使用了默认值。6.3 记忆冲突与覆盖问题用户第一次说城市是北京第二次说“我最近搬到杭州了”模型应该更新为杭州。但如果规则不清晰可能出现两种错误要么保留旧值不更新要么把用户转述的“朋友在杭州”也更新为杭州。建议在提示词中明确覆盖规则如果用户提到“我现在住在”“我搬到”“以后联系我可以用”等表达视为更新记忆。 如果用户是以第三人称或假设语气提到某地不更新记忆。另外不要频繁让模型更新所有字段。可以只让模型在小范围内更新“只有用户明确表达变化时才更新city字段其他字段不更新。”7. 利用记忆功能优化用户体验的几个实践模式7.1 学习型智能体记住用户偏好典型场景是内容推荐、学习助手、陪聊类智能体。通过记忆字段保存用户阅读偏好、内容长度、是否喜欢举例、专业背景等信息。每次对话都基于这些信息调整回复。提示词思路你的任务是推荐学习资料。需要结合用户的兴趣领域 {interest} 和阅读深度 {depth}。 如果记忆中没有对应信息请询问用户并给出几个示例选项帮助用户快速选择。这种模式下用户体验的提升路径很直观用户第一次手动指定偏好后续每次对话都不需要重新设置智能体越来越“懂自己”。7.2 任务型智能体记住表单进度在报名、预约、投诉等场景中用户往往需要分多轮提供信息。如果没有记忆每轮都要重复之前已经填过的内容。使用记忆字段可以保存表单进度。例如预约场景记忆字段appointment_service预约的服务类型appointment_time期望时间customer_phone联系电话form_step当前完成的步骤流程可以设计为用户说“我要预约维修”智能体询问服务类型和地址。每获取一项信息就把对应字段写入记忆。再次进入会话时智能体检查form_step字段自动继续提醒未填写的字段。这种模式能显著减少用户重复输入提升表单完成率。7.3 服务型智能体记住历史工单与投诉记录面向客服场景时单纯记住姓名和城市还不够。用户更希望智能体能关联到自己的历史工单、售后状态、优惠权益等。此时推荐把用户记忆字段和外部数据库/API 配合使用。用户首次登录后通过工作流查询订单信息将最近一条订单状态写入记忆字段。之后用户咨询时智能体可以直接说“您上次反馈的物流问题已经解决请问还需要帮忙吗”。这种实践对用户体验提升最明显但实现复杂度也最高。关键点是用户标识必须一致并且外部数据读取失败时要给兜底回复不能让智能体“胡说”。8. 生产环境中的记忆功能最佳实践与扩展方向8.1 记忆信息的安全与权限控制记忆本质上是用户隐私数据。在生产环境上线前要明确几个问题哪些字段允许被自动记忆谁可以查看用户记忆内容用户如何申请删除自己的记忆记忆数据的保留周期是多久建议默认只记忆用户主动提供且非敏感的信息。身份证号、银行卡号、密码、验证码等信息绝不写入普通记忆字段。如果业务流程确实需要应该使用加密存储和专用接口而不是放进模型记忆。同时要保证用户有“清除记忆”的途径。可以在产品中提供一个“忘记我”按钮调用清理记忆的接口或逻辑。8.2 记忆内容的质量控制和定期清理模型自动抽取的信息可能存在噪声。建议建立定期核对机制每周抽样检查记忆字段与真实对话的一致性。对误写率高的字段调整抽取规则或关闭自动抽取。对超过 90 天未更新的记忆信息进行清理或归档。另外建议使用“记忆不变量”机制当记忆字段要更新时先检查当前值和新值如果差异巨大可以要求用户确认。例如原来城市是北京现在要改成东京可以回复“您之前提到在北京现在是否需要更新为东京”8.3 结合外部数据库实现更复杂的记忆体系平台内置记忆适合保存轻型信息。当业务数据复杂到一定程度时建议将记忆功能与外部数据库结合。典型的扩展架构Coze 记忆字段用户基础信息、偏好设置、当前会话状态。外部业务数据库订单、工单、积分、历史记录等结构化数据。工作流或插件在对话中查询、写入、更新业务数据。检索增强当对话需要历史记录时通过插件检索并注入上下文。这样既享受了 Coze 记忆功能的自动化抽取又不会把大量业务数据塞进平台存储保持了数据归属和查询灵活性。8.4 上线前检查清单复制以下清单在发布智能体前逐项核对是否已开启记忆功能并明确用户 ID 传入方式。记忆字段是否只包含必要信息是否包含敏感字段。每个字段的抽取指令是否描述清楚能处理“未提及”和“否定表达”。系统提示词是否引用了记忆变量并设置了缺失兜底。是否配置了记忆更新规则避免误写和覆盖。是否验证了跨会话记忆恢复而不只是当前会话。是否验证了记忆字段为空时模型不会使用空值。是否提供用户清除记忆的路径并测试清除后新会话不再使用旧记忆。是否监控了记忆写入准确率并建立定期清理机制。是否对外部数据库的查询失败做了兜底回复。Coze 记忆功能的价值不只在“能记住”更在于“记住该记的、用对该用的、忘掉不该记的”。把字段设计、提示词规则、验证流程和清理机制结合起来才能真正把记忆能力转化为可感知的体验提升。建议从一个最核心的字段开始试点跑通后再逐步扩展而不是一开始就设计几十个记忆字段。
Coze记忆功能全解析：让智能体告别“失忆”
在使用 Coze 搭建智能体时很多开发者和产品经理会发现一个典型问题用户对话到第二、三轮智能体就开始“失忆”用户不得不重复姓名、地点、偏好等基础信息。这正是缺少记忆功能导致的体验断层。Coze 平台提供的记忆功能可以把用户信息、上下文偏好、历史意图等内容在会话之间保留下来让智能体从“只能聊当前这一轮”变成“能记住用户是谁、之前聊过什么”。这篇文章会围绕 Coze 记忆功能讲清楚它的底层机制、配置方式、实战用法、验证方法和排查思路帮助你在不重写代码的情况下用平台能力提升智能体的个性化体验。不建议一上来就堆功能开关。先理解记忆功能解决什么问题再明确 Coze 里的记忆体系分成哪几层最后按“配置、写提示词、测试、上线、排查”的顺序落地。这样即使后续版本界面变化你也能知道该去哪里找、该看什么指标。1. Coze 记忆功能到底解决什么问题1.1 没有记忆的智能体会话像失忆大语言模型的本质是无状态函数。每一次对话请求都会携带完整的上下文窗口模型本身并不具备跨请求保存数据的能力。在没有额外记忆机制的情况下智能体每次收到消息都要重新从 prompt、知识库和当前对话历史里理解用户意图。这在很多场景里会造成糟糕的用户体验用户第一次说“我住在上海喜欢安静的环境”第二次问“推荐一个周末去处”时智能体完全不记得“上海”和“安静”这两个条件。用户在多轮交互中提供了邮箱、手机号、公司名称最后提交订单时智能体仍然要求逐项重新输入。用户上周已经反馈过某个产品故障这周再次咨询时智能体无法关联上次的问题和解决状态。Coze 记忆功能的目标是把这些关键信息从“单次对话上下文”中抽离出来以结构化或半结构化的方式保存在后续对话中自动注入回模型上下文从而让智能体具备连续的个性化服务能力。1.2 记忆功能的核心能力与工作方式Coze 记忆功能本质上是一套“抽取、存储、注入、更新”的机制。抽取从用户对话中识别需要记住的内容例如用户名、年龄、城市、偏好、任务状态、用户 ID 等。存储将抽取结果写入平台提供的记忆存储区区分用户级记忆和会话级记忆。注入在后续对话开始时把与当前用户相关的记忆内容拼接到 prompt 中让模型能够感知。更新当用户信息变化或模型发现新信息与旧信息冲突时写入新的记忆并覆盖旧值。在 Coze 平台中开发者不需要手动维护数据库表只需要在“记忆”配置面板中定义字段并为模型配置抽取提示词系统就会在对话过程中自动完成上述流程。本质是平台帮你封装了常见的记忆管理逻辑。1.3 记忆功能与普通上下文窗口的区别很多人会把记忆功能和上下文窗口混淆。它们的差别要注意。上下文窗口是模型单次推理时能看到的 token 范围包括系统提示词、历史对话、工具返回结果等。它的作用是“这次对话中能理解多少内容”但它会随着会话结束而消失也有长度上限。记忆功能则是把信息从上下文中持久化出来。即使会话结束下次新开会话智能体仍然能把上次记忆的用户偏好注入进来。维度普通上下文窗口Coze 记忆功能生命周期单次会话随会话结束而失效跨会话长期保存可按用户维度管理存储位置模型请求参数中内存态平台侧持久化存储可配置字段信息范围当前对话涉及的所有内容被识别为重要且需要长期保存的字段是否可检索一次性使用不可单独查询可在平台管理界面查看和修改对体验的影响换会话后失忆信息容易丢失换会话后仍可恢复个性化更强所以在实际项目中不要把记忆功能当成“无限上下文”。它更适合保存高频、稳定、跨会话需要复用的信息而临时对话内容仍应依赖普通上下文。2. 认识 Coze 记忆体系用户记忆、会话记忆与数据库记忆2.1 用户记忆是什么用户记忆是所有记忆类型中最核心的一层。它按照用户维度保存信息同一个用户在多次对话甚至多个智能体间可以共享且持久化的记忆。在 Coze 中用户记忆通常有一个明确的记忆字段列表。开发者可以定义字段名、字段描述、数据类型和是否必填。例如姓名用户如何称呼自己。所在城市用户当前所在城市或常用城市。联系方式用户主动提供的邮箱或电话。偏好风格用户希望回复使用简洁还是详细风格。模型会从对话中抽取这些字段并自动写入。用户在下一轮对话时智能体就能组合这些信息生成更贴切的回复。这里要注意一个区分Coze 平台下的“用户”应该以产品内的用户 ID 为准。如果智能体被嵌入到你的网站或 App应该通过用户标识传入 Coze确保不同设备同一个人能看到一致记忆。2.2 会话记忆的边界会话记忆指的是当前会话内的临时上下文。Coze 平台通常会保留一定轮次的对话历史让模型能理解“刚才聊到哪”。这部分不需要开发者额外配置属于模型上下文的基础能力。但它的边界很明显会话结束、超时关闭或手动清空后临时上下文就会丢失。所以如果某个信息需要长期使用就应该通过提示词或规则让模型把它写入用户记忆而不是只停留在会话记忆中。另一个常见误区是不要把所有对话历史都塞给模型。上下文越长推理延迟越高费用也越高。会话记忆只需要保留最近几轮有效信息即可长期信息交给用户记忆字段。2.3 数据库记忆用于长期结构化存储当用户记忆字段已经无法满足复杂数据时可以考虑使用 Coze 的变量或知识库能力配合数据库记忆来实现。例如一个任务型智能体需要记录用户多个订单的状态或者记录用户多个偏好项。此时可以在平台中创建“变量”使用变量存储 JSON 对象或通过外部数据库集成。Coze 平台也支持通过插件或工作流把数据写入第三方数据库再通过检索任务取回。实际项目中很常见的组合用户基本信息写入 Coze 用户记忆字段。订单列表、历史投诉、日程安排写入外部数据库通过 API 或插件查询。临时流程状态写入会话级变量在当前会话内使用。这种分层的好处是记忆功能负责高频小数据外部数据库负责大容量结构化数据两者互补而不是互斥。3. 在 Coze 平台上开启和配置记忆功能3.1 创建一个带记忆能力的智能体操作流程如下不同版本可能界面稍有差异但入口逻辑类似。第一步登录 Coze 平台创建一个智能体项目。第二步在智能体“设置”或“配置”页面中找到“记忆”相关选项通常会有“启用长期记忆”或“用户记忆”开关。第三步开启后进入记忆字段配置页面。开启后不要急着写提示词先把字段设计好。字段设计会直接影响模型抽取信息的准确度。命名要清晰描述要写清楚“从什么信息中抽取”例如“用户所在城市根据用户提到的地理位置信息提取如果没有提到不要猜测。”这个阶段的目标是让平台能识别出“该存什么、存到哪、怎么抽”。3.2 设置用户记忆字段与默认值在配置页面里常见的字段属性包括字段名称使用英文或拼音便于在变量中引用。字段别名中文描述用于让模型理解。数据类型字符串、数字、数组等。抽取指令告诉模型什么情况下需要写入该字段。默认值当没获取到信息时使用什么值。例如字段名称字段描述数据类型默认值抽取指令user_name用户姓名或昵称string未知当用户自我介绍时记录不要随意猜测city用户所在城市string未知从用户的表述中提取城市名称tone回复风格偏好string简洁当用户表达“要详细/太长/简洁”时更新order_times累计咨询次数number0每次用户咨询后加 1这里需要注意默认值不是简单的“初始值”。如果在用户记忆中没有读取到值模型会使用默认值作为兜底避免关键词为空报错。配置完成后保存并发布智能体记忆功能才会在线上接口中生效。在测试环境修改字段后需要重新发布到对应环境否则调试时可能仍然看不到记忆效果。3.3 让模型自动记忆与人工校验结合Coze 记忆功能默认依赖模型自动抽取信息。这种做法对简单字段有效但对复杂、敏感、易错的字段可能不够稳定。建议采用“自动 规则 人工”三层校验。自动层在记忆配置中打开关键字段的自动抽取如用户城市、偏好风格。规则层在业务环节中使用工作流或插件对特定输入做二次校验。例如用户输入手机号时可以先用正则校验格式再写入记忆字段而不是直接让模型存。人工层在产品后台增加“查看用户记忆”页面允许客服人员查看和修正记忆内容。Coze 平台的管理端如果支持修改用户记忆可直接修改如果暂不支持可以通过数据库工具或 API 修正。实际项目中建议先在对内测试环境中开启自动记忆通过多轮对话种子数据验证抽取准确率准确率达到预期后再全量开放。4. 通过提示词和变量写出“会记人”的对话逻辑4.1 使用记忆变量填充个性化回复开启记忆功能后你会得到可以引用的变量。在 Coze 的提示词编辑器中可以直接使用这些变量例如系统提示词 你是一个生活助手。请根据以下信息回复用户 用户昵称{user_name} 用户所在城市{city} 用户偏好表达风格{tone} 如果用户没有提供完整信息先询问缺失的关键项不要编造。这里的关键点是记忆变量必须正确拼写且要在发布前检查变量名是否存在。如果变量名写错模型不会报错但取不到值回复就会出现“空值”或不自然的兜底。实际使用中还可以用变量组合出更复杂的个性化逻辑。例如如果用户所在城市是北京回复时要优先推荐北京的线下门店 如果用户所在城市未知则提示“告诉我你的城市我可以推荐离你最近的服务点”。这样记忆就不是孤立的字段而是参与业务决策的重要输入。4.2 多轮对话中更新记忆的触发条件记忆不是一次写入后就永远不变。用户会改城市、换公司、更新偏好。所以要为更新设置触发条件。建议在系统提示词中明确写入更新规则例如记忆更新规则 1. 当用户直接说“我在上海”“我家在杭州”这类地点信息时更新 city 字段。 2. 当用户说“你以后说简单点”“能不能详细一点”时更新 tone 字段。 3. 不要因为用户举例、转述别人信息而更新记忆。 4. 如果用户纠正了之前的信息将旧值覆盖为新值。这些规则确保模型只在用户表达真实意图时更新记忆而不是把模拟、假设、玩笑都当成事实存进去。规则越具体误写率越低。4.3 记忆缺失时的兜底策略即便配置了记忆功能依然会出现记忆缺失的情况。例如新用户第一次访问没有任何历史记忆或者用户之前使用的是未开启记忆的旧版本会话。此时需要兜底策略。兜底策略的核心是“优雅地询问而不是假装记得”。示例提示词如果 memory 中没有用户姓名回复时不要使用空占位符而是说 “为了后续更方便地为您服务请问如何称呼您” 如果 memory 中没有城市回复时可以说 “您可以先告诉我所在城市我会按城市为您推荐。”这里特别注意不要使用{user_name}为空时仍然正常输出的写法因为模型可能会输出“你好{}”或“你好未知”。要让模型根据变量是否为空做分支处理。Coze 中可以通过条件判断插件或工作流节点来检查变量值但最简单的方式是让模型在提示词中学会判断。如果追求稳定建议用工作流做“变量值校验”后再决定如何回复。5. 验证记忆效果从测试到用户反馈5.1 在 Playground 中测试记忆是否写入Coze 智能体通常提供 Playground 测试窗。验证步骤可以这样进行。第一轮对话输入你好我叫李晨我在上海工作平时更喜欢详细一点的回答。查看回复是否符合预期然后打开“记忆”或“变量”面板检查是否已经写入user_name 李晨city 上海tone 详细如果在 Playground 中看不到记忆面板可以换一个办法发起第二段新的会话在第一轮之后隔几分钟再测试。第二段会话注意开始新对话而不是继续原会话输入你知道我在哪座城市吗预期回复能说出“你在上海”并自然使用“李晨”称呼你。如果回答“我无法记住”或“我不知道”说明记忆未写入或未注入需要进入排查流程。5.2 跨会话恢复记忆的验证步骤跨会话恢复是记忆功能的核心价值。建议按这个步骤验证会话 A用户提供姓名、城市、偏好结束会话。等待 30 秒以上确保存储延迟已过去。会话 B重新发起对话输入“我家在一个安静的地方推荐一个周末活动”。检查模型是否结合了“上海”和“安静”两个信息生成回复。如果模型没有调用历史信息检查系统提示词是否引用了记忆变量以及用户标识是否一致。这里有个常见问题如果使用匿名用户或不传用户 IDCoze 可能无法定位到同一个用户导致记忆无法关联。在集成到产品中时必须保证每次对话都携带同一个用户标识。5.3 记忆误写与隐私问题的观察点在验证时不要只看“记得住”还要看“记得对”和“不该记的不记”。重点观察以下场景用户说“我朋友在上海”时是否错误记忆成“用户所在城市上海”。用户开了个玩笑“我住在火星”是否真的写入 city火星。用户提供身份证号、银行卡号等敏感信息时是否被存入了普通记忆字段。用户明确说“不要记住我的信息”时模型是否仍然写入。如果发现误写一方面要调整提示词中的抽取规则另一方面要对敏感字段增加白名单校验。必要时可以关闭某些字段的自动记忆改为由工作流显式写入。6. 记忆功能常见问题排查6.1 为什么记忆没有保存出现“对话中说了信息但记忆字段仍然为空”的情况时按这个顺序检查问题现象可能原因检查方式处理建议记忆字段一直为空未开启记忆开关检查智能体配置中的记忆开关在配置页开启记忆能力用户说了信息但没写入抽取指令不够具体查看字段配置的抽取指令补充“当……时记录”的规则系统提示词未引用记忆变量模型没有感知记忆字段检查提示词中是否包含变量名在系统提示词中加入记忆变量用户 ID 不同跨会话时未传同一用户标识检查端侧传参和会话创建逻辑统一用户标识并在请求中传入存储延迟刚写入后立即查询未同步等待几秒后再次查询预留异步写延迟容忍时间6.2 为什么回复没有用到记忆即使记忆字段已经有值回复仍然可能没有使用它们。常见原因包括提示词里没有让模型“优先使用记忆”或者记忆值被业务逻辑覆盖。检查点是否在系统提示词中说明“你应该根据用户的记忆信息来回复”。是否在回复模板中显式使用了变量。是否因为用户的当前消息信息量更大模型选择了当前消息而忽略历史记忆。这时需要在提示词中明确“如果没有新的冲突信息优先使用记忆中保存的信息”。是否在工作流中强行覆盖了该字段使用了默认值。6.3 记忆冲突与覆盖问题用户第一次说城市是北京第二次说“我最近搬到杭州了”模型应该更新为杭州。但如果规则不清晰可能出现两种错误要么保留旧值不更新要么把用户转述的“朋友在杭州”也更新为杭州。建议在提示词中明确覆盖规则如果用户提到“我现在住在”“我搬到”“以后联系我可以用”等表达视为更新记忆。 如果用户是以第三人称或假设语气提到某地不更新记忆。另外不要频繁让模型更新所有字段。可以只让模型在小范围内更新“只有用户明确表达变化时才更新city字段其他字段不更新。”7. 利用记忆功能优化用户体验的几个实践模式7.1 学习型智能体记住用户偏好典型场景是内容推荐、学习助手、陪聊类智能体。通过记忆字段保存用户阅读偏好、内容长度、是否喜欢举例、专业背景等信息。每次对话都基于这些信息调整回复。提示词思路你的任务是推荐学习资料。需要结合用户的兴趣领域 {interest} 和阅读深度 {depth}。 如果记忆中没有对应信息请询问用户并给出几个示例选项帮助用户快速选择。这种模式下用户体验的提升路径很直观用户第一次手动指定偏好后续每次对话都不需要重新设置智能体越来越“懂自己”。7.2 任务型智能体记住表单进度在报名、预约、投诉等场景中用户往往需要分多轮提供信息。如果没有记忆每轮都要重复之前已经填过的内容。使用记忆字段可以保存表单进度。例如预约场景记忆字段appointment_service预约的服务类型appointment_time期望时间customer_phone联系电话form_step当前完成的步骤流程可以设计为用户说“我要预约维修”智能体询问服务类型和地址。每获取一项信息就把对应字段写入记忆。再次进入会话时智能体检查form_step字段自动继续提醒未填写的字段。这种模式能显著减少用户重复输入提升表单完成率。7.3 服务型智能体记住历史工单与投诉记录面向客服场景时单纯记住姓名和城市还不够。用户更希望智能体能关联到自己的历史工单、售后状态、优惠权益等。此时推荐把用户记忆字段和外部数据库/API 配合使用。用户首次登录后通过工作流查询订单信息将最近一条订单状态写入记忆字段。之后用户咨询时智能体可以直接说“您上次反馈的物流问题已经解决请问还需要帮忙吗”。这种实践对用户体验提升最明显但实现复杂度也最高。关键点是用户标识必须一致并且外部数据读取失败时要给兜底回复不能让智能体“胡说”。8. 生产环境中的记忆功能最佳实践与扩展方向8.1 记忆信息的安全与权限控制记忆本质上是用户隐私数据。在生产环境上线前要明确几个问题哪些字段允许被自动记忆谁可以查看用户记忆内容用户如何申请删除自己的记忆记忆数据的保留周期是多久建议默认只记忆用户主动提供且非敏感的信息。身份证号、银行卡号、密码、验证码等信息绝不写入普通记忆字段。如果业务流程确实需要应该使用加密存储和专用接口而不是放进模型记忆。同时要保证用户有“清除记忆”的途径。可以在产品中提供一个“忘记我”按钮调用清理记忆的接口或逻辑。8.2 记忆内容的质量控制和定期清理模型自动抽取的信息可能存在噪声。建议建立定期核对机制每周抽样检查记忆字段与真实对话的一致性。对误写率高的字段调整抽取规则或关闭自动抽取。对超过 90 天未更新的记忆信息进行清理或归档。另外建议使用“记忆不变量”机制当记忆字段要更新时先检查当前值和新值如果差异巨大可以要求用户确认。例如原来城市是北京现在要改成东京可以回复“您之前提到在北京现在是否需要更新为东京”8.3 结合外部数据库实现更复杂的记忆体系平台内置记忆适合保存轻型信息。当业务数据复杂到一定程度时建议将记忆功能与外部数据库结合。典型的扩展架构Coze 记忆字段用户基础信息、偏好设置、当前会话状态。外部业务数据库订单、工单、积分、历史记录等结构化数据。工作流或插件在对话中查询、写入、更新业务数据。检索增强当对话需要历史记录时通过插件检索并注入上下文。这样既享受了 Coze 记忆功能的自动化抽取又不会把大量业务数据塞进平台存储保持了数据归属和查询灵活性。8.4 上线前检查清单复制以下清单在发布智能体前逐项核对是否已开启记忆功能并明确用户 ID 传入方式。记忆字段是否只包含必要信息是否包含敏感字段。每个字段的抽取指令是否描述清楚能处理“未提及”和“否定表达”。系统提示词是否引用了记忆变量并设置了缺失兜底。是否配置了记忆更新规则避免误写和覆盖。是否验证了跨会话记忆恢复而不只是当前会话。是否验证了记忆字段为空时模型不会使用空值。是否提供用户清除记忆的路径并测试清除后新会话不再使用旧记忆。是否监控了记忆写入准确率并建立定期清理机制。是否对外部数据库的查询失败做了兜底回复。Coze 记忆功能的价值不只在“能记住”更在于“记住该记的、用对该用的、忘掉不该记的”。把字段设计、提示词规则、验证流程和清理机制结合起来才能真正把记忆能力转化为可感知的体验提升。建议从一个最核心的字段开始试点跑通后再逐步扩展而不是一开始就设计几十个记忆字段。