跳到主要内容

Agent Memory and State

学到 Agent Engineering 之后，一个很快会冒出来的问题就是：

Agent 到底靠什么记住自己已经做过什么？

如果这个问题处理不好，Agent 很容易出现这些现象：

  • 做到一半忘了前面查过什么
  • 不断重复同一个工具调用
  • 明明拿到了关键信息，却没有在后续步骤里用上
  • 对用户长期偏好一无所知

所以在 Agent 系统里，Memory 和 State 不是可有可无的附属品，而是核心运行部件。

这篇文档重点讲 4 件事：

  • State 和 Memory 分别是什么
  • 两者和 Context、RAG 有什么区别
  • 一个 Agent 系统通常需要保存哪些信息
  • 真实工程里该怎么设计，才能既有连续性，又不把系统搞乱

1. 先看一句最简定义​

可以先用一句很实用的话记住：

  • State 是“当前任务正在进行中的工作状态”
  • Memory 是“跨任务、跨轮次可复用的长期信息”

它们的共同点是都在“帮助系统记住事情”。

但两者服务的时间尺度不一样：

  • State 更短期
  • Memory 更长期

2. 为什么 Agent 一定要有 State​

普通单轮问答里，模型只需要回答一次。

但 Agent 是多步执行系统，它必须知道：

  • 当前目标是什么
  • 已经做到了哪一步
  • 还缺什么
  • 哪些工具已经调用过
  • 哪些结果值得保留
  • 什么时候应该停止

如果没有这些状态信息，Agent 每一轮都像重新开始。

这也是为什么：

State 几乎是所有 Agent 系统的标配。`

3. 为什么不是所有东西都应该放进 Memory​

很多人一学到“记忆”就会本能地觉得：

“那我是不是应该把所有内容都记下来？”

这其实非常危险。

因为一旦什么都记，系统就会出现：

  • 噪音积累
  • 旧信息污染当前任务
  • 用户临时说法被误当成长期偏好
  • 不再相关的历史事实持续干扰决策

所以 Memory 不是“存越多越好”，而是“只保留稳定、值得复用的信息”。

4. State、Memory、Context、RAG 的区别​

这几个概念经常混在一起，最好一次分清。

4.1 Context​

Context 是模型这次调用时真正看到的输入包。

它可以包含：

  • 当前任务
  • 规则
  • 历史摘要
  • 检索资料
  • 工具结果
  • 当前状态

所以：

  • Context 是“本次调用可见的信息”

4.2 State​

State 是任务运行时的工作进度板。

它更关注：

  • 现在正在做什么
  • 已完成什么
  • 下一步可能做什么

所以：

  • State 是“当前任务的运行状态”

4.3 Memory​

Memory 是跨任务保留的长期信息。

比如：

  • 用户偏好
  • 常用规则
  • 稳定背景设定
  • 经常复用的事实

所以：

  • Memory 是“值得长期复用的信息”

4.4 RAG​

RAG 是按需从外部知识源取资料。

它解决的是：

  • 模型本身不知道的知识
  • 当前上下文里没带上的资料
  • 需要实时查的外部文档

所以：

  • RAG 是“按需拉取知识”

一句话区分：

  • Context：本轮可见信息
  • State：当前任务进度
  • Memory：长期可复用信息
  • RAG：按需检索外部知识

5. Agent State 通常包含什么​

一个比较典型的 Agent State，通常会包含下面几类信息。

5.1 Goal State​

也就是任务目标。

比如：

  • 用户最终想完成什么
  • 当前任务成功的标准是什么

5.2 Progress State​

也就是任务进度。

比如：

  • 已完成步骤
  • 当前步骤
  • 剩余待办

5.3 Evidence State​

也就是已经获得的证据或中间结果。

比如：

  • 查到的文档片段
  • 工具返回的数据
  • 已确认的事实

5.4 Decision State​

也就是关键决策痕迹。

比如：

  • 为什么选了这个工具
  • 为什么放弃了某条路径
  • 为什么进入下一步

5.5 Control State​

也就是执行控制信息。

比如：

  • 当前轮次
  • 最大步数
  • 重试次数
  • 是否已触发人工接管

这些状态不一定都要原样塞进模型上下文，但系统内部通常需要维护。

6. Memory 通常包含什么​

对 Agent 来说，真正适合进入 Memory 的内容，通常要满足两个条件：

  • 相对稳定
  • 后续任务大概率还会用到

常见类型有：

6.1 User Preference Memory​

比如：

  • 用户偏好中文还是英文
  • 用户喜欢简洁还是详细
  • 用户常用的输出格式

6.2 Profile / Background Memory​

比如：

  • 用户所属团队
  • 业务背景
  • 常见工作上下文

6.3 Durable Task Memory​

有些长期任务会跨天持续，比如：

  • 某个项目已确认的目标
  • 已排除的方案
  • 长期约束条件

6.4 System Learned Memory​

比如系统在长期使用中沉淀出来的稳定偏好或约定。

但这类信息要特别谨慎，防止误记。

7. 一个很实用的设计原则​

判断一条信息该进 State 还是 Memory，可以问两个问题：

7.1 它是不是只对当前任务有用​

如果是，优先放进 State。

7.2 它在未来任务里是否稳定复用​

如果是，才考虑进入 Memory。

换句话说：

  • 当前任务专用信息，尽量短期保存
  • 长期稳定信息，才值得记忆化

8. 为什么 Memory 很容易出问题​

Memory 的问题往往不是“记不住”，而是“记错了、记多了、记脏了”。

常见问题包括：

8.1 错误记忆​

模型或系统把不可靠信息写成了长期记忆。

8.2 过度记忆​

把一次性的临时需求保存成长期规则。

8.3 冲突记忆​

旧偏好和新偏好不一致，却都留着。

8.4 污染当前决策​

历史信息被无差别注入上下文，导致当前任务跑偏。

所以 Memory 设计一定要比 State 更保守。

9. 工程上怎么设计更稳​

9.1 先把 State 设计清楚​

很多系统一上来就想做复杂 Memory，反而忽略了最关键的任务状态管理。

更稳的顺序通常是：

  1. 先让任务状态清晰
  2. 再考虑哪些内容值得长期保留

9.2 Memory 要有写入规则​

不要让系统“什么都能记”。

最好明确：

  • 哪些字段允许写入
  • 什么条件下才写
  • 由谁决定写入
  • 是否需要置信度或人工确认

9.3 Memory 要有更新和过期机制​

长期信息不是一成不变的。

所以你最好考虑：

  • 如何覆盖旧值
  • 如何处理冲突
  • 哪些信息应该过期

9.4 注入上下文时要做选择​

不是所有 Memory 都要在每轮注入。

应该根据当前任务挑选真正相关的部分。

这本质上仍然属于 Context Engineering。

10. 一个常见的系统分层​

很多 Agent 系统可以按下面这个方式设计：

Working State -> Session Memory -> Long-term Memory -> External Knowledge

可以理解成：

  1. Working State 当前任务正在运行的状态
  2. Session Memory 当前会话里持续有效的信息
  3. Long-term Memory 跨会话的稳定信息
  4. External Knowledge 通过 RAG 按需拉取的外部资料

这样的分层有个好处：

  • 短期信息不会污染长期记忆
  • 长期记忆也不会无差别挤占上下文

11. 常见误区​

11.1 把历史对话全都当 Memory​

不是所有历史都值得长期保存。

大部分历史更适合：

  • 被压缩成摘要
  • 暂存在 session
  • 或直接丢弃

11.2 把 RAG 当 Memory​

RAG 是按需查资料，不是长期记忆本身。

两者可以配合，但职责不同。

11.3 只做 Memory，不做 State​

这会导致系统看起来“好像记住了很多”，但其实当前任务仍然混乱。

对 Agent 来说，State 往往比 Memory 更先影响成败。

11.4 让模型自由写长期记忆​

如果没有边界，系统很容易记住错误、临时甚至敏感信息。

12. 一句话总结​

如果说：

  • State 解决的是“当前任务做到哪了”
  • Memory 解决的是“哪些稳定信息值得长期保留”

那么一个稳健的 Agent 系统通常应该做到：

先把任务状态管理清楚，再谨慎地引入长期记忆，并且始终通过 Context Engineering 控制哪些记忆真正进入模型视野。