（三）Agent 记忆模块
解读 AWS 系列（三）——记忆为何是刚需、记忆管理的四个决策面、以及主流框架各自的关键设计。
业界实践解读 · 对应 ETCLOVG C 层（上下文与记忆）。以下是对原文的解读，保留其核心概念、 关键指标与设计决策；完整叙述、代码与架构图请读原文：https://aws.amazon.com/cn/blogs/china/agentic-ai-infrastructure-deep-practice-experience-thinking-series-three-best-practices-for-agent-memory-module/
记忆为什么不是可选项
原文先把问题钉死：大模型本质无状态，每次交互都是”第一次见面”。它由此推出记忆之所以刚需的四条约束——而这四条恰好是 理解后面所有设计的地基：
- 上下文窗口是硬上限：所有输入都得塞进有限窗口，一旦超出就”遗忘”、无法再访问。
- 多轮/复杂任务难连贯：尤其 Agent 场景，工具定义与工具返回值都占上下文、交互轮数又远多于普通对话，遗忘来得更快。
- 无法个性化：不记用户历史偏好，服务永远像初次接触。
- 长上下文的代价：不是”窗口越大越好”——推理变慢、超长上下文里检索关键信息的能力会下降、token 费用随长度累积。
所以记忆系统的目标不是”存更多”，而是在有限窗口之外，把该记的信息高效地留住、又能高效地取回——并借此实现持续知识 更新、个性化、复杂任务追踪、以及靠反思从错误中学习。
两类记忆：区别在”存在哪”
原文按人类记忆类比分两类，关键差异是存储位置：短期/工作记忆活在上下文窗口里（会话缓冲的滚动窗口 + 当前任务的 中间结果/变量），因此受窗口限制、只适合简单单一任务；长期记忆活在外部存储里（摘要记忆、结构化知识库/知识图谱、 向量化存储），因此能跨会话跨任务累积经验，是知识密集与长期个性化的基础。这条”短期在窗内、长期在窗外”的分界，是所有记忆 架构的第一性原则。
记忆管理的四个决策面
原文把”设计一个记忆系统”拆成四个必须回答的问题，每个都是一个设计决策：
- 记忆产生——记什么？ 不是所有对话都值得长期保存。原文给出判断的五个维度：时间、空间、参与者状态、意图上下文、 文化上下文；并按场景落地（代码助手记项目结构/命名风格/技术栈；客服记历史故障与方案；个人助理记日程/行为模式；推荐记 显式与隐式反馈）。核心洞察是：记忆是与任务相关、对后续交互有价值的信息，而非对话流水账。
- 记忆存储——怎么组织？ 采用用户→会话→记忆片段三层结构：用户层分账号空间、会话层隔离上下文、片段层存内容 + 元 数据（时间/关键词/来源）。这个三层不是随意的——它同时服务隔离（安全）与检索（效率）。
- 记忆检索——怎么取回？ 基于当前意图，用关键词匹配 + 向量语义搜索 + 元数据过滤，按相关度排序后注入上下文。检索质量 直接决定注入的上下文相不相关。
- 记忆策略——何时写入？ 两种触发：轮数触发（每 3–5 轮自动摘要存入）或事件触发（完成任务、场景转换等关键节点）； 并支持用户主动标记与删除，把数据控制权交回用户。
原文还给了一个可操作的例子：长文档处理 Agent 在上下文超限时触发 LLM 压缩，提示词明确要求”保留文件路径/章节名/待办状态、 省略对话元素、以要点组织”——这说明压缩不是无差别砍字，而是按任务保留可操作信息。
上下文工程与记忆：仓库与调度员
原文点出二者的共生关系，一句话最传神：记忆是”信息仓库”，上下文工程是”智能调度员/优化器”——记忆负责存（历史对话、 知识、偏好），上下文工程负责决定”从仓库里取哪些、怎么组织后喂给 LLM”。它把上下文工程的组件分三类：检索与生成、处理（长 序列/自我完善/结构化集成）、管理（记忆层次/压缩/优化）。原文的 500+ 页文档项目正是这套思路的实证：分块存盘 + 逐块摘要 + Agent 动态调取相关块 + 任务完成后释放不再需要的上下文——在超出模型窗口的前提下仍保住高准确率。
主流框架：各自押注了什么
原文比较四种方案，理解它们的差异要看各自的关键设计决策：
- Mem0（开源）——押注”智能记忆管理而非简单存储”。最有辨识度的是双 LLM 架构：一次调用专注信息提取、一次专注 更新决策，分工以提准确；再配上下文感知处理（在现有记忆语境里分析新数据、防碎片化）、智能去重（向量相似度 + LLM 判断）、 冲突解决。可接 Bedrock（Claude/Titan）、Aurora PostgreSQL/OpenSearch（向量）、Neptune（图），Strands 内置 mem0_memory 工具。
- Letta（前身 MemGPT）——押注”把 LLM 代理当操作系统”的虚拟内存类比：双层记忆——上下文内（系统指令 + 可读写记忆块 + 当前对话）与上下文外（历史与外部知识）；窗口将满时自动把对话压成递归摘要存为记忆块、保留原始对话供检索，用 core_memory_append/replace 与 recall 编辑与召回。可对接 Bedrock + PostgreSQL/OpenSearch + ElastiCache + Lambda。
- LangMem（LangChain）——押注”借人类记忆学分三类”：语义记忆（客观事实/偏好，嵌入系统提示，Collection 存全量或 Profile 存最新）、情节记忆（交互经历含完整上下文与推理，构建用户提示）、程序记忆（“如何做”的实操知识，持续优化行为）。 主与 LangGraph 集成、支持 Bedrock。
- Bedrock AgentCore Memory（托管）——押注”免运维、一键集成”。短期记忆记会话最近几轮、长期记忆从对话异步提取 结构化知识跨会话保留；架构分短期层（原始事件）与长期层（提取的概要知识）。它把”如何把对话转成长期记忆”做成可插拔的 记忆策略：SemanticMemoryStrategy（抽事实）、SummaryMemoryStrategy（会话摘要）、UserPreferenceMemoryStrategy（用户 偏好），还支持 CustomMemoryStrategy（自定义提示词 + 指定模型）。用 CreateEvent 存事件后策略自动异步触发、生成带唯一 ID 与命名空间/类型的长期记忆记录；使用侧 list_events 取短期、retrieve_memories 语义查长期。最值得记住的一个设计是 Memory as tool——把记忆经 AgentCoreMemoryToolProvider 注册成工具，让模型用 retrieve/record 动作自主决定何时读写 （可经 MCP），把上下文管理的主动权交给 Agent。所有数据加密存储、按 namespace 隔离。
原文结语的立场很鲜明：记忆应被视作 AI 智能体的基础而非可选项——无记忆的 Agent 每次都从零开始，有记忆才谈得上认知 连续性。
本页是对原文的解读，保留其核心概念/指标/决策；完整叙述、代码与架构图请以 AWS 原文 为准。