实体记忆与用户画像：让 Agent 记住人，而不是乱贴标签

很多 Agent 项目一做长期记忆，就会想到用户画像：用户是谁、喜欢什么、做什么工作、常问什么问题。这个方向没错，但最容易做坏。画像如果只是不断给用户贴标签，最后会变成一堆看似有用、实际很难验证的描述，比如“偏理性”“关注效率”“喜欢简洁回答”。这些词很顺，却不一定能帮模型答对问题。

长期记忆相关概念 在实体记忆部分给了一个更稳的入口：先记住对话里出现的关键实体，再记录实体之间的关系。法律咨询里，用户可能提到案件名称、法律条款、事故时间和个人信息；医疗咨询里，用户会说症状、病史和近期变化；技术支持里，用户会反复补充错误信息、环境版本和尝试过的步骤。这些不是抽象标签，而是后续回答真的会用到的上下文。

所以，用户画像应该从实体记忆长出来。先把人、项目、产品、疾病、课程、问题、偏好这些实体记清楚，再看它们和用户当前任务有什么关系。画像不是为了让系统显得懂用户，而是为了让下一次对话少问几遍、少猜一点、少把旧信息当新事实。

ConversationEntityMemory 的价值在于，它会从历史对话里抽取实体，并在后续问题中带回这些实体的信息。文中的例子提到，用户说了某个微信号、笔名或人物关系，系统后面再问“莫尔索是谁”，就能从实体记忆里取出关系。这个能力看起来小，但它是长期对话的地基。

真实业务里，很多问题都不是单轮就能讲清楚。法律咨询中，“去年的交通事故”后面可能会继续出现“对方保险公司”“误工费”“伤残鉴定”；医疗咨询中，“糖尿病史”会和“口渴”“疲劳”“最近用药”发生关系；企业客服中，“那台设备”“上次报错”“你们那个新版本”都需要被还原成明确对象。

如果系统只保存一段摘要，很容易把这些对象混在一起。实体记忆的好处是把对象拆开：张三是用户，A 项目是业务系统，B 版本是当前环境，某个故障属于上次排查。模型再回答时，至少知道自己讨论的是哪个人、哪个系统、哪个问题。

用户画像不能越多越好。字段太多，系统会为了填字段而保存无用信息；字段太少，又会把重要约束塞进一段自然语言里，后面不好检索。比较实用的画像字段可以分成五类：身份实体、稳定偏好、长期约束、场景记录、来源与时间。

身份实体回答“这是谁，和哪些对象有关”。稳定偏好回答“用户长期希望系统怎样服务他”，比如回答详略、语言风格、常用工具。长期约束回答“什么条件不能变”，比如地区、预算、版本、权限。场景记录回答“这件事处理到哪一步”。来源与时间则回答“这条记忆从哪里来，什么时候保存”。

这里最容易被忽略的是来源。相关概念 在 RAG 里反复展示 metadata 的作用，source 和 page 可以让检索结果回到原始文档。画像记忆也要有自己的 metadata：来自哪轮对话、是否用户明确确认、保存时间、适用场景。如果没有这些，画像很快会变成模型自己写的印象笔记。

文中的滑动窗口记忆适合电商配送这类短期问题，全量历史适合一般客服里需要保留完整上下文的场景；实体记忆和知识图谱适合长期关系明确的场景。这个分类说明了一件事：不是所有信息都应该进入用户画像。

写入前可以先问三个问题。第一，它后面还会不会影响回答？第二，它是不是用户明确表达的事实或偏好？第三，它有没有一个可限定的场景？用户说“今天帮我写得短一点”，可能只是当前任务偏好；用户多次说“以后给我代码时尽量附上运行方式”，才更像长期偏好。

敏感信息尤其要谨慎。医疗、法律、金融场景确实需要记住一些事实，但这些事实不应该被默认永久保存。更稳的做法是先保存在当前任务或当前案件里，必要时再让用户确认是否进入长期画像。长期记忆的质量，往往取决于系统拒绝保存多少不该保存的内容。

ConversationKGMemory 把实体和关系组织成图。文中的医疗例子很典型：病人有糖尿病史，最近经常口渴和疲劳，这些实体之间存在健康关联。另一个示例把“小李是从事技术工作的人”“莫尔索是小李的笔名”保存成关系，后面询问小李时，系统能带出职业和笔名。

知识图谱适合记录关系，比如用户属于哪个团队、项目使用哪个数据库、某个问题发生在哪个版本、某个症状和既往病史有关。它不适合替系统做未经验证的推断。用户说“最近口渴和疲劳”，系统可以记为症状，不能直接写成“用户病情加重”。用户说“我们可能要换 Redis”，系统可以记为待确认计划，不能写成“项目已切换 Redis”。

这也是画像设计里很重要的一条边界：事实、关系、推断要分开。事实来自用户表达或业务文档；关系来自实体抽取和上下文；推断只能作为待确认信息。否则图谱看起来很完整，实际会把模型猜测包装成长期事实。

用户画像不能一股脑塞进 prompt。画像越长，越容易挤掉真正相关的文档内容，也越容易让模型过度迎合旧偏好。相关概念 里讲过相似性检索的几个问题：重复内容会占满 Top-K，问题带有章节条件时会检出其他章节，MMR 和 metadata 过滤能改善这种情况。画像召回同样需要过滤。

比较稳的顺序是：先判断当前问题属于哪个场景，再用 metadata 过滤相关画像，接着做相似度检索或 MMR 去重，最后只把少量和当前回答有关的记忆放入上下文。比如用户问投资组合，金融偏好和风险承受能力可能有用；用户问网络报错，投资偏好就不该出现。

还要把画像和知识库分清楚。画像提供用户背景，知识库提供业务事实。用户记忆里写着“我常用 MySQL”，这能帮助系统举例；但如果知识库文档说明当前系统已经改用 PostgreSQL，回答应以文档为准。画像是辅助，不是裁判。

用户画像一定会遇到冲突。用户之前说自己在上海，后来又说长期在深圳；旧记录写着项目用 Chroma，新对话说切到了 Milvus；一次客服记录里的联系方式和 CRM 里的号码不一致。如果没有冲突处理，系统只能随机相信其中一条。

冲突处理可以分三类。确定的新事实，可以改为新值，并保留旧值历史；明显相同或重复的信息，可以合并或保留置信度更高的一条；无法判断的新旧差异，要进入确认流程。这里的关键不是让模型“聪明判断”，而是让系统有可审计的处理动作。

LLM 全教程里 metadata 过滤的思想也能用在这里。每条画像都带来源、时间、置信度和适用范围，冲突时就有依据。来自用户最新确认的信息，通常比早期摘要更可信；来自业务系统的字段，通常比聊天里的随口表达更稳定；敏感或高风险字段，则宁可确认一次，也不要自动覆盖。

画像系统上线后，不要用“保存了多少条记忆”当成绩。保存得越多，召回成本越高，错误传播也越快。真正该看的，是它有没有让回答更准、更连贯、更少追问。

可以准备一组多轮测试题：有些问题需要识别实体关系，有些问题需要长期偏好，有些问题应该完全忽略画像，只查知识库。每次测试记录问题、召回画像、命中文档、最终答案和人工判断。这样才能看出错误发生在哪一段。

如果画像召回正确但答案仍然错，问题可能在提示词或生成环节；如果答案用了过期画像，问题在过滤和冲突处理；如果画像里长期堆着模型猜测，问题在写入规则。长期记忆不是把用户的一切都记下来，而是在该记的时候记准，该忘的时候忘掉。