一名云计算从业者的思考

大家都在搜：

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

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

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

anycodes3个月前 (06-05)产品思考3400

最近 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://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://runor.cn/zb_users/upload/2026/06/202606051841441041539.png)

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

我现在的理解是：

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

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

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

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

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

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

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

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

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

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

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

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

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

分享给朋友：

返回列表

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

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

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

刘博说云

大家都在搜：

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

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

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

为 AgentRun二进宫：一个关于 Serverless 与 Agent Infra 的未竟执念

两种 FaaS 产品哲学：AWS Lambda 和 AgentCore Runtime 的专业化分工 vs 阿里云 FC 的平台进化

回归产品思维：一位前产品经理的八点反思

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

产品对标的陷阱：为何技术优势不等于市场成功

发表评论

Powered By Z-BlogPHP. Theme by TOYEAN.

刘博说云

大家都在搜：

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

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

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

为 AgentRun二进宫：一个关于 Serverless 与 Agent Infra 的未竟执念

两种 FaaS 产品哲学：AWS Lambda 和 AgentCore Runtime 的专业化分工 vs 阿里云 FC 的平台进化

回归产品思维：一位前产品经理的八点反思

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

产品对标的陷阱：为何技术优势不等于市场成功

发表评论取消回复

Powered By Z-BlogPHP. Theme by TOYEAN.

发表评论