面经策

如何让 LLM Agent 具备长期记忆能力？ ​

  • 标签：大模型、AI、Agent

🏛 业务架构师 ​

让 Agent 具备长期记忆，我的方案按"记什么—怎么存—怎么用"三层设计：

记什么（记忆分类）：

  • 用户画像：偏好、身份、历史行为模式（客户经理的 Agent 记住"该客户风险偏好低"）；
  • 情景记忆：过往交互的具体事件（"上次提过要换供应商"）；
  • 程序性记忆：任务经验（什么样的步骤组合解决问题成功率最高）。

怎么存（三种技术方案）：

  1. 向量库方案（主流）：把历史对话/事件摘要向量化存储，新任务时按语义检索相关记忆注入上下文——通用性强，RAG 式召回；
  2. 结构化档案方案：用 LLM 定期抽取结构化字段写入 Profile 表（用户标签、关键事实），可控、可审计，适合 CRM 类场景；
  3. 混合方案：档案存"确定的"，向量库存"模糊的"，效果与可控性兼得——生产推荐。

怎么用（关键在管理策略）：记忆要有生命周期——写入要过滤（敏感信息不存，合规红线）、读取要相关（只注入与当前任务相关的记忆，避免污染上下文）、更新要合并（新旧信息冲突时以最新为准）、用户可查删（个人信息保护要求）。

业务提醒：长期记忆的价值要靠场景兑现——跨会话的个性化服务（私人助理、客户成功）值得重投入；单次任务型 Agent（批量数据处理）根本不需要记忆，别为了架构完整而过度设计。

🏗 系统架构师 ​

Agent 长期记忆我按**"存什么、怎么存、怎么取、怎么治理"**四问设计，本质是给 Agent 建一套个人化的数据系统：

存什么（记忆分类）：

  • 语义记忆：用户事实与偏好（职业、习惯、约束条件）；
  • 情节记忆：历史任务与会话事件（"上周让他做过 XX 报告"）；
  • 程序记忆：已验证的做法（成功的工具链、代码模板）。

怎么存（分层存储选型）：

  • 结构化事实 → Postgres（可更新、可约束、可审计）；
  • 语义情节 → 向量库（embedding 检索）；
  • 热会话缓存 → Redis；
  • 写入是异步旁路：会话结束 LLM 抽取"值得记的"，带置信度与时间戳。

怎么取（检索注入）：当前 query 向量化 → 记忆库召回 Top-K 相关条目 → 与用户画像一起注入 System Prompt（预算 500~2000 token）——即"个人 RAG"。

怎么治理（生产关键）：TTL 与衰减（旧记忆降权）、冲突合并（用户改口，新事实覆盖旧事实并记录版本）、置信度门槛（低置信不注入）、记忆可查看可编辑（用户可控是合规趋势）、隐私最小化（PII 加密，记忆删除接口）。

架构提醒：记忆是双刃剑——污染的记忆会让 Agent 持续犯错且难归因，记忆层的可观测（哪些记忆被注入、命中了什么）必须和检索层同级建设。

💻 全栈开发专家 ​

长期记忆我的实现方案是「三库一管道」：

三库（按记忆类型分存储）：

  1. 情景记忆（向量库）：历史对话中的事实与事件，Embedding 入库，每轮按当前 query 检索 top-3 注入上下文；
  2. 语义记忆（结构化 KV）：稳定的用户画像——姓名、偏好、组织关系，存关系库/Redis，规则化读写，最可控、可编辑；
  3. 程序记忆（规则/技能库）：用户确认过的操作习惯（「每次报告用中文」），本质是可执行的偏好规则。

一管道（写入管线）：不是每句话都值得记。对话结束后（或每 N 轮）异步跑「记忆抽取」：LLM 判断哪些信息是长期有效的 → 与已有记忆做冲突检测（新偏好覆盖旧的）→ 带时间戳和置信度入库。Mem0 和 LangGraph Store 已经把这套路产品化：

python
from langgraph.store.postgres import PostgresStore
store.put(("memories", user_id), key=str(uuid4()),
          {"text": "用户的公司用飞书，不用钉钉", "kind": "preference"})
hits = store.search(("memories", user_id), query=user_msg, limit=3)

必须处理的三个问题：遗忘（时间衰减 + 容量上限淘汰低频记忆）、冲突（新事实优先+版本历史）、权限（记忆严格按 user_id 隔离，绝不能串户——这是事故级 bug）。检索注入要有预算控制，记忆条目超 5 条反而干扰主任务。