3.5. 用户画像与情景记忆是智能体人性化交互的关键

用户画像与情景记忆是智能体人性化交互的关键

2025年9月,LangChain 的 LangMem 库正式发布了情景记忆提取能力,开发者第一次可以用一个简单的 Pydantic 模型把“上次推理怎么成功的”变成可检索的结构化记忆。几乎在同一时期,MemGPT、Letta 等框架也开始用操作系统虚拟内存的思维重新设计智能体的上下文窗口。这些动作指向同一个方向:人性化交互的关键不是记忆的容量,而是记忆的结构——把“用户是谁”和“用户怎么想”分离开,分别建模,再按需动态组装。

我们可以先把自己代入这样一个场景:你正在测试一个客服智能体,第一次对话你问“帮我查一下上周的订单”,智能体流利地给出了物流信息。第二天你接着问“那笔订单现在能改地址吗”,智能体却茫然反问“哪笔订单?”——之前的记忆还在数据库里,但只是原始对话的堆砌,没有抽象成“用户正在追踪订单#2305,并在寻求修改地址”这样的认知单位。这种失败不是忘记,而是记忆没有被组织成可用的用户模型。

这一章的使命就是让你能完成一项判断:当你的智能体需要表现得更像一个了解你的长期协作者时,应该为它设计什么样的记忆结构。 我们将从三个维度拆解这个结构,并给出可直接落地的方案。

现象:从“一次性助手”到“有体温的长期协作者”

直到2024年,大多数生产环境中的 LLM 应用仍然把记忆简化为“把最近k轮对话放进上下文窗口”。这种方法能应对连续对话,但一离开当前会话,智能体立刻失忆。用户反复说明自己的偏好、工作角色、常见需求,交互成本极高。

2024年底至2025年,随着 LangChain、AutoGen 等框架把长期记忆作为一级特性开放,工程界开始区分短期记忆、语义记忆和情景记忆。可是很多团队很快掉进新坑:他们把所有对话历史不加区分地塞进向量数据库,检索时返回一堆语义相似但场景无关的片段,个性化响应依然低质。问题不在记忆存不存在,而在记忆有没有被赋予正确的认知层次。

目前,从已公开的实践方案中(如 PRIME 论文中提出的认知记忆结构,以及 LangMem 的 Episode 模型),一个共识正在形成:让交互人性化,需要同时维护两种记忆——用户画像(长期事实与偏好)情景记忆(成功交互经验的完整推理链),并在每次推理前把它们剪裁成与该时刻最相关的那一帧。

核心维度分析:人性化交互的三根支柱

我们把成功实现个性化响应所需要的能力分解为三个可工程化的动作:分离隐式偏好与显式指令、用时间线索引组织情景记忆、在会话开始时按用户画像动态组装上下文。它们形成了一个递进的记忆处理流水线。

维度一:隐式偏好提取与显式指令分离

用户在不同时刻说出的句子,承载着两种截然不同的意图:一次性显式指令(“帮我把这次查询结果导出为 PDF”)和 长期隐式偏好(“我更喜欢表格形式的数据”)。如果将两者混在一起存入长期记忆,智能体很容易把临时请求固化为永久行为,或者把长期偏好当成一次性要求而遗忘。

一个可落地的做法是设计一个消息分类器,它可以在记忆写入前根据语义特征和上下文进行判断。例如,可以利用 LangChain 的记忆中间件,让智能体在每轮交互结束后调用一个轻量级的判断提示词:这条消息是作用于当前任务的临时指令,还是反映了用户的身份、习惯或长期偏好?前者仅保留在会话生命周期内,后者则路由到语义记忆层(如用户画像的 Profile 模型)中更新。

下面的对比表格展示了两种处理方式的差异:

处理方式 典型表现 风险 本章推荐的做法
全部存储 用户说“今天用暗色主题”,被永久记录为偏好 第二天用户打开亮色主题却无法生效 分类器识别为临时指令,不写入长期画像
分离处理 显式指令仅作用于本会话;隐式偏好经确认后存入语义记忆 偶有误判,但偏好一致性显著提高 使用 LangMem 的 Semantic Memory 存储偏好,情景记忆负责记录达成偏好的交互链

从当前调研资料看,LangMem 的语义记忆模块支持以 Triple(主语-谓词-宾语)形式存储用户偏好,这天然适合用来存放“用户喜欢的回复风格是简洁”这类事实。而指令的短暂性则可以通过 session 级别的状态管理实现,无需污染长期记忆。

维度二:情景记忆的时间线索引

仅仅知道用户喜欢简短回答还不够——在一次具体的多轮交互中,智能体需要回忆起“刚刚我们讨论了什么”“上次遇到类似需求时我是怎么解决的”。这就是情景记忆(Episodic Memory)的用武之地。与语义记忆存储“是什么”不同,情景记忆存储“如何做”的完整经验。

LangMem 为此提供了一个非常明确的建模方式。你需要定义一个继承自 BaseModel 的 Pydantic 类,包含四个字段,对应解决问题的认知链条:

  • observation:当时的上下文和触发条件,例如“用户在周五下午询问复杂报表的生成方式,语气显示时间紧迫”。
  • thoughts:智能体的内部推理过程,必须以“I…”的视角记录,例如“我认为用户需要快速获取汇总数据而非明细,因此优先推荐了一键导出功能”。
  • action:具体执行的动作和使用的工具,例如“调用了 report_api.export_summary,参数为 date_range=last_week”。
  • result:行动的结果与事后反思,例如“生成成功,用户表示满意。事后分析如果先确认日期格式可能会更顺畅”。

之所以强制包含 thoughts 字段,是因为 原始对话只记录了“说了什么”,没有记录“为什么这么说”。当未来遇到相似情境时,智能体需要复用的是那条曾经有效的推理路径,而不是仅重复相同的话。

有了 Episode 模型之后,你可以使用 LangMem 的 create_memory_manager 来提取记忆。下面这段代码展示了核心调用方式,它应该被视为你构建情景记忆流水线的起点(示例基于 LangMem 官方指南,截至2025年9月):

from pydantic import BaseModel, Field
from langmem import create_memory_manager

class Episode(BaseModel):
    observation: str = Field(description="触发的情景描述")
    thoughts: str = Field(description="内部推理过程,以第一人称")
    action: str = Field(description="采取的行动和工具调用")
    result: str = Field(description="结果及事后洞察")

manager = create_memory_manager(
    model="anthropic:claude-3-5-sonnet-latest",
    schemas=[Episode],
    instructions="提取成功的交互经验,用事后洞察的视角书写。",
    enable_inserts=True,
)

# conversations 是完整的对话列表
result = manager.invoke({"messages": conversations})
episode = result["episodes"][0]  # 获得 ExtractedMemory 对象

仅提取记忆还不够,你需要为每条情景记忆建立 时间线索引。这意味着存储结构不仅要支持语义搜索(“查找所有关于订单修改的经验”),还要支持按会话顺序的回溯(“把最近三次对话中涉及发票的场景串联起来”)。在实践中,你可以给每条 Episode 附加 session_idtimestamp,并借助向量数据库的时间过滤功能,在检索时同时施加时间范围和语义相似度双重约束。

下表的对比可以帮你判断是否值得引入结构化情景记忆:

存储方式 检索表现 可复用性 结论
原始对话全文存储 搜索“上次怎么解决登录问题的”返回大量无关闲聊 智能体只能重复原话,无法泛化推理 仅适合简单 FAQ 场景
结构化情景记忆 可精准命中“为什么当时我让用户清除缓存”的思维过程 未来类似情境可直接复用该推理链 支撑真正的经验学习

维度三:用户画像驱动的上下文组装

有了独立的用户画像和情景记忆后,最后一步是在每次与大模型交互时,把正确的信息放进有限的上下文窗口。如果不管当前任务是什么,每次都把完整的用户画像和所有历史情景记忆塞进去,不仅浪费 Token,还会让模型迷失在海量信息中。

正确的做法是实施 动态上下文组装:在组装 system prompt 时,只从用户画像中抽取与当前意图相关的属性,并从情景记忆库中检索与当前问题语义相似且时间上邻近的 Episode。例如,当智能体识别到用户问“帮我续订上个月的咖啡豆”时,它应当:

  1. 从画像中读取用户的默认地址、支付偏好(语义记忆)。
  2. 搜索最近包含“咖啡豆购买”的 Episode,提取上次成功下单时使用的具体流程和注意事项(情景记忆)。
  3. 将上述两块信息简洁地注入 prompt,并忽略掉画像中的音乐口味、无关的历史闲聊。

这种按需注入的操作,本质上是在构建一个以当前用户和当前任务为中心的记忆视图。下面这张表格总结了固定画像与动态组装之间的关键区别:

组装策略 Token 效率 个性化质量 结论
固定画像全量注入 低,大量无关信息占据窗口 表面个性化,实则信息稀释 对话轮次一多就失效
动态裁剪组装 高,仅注入当前场景相关的画像字段和情景记忆 精准匹配用户即时的深层需求 是生产环境的人性化基础

按场景落地:三个可照抄的起点

完成上述三个维度的分析后,你无需一次性在系统中实现全部能力。根据智能体的应用场景,你可以在以下三个层次中选择一个切入。

场景一:电商客服智能体 —— 聚焦情景记忆的时间线索引

  • 痛点:用户常中断后重连,需要快速接续上下文。
  • 做法:以 session 为单位提取 Episode,并在用户发起新对话时用 user_id 拉取最近3条未解决的 Episode,在首条消息中让智能体主动说“您上次问到订单#2305,还需要继续处理吗?”
  • 关键约束:明确只存储“事件尚未关闭”的 Episode,避免用已解决的问题干扰当前会话。

场景二:个人编程助手 —— 优先建设隐式偏好分离

  • 痛点:用户需要长期保持一致的技术栈偏好,但也会临时要求用特定语言。
  • 做法:利用消息分类器,把“我喜欢用 TypeScript 写接口”存入用户画像;把“这次用 Python 演示”限制在当前会话的短期记忆中。在每次 API 调用前,优先读取画梁中的技术栈偏好,除非当前会话有显式覆盖。
  • 关键约束:当临时指令与长期偏好冲突时,以临时指令为准,但要在会话结束后向用户确认是否更新偏好。

场景三:教育辅导智能体 —— 用户画像驱动的动态组装

  • 痛点:学生能力模型动态变化,辅导策略需要跟随调整。
  • 做法:在用户画像中维护一个动态更新的“知识点掌握度”表。每次回答问题时,组装当前知识点的状态以及最近三条与该知识点相关的辅导 Episode,使讲解既符合学生当前水平,又衔接上次的教学思路。
  • 关键约束:画像更新必须基于学习评估的结果,而不是单纯的对话频率,防止产生“聊得多=已掌握”的错误推断。

无论你选择哪个场景,一条普适的经验法则是:先让智能体具备“回溯上次”的能力,再赋予它“记住你这个人”的能力。 情景记忆是交互连贯性的基础,用户画像是长期个性化的上层建筑,前者不扎实,后者很容易变成噪音。

当这套面向人性化的记忆结构开始运转时,你会立刻碰到下一个工程挑战:即使我们只注入裁剪后的记忆,上下文窗口依然有物理上限,而记忆总量会永远增长。如何在有限窗口内让无限积累的记忆产生最大价值?下一章《MemGPT 论文彻底改变了上下文管理的思维模型》将揭示用虚拟内存思想管理上下文的革命性方法,让智能体像现代操作系统一样,在看似无限的记忆空间上优雅地调度注意力。

本文章首发在 LearnKu.com 网站上。

上一篇 下一篇
讨论数量: 0
发起讨论 只看当前版本


暂无话题~