Minimal stack
轻量型 / Lightweight Memory
以短期记忆和少量任务状态为主，不急着做复杂长期层，先把当前回合做稳。
Strengths
实现成本低、调试简单、很适合早期系统快速验证。
Risks
跨会话价值弱，任务跨度一长就容易露出遗忘问题。
Best Fit
早期助手、短流程对话、低连续性需求场景。
7. Agent Memory Global Map
从全局角度看，memory 机制是怎么分工的
如果把 agent memory 当成一个整体来看，它不是一个单点能力，而是一条从“眼前保留什么”到“长期存什么”、再到“当前怎么用”和“跑久了怎么不变脏”的完整链路。很多讨论之所以混乱，就是因为把这些层混在一起谈了。
这一章不按某一类 agent 来讲，也不只讲单个技术点，而是从全局角度把 memory 机制整理成一张地图：短期记忆管最近上下文，长期记忆管远处知识与经验，工作记忆管当前回合怎么组装，写入策略决定什么能留下，污染治理决定系统跑久之后还可信不可信，目标层则决定前面这一切到底为谁服务。
Plain Explanation
前面几章像是在拆车，看发动机、油箱、刹车、仪表盘分别怎么工作；这一章像是把整车重新装回去，回答一个更大的问题：memory 到底是由哪几层拼起来的，这几层分别负责什么，哪些组合比较轻，哪些组合比较重。
When To Use
- 当你已经看完各章，但脑子里还没有一张整体地图时，这一章最有用。
- 当团队老是在混着讨论“检索”“状态”“写入”“治理”时，这一章可以帮大家把层次分清。
- 当你想从机制本身理解 memory，而不是从某个 agent 或某个产品切入时，这一章最适合作为总览。
- 当你要做选型判断，却不确定自己是在补短期、长期、工作记忆还是治理能力时，也应该先回来看这章。
Design Questions
- 你现在讨论的是“怎么存”、还是“怎么取”、还是“怎么在当前回合用起来”？
- 系统最缺的是短期上下文管理、长期召回、工作记忆编排，还是写入和治理？
- 如果只能优先补一层，补哪一层最能立刻改善当前效果？
- 你的问题真的是 memory 问题，还是 prompt、workflow、工具接口或状态机问题？
- 这套 memory 是要先做轻量闭环，还是已经到了值得做多层混合治理的阶段？
Evaluation Metrics
系统当前的问题能不能被清楚归因到某一层 memory
最近上下文、长期检索、当前编排、写入门控、治理能力是否各有可观测性
memory 层的复杂度增加后，收益是否真的大于维护成本
新增一层 memory 之后，是解决了真实问题，还是只是让系统更重了
Mainstream Mechanisms
先抓住这一页真正主流的机制主线
这一组不是“所有相关概念”，而是这个维度最核心、最值得先理解的主线。带下划线的机制可以直接点开，会弹出一个更细的解释窗。
1. Short-term Memory Layer
2. Long-term Memory Layer
3. Working Memory Layer
4. Write Policy Layer
5. Memory Hygiene Layer
6. Memory Objective Layer
Pipeline
把这些机制放回一条工作流里看
如果只看孤立卡片，机制之间的关系会很模糊。把它们放回 pipeline 中，就能看清每一步在系统里承担什么角色，以及问题通常出在什么位置。
1
See
先决定当前回合眼前要保留哪些最近信息，这一层对应短期记忆。
2
Store
把值得长期留下的知识、状态或经验存到合适的长期层里。
3
Recall
当需要远处信息时，用检索或状态读取把它们调回来。
4
Assemble
把最近上下文、长期召回、约束和状态一起组装成当前工作记忆。
5
Write Back
判断这一轮里哪些内容值得沉淀，哪些只是临时经过。
6
Clean
通过去重、冲突处理、衰减和作用域隔离，避免系统越跑越乱。
7
Optimize
最后根据系统目标，决定前面哪一层该优先做重，哪一层暂时可以轻一点。
Mechanisms
扩展机制与细部取舍
Knowledge-heavy
检索型 / Retrieval-centered Memory
以长期知识召回为主，核心是 chunking、embedding、ANN、metadata 和 reranking。
State + working memory
执行型 / Execution-centered Memory
以工作记忆、任务状态和恢复点为中心，重点不是记住很多，而是当前做事别断线。
Cross-session continuity
连续协作型 / Continuity-centered Memory
重点解决跨会话接续问题，让用户回来时系统能接上进度，而不是每次从头开始。
Experience memory
学习型 / Learning-centered Memory
把成功和失败经历整理成经验、策略或技能模块，希望系统下次做得更好。
Layered architecture
平台混合型 / Hybrid Platform Memory
多层 memory 各司其职：短期、长期、工作、写入和治理一起构成完整平台。
Examples
把这一章放进真实场景里看
为什么很多团队以为在讨论 memory，其实讨论的是三个不同问题
有人说“我们 memory 不行”，但细看后会发现，一部分是在抱怨长期检索召不回资料，一部分是在抱怨当前回合没把状态摆对，还有一部分是在抱怨系统越跑越乱。它们都叫 memory 问题，但其实落在完全不同的层。
Takeaway: 先把问题落到具体层次上，很多看起来很大的 memory 问题会一下子变清楚。
为什么轻量型系统也能比复杂系统更好用
一个早期 coding agent 如果先把最近上下文、任务状态和错误恢复点做好，往往就已经能明显提升完成率；反而一上来做复杂经验沉淀和混合存储，可能只会增加调试难度。
Takeaway: memory 不是越重越好，而是越贴近当前阶段的真实瓶颈越好。
为什么成熟平台最后大多会走向多层组合
当系统既要做知识问答、又要做项目接续、还要记住用户偏好并执行任务时，单一 memory 机制通常不够用了，最后自然会长成多层 memory 各自分工的样子。
Takeaway: 混合型不是因为“先进”，而是因为真实需求开始变多，必须分层处理。
Architecture Notes
从系统设计角度看这个维度
这一部分补充的是更偏 memory system design 的视角：不只看概念本身，而是看这些机制在真实系统里应该放在哪一层、如何被组织、如何被观测。
全局视角下，memory 更像一条分层链路，而不是某个单独数据库或中间件。
最容易出问题的地方，不是某个机制本身，而是不同层之间边界不清：谁负责存、谁负责调、谁负责写回、谁负责清理。
如果系统开始走向混合型架构，必须先明确 source of truth 和作用域边界，否则不同层会很快打架。
这一章的价值不在于替代前面六章，而在于帮读者知道每一章在整张地图里的位置。
Misconceptions
这一章最容易被误解的地方
误解一：memory 就等于长期记忆或向量数据库。
误解二：只要检索做强，memory 系统就算完整了。
误解三：写入和治理是后期优化，不需要一开始分层考虑。
误解四：memory 越重越高级，做得越多系统就一定越聪明。
Deep Dive
展开理解这个维度
memory 为什么应该被看成一条链路，而不是一个功能点
如果只把 memory 理解成“存东西”，很多关键问题会直接消失在视野里。真实系统里，memory 至少包含：最近信息怎么保、远处信息怎么存、需要时怎么召回、当前回合怎么组装、哪些内容该写回，以及系统跑久了怎么不变脏。
- 短期记忆回答的是“眼前留什么”。
- 长期记忆回答的是“远处存什么、怎么找回来”。
- 工作记忆回答的是“这一轮真正喂给模型什么”。
- 写入和治理回答的是“系统跑久后还能不能信”。
不同机制其实在解决不同层的问题
很多术语经常被混在一起提，但它们管的并不是同一件事。Buffer、Window、Summary 管的是最近历史；Vector、Graph、Relational 管的是长期表示；Ranking、Slotting、Budget 管的是当前回合怎么用；Write Policy 和 Consolidation 管的是哪些东西值得留下；Dedup、Conflict、TTL、Decay 管的是系统会不会越跑越脏。
- 别拿长期存储机制去解决当前回合编排问题。
- 别拿写入策略去替代污染治理。
- 别把检索做得很好，就误以为整套 memory 已经闭环。
从全局看，最常见的不是单机制，而是机制组合
真实系统里很少只靠一种机制。更常见的形态是：短期记忆保住当前连续性，长期记忆承接远处知识，工作记忆负责当前回合编排，写入策略控制沉淀门槛，治理机制负责长期可信度。
- 轻量型组合通常只做短期 + 少量状态。
- 检索型组合通常强调长期知识库 + reranking + working memory。
- 执行型组合通常强调工作记忆 + 任务状态 + 写入门控。
- 平台型组合则会把多层 memory 分工彻底拉开。
什么时候该轻，什么时候才值得做重
不是所有产品都需要一开始就做重 memory。很多时候，系统当前最缺的只是近期上下文管理、任务状态恢复或检索链路调优，而不是上多层混合治理。只有当跨会话价值、长期知识规模、任务连续性和经验复用都开始变重要时，重 memory 才真正划算。
- 如果单轮任务还不稳，先别急着做复杂长期层。
- 如果用户不会频繁回来，continuity 的优先级可能没那么高。
- 如果任务很依赖多步执行，working memory 往往比大而全的长期层更优先。
- 如果系统已经长期在线并持续写入，治理层就不能再拖了。
一个更有用的全局判断顺序
判断一套 memory 该怎么做，最实用的方法不是先选技术栈，而是先按问题顺序往下问：我最怕忘掉什么？这些内容是近期的、远期的、结构化的、语义型的，还是经验型的？它们要怎么进当前回合？哪些该留下？留下之后怎么别变脏？
- 先判断问题在哪一层，再选那一层的机制。
- 先做能立刻带来收益的层，再补更重的层。
- 最后才是选 Vector、Graph、Relational 还是 Hybrid 这类实现问题。
这章和下一章的边界在哪里
这一章讲的是 memory 机制本身的全景图，也就是“有哪些层、各自做什么、常见怎么组合”。下一章讲的是“不同 agent 类型为什么会偏不同组合”。一个是站在机制视角看整体，一个是站在 agent 视角看偏好差异。
- 如果你在问“memory 机制整体怎么分层”，看这一章。
- 如果你在问“为什么聊天助手和 coding agent 用得不一样”，看下一章。
- 两章连起来读，才会既有全局图，也有类型差异。
Failure Modes
常见失败模式
把所有 memory 问题都理解成长期检索问题，结果工作记忆和状态管理长期被忽视
只做存储和召回，不做写入与治理，系统短期好用、长期变脏
一上来就做很重的混合 memory，结果还没找到当前阶段真正的瓶颈
不同层边界不清，导致同一条信息在多层重复写入、互相打架
Previous Chapter
6. Memory Objectives
记忆服务于什么
看整套记忆最终为哪类能力服务
Next Chapter
8. Agent Memory Patterns
按 agent 类型看，memory 组合为什么会不一样
看不同 agent 为什么会长出不同 memory 组合