1. 从“健忘”到“贴心”：为什么你的智能体需要记忆

大家好，我是老陈，一个在AI和智能硬件领域摸爬滚打了十来年的老码农。这些年，我亲手搭建和调试过的智能体（Bot）少说也有上百个了。踩过最多的坑是什么？不是模型不够聪明，也不是插件不好用，而是我辛辛苦苦调教出来的智能体，每次和用户聊天都像“第一次见面”。

想象一下这个场景：你精心设计了一个电商导购智能体。用户小张第一次来，聊了半天，告诉你他喜欢简约风格的家具，预算在5000元左右。你们相谈甚欢，他加了购物车，但因为临时有事离开了。第二天，小张满心期待地回来，想继续看看昨天聊过的沙发，结果你的智能体开口就是：“您好，欢迎光临！请问您需要什么类型的家具呢？” 小张瞬间就没了兴致，觉得这个助手“很笨”，毫无记忆。

这就是典型的“健忘”智能体。它的每一次对话都是孤岛，无法形成连贯的服务体验。用户需要反复陈述自己的需求，体验感大打折扣。而解决这个问题的核心钥匙，就在Coze平台提供的两大利器：变量和长期记忆。变量就像是智能体的“短期工作记忆”，负责处理单次对话中的动态信息；而长期记忆，则是它的“个人日记本”，能够跨会话、持久地记录用户的个性化数据。两者结合，才能让智能体真正“认识”用户，从一问一答的机器，升级为懂得用户喜好的私人助理。

在接下来的内容里，我不会只讲枯燥的概念。我会带你像搭积木一样，从最基础的变量设置开始，一步步深入到如何用变量构建记忆，最终打造出一个能记住用户偏好、甚至能预测用户需求的“贴心”智能体。你会发现，这一切并没有想象中复杂，但效果却是立竿见影的。

2. 变量：智能体的“记忆细胞”详解

如果把智能体比作一个生物，那么变量就是它的记忆细胞。在Coze里，变量主要分为三大类，它们各有各的“脾气”和适用场景，用对了地方，事半功倍；用错了，可能就会闹出“失忆”或“记忆混乱”的笑话。

2.1 系统变量：智能体的“身份证读取器”

系统变量是Coze平台预置好的，你无法创建、修改或删除，只能选择开启或关闭。它最大的特点是只读，数据由系统自动填充。你可以把它理解成智能体自带的“身份证读取器”，能自动识别来访用户的身份和渠道信息。

我刚开始用的时候也犯过迷糊，试图去修改sys_uuid的值，结果当然是失败了。后来才明白，它的作用就是提供稳定的用户标识。比如，在飞书环境下，你可以开启sys_lark_open_id和sys_lark_chat_id。前者能唯一标识一个飞书用户，后者能标识一个群聊或单聊会话。这意味着什么？意味着你可以轻松实现这样的功能：在飞书群里，你的智能体可以识别出是哪个同事在提问，并且能记住他在这个群里的历史讨论偏好；当切换到私聊时，它又能调取这位同事的个人设置。

这里有个我实测过的例子。我们团队内部用Coze搭了一个“技术百科”Bot，接入了飞书群。我们开启了sys_lark_chat_mode这个变量，它能够判断当前是私聊（p2p）还是群聊（group）。在群聊模式下，Bot的回复会更正式、更全面，偏向知识分享；一旦切换到和某个同事的私聊，它的语气就会变得更随意，并且会根据sys_lark_open_id关联到这位同事之前私聊问过的问题，实现连贯的深度探讨。这个小小的系统变量，让同一个Bot在不同场景下有了完全不同的“人格”，体验感提升巨大。

2.2 应用变量：单次对话的“临时白板”

应用变量，我更喜欢叫它“会话级变量”或“临时白板”。它的生命周期仅限于一次工作流的执行过程。工作流跑完，这块白板就被擦干净了，下次对话又是崭新的一块。

这听起来好像没什么用？恰恰相反，它在处理单次复杂交互时不可或缺。比如，你设计了一个“旅游行程规划”工作流。用户先输入目的地，你用一个叫destination的应用变量存下来；接着用户选择出行天数，你用travel_days变量存下来；然后智能体调用天气插件、酒店查询插件，这些插件的返回结果，都可以用类似weather_info、hotel_list这样的应用变量暂存起来，最后汇总生成一份完整的行程规划发给用户。

在这个过程中，destination、travel_days这些变量就像流水线上的半成品，在不同节点间传递。一旦行程规划完毕，工作流结束，这些临时变量就清空了，不会占用多余的存储空间，也不会干扰下一次全新的行程规划。它非常适合用来跟踪单次会话内的多轮状态。但切记，不要用它来存用户昵称、偏好这类需要持久化的信息，否则用户下次来，你又得从头问起。

2.3 用户变量：构建个性化服务的基石

用户变量，是咱们实现“长期记忆”的核心武器。它的数据是绑定在具体用户身上的，并且会持久化存储。只要你不主动删除，这个用户无论何时、何地（不同设备、不同会话）再来访问你的智能体，都能读取到之前存下的信息。

Coze的用户变量目前有一个重要的限制：只支持String（字符串）类型。这个限制让我早期也头疼过，比如我想存一个用户的偏好列表[“科技”, “体育”, “音乐”]，或者存一个复杂的用户档案对象，该怎么办？解决方案就是“序列化”。对于列表，我可以存成用逗号分隔的字符串：“科技,体育,音乐”，使用时再按逗号分割。对于更复杂的对象，最通用的办法就是存成JSON字符串。比如，用户档案可以存为：“{\”preferred_language\”: \”zh-CN\”, \”member_level\”: \”VIP\”, \”hobby_list\”: [\”reading\”, \”hiking\”]}”。在需要使用的节点里，用一个代码节点或者支持JSON解析的插件，把它再还原成结构化的数据即可。

虽然多了一步转换，但换来的是强大的持久化能力。你可以用用户变量记录：用户的昵称、语言偏好、历史购买商品ID列表、上次咨询到哪个步骤、对某些功能的反馈评分等等。有了这些数据，你的智能体才能真正做到“千人千面”。

3. 实战演练：手把手配置变量与记忆

光说不练假把式，咱们直接进入Coze工作台，一步步把变量用起来。我会用一个“个性化读书推荐助手”的案例贯穿始终，这个助手能记住用户爱看的书籍类型和最近读过的书，越用越懂你。

3.1 第一步：定义你的“记忆库”（变量创建）

进入你的Bot编辑页面，找到左侧边栏的“变量”选项卡。这里就是定义“记忆库”的地方。

1. 创建用户变量（长期记忆）：

   • 点击“用户变量”区域的“+ 新增子项”。
   • 名称：favorite_genres。命名要有意义，我习惯用英文蛇形命名法，清晰明了。
   • 描述：存储用户喜欢的书籍类型，如“科幻,历史,推理”。写好描述，方便以后维护。
   • 类型：没得选，就是String。
   • 默认值：可以留空，或者填“未设置”。我建议给一个默认值，避免首次读取时出错。
   • 点击“保存”。用同样的方法，我们再创建一个recent_books变量，用来存用户最近看过的书ID，描述可以写“用户最近阅读的书籍ID列表，JSON格式存储”。

2. 创建应用变量（临时记忆）：

   • 点击“应用变量”区域的“+ 新增子项”。
   • 名称：current_query。
   • 描述：暂存用户本次查询的关键词。
   • 类型：选择String。
   • 默认值：留空即可。
   • 点击“保存”。这个变量用于在本次对话中，临时记住用户想找什么书。

3. 开启系统变量（身份识别）：

   • 在“系统变量”区域，找到sys_uuid，把旁边的开关打开。这样，我们就获得了唯一标识用户的ID。

3.2 第二步：让记忆流动起来（在工作流中使用变量）

变量定义好了，是死的。我们要在工作流里让它活起来，实现数据的读写。

1. 写入记忆（变量赋值节点）： 当用户第一次告诉我们他喜欢“科幻和历史”时，我们需要把这个信息存到他的长期记忆里。在工作流中拖入一个“变量赋值”节点。

   • 变量选择：在下拉框里选择我们创建好的用户变量 favorite_genres。
   • 赋值方式：选择“静态值”。
   • 值：填入 科幻,历史。这样就把用户的口头偏好，固化存储下来了。 如果用户是在多轮对话中逐步透露喜好，比如先说了“科幻”，后说了“历史”，我们可以用“动态值”赋值方式，选择“拼接字符串”，把新喜欢的类型追加到原有值后面。

2. 读取记忆（在任意节点引用变量）： 当用户再次来访，问“有什么新书推荐吗？”时，我们需要从他的记忆里提取偏好。在大模型（LLM）节点的“提示词”里，或者在任何文本输入框里，你都可以通过 {{变量名}} 的方式引用变量。 例如，在给大模型的提示词里可以这样写：

   用户当前询问：{{current_query}}
   该用户的历史偏好是：{{favorite_genres}}
   请结合他的偏好，为他推荐5本书。如果他还没有设置偏好，请友好地询问他喜欢什么类型的书籍。
   

   注意看，这里同时引用了应用变量current_query（本次问题）和用户变量favorite_genres（长期偏好）。系统会自动将这些占位符替换成实际的值。

3. 实现条件分支（根据记忆做判断）： 更高级的用法是，用变量来控制工作流的走向。拖入一个“条件分支”节点。

   • 在条件设置里，可以写：{{favorite_genres}} 等于 “未设置”。
   • 如果条件成立（即用户没设置过偏好），流程可以走向一个“询问偏好”的子流程。
   • 如果条件不成立（用户有偏好），流程可以直接走向“生成推荐”的子流程。 这样，你的智能体就有了初步的“判断力”，能根据对用户的了解程度，提供不同的交互路径。

3.3 第三步：调试与验证你的记忆系统

配置完了，一定要测试！Coze提供了强大的调试功能。

点击工作流画布上的“运行”按钮，在右侧的调试面板里，你可以清晰地看到每一步的执行情况。重点观察“变量”选项卡。在这里，你能实时看到所有系统变量和用户变量的值的变化过程。

比如，你运行一次流程，发现favorite_genres变量从“未设置”变成了“科幻,历史”，这说明写入成功了。然后你换个对话窗口（模拟另一个用户），或者清空对话历史重新开始，再运行一次，发现favorite_genres的值依然是“科幻,历史”，这就证明了用户变量的跨会话持久化生效了！而应用变量current_query在每次运行结束后，在调试面板里可能就看不到或者重置了，这符合它的临时特性。

多试几次，模拟用户各种不同的操作路径，确保你的记忆系统在各种情况下都能正确读写，这是上线前最关键的一步。

4. 高级技巧：变量组合拳打造深度个性化体验

掌握了基础操作，咱们来点更实用的“骚操作”。单独使用变量效果有限，把不同类型的变量和Coze的其他功能组合起来，才能发挥最大威力。

4.1 场景一：电商推荐系统的“记忆引擎”

我们团队曾用Coze为一个潮玩电商做过客服推荐Bot。它的核心逻辑是这样的：

1. 首次接触（冷启动）：用户小美第一次进入，系统变量sys_uuid生成唯一ID。Bot会主动询问：“嘿，欢迎来到潮玩星球！你平时喜欢收集什么风格的玩具？是可爱风、机甲风还是复古风呀？” 小美回答：“喜欢可爱风和复古风。” 通过变量赋值节点，将“可爱风,复古风”存入用户变量user_style_preference。
2. 行为记录：小美浏览并点击了几个“复古胶卷相机”玩具。每次点击，我们都通过一个后台的“记录行为”插件（自定义插件），将商品ID追加记录到用户变量user_browse_history里（用JSON数组存储，如[“item_001”, “item_005”]）。
3. 精准推荐：三天后，小美再次光临，问“有没有新品？”。
   • 工作流首先读取 user_style_preference（可爱、复古）和 user_browse_history（胶卷相机）。
   • 将这些信息连同新品列表，一起喂给大模型。提示词大概是：“用户偏好是{{user_style_preference}}，浏览历史是{{user_browse_history}}。请从以下新品列表中，筛选并推荐最符合她口味的3款，并说明理由。”
   • Bot回复：“小美你好呀！根据你喜欢的可爱复古风，以及之前看过的胶卷相机，这款‘复古猫咪胶片机’新品你一定不能错过！它既有复古相机造型，又带了小猫元素……” 这个回复的精准度和亲切感，远超普通的商品列表推送。用户会觉得这个Bot真的“懂我”。

4.2 场景二：多轮对话与状态保持

很多复杂服务需要多轮对话完成，比如订餐、预约、复杂问题排查。应用变量在这里就是维持“对话状态”的关键。

假设我们做一个“智能订餐助手”：

1. 用户说：“我想订餐。” Bot开启工作流，创建一个应用变量 order_step，赋值为 “选择餐厅”。
2. 用户选好餐厅后，Bot将 order_step 更新为 “选择菜品”，同时用另一个应用变量 selected_restaurant 存下餐厅名。
3. 用户选择菜品时，Bot将菜品ID暂存到应用变量 cart_items 的数组里。
4. 如果用户突然问：“我刚才选了哪家店？”，Bot只需读取 selected_restaurant 变量就能回答，无需用户重复。
5. 最终下单时，将 cart_items、selected_restaurant 以及用户变量里存的送餐地址 user_address 一起提交。
6. 订单生成后，整个工作流结束，order_step、selected_restaurant 等应用变量自动清零，为下一次订餐做好准备。而用户的送餐地址 user_address 作为用户变量被永久保存，下次订餐可以直接使用。

这个流程里，应用变量确保了单次订餐流程的连贯，用户变量则保留了用户的长期信息，两者缺一不可。

4.3 场景三：结合知识库实现“越用越聪明”

变量和长期记忆还能和Coze的“知识库”功能联动，实现更智能的体验。知识库负责存储领域知识（如产品手册、公司制度），而用户变量负责存储用户的个性化交互数据。

例如，一个“产品技术支持Bot”：

• 知识库里上传了所有产品的FAQ和故障排查指南。
• 用户变量里记录每个用户（通过sys_uuid关联）最近咨询过的3个问题（recent_issues）。
• 当用户再次提问时，Bot会同时检索知识库，并参考 recent_issues。如果发现用户最近反复问同一个问题，Bot在给出标准答案后，可以额外补充一句：“注意到您最近多次咨询此问题，是否需要我为您转接人工客服做进一步排查？” 或者主动推送一篇更详细的图文教程。
• 更进一步，可以分析所有用户的 recent_issues，如果某个问题被大量用户频繁询问，就可以反馈给产品团队，优化产品设计或说明书。这样，你的Bot不仅是个客服，还成了产品改进的“数据雷达”。

5. 避坑指南与最佳实践

在实战中，我踩过不少坑，也总结出一些让“记忆系统”更稳健、高效的心得。

第一大坑：用户变量的String类型限制。前面提过，存复杂数据要用JSON字符串。这里有个细节：从变量里读取JSON字符串后，在“条件判断”或“代码节点”里使用前，一定要先做解析。直接拿字符串去判断 {{user_data}}.hobby 是否包含“游泳”，是会报错的。正确做法是，先用一个代码节点（或能处理JSON的插件）把字符串解析成对象，再进行后续操作。

第二大坑：变量命名混乱和滥用。早期我图省事，变量名起得随心所欲，像a, b, tmp1，过两周自己都忘了是干嘛的。一定要用清晰的、有业务含义的英文名，比如 user_preferred_language, cart_total_amount。另外，不要为了存而存，只存储真正对个性化服务有贡献的数据。过度收集和存储用户数据，不仅增加维护复杂度，还可能带来隐私风险。

第三大坑：忽视数据的初始化与清理。用户变量一旦创建，除非手动删除或通过流程覆盖，否则会一直存在。如果你的业务逻辑中，用户偏好可以被清空或重置，一定要在工作流里设计相应的“重置”功能，比如提供一个“清除我的偏好”的指令，触发后将对应的用户变量赋值为空或默认值。否则，过时的、错误的“记忆”反而会干扰智能体的判断。

最佳实践建议：

1. 分层设计记忆：将系统变量用于识别，用户变量用于长期画像，应用变量用于会话状态。各司其职，结构清晰。
2. 设置记忆有效期（心理层面）：虽然Coze目前可能没有显式的变量过期设置，但可以在设计上体现。例如，recent_browse这种变量，可以在用户每次登录时，用代码节点检查其中记录的“时间戳”，自动清理掉过于陈旧的数据。
3. 提供用户可控性：让用户知道Bot“记住”了他什么，并给他修改和删除的权利。比如，Bot可以说：“我记得您喜欢科幻小说，对吗？如果想修改这个偏好，请对我说‘更新我的偏好’。” 这不仅能增加透明度，提升信任感，也能让记忆数据更准确。
4. 从小处着手，快速迭代：不要一开始就试图构建一个完整的用户画像。先从记住一个关键信息开始，比如昵称或语言偏好，看到效果后，再逐步增加“记忆维度”，比如偏好、历史行为等。这样试错成本低，也更容易调整。

说到底，技术是冰冷的，但用技术打造出的体验可以是温暖的。变量和长期记忆，就是我们在Coze平台上为智能体注入“记忆力”和“同理心”的工具。当你看到用户因为被智能体叫出名字而惊喜，因为推荐正中下怀而满意时，你就会觉得，这些看似微小的配置工作，充满了价值。