深度解析 Agent Memory 演进历程

• 记忆的 1.0 时代：手动贴便签 (Agents.md)
• 记忆的 2.0 时代：从手动注入到持久化管理
• 技术深挖：应用层记忆，不等于模型层“有状态”
• Memory 常见是怎么实现的？
• 这对开发者意味着什么？
• 总结

本文首发地址 https://h89.cn/archives/534.html

最近在使用 Trae.ai 的时候，很多开发者可能都注意到了 Agent 侧边栏那个 Memories 图标。

如果你曾经为了让 AI 记住项目规范，不得不在每个对话框里重复“请使用 Compose 开发”“注意内存对齐”，那你大概会直观地感受到：记忆能力一旦做得好，交互成本会明显下降。

今天我们就来聊聊：AI 的记忆机制，是怎么从“手动补上下文”演进到“可复用的记忆管理”的？

记忆的 1.0 时代：手动贴便签 (Agents.md)

在 Trae、Cursor、Claude 等 AI IDE 中，我们主要依靠手动提供上下文。

最典型的代表就是 Agents.md（或者类似的 Claude.md）。它的逻辑很直接：

• 原理：每当你向模型提问时，工具会把这类文件中的规则或说明拼接进上下文。
• 本质：它更接近一种外部上下文注入机制，而不是模型本身真的“记住了”这些信息。
• 局限性：它像一张手动维护的便签。虽然简单有效，但会持续占用上下文窗口（Context Window）。随着项目变大、规则变多，模型可用于当前任务的有效注意力就会被摊薄。

记忆的 2.0 时代：从手动注入到持久化管理

你在 Trae.ai 中看到的 Agent Memories，如果从产品形态上看，通常已经不只是“读取一份固定配置文件”那么简单。更准确地说，它更像是一层持久化的上下文管理能力。为什么说它和单纯的 Agents.md 不太一样？

1. 信息来源更动态：它不一定要求你手动维护 Markdown，也可能结合历史对话、显式保存的偏好、任务上下文等信息来形成记忆。
2. 通常会做压缩和筛选：它不会把全部历史原样塞回模型，而更可能通过摘要（Summarization）、检索（Retrieval）或结构化存储，挑出和当前任务最相关的部分。
3. 它仍主要是应用层能力：这里更准确的说法不是“模型从无状态变成有状态”，而是在无状态模型之上，增加了一层可持久化的记忆系统。

技术深挖：应用层记忆，不等于模型层“有状态”

传统基于 Transformer 架构的大模型（如 GPT-4、Llama 3）在推理时通常可以看作是无状态（Stateless）的。换句话说，模型不会在会话结束后自动把历史经验永久保存在自身参数或运行状态里；它主要依赖你重新提供上下文（Context）来“想起”之前的内容。

所以，今天很多 Agent 产品里的 Memory，更准确地说是：

• 应用层记忆系统：把用户偏好、历史决策、任务摘要等信息存到外部存储里，需要时再取回。
• 检索与摘要机制：不是把所有历史都重新喂给模型，而是尽量只回注入和当前任务相关的部分。
• 工作流层增强：Memory 往往和检索、规则、工具调用一起工作，属于 Agent 编排能力的一部分。

真正意义上的模型层有状态（Stateful）是另一条技术路线，例如：

• 状态空间模型（SSM）：如 Mamba、RWKV 这类方向，会尝试用持续更新的内部状态来压缩历史信息。
• 内存增强型模型：即便底层仍然是 Transformer，也可能通过外部记忆模块让系统具备更强的读写历史能力。

但要注意：这类模型架构方向，并不能直接等同于今天 IDE 里看到的 Memories 功能。 后者更多还是产品层、系统层的设计。

可以这样理解：

• 无状态模型：模型本身不会自动长期保留你的项目经验，历史信息需要靠上下文重新提供。
• 带 Memory 的 Agent：系统会把历史偏好和决策以外部记忆的方式保存下来，再在合适的时候取回给模型使用。
• 模型层有状态：这是更底层的架构能力，和今天常见的产品级 Memory 不是同一个概念。

Memory 常见是怎么实现的？

如果继续往下拆，今天很多 Agent Memory 大致都会包含下面几步：

1. 存储（Store）：先把值得保留的信息存下来，例如用户偏好、项目约束、历史决策、任务摘要。
2. 压缩（Summarize）：原始对话通常太长，不适合每次原样回放，所以系统往往会做摘要、归类或结构化整理。
3. 检索（Retrieve）：当前任务开始时，再根据关键词、语义相关性或任务类型，从历史信息里找出最相关的部分。
4. 回注入（Inject）：最后把这些筛选过的内容重新放回当前上下文，交给模型参与推理。

用工程视角看，这更像一个“存储 + 检索 + 组装上下文”的过程，而不是模型自己在后台持续保留完整记忆。

这也是为什么 Memory 系统的效果，往往不只取决于模型本身，还取决于：

• 存了什么信息
• 怎么做摘要
• 检索是否准确
• 回注入的时机和长度是否合适

这对开发者意味着什么？

1. 减少重复说明成本：常用规范、偏好和历史决策不必每次都手动重讲。
2. 更适合长周期任务：当项目很大、开发周期很长时，Memory 可以帮助系统在多次会话之间尽量保持一致性。
3. 让 Agent 更贴近具体项目：它未必会变成你的“数字分身”，但确实更有可能理解这个项目的历史约束和团队习惯。

总结

Agent 的 “Memories” 更适合被理解为：在无状态模型之上，为 AI 系统补上一层可复用、可持久化的记忆能力。它不一定意味着模型本身已经拥有了真正的长期记忆，但确实让 AI 工具开始从“只处理当前对话”走向“能够利用历史经验辅助当前任务”。

你会更偏向手动维护 Agents.md，还是把更多上下文交给 Memory 系统来管理？欢迎分享你的看法。