Agent 的"失忆症"——为什么 LLM 记不住事

一、从一个真实场景开始

先问一个问题：你在开发过程中，"断片"过多少次？

我有过一次印象深刻的。那天下午我在调试一个数据同步的问题——上游 API 返回的字段跟数据库结构对不上，sync 引擎报了错。我花了 40 分钟排查，定位到问题，改好了代码，部署了修复。

第二天上午，同一套流程重新开始。我打开一个新的终端会话，开始写一个新的调试任务。然后我突然想不起来：昨天那个字段映射的问题，我最后是怎么解决的？

我翻日志。翻代码提交记录。翻了五分钟才找到答案。

这个场景，做过开发的人都不陌生。但有意思的是："断片"的不是我，是我的 AI Agent。

因为每次我开启新会话，Agent 都不记得上一轮和上几轮我们讨论过什么。它知道全局的偏好和配置，能搜索历史会话，但它不会主动想起："等等，上次我们花了 40 分钟修了一个字段映射问题，那个结论你别忘了。"

这不是模型不够聪明。这是记忆架构没有设计。

二、"断片"的三种表现

在实际开发中，我总结了三种最常见的"断片"现象：

1. 记不住上一轮说了什么（工作记忆失效）

在一个长对话中，Agent 越来越"健忘"。前面的推理结果、中间做出的决策，后面就被忽略了。

场景： "刚才我们不是确认了用方案 A 吗？为什么你现在又建议用方案 B？"

根因： 上下文窗口满了，早期信息被挤出。模型并不是"故意忘记"，而是注意力被新内容稀释了。

2. 新会话一切归零（情景记忆缺失）

每次打开新会话，Agent 都是"初次见面"的状态。它不知道你是谁、之前讨论过什么、做过什么决策。

场景： 昨天修了一个 bug，今天想继续深入，但 Agent 完全想不起来，你得重新描述一遍。

根因： 会话结束后的状态没有持久化。Agent 没有"跨会话记忆"，每次都是从零开始。

3. 同样的问题反复出现（语义知识未固化）

一些问题明明已经解决过，方案已经验证过，但每次遇到类似情况，Agent 还是要从头推理，而不是调取已有的经验。

场景： 每次做数据库字段扩展，都要重新讨论一遍"怎么加列、怎么改 struct、怎么更新 SQL"的流程。

根因： 正确的操作路径没有被固化为可复用的知识。经验随会话结束蒸发了，没有被沉淀下来。

三、LLM 天生就是"失忆"的

要解决"断片"，先要理解它为什么会发生。

LLM 的设计从根上是无状态的：

用户输入 → LLM 推理 → 输出
          ↑
      上下文窗口（仅本次请求）

每一次 API 调用，模型都是独立推理。它不"记得"前一次调用了什么、输出了什么。你觉得它在"对话"，实际上它在每轮都在回答一个包含了完整历史的新问题。

你感觉的对话：
  Round 1: "帮我查一下订单 A" → "订单 A 的状态是已发货"
  Round 2: "那订单 B 呢？"     → "订单 B 的状态是待支付"

实际发生的事：
  Round 1: "帮我查一下订单 A" → LLM 返回结果
  Round 2: "帮我查一下订单 A，它的状态是已发货。那订单 B 呢？" → LLM 返回结果
          ↑ 上下文里包含了上一轮的对话历史

这种设计有一个好处——实现简单。但有一个巨大的代价：记忆不是模型的固有属性，而是需要工程手段来实现的附加系统。

这就是记忆系统存在的根本原因。

四、给"断片"拍个 X 光：三层记忆模型

要诊断断片，先理解 Agent 应该有什么样的记忆架构。业界最广泛接受的框架是三层记忆模型，它来自认知科学，被 MemGPT、LangGraph、CrewAI 等主流框架以不同方式实现：

┌─────────────────────────────────────────┐
│    语义记忆（Semantic）                   │
│    长期知识：业务规则、领域常识、技能模板   │
│    → 固化为可复用的模式库                 │
├─────────────────────────────────────────┤
│    情景记忆（Episodic）                    │
│    历史记录：过去的会话、决策链、中间结果   │
│    → 跨会话检索关键信息                   │
├─────────────────────────────────────────┤
│    工作记忆（Working Memory）              │
│    当前上下文：本轮对话的推理链、临时变量   │
│    → 会话内的注意力管理                   │
└─────────────────────────────────────────┘

把前面三种"断片"放进去对应：

五、Harness 已经做了哪些？还缺什么？

好消息是，Harness 方法论中，我们已经覆盖了部分记忆问题：

但还有两个大缺口：

• 情景记忆完全没有覆盖——跨会话的状态持久化和检索，这是"断片"最频繁的领域
• 三层模型的系统性框架没有建立——目前是点状解决方案，不是体系化设计

六、写在最后：这不是模型的错

当你的 Agent "断片"时，很容易觉得："这个模型不够聪明"。

但真相是：LLM 就是设计成这样的。一个无状态的推理引擎，每次调用独立运行，不记得任何过往。这不是 bug，这是设计约束。

把"断片"归咎于模型不够强，就像抱怨计算器不会记住你上次算的结果。这不是计算器的职责——它负责算，你负责记。

但 Agent 不同。Agent 被期望像人一样工作：有上下文、有记忆、能复用经验。这就要求我们把记忆系统作为 Agent 架构的一等公民来设计——不是"加个 RAG 就行"，而是从架构层面把三层记忆模型内建到 Agent 系统中。

下一篇，我们将深入三层记忆模型，看看每一层的设计目标、技术选型和工程取舍。