一名云计算从业者的思考

大家都在搜：

热搜词1 热搜词2 热搜词3

当前位置：首页 > 产品思考 > 正文内容

Agent 记忆的分水岭：不是 Markdown，不是向量库，而是上下文治理

anycodes2个月前 (06-05)产品思考1680

最近 Agent 记忆很热。

热到很多框架、产品、MCP Server 都开始说自己有 memory。有人把记忆写进 Markdown，有人接向量库，有人做本地文件，有人做云端服务，有人做图谱，有人做 summary。表面上看，好像只要提供 `add_memory`、`search_memory`、`update_memory`、`delete_memory`，Agent 就拥有了长期记忆。

但我越来越觉得，行业里很多关于记忆的讨论，其实还停留在很浅的一层。

**把信息存下来，不等于 Agent 拥有了记忆。**

能检索出来，也不代表这段信息应该进入当前上下文；能被模型总结，也不代表它应该成为长期事实；能通过 MCP 暴露出去，也不代表它在安全、权限、并发、回滚、审计上已经准备好了。

真正难的不是“记忆放在哪里”，而是这段信息在未来到底应该如何影响 Agent 的行动。

所以我现在对记忆最核心的理解是：

**Agent 记忆不是存储系统，而是一套面向未来行动的上下文治理系统。**

## 记忆不是为了保存过去

我以前比较固执地认为，把用户所有信息完整保存下来，就是最好的记忆。因为全量、可追溯、不丢失。只要原文还在，未来不管发生什么，都可以回到原始现场重新判断。

这个想法到现在我也不认为完全错。原始历史非常重要，因为它是事实来源。没有原始历史，所有摘要、标签、偏好、画像、经验，都会变成不可追溯的二手信息。一旦总结错了、漏了、过期了，系统后面的判断都会建立在不可靠的基础上。

但全量保存不等于有效记忆。

如果一切都只是原始历史，那系统本质上只是一个日志仓库。它保留了过去，却没有真正回答：过去的哪一部分，应该在未来哪个场景里重新影响 Agent 的判断？

用户真正需要的，也不是 Agent 告诉他“我保存了你所有历史”，而是在下一次任务中少解释一次背景，少重复一次偏好，少踩一次之前踩过的坑。

所以，**记忆的目的不是保存过去，而是让未来的行动更可靠。**

如果一段信息不会影响未来判断，它只是日志；如果一段信息可以被查询但不会进入任务决策，它更像资料；只有当一段信息会影响 Agent 未来回答、工具调用、任务路径或权限判断时，它才真正进入了记忆系统。

这也是记忆比知识库更敏感的原因。

知识库回答的是“世界是什么”。它通常来自文档、制度、API 说明、产品手册、业务资料。知识库可以离线处理，可以切片、索引、摘要、结构化。哪怕处理慢一点，很多时候也能接受。

记忆回答的是“我们经历过什么”。它来自对话、任务执行、工具调用、失败恢复、用户偏好、项目决策和上下文迁移。它是动态产生的，而且经常刚产生就要被使用。

知识库错了，往往是一次回答查错资料；记忆错了，可能会让 Agent 在未来很多次任务里持续带着错误理解行动。尤其当这条记忆被包装成“用户偏好”“项目约束”“组织经验”之后，模型会天然更愿意相信它。

**错误记忆比没有记忆更危险。**

没有记忆时，Agent 至少会问；错误记忆生效后，Agent 会自信地错。

## 全量记忆和汇总记忆不是二选一

关于记忆，最容易争论的一点是：到底应该全量保存，还是应该压缩汇总？

我过去更偏全量保存，因为全量意味着可追溯，意味着不提前判断什么重要，意味着未来问题发生时还有机会重新回到现场。尤其在 Agent 场景下，未来的信息需求很难预测。今天看起来不起眼的一句话，可能后天就是某个任务的关键约束。

但只做全量也有问题。全量历史越积越多，检索成本会上升，上下文会变脏，模型会被无关信息干扰。更重要的是，原始历史本身没有替你完成抽象。它保留了事实，却没有告诉你状态有没有变化、偏好是否稳定、某个结论是不是已经被推翻。

所以我现在更倾向于一个分层答案：

**原始记忆解决可信和追溯，汇总记忆解决效率和可用，结构化记忆解决推理和治理。**

原始历史应该尽量保留，因为它是事实来源；摘要和汇总可以生成，但不能替代原文；结构化信息很有价值，但它应该带着来源、版本和可信度，而不是变成不可追溯的新事实。

这件事很像代码里的 source of truth。原始记忆是 source，摘要、画像、偏好、经验都是 view。View 可以被加速、被索引、被优化，但不能反过来把 source 覆盖掉。

如果只有原始历史，系统会笨。  
如果只有摘要汇总，系统会危险。  
如果只有结构化结论，系统会僵硬。

好的记忆系统应该允许三者共存，并在不同场景下选择不同层次的信息。当前任务需要保真，就回原文；快速个性化需要偏好，就用稳定记忆；时间推理和状态变化需要结构化，就用派生信息；出现冲突时，必须能回到原始来源重新判断。

这才是比较健康的记忆架构。

## 记忆不是 KV 表，它需要版本、冲突和回滚

![](https://www.runor.cn/zb_users/upload/2026/06/202606051841275201587.png)

很多 Memory API 看起来像一套很简单的增删改查。但 Agent 记忆一旦真的进入产品，就会很快遇到更新问题。

今天系统记录了一条记忆：用户喜欢方案 A。明天用户说不对，应该用方案 B。后天发现明天那次其实是某个特殊项目的临时要求，或者是 Agent 理解错了，那这条记忆应该怎么办？

如果直接覆盖成 B，可能会丢掉 A 这个长期偏好；如果恢复成 A，又可能忽略 B 在特定项目里的有效性；如果 A 和 B 都保留，又需要知道它们分别适用于什么范围、什么时间、什么任务。如果这条记忆已经被摘要、向量化、结构化，甚至同步到多个索引里，那么一次回滚就不只是改一行文本，而是要处理一整条派生链路。

这不是简单的 update。

**Agent 记忆不是一张可以随便覆盖的 KV 表，而是一个带来源、版本、范围、可信度和生命周期的状态系统。**

一条成熟的记忆，不应该只有内容，还应该知道它从哪里来，是用户明确表达的，还是模型推断出来的；它属于谁，是个人、项目、团队还是组织；它什么时候生效，什么时候可能过期；它是否被更新过，旧版本是否还可追溯；如果后续发现错误，系统能不能回滚到更早的可信状态。

这些能力如果没有，所谓长期记忆就会变成长期风险。

尤其是模型参与写记忆之后，风险会更大。模型可能把临时上下文总结成长期偏好，把一次异常情况总结成普遍规律，把工具返回的噪声写成事实，把网页里的 prompt injection 当成用户指令。mem0-mcp 这类把长期记忆能力暴露给 Agent 和 MCP Client 的形态，产品上很方便，但安全边界一定要非常谨慎。因为一旦模型能写入、更新、删除长期记忆，记忆系统就不再只是存储组件，而是一个会被攻击、会被污染、会影响未来行为的状态入口。

行业现在对这件事讨论得还不够。

很多人看到了 Markdown 形式的记忆很好读、很好改，也看到了 MCP 暴露 memory 能力很方便，但很少继续追问：服务端并发读写怎么办？索引和原文怎么保持一致？多个 Agent 同时更新同一条记忆怎么办？记忆删除是否真的删除了所有派生索引？本地单机方案迁移到多租户服务端后，权限隔离和审计怎么做？用户撤回或纠错后，已经被摘要、向量化、结构化的派生记忆怎么回滚？

这些才是记忆系统真正进入生产后绕不开的问题。

## 为什么会有短期记忆和长期记忆

不同框架里对记忆的命名很多：short-term memory、long-term memory、working memory、episodic memory、semantic memory、profile memory、project memory。名字很多，有时候反而让人困惑。

但透过名字看本质，它们其实是在描述同一个问题的不同维度：不同信息的生命周期、稳定性、作用范围和使用方式不同。

短期记忆存在，是因为当前任务需要连续性。Agent 在一个任务里试过什么、失败在哪里、下一步要接着做什么，这些信息价值极高，但不一定应该长期保存。长期记忆存在，是因为用户偏好、组织规则、项目背景、常用工具、历史决策这些东西会反复影响未来任务。如果每次都让用户重新说，Agent 就没有长期协作能力。

项目记忆存在，是因为企业协作很多时候不是围绕个人，而是围绕空间和任务。某个项目里的技术选型、约束、决策，不应该自动变成某个人的全局偏好，也不应该泄露到另一个项目空间。经验记忆存在，是因为 Agent 不应该重复犯同样的错。一次工具调用失败、一次部署失败、一次权限申请流程，如果能沉淀成可复用经验，下一次就能少走弯路。

所以短期和长期不是为了模拟人脑，而是为了区分信息的生命周期。

**短期记忆解决任务连续性，长期记忆解决协作连续性，项目记忆解决空间连续性，经验记忆解决能力连续性。**

它们的写入规则、召回方式、权限边界和过期机制都应该不同。把它们都塞进一个 `memory.md` 或者一个向量库里，早期看起来简单，后期一定会混乱。

## 记忆需要升级，而不是一次写死

在 Agent 记忆里，我认为“记忆升级”会是一个非常关键的机制。

不是所有信息一进来就应该变成长期记忆。很多信息应该先停留在当前上下文里。如果它反复出现，被用户确认，被多个任务验证，或者明显具备长期价值，再逐渐升级为长期记忆。反过来，长期记忆也应该可以降级、过期、失效、被纠正、被回滚。

这比“自动总结用户偏好”更重要。

因为很多偏好不是偏好，只是当时的任务约束。用户说“这次先简单一点”，不代表他永远喜欢简单方案。用户说“这个项目不要用某个技术”，不代表所有项目都不能用。Agent 如果没有作用域和升级机制，就会把局部经验错误地泛化成全局规则。

这也是我认为理想化的“全知全记忆 Agent”不合理的原因。什么都记，什么都用，听起来智能，实际很容易污染上下文。真正成熟的记忆系统，不是尽可能多记，而是谨慎地决定哪些信息值得影响未来。

**记忆的写入应该保守，召回应该精准，更新应该可追溯，使用应该有边界。**

## Markdown 记忆只是入口，不是答案

我理解为什么很多人喜欢 Markdown 记忆。它可读、可编辑、天然适合人机协作，也很适合个人开发者场景。用户打开文件，就能看到 Agent 记住了什么，还能直接修改。这种透明感是很有价值的。

但 Markdown 不应该被神化。

Markdown 更适合作为记忆的表达层、导出层、人工编辑层，而不是企业级记忆系统的全部。真正进入 Agent 平台后，记忆要面对的是检索性能、增量索引、并发读写、版本管理、权限隔离、审计追踪、冲突合并、异步摘要、派生索引回滚、服务端多租户和数据安全。

单机文件很好，但服务端系统不是单机文件的简单放大。

如果未来 Agent 记忆会成为基础设施，那它一定不只是一个目录里的几份 md。它可能需要像数据库一样有事务和版本，像搜索系统一样有索引和召回，像权限系统一样有 scope 和 policy，像审计系统一样有来源和日志，像运行时一样能处理并发和状态变化。

所以我会更倾向于把 Markdown 看成一个很好的交互界面，而不是最终形态。

**用户可以用 Markdown 理解和编辑记忆，但系统不能只靠 Markdown 管理记忆。**

## 真正意义上的记忆是什么

![](https://www.runor.cn/zb_users/upload/2026/06/202606051841441041539.png)

回到最根本的问题：真正意义上的 Agent 记忆是什么？

我现在的理解是：

**记忆不是过去的全部记录，而是未来行动可用、可信、可治理的上下文资产。**

“可用”意味着它不是躺在日志里，而是在合适的时候能被召回；“可信”意味着它有来源、有证据、有版本，不是模型随便总结出来就成为事实；“可治理”意味着它有权限、有范围、有生命周期，能更新、能回滚、能删除、能审计；“上下文资产”意味着它会影响未来行动，而不是仅仅供人回看。

所以记忆的价值，不在于存了多少，而在于它能不能让 Agent 在未来更少打扰用户、更少丢失现场、更少重复犯错、更少错误迁移、更少越权使用上下文。

这件事比做一个 Memory API 难得多。

Memory API 只是入口，记忆治理才是系统。向量检索只是能力，记忆召回才是判断。Markdown 只是表达，记忆状态才是本质。摘要只是视图，原始历史才是来源。长期记忆只是结果，记忆升级才是过程。

如果说知识库让 Agent 有知识，工具让 Agent 有行动能力，那么记忆让 Agent 有连续性。而真正决定 Agent 能不能长期协作的，不只是有没有记忆，而是这套记忆能不能被正确地写入、召回、更新、回滚和治理。

所以我现在越来越觉得，未来 Agent 平台的分水岭，不会只是模型能力，也不会只是工具数量，而是上下文系统的质量。

**知识库回答“世界是什么”。工具回答“我能做什么”。记忆回答“我们经历过什么”。上下文系统回答“此刻什么最重要”。**

Agent 真正进入生产之后，最难的往往不是让它记住，而是让它在正确的时刻想起正确的东西，并且知道这段记忆是否可信、是否仍然有效、是否允许被使用。

**记忆不是为了保存过去，而是为了让未来的行动更可靠。**

这可能才是 Agent 记忆真正的意义。

扫描二维码推送至手机访问。

本文链接：https://www.runor.cn/?id=53

分享给朋友：

返回列表

上一篇：在 AgentRun 上的思考：传统 Infra 必须再做一层

下一篇：AI Coding 的终点不是写代码，而是应用生产入口

“Agent 记忆的分水岭：不是 Markdown，不是向量库，而是上下文治理” 的相关文章

刘博说云

大家都在搜：

Agent 记忆的分水岭：不是 Markdown，不是向量库，而是上下文治理

“Agent 记忆的分水岭：不是 Markdown，不是向量库，而是上下文治理” 的相关文章

AI Coding 的危险，不是写错代码，而是让人放弃判断

"用户第一"的悖论：从三朵云看产品设计的中庸之道

回归阿里云九个月：拥抱变化，理解变化，接受变化

自证害死的不仅仅是产品经理，更是一个团队

五个人教一个人点鼠标：云服务的荒诞现实

发表评论

Powered By Z-BlogPHP. Theme by TOYEAN.

刘博说云

大家都在搜：

Agent 记忆的分水岭：不是 Markdown，不是向量库，而是上下文治理

“Agent 记忆的分水岭：不是 Markdown，不是向量库，而是上下文治理” 的相关文章

AI Coding 的危险，不是写错代码，而是让人放弃判断

"用户第一"的悖论：从三朵云看产品设计的中庸之道

回归阿里云九个月：拥抱变化，理解变化，接受变化

自证害死的不仅仅是产品经理，更是一个团队

五个人教一个人点鼠标：云服务的荒诞现实

发表评论取消回复

Powered By Z-BlogPHP. Theme by TOYEAN.

发表评论