智能体「记不住人」，是体验掉档的常见原因：用户每轮都要重新交代偏好，问过一次的口味、选过的方案，下一轮全部归零。数据库功能解决的就是这件事——把用户的偏好、历史选择、自定义字段存进表里，下次对话直接读取。配置只有三步：建表、写入、读取。
建表：字段宁少勿多
建表前列一张需求清单：这个智能体需要记住用户的哪些信息？常见字段是昵称、偏好设置、历史订单号、上次对话未完成的事项。每个字段定好类型（文本、数字、布尔值），别把什么都塞进一个文本列。
经验是字段宁少勿多，只存后续真的会读取的信息。堆字段的代价不是存储，是维护：半年后连你自己都说不清某一列是干什么用的，也不敢删。
还有一条：每条记录都要带归属字段（用户标识）。没有它，后面所有查询都没法做隔离，多人使用时数据必然串。
写入：两条路，重点在去重
写入有两条路。一是让模型在工作流里调用写入节点，把对话中提取到的信息按字段存进去，比如用户说「我对花生过敏」，就在偏好表里写入一条；二是结合表单或变量主动收集，适合注册、首次使用这类有明确节点的场景。
写入的关键是处理重复。同一用户更新偏好时应该更新记录而不是新增一条，否则表里很快出现互相矛盾的多条记录，读取时不知该信哪条。做法是以用户标识为键做「存在则更新，不存在则插入」。
还有一个容易忽略的点：模型提取不一定准。用户说「不要香菜」，被写成「喜欢香菜」的情况真实存在。关键字段让用户确认一次再入库，比事后纠错便宜。
读取：注入要精准
读取通常发生在对话开始或特定节点：按用户标识查询该用户的记录，把结果拼进提示词，模型就能说出「上次你选的是中杯、不加糖」。
两个注意点。查询失败或没有记录时要有兜底话术，别让智能体卡在那里等数据。注入提示词的字段挑重要的放——全表灌进去既稀释模型注意力，也浪费 token。记忆注入得越精准，回答越像认识这个人。
数据边界要想在前面
存用户信息之前想清楚三件事：这些字段是否为提供服务所必需；要不要在对话里告知用户会记录偏好，并提供清除方式；敏感信息（证件号、支付信息）一律不入表。
给用户一个「忘记我」的入口，既是稳妥做法，也减少顾虑。数据保留期限提前定好，到期清理，别默认永久保存。这一块的权限设计，知识库那边有更细的做法，见知识库权限怎么设。
一个完整的例子
做一个点餐推荐智能体。建一张偏好表，字段包括用户编号、口味偏好、忌口、上次推荐过的菜；用户说「不要香菜」时，工作流里的写入节点把忌口字段更新为「香菜」；下一轮对话开始时查询这张表，把结果拼进提示词，推荐时自然绕开。
跑通这一条链路，就掌握了主干，之后加字段、加表都是重复劳动。调试时优先看两处：写入节点有没有真的执行（失败多是节点条件没配对），查询结果有没有按预期格式注入提示词。
一个省时间的调试顺序：先用假数据跑通全链路——手动往表里插两三条记录，确认读取与注入正常，再接真实的对话写入。反过来先调写入、读取还没就绪，你很难判断问题出在哪一段。字段变更也要留心，删改字段前确认工作流里没有节点还在引用它，否则会表现为偶发的空值报错。
智能体数据库速查
- 三步：建表、写入、读取
- 字段宁少勿多，只存会读取的
- 每条记录必带用户标识，否则无法隔离
- 写入以用户标识为键，存在则更新
- 注入挑重要字段，全表灌入反而稀释注意力
- 先用假数据跑通读取，再接真实写入
常见问题
- 长期记忆用变量还是数据库表？单个用户的少量状态用变量更轻；需要结构化存储、多条记录、条件查询的，用表。判断标准是「要不要按条件查」，不是数据量大不大。
- 模型提取信息不准，写错了怎么办？在写入节点前加一步格式校验，关键字段让用户确认后再入库。错误数据比没有数据更伤体验——用户会觉得「它记错了」，而不是「它没记住」。
- 多人用的智能体，数据会串吗？只要每条记录都带归属字段、查询条件里永远带上这个键，就不会串。串数据的根源通常是某条记录漏了归属字段。
账号与权限的整理见多个 AI 工具怎么管理；更多工具教程在AI 工具教程栏目。
信息来源
- 本文为智能体数据库的配置方法整理，三步结构（建表、写入、读取）依据通行的工作流编排逻辑，核对时间 2026 年 11 月；
- 具体平台的节点名称、字段类型与限制以其当前版本的文档为准，本文不作承诺。
