Memory和RAG的区别在哪？用「上下文工程」做出个性化 AI（谷歌白皮书精读）

谷歌在第三天发布了《上下文工程：会话与记忆》(Context Engineering: Sessions & Memory) 白皮书。文中开篇指出，LLM模型本身是无状态的 (stateless)。如果要构建有状态的（stateful）和个性化的 AI，关键在于上下文工程。

具体来讲，LLM 的所有推理和意识都局限于单个 API 调用中提供的信息，即“上下文窗口”为了让 AI智能体（Agent）能够记住用户、学习偏好并个性化交互，开发者必须在每一次对话中动态地构建和管理这个上下文。这个动态组装和管理信息的过程，就被称为上下文工程 (Context Engineering)。与Prompt Engineering的区别在于：

• 提示工程：专注于制作最优的、通常是静态的系统指令。
• 上下文工程：则是一个动态的过程，它负责为 LLM 动态组装和管理整个有效载荷 (payload)，包括指令、工具、外部数据，以及最重要的——历史和记忆。

这份白皮书为我们提供了一张宝贵的架构蓝图。它警告说，一味追求更大的上下文窗口并不能解决根本问题——它只会带来更高的成本、更慢的延迟，以及一种被称为 “上下文腐烂” (context rot) 的现象，即模型在过长信息中的注意力会逐渐下降。

真正的解决方案是构建一个智能系统。这份文档将这个系统清晰地解构为两个协同工作的核心基石，并引入了一个贯穿始终的绝妙比喻：

1. 会话 (Session)：是临时的“工作台” (Workbench)。
2. 记忆 (Memory)：是持久的“文件柜” (Filing Cabinet)。

本文将深入解读这份白皮书的精髓，详细拆解构建一个真正“有记性”的智能系统所需的两大基石，以及它们之间复杂的协同机制。关于之前的内容，感兴趣您可以看下《谷歌的两个5天课程都讲了什么，介绍一下这9+N份白皮书 ｜最新》

基石一：会话 (Sessions) 

“会话”是上下文工程的基础，是智能体的“工作台”。

定义：一个会话封装了单次、连续对话的即时对话历史和工作记忆。它与特定用户绑定，但一个用户可以拥有多个“断开连接”的会话。

这个“工作台”上放着两样东西：

1. 事件 (Events)：即按时间顺序排列的对话历史。这是不可变的日志，包含了用户的输入、智能体的回复、工具的调用和工具的输出。
2. 状态 (State)：一个结构化的“工作记忆”或“暂存器” (scratchpad)。这是可变的，用于存放当前对话的临时数据（例如，购物车中的商品）。

“工作台”的困境：混乱与过载

这个工作台模式在生产环境中会迅速遇到三个严峻的挑战：

1. 上下文窗口限制：工作台的空间（上下文窗口）是有限的。对话历史一旦超出限制，API 调用就会失败。
2. 成本与延迟：工作台上的东西越多（token 越多），处理它的成本（API 费用）就越高，速度（延迟）也越慢。
3. 质量（上下文腐烂）：工作台上的东西太杂乱，智能体的注意力就会下降，性能变差，这就是“上下文腐烂” (context rot)。

文档将此比作一个精明的旅行者打包行李箱：你不能把所有东西都塞进去（成本高、混乱），也不能丢掉必需品（丢失关键信息）。

解决方案：压缩 (Compaction)

为了解决这个问题，我们必须在每次交互时对“会话”历史进行压缩 (Compaction)。

• 简单策略：
• 保留最近 N 轮：也称为“滑动窗口”，简单地丢弃旧信息。
• 基于令牌的截断：从最近的对话开始往回计算，直到达到 token 限制（如 4000 个 token）。
• 高级策略：
• 递归摘要 (Recursive Summarization)：这才是通向“记忆”的桥梁。系统使用 LLM 将对话中较早的部分替换为一个AI生成的摘要。这个摘要本身，就是一种原始的“记忆”。

会话的生产级挑战：隔离与互操作性

在将“会话”推向生产环境时，白皮书强调了两个必须解决的非功能性需求：

1.安全与隐私：这是不可协商的。

• 严格隔离：系统必须通过 ACLs（访问控制列表）强制执行，确保一个用户永远不能访问另一个用户的会话数据。
• PII 删减：最佳实践是，在会话数据被写入存储之前，就使用 Model Armor 这样的工具自动编辑掉所有 PII（个人身份信息）。

2.多智能体互操作性 (Interoperability)：

• 问题：在一个多智能体系统中，不同的智能体框架（如谷歌的 ADK 或 LangGraph）使用各自私有的、不兼容的对象来定义“会话”。
• 后果：这导致了架构孤岛，ADK 智能体无法原生理解 LangGraph 智能体的会话历史。
• 解决方案：这迫使我们寻找一个更高阶的解决方案，将共享知识抽象到一个“与框架无关的数据层” (framework-agnostic data layer)。

这个与框架无关的、用于持久化和共享知识的通用层，就是“记忆”。

基石二：记忆 (Memory) 

如果说“会话”是临时的“工作台”，那么“记忆”就是精心组织的“文件柜”。

定义：记忆是从对话或数据源中提取的、有意义的信息快照。它不是原始的逐字稿，而是跨多个会话持久化的、浓缩的知识。

“会话”是“记忆”的主要数据来源。当一个项目在“工作台”（会话）上完成后，你不会把整个凌乱的工作台塞进存储。相反，你会“创建记忆”——丢弃草稿，只把最终的、关键的文件归档到“文件柜”（记忆）中。

记忆的核心价值：它与 RAG 的根本区别

这是整篇白皮书中最重要的概念区分之一。记忆和 RAG（检索增强生成）都为 LLM 提供外部知识，但它们服务于完全不同且互补的目标。

文档再次使用了一个绝妙的比喻：

• RAG (检索增强生成)：是智能体的“研究图书管理员” (Research Librarian)。
• 目标：注入外部的、事实性的、共享的知识（如 PDF、文档、网页）。
• 角色：RAG 使智能体成为事实专家。
• 记忆 (Memory)：是智能体的“私人助理” (Personal Assistant)。
• 目标：创建个性化的、有状态的体验。其数据源是与用户的动态对话。
• 角色：记忆使智能体成为用户专家。

一个真正智能的Agent，既需要“图书管理员”（RAG）来了解世界，也需要“私人助理”（记忆）来了解你。

记忆的详细分类：构建“文件柜”的蓝图

白皮书从多个维度对记忆进行了详细的解构，为我们提供了构建记忆系统的完整分类法：

1.按信息类型 (Information Type)：

• 陈述性记忆 (Declarative)：“知道什么” (Knowing what)。这是关于事实、数据和事件的知识（例如，“用户的座位偏好是靠窗”）。
• 程序性记忆 (Procedural)：“知道如何” (Knowing how)。这是关于技能和工作流的知识（例如，“预订航班的正确工具调用顺序”）。

2.按组织模式 (Organization Patterns)：

• 集合 (Collections)：一组独立的、自然语言的记忆事实（“用户喜欢A”，“用户住在B”）。
• 结构化用户画像 (Structured User Profile)：像一张不断更新的“联系人卡片”，存储核心事实（{"seat_preference": "window"}）。
• 滚动摘要 (Rolling Summary)：一个单一的、不断演变的自然语言摘要，代表整个用户关系。

3.按存储架构 (Storage Architectures)：

• 向量数据库：最常见的，用于语义相似性搜索（查找概念上相关的记忆）。
• 知识图谱：存储实体和它们之间的关系（查找结构化连接的记忆）。

4.按范围 (Scope)：

• 用户级 (User-Level)：最常见的，用于实现跨会话的个性化。
• 会话级 (Session-Level)：主要用于对话压缩，记忆只与该特定会话相关。
• 应用级 (Application-level)：所有用户共享的全局上下文，常用于存储程序性记忆（即智能体的“操作手册”）。

记忆的生命周期：一个 LLM 驱动的 ETL 管道

这部分是白皮书的技术核心。它揭示了“记忆管理器” (Memory Manager) 不是一个被动的数据库，而是一个主动的、由 LLM 驱动的 ETL (Extract, Transform, Load) 管道。

这个自动化的 ETL 流程，正是记忆管理器的核心价值所在。

步骤一：提取 (Extraction) —— 从噪音中分离信号

• 目标：回答“这段对话中，什么信息才算有意义，值得被记住？”。
• 挑战：这是一个过滤过程，旨在从对话“噪音”（如寒暄、废话）中分离出“信号”（如事实、偏好、目标）。
• 方法：记忆管理器使用一个 LLM，并通过“主题定义” (topic definitions) 来指导它。
• 技术实现：

1. 模式/模板 (Schema)：强制 LLM 输出结构化的 JSON。
2. 自然语言：用自然语言描述主题（例如，“提取用户对咖啡店氛围的反馈”）。
3. 小样本提示 (Few-shot)：提供输入对话和理想输出记忆的示例，让 LLM 从中学习模式。

步骤二：整合 (Consolidation) —— 文件柜的“自我策展”

这是整个生命周期中最复杂、最智能的阶段。

• 目标：在将新信息存入文件柜之前，必须进行策展，以解决信息重复、信息冲突和信息演变的问题。
• 为什么必须？ 否则，文件柜会迅速变得混乱和不可信。例如：
• 冲突：用户今天说 “我喜欢靠窗座位”，而记忆中有一条“用户喜欢靠走道座位”。
• 演变：记忆中是“用户对营销感兴趣”，新信息是“用户正在领导一个 Q4 获客项目”。
• 流程 (Workflow)：

1. 检索：获取与“新提取的记忆”相似的“已存在的记忆”。
2. 分析：LLM 同时分析“已存在的记忆”和“新提取的记忆”。
3. 决策：LLM 决定执行哪个操作：

• UPDATE (更新)：用新信息修改或扩充旧记忆。
• CREATE (创建)：如果信息是全新的。
• DELETE / INVALIDATE (删除/失效)：如果旧记忆被新信息明确推翻。

1. 存储：执行数据库事务。

关键机制：记忆溯源 (Memory Provenance) —— 建立信任

为了让“整合”阶段能智能地解决冲突，系统必须知道每条记忆的可信度。

• 问题：经典的“垃圾输入，垃圾输出”，在 LLM 时代变成了“垃圾输入，自信的垃圾输出”。
• 解决方案：追踪每条记忆的来源 (Provenance)，并建立一个“信任层级” (Hierarchy of Trust)。
• 信任排序：

1. 高信任：引导数据 (Bootstrapped Data)。例如，从公司 CRM 系统预加载的用户数据。
2. 中信任：显式用户输入。例如，用户明确说“记住我的生日是 10 月 26 日”。
3. 低信任：隐式推断。例如，从“我下周要为我的周年纪念日买礼物”中推断出周年纪念日。

• 应用：
• 在整合时：用于解决冲突。当 CRM 数据（高信任）与对话推断（低信任）冲突时，系统应优先信任 CRM 数据。
• 在推理时：将“置信度分数”连同记忆一起注入提示词。这样 LLM 自己就能判断该在多大程度上依赖这条记忆。

生产中的记忆：架构、检索与推理

白皮书最后详细阐述了在生产环境中实现记忆系统的架构决策。

写入路径 (Generation)：异步是铁律

• 核心原则：记忆生成（提取和整合）是一个昂贵的操作，涉及 LLM 调用和数据库写入。
• 架构：它绝不能阻塞用户体验。因此，记忆生成必须始终作为异步（后台）进程运行。
• 流程：智能体立即响应用户，然后“推送”对话数据到记忆管理器，后者在后台排队处理。

读取路径 (Retrieval)：何时以及如何检索？

• 寻找什么？一个好的检索策略不只看相关性。它必须是一个混合分数，平衡了：

1. 相关性 (Relevance)：与当前话题的语义相似度。
2. 新近度 (Recency)：记忆是何时创建的。
3. 重要性 (Importance)：这个记忆有多关键。

• 何时检索？（两大模式）

1. 主动式检索 (Proactive Retrieval)：在每轮对话开始前自动检索记忆。

• 优点：上下文始终可用。
• 缺点：如果这轮对话不需要记忆，就会浪费延迟。

1. 反应式检索 (Reactive Retrieval) / “记忆即工具”：智能体（LLM）在对话中自己决定何时需要信息，并主动调用一个 load_memory 工具来查询。

• 优点：更高效，只在需要时才产生延迟。
• 缺点：需要额外的 LLM 调用（“思考”步骤）来决定是否使用工具。

推理 (Inference)：记忆放在上下文的哪里？

• 方式一：放入系统指令 (System Instructions)。
• 优点：适合放用户画像等“全局”信息。上下文和对话历史被清晰分开。
• 缺点：有“过度影响”的风险（LLM 可能强行将所有话题与该记忆关联）。且无法与“反应式”检索（即工具）兼容。
• 方式二：放入对话历史 (Conversation History)。
• 优点：这是“反应式”工具调用的自然结果（工具的输出本就是历史的一部分）。
• 缺点：有“对话注入”风险（LLM 可能误认为这条记忆是用户或它自己说过的某句话）。

终极挑战：安全与未来

最后，这份文档以严谨的态度探讨了生产系统必须面对的残酷现实。

• 评估 (Evaluation)： 一个记忆系统必须在三个层面被评估：

1. 生成质量 (Precision/Recall)：智能体是否记住了“正确”的事情？
2. 检索性能 (Recall@K, Latency)：智能体能否“快速”找到它需要的东西？
3. 端到端任务成功率：记忆到底有没有用？ 使用一个 LLM “裁判” (judge) 来评判最终结果。

• 安全 (Security) —— 首要原则：

1. 严格隔离 (Strict Isolation)：这是首要规则。一个用户的智能体绝对不能访问另一个用户的记忆。
2. PII 删减：必须在数据持久化之前完成。
3. 记忆投毒 (Memory Poisoning)：这是最大的威胁之一。系统必须有防护措施（如 Model Armor），防止恶意用户通过提示注入 (Prompt Injection) 来故意污染或篡改智能体的长期记忆。

结论

谷歌的这份《上下文工程：会话与记忆》白皮书，清晰地定义了实现“有状态” AI 的两大核心组件，临时的“工作台”（会话）和持久的“文件柜”（记忆）。它不仅提供了蓝图，更深入到了 ETL 管道、信任层级、异步架构和安全模型的实现细节中。希望这篇文章能让您对Context Engineering拥有更深层的理解，所有资料我将在群里分享，欢迎来聊。

文章来自于“AI修猫Prompt”，作者 “AI修猫Prompt”。