给 Agent 做长期记忆的 4 种架构，每种我都踩过一次坑

为什么记忆这件事这么难

先说个直观感受。人类聊天为什么不会失忆？因为我们有工作记忆（几秒到几分钟）、短期记忆（几小时到几天）、长期记忆（几年）。每种用不同的脑区，有不同的编码方式，大脑自动做 routing。

LLM 没有这套。它每次推理就是把你给的 context 从头到尾读一遍，context 之外的东西对它来说不存在。所以”长期记忆”在 LLM 语境下其实是假命题——你是在工程层面伪造记忆效果。

伪造的方式大概四种，我一种种说。

方式 A：全塞 context（粗暴但通用）

最简单，把过去所有对话直接拼在一起喂进去。Claude 200K 窗口，理论上能塞几百轮对话。

适用场景：对话轮数少（< 30 轮），单次会话不跨天，不需要跨会话记忆。

隐藏成本：token。每轮的 input 都在涨，到 50 轮一次调用 80K input 是常态。Claude 的 input 定价 3 美刀/百万 token，80K 一次就是 0.24 刀。一个用户聊一小时就是几刀。

我踩的坑：2024 年做了个宠物健康咨询 bot，没做记忆压缩，直接全塞。上线第二天有个用户聊了 120 轮，最后一次请求 142K token。甲方看账单的时候脸都绿了。最后连夜上了摘要机制。

一句话结论：demo 阶段和轻量场景够用，上生产必翻车。

方式 B：summary 向前滚动（经济但易断层）

思路是：对话超过一定长度后，把早期部分压缩成摘要，保留近期原文。比如前 30 轮压成 500 字摘要，然后把最近 10 轮原文接上。再过 10 轮，就把原本的摘要 + 新的 10 轮再压一次。

适用场景：长对话但不需要精确引用细节，比如陪伴类、咨询类。

隐藏成本：信息损失是复利式的。每一次再压缩都在摘要的摘要基础上做，到第五六次迭代的时候，最早的对话已经面目全非。

我踩的坑：给一家心理咨询平台做 AI 倾诉对话。前 20 轮用户讲了自己的童年经历——一个具体的、对她很重要的细节。第一次摘要的时候这个细节被保留了。第四次摘要的时候这个细节被合并进了一个”用户有不愉快的家庭记忆”的笼统描述。后来用户在第 60 轮又提起这个细节，AI 回复”嗯，听起来挺难的”——因为它真的不知道了。用户当场崩溃。

那之后我做摘要会显式指令保留这些：具体人名、地点、日期、金额、医疗/法律相关的细节。不管压缩多少次都不能丢。

一句话结论：必须配合”重要 entity 白名单”机制，不能傻滚动。

方式 C：外挂知识库 + 检索（主流方案）

把历史对话写入向量库或者结构化数据库，下次需要的时候检索回来。这是大部分生产级 agent 的做法。

适用场景：跨会话、跨天、跨用户的长期记忆。比如”这个用户三个月前提到过他的过敏史”。

隐藏成本：

第一，存什么是个大问题。不能把每一轮对话都存——太多了，检索的时候召回质量反而下降。我现在的做法是每轮对话后跑一个小任务（用 Haiku），判断”这一轮有没有产生值得长期记忆的 fact”，有的话抽成结构化条目再入库。

第二，检索时机。每次用户说话都做一次记忆检索？太贵。我的做法是：只有在 Claude 需要的时候才触发——在 system prompt 里告诉 Claude 它有个 recall 工具，需要回忆的时候自己调。这样大部分对话不触发检索。

第三，记忆冲突怎么办。用户三个月前说自己不吃辣，今天说想尝尝辣的。两个 fact 都在库里，检索回来了，模型懵了。我现在给每个记忆条目加时间戳 + confidence score，检索时按时间衰减 + 用户显式更新的优先级处理。

我踩的坑：最开始没做冲突处理，一个电商客服 bot 把用户”已经取消订阅”和”刚下单”两个 fact 同时召回。模型给出的回复自相矛盾，被投诉到客户那边。

一句话结论：现在做 agent 的主流选择，但工程量比想象大。关于怎么在 CLAUDE.md 里管理长期知识也是类似思路。

方式 D：事件溯源 + 按需回放（复杂但强大）

这是最工程化的方案。把每轮对话当做 event 存成时间序列，需要重建 context 的时候根据 query 回放相关 event。

和方式 C 的区别是：C 存的是抽象过的 fact（”用户过敏花生”），D 存的是原始事件流（”2026-01-15 14:30 用户说：我小时候吃花生起过疹子”）。

适用场景：对审计、可追溯性要求高的场景。金融、医疗、法务。还有就是你不确定未来要怎么用这些数据、不想过早抽象的时候。

隐藏成本：回放逻辑复杂。你要写很多”从事件流构建 context”的代码。而且存储成本线性增长，一年数据能到几十 GB。

我踩的坑：给一家医疗公司做随访 AI，用了事件溯源。前半年很爽，数据都留着，随时能追溯。问题在第八个月——单个患者的事件已经到几千条，每次回放都要过滤排序，latency 爬到 4-5 秒。后来加了”压缩快照”机制，每 100 个 event 生成一个中间快照，回放时从最近快照开始。这事儿其实就是借鉴了 event sourcing 里的 snapshot 模式。

一句话结论：大厂或者强监管场景才用得上，中小团队别碰。

一个”200 轮对话还不崩”的参考架构

最后给个我现在给中型项目用的默认架构，规模大概对标日活 10 万、单用户平均 30 分钟会话。

┌─ 近期原文（最近 8 轮）
│     完整保留，不压缩
│
├─ 中期要点（第 9-24 轮）
│     每 4 轮一个小摘要，保留 entity
│
├─ 远期摘要（第 25 轮以前）
│     整段摘要，~800 token
│
├─ 长期记忆（跨会话 fact 库）
│     向量库 + 结构化表
│     Claude 按需调用 recall 工具触发检索
│
└─ 用户画像（静态 profile）
      ~500 token，每天异步更新一次

几个实现要点：

第一，摘要是异步的，不阻塞当前对话。用户发完消息，直接用近期原文 + 现有摘要拼 context。摘要更新在后台跑。

第二，fact 抽取用 Haiku 4.5，prompt 里明确要求结构化输出（见 XML 标签），包括 fact 类型、confidence、过期时间。

第三，主模型用 Sonnet 或 Opus，通过 tool use 主动调用 recall。具体工具定义和 MCP 结合可以看 MCP vs Function Calling。

第四，每 50 轮对话跑一次”记忆整理”——合并重复 fact、标记过时 fact、提升高频 fact 的权重。这个灵感来自人类睡眠时的记忆巩固。

跑了七八个月，200 轮以上的长会话测下来”还能记得早期重要信息”的比例 87.6%，比最朴素的方案 B 高了 30 多个点。

最后说个容易被忽视的事

所有记忆方案都绕不过一个灵魂问题：这个”记忆”到底属于谁？

用户以为 AI 记住了他说的话。但底层可能是向量库里的几条 embedding，跟他想象的”AI 在关心我”差距很大。一旦产品把”长期记忆”做成卖点，就要对用户的期待负责——包括遗忘权、导出权、修正权。

这不是技术问题，是产品伦理问题。但做技术的人最好一开始就想清楚。