Agent Memory 架构全景：从规则文件、会话检索到反思与技能沉淀
输入“/”快速插入内容
Agent Memory 架构全景：从规则文件、会话检索到反思与技能沉淀
Agent Memory 架构全景：从规则文件、会话检索到反思与技能沉淀
用户4242用户42426月25日修改
几个月前我开始用 OpenClaw，发现它带给 Agent 行业的东西里，最让我兴奋的除了定时任务，还有一个看起来平平无奇的文件：MEMORY.md。
这个好奇心驱使我翻了翻本机 ~/.claude/ 目录。结果发现，我经常用 Claude Code 跑 /loop 的那些项目，每个下面都有自己对应的 memory 文件。它们不是日志，不是 README，也不是类似 session 历史的东西：
把几个项目的 memory 放在一起看，一个问题自然浮现：他们都在记录些什么内容 。 有的是“以后必须这么做”，有的是“这个项目现在是这个状态”，有的是“上次在这里踩过坑，别再来了”，有的是“我们为什么相信这个结论”，还有的是“下一轮 loop 从这里接着来”。
Agent Memory 其实已经从“存聊天记录”分化成了一整套架构。规则、画像、历史、证据、反思和技能沉淀，各有各的存储方式、加载时机和治理难题。这篇文章想完整讲清楚的，就是截至 2026 年中，这套架构到底长什么样。
本文适合哪些人阅读：
•
正使用或者构建Coding Agent、研究Agent、个人AI Agent或任何需要跨 session 持续工作的 LLM 应用的开发者；
•
对 agent 架构感兴趣但还没想清楚 memory 该怎么分层的技术决策者；
•
已经在用 Claude Code / Codex / OpenClaw / Hermes 等工具、想理解自己项目里那些 memory 文件到底在干什么的重度用户
一、长上下文解决当前任务，Memory 解决跨任务复利
先说一个很多人都搞混的点：Agent Memory 不是长上下文的替代品。
250K、1M 甚至更长的 context window 已经是标配。长上下文当然重要——它让模型在当前任务里能同时看见更多文件、更多日志、更多证据，避免频繁摘要带来的信息损耗。
但长上下文解决的永远是“这一轮能装下多少”。
Memory 解决的是另一个问题： 下一轮醒来的时候，agent 还记不记得上一次为什么要那样做。
Context window 是工作台，当前任务需要的材料全摊在上面；RAG 和搜索是按需调用的外部资料库；Memory 则是跨会话、跨项目、跨 agent 持久存在的状态层。三者分工清晰。
一个 coding agent 只有长上下文没有 memory，下周重开 session 照样踩同一个测试环境的坑。一个 research agent 只有 RAG，它能查到过去的资料，却不知道哪条已经被证伪、哪个来源在这个主题上不可靠。一个交易 agent 只有 transcript，回看得了所有日志，分不清哪些已经升格成不变量、哪些只是一次偶然。
Memory 的核心价值不在“存得多”，而在 把过去的东西分层 ：哪些该常驻，哪些该搜索，哪些该归档，哪些该变成以后可复用的技能。
二、第一层：规则记忆——Agent 的工作宪法
最早被广泛使用的 agent memory，其实比任何自动记忆系统都更早落地。它就是规则文件
Claude Code 叫 CLAUDE.md, Codex 叫 AGENTS.md。本质是一份“工作宪法”：这个项目怎么构建和测试，哪些目录绝对不能碰，哪些命令必须在特定子目录跑，哪些代码风格和提交规则不可破坏，哪些业务红线比完成当前任务本身更重要。
优点一目了然：可读、可改、可审计、可放进 Git。团队能 review，CI 能检查，agent 每次启动都能看到。
但它有明确边界。规则文件适合放“长期稳定、每次都该遵守”的东西，不适合塞所有历史细节。把每个 bug、每次实验、每条日志都往 CLAUDE.md 里堆，最后只会把上下文变成一坨低密度噪声。
Claude Code 官方文档也把 CLAUDE.md 和 auto memory 拆得清清楚楚：前者是人写的指令和规则，后者是 Claude 根据修正和偏好自己积累的学习。Codex 同样强调，团队必须遵守的规则应该放在 AGENTS.md 或 repo 文档里，memories 只是本地 recall layer.
第一条设计原则就此确立：
必须遵守的规则，不要只放在自动记忆里。它们应该进入版本化的规则文件。
规则 memory 是 agent memory 的第一层。它解决的是“以后都按这个方式做”。
三、第二层：常驻画像——每一轮都要付 token 税的东西