High fidelity
Conversation Buffer Memory
直接保留会话中的完整近期历史，包括用户输入、代理回应、工具输出，必要时还包括中间思考或状态描述。
Strengths
保真度最高，实现最简单，能完整保留最近互动的细节与语义连续性。
Risks
随着交互增长会迅速吃掉 L_context，同时带来更高的成本与延迟；只适合很短的会话。
Best Fit
短流程、高精度、需要完整回看原始上下文的任务与调试场景。
1. Short-term Memory
短期记忆怎么管
短期记忆决定 agent 这一刻手边还留着哪些信息。它不只是聊天记录，而是在有限上下文窗口 L_context 里，帮系统留住下一步最可能用得上的内容。
当代理要连续聊很多轮，或者要分很多步完成任务时，如果没有短期记忆，它很快就会忘记刚刚做到哪、看到了什么、接下来要接什么。从工程实现看，短期记忆最好理解成 3 个基础机制加 1 个关键混合机制：Conversation Buffer、Conversation Window、Conversation Summary，以及 Conversation Summary Buffer。它们本质上都在“保留细节”和“别把上下文塞爆”之间找平衡。
Plain Explanation
可以把短期记忆想成代理桌面上摊开的那几张纸。纸太少，它会忘记刚刚做到哪；纸太多，桌面又会被堆满，看不出重点。所以短期记忆做的事，就是决定哪些最近信息要继续摊在桌上，哪些该收起来，哪些该压缩成便签。
When To Use
- 当任务只看最近几轮对话时，优先考虑更简单的窗口式方案。
- 当任务需要连续推进很多步时，必须考虑摘要或混合式短期记忆。
- 当工具输出很多时，要特别注意短期记忆会不会被日志淹没。
Design Questions
- 最近几轮是保留原文，还是压缩成摘要？
- token 预算逼近上限时，谁先被截断：闲聊、工具日志还是任务状态？
- 短期记忆是被动缓存，还是允许 agent 主动整理、删减、重写？
Evaluation Metrics
最近 3-5 轮里，关键信息有没有被完整保住
短期记忆吃掉了多少 prompt token
做完摘要后，关键事实和限制条件还在不在
长对话里，系统是不是越来越常要求用户重复说明
窗口大小或摘要阈值一调，效果会不会大幅抖动
Mainstream Mechanisms
先抓住这一页真正主流的机制主线
这一组不是“所有相关概念”，而是这个维度最核心、最值得先理解的主线。带下划线的机制可以直接点开，会弹出一个更细的解释窗。
3. Conversation Summary Memory
Pipeline
把这些机制放回一条工作流里看
如果只看孤立卡片，机制之间的关系会很模糊。把它们放回 pipeline 中，就能看清每一步在系统里承担什么角色，以及问题通常出在什么位置。
1
Capture
捕获最近互动、工具输出与即时状态。
2
Retain
决定原文保留、窗口截断还是滚动摘要。
3
Compress
必要时对旧内容做 summary 或 token-based trimming。
4
Inject
把当前仍然重要的短期内容送入本轮 prompt。
Mechanisms
扩展机制与细部取舍
Bounded context
Conversation Window Memory
只保留最近 k 轮互动或最近固定 token 范围内的内容，通过滑动窗口控制短期记忆大小。
Compressed continuity
Conversation Summary Buffer
用 LLM 定期总结较早互动，把旧内容压缩成摘要，同时保留最近几轮原始内容。
Hybrid balance
Recent Raw + Rolling Summary
把近期内容保留为原文，把更早内容滚动压缩成摘要，是很多框架和真实系统里最常见的混合短期记忆形态。
Examples
把这一章放进真实场景里看
客服助手的最近上下文
用户刚刚问完退货政策，紧接着又问“那运费呢？”。如果短期记忆还保留着上一轮上下文，系统就知道“那”指的是退货流程，而不是随便一个运费问题。
Takeaway: 短期记忆的价值不在于记得很多，而在于记得刚刚最关键的那一点。
Coding agent 的多步修复
代理刚运行完测试、看到报错、准备改下一处代码。如果前面的测试输出和当前子任务被窗口裁掉，它就会像“没看过日志”一样重新摸索。
Takeaway: 工具型 agent 越多步骤，越依赖高质量的短期记忆。
四种短期记忆像四种记事方式
Conversation Buffer 像写全量日记，什么都记；Window 像桌上的便利贴，只留最近几件事；Summary Memory 像每周写周报，只留总结不留原文；Summary Buffer 则像智能笔记本，近期保留原文，旧内容快满时自动压成摘要。
Takeaway: 这四种方式的差别，不在于谁更高级，而在于你更怕丢细节、怕超预算，还是怕长任务断线。
Architecture Notes
从系统设计角度看这个维度
这一部分补充的是更偏 memory system design 的视角：不只看概念本身，而是看这些机制在真实系统里应该放在哪一层、如何被组织、如何被观测。
短期记忆离推理回路最近，几乎每一轮都会直接参与 prompt 组装。
工程上，它往往要和对话状态、工具输出、临时任务状态一起争抢 L_context 预算。
如果用了 summary pipeline，就要先想清楚：什么时候开始总结、总结哪一段、原文还要不要保底留一份。
如果采用的是 LangChain 一类现成抽象，还要特别注意窗口参数 `k`、以及摘要触发阈值这类关键参数怎么调。
Misconceptions
这一章最容易被误解的地方
误解一：上下文窗口越来越大，短期记忆就不重要了。
误解二：只要把最近所有内容都塞进去，模型自然会自己抓重点。
误解三：摘要一定比原文高级，实际上摘要很可能丢掉最关键的细节。
Deep Dive
展开理解这个维度
为什么短期记忆本质上是上下文管理问题
短期记忆重要，不是因为系统想无上限地记更多，而是因为 LLM 的上下文窗口 L_context 有硬上限。最近发生的事如果没管好，代理做着做着就会忘记自己刚刚干了什么。
- 如果最近窗口过短，agent 会表现出“听不懂自己刚做过什么”。
- 如果最近窗口过长，旧状态、闲聊和工具日志会淹没当前目标。
- 因此短期记忆的关键不是越长越好，而是让最可能影响下一步推理或动作的信息保持可见。
3 个基础机制 + 1 个关键混合机制，分别在做什么
短期记忆如果从工程实现看，最清楚的理解方式不是只停在三个抽象词，而是拆成 3 个基础机制加 1 个关键混合机制。它们都在处理同一个现实问题：最近历史很有用，但上下文装不下那么多。
- Conversation Buffer 像全量日记，什么都留着，细节最全，但也最占地方。
- Conversation Window 像便利贴，只保留最近几条，预算稳定，但早期内容会被撕掉。
- Conversation Summary Memory 像周报，不留原文，只留总结，最省空间，但信息损耗最大。
- Conversation Summary Buffer 像智能笔记本，近期保留原文，远期自动压缩，通常是最实用的折中。
如何选择合适的短期记忆机制
没有一种短期记忆适合所有代理。真正该看的，不是框架里这个类叫什么，而是你的任务到底有多依赖最近几轮的细节，以及要连续跑多久。
- 简短、近乎无状态的查询：Conversation Buffer 往往已经足够。
- 只依赖最新几轮上下文的任务：Sliding Window 更高效。
- 如果你只想保核心结论、并能接受不回看原文：Conversation Summary Memory 会更轻。
- 需要较远上下文的长对话或多步骤任务：Summary Buffer 或 recent raw + rolling summary 往往更必要，但必须接受额外成本和摘要误差。
从系统设计角度看短期记忆的真实权衡
短期记忆设计绕不开三组现实取舍：保留原文越多，上下文越紧；压缩得越狠，越可能失真；上下文越长，成本和延迟通常越高。
- 保真度越高，越接近原始历史，但越容易顶满上下文窗口。
- 压缩程度越强，越能节约 token，但越可能丢掉细节和约束。
- 纯 Summary 路线最省空间，但也最容易把原始证据压没。
- 因此很多系统最后会采用“最近原文 + 更早摘要”的折中结构，而不是完全依赖某一种机制。
Failure Modes
常见失败模式
只用会话缓冲区，导致上下文长度、成本和延迟快速失控
只保留窗口，导致跨十几轮任务时频繁忘前文
只保留摘要，导致原始证据消失、精确细节和数字逐步漂移
工具输出不分层，导致短期记忆被 observation 日志噪声淹没
混合策略阈值没调好，结果摘要过早触发，近期细节被不必要地压缩
Previous Chapter
已经是第一章
这一章前面没有别的章节了，可以继续往后读，或者返回总览。
Next Chapter
2. Long-term Memory
长期记忆怎么存
看记忆底层表示如何承接不同信息类型