发帖
雷达卡
深度解读Google Context Engineering中的会话与记忆机制
在当今大型模型技术如日中天的情况下，有一个显而易见但经常被忽略的问题浮现出来：模型如何真正理解“你”？虽然我们已经习惯了与ChatGPT、Claude或国内的大模型进行交流，这些模型能够回答百科全书式的问题、编写代码，甚至与你闲聊。然而，如果你今天告诉它你喜欢咖啡，第二天再问“上次我说喜欢哪种饮料”，它很可能会显得困惑——这并不是因为它的智力有限，而是因为它并没有‘记住’这些信息。
Google在其最新的技术白皮书《Context Engineering: Sessions, Memory》中提出了一种革命性的解决方案——上下文工程。这一方法正在重新定义如何构建具备长期记忆的人工智能代理。这不仅是一项技术上的优化，更是在根本上改变了人工智能与人类交互的方式。设想一下，一个能够记住你的所有偏好、学习你的习惯的个性化助手，而不仅仅是一个重复回答相同问题的聊天机器人。这就是上下文工程所承诺的未来。
从提示工程到上下文工程的演变
传统的提示工程主要集中在设计完美的系统指令上，这就好比给厨师提供了一份固定的食谱。而上下文工程则更像是为厨师准备了一个完整的厨房——动态地组合所有必要的工具、食材和知识，确保每次都能制作出个性化的美食。由于大型语言模型（LLM）本质上是无状态的，其推理能力仅限于单次API调用的“上下文窗口”。因此，出现了一个根本性的问题：为了完成任务，智能代理需要操作指令、推理数据以及当前的对话信息。上下文工程正是为了解决这个问题而诞生的——通过动态构建和管理上下文窗口中的信息，使AI代理能够记忆、学习并实现个性化的交互。
这个过程可以概括为一个持续的循环：
- 获取上下文：代理检索用户记忆、RAG文档和最近的对话事件
- 准备上下文：动态构建完整的提示词
- 调用LLM和工具：迭代生成最终响应
- 上传上下文：将新信息异步保存到持久存储
这一流程的核心在于两个基本组件：会话（Sessions）和内存（Memory）。理解它们的区别和协作方式，对于掌握上下文工程至关重要。
会话：AI的“工作台”
会话可以被视为AI代理的临时工作区，类似于为特定项目准备的办公桌。它包含了当前对话所需的所有工具、笔记和参考资料，一切都可以即时访问，但具有临时性和特定任务性质。技术上，会话封装了单个连续对话的即时对话历史和工作内存。每个会话都与特定用户绑定，包含两个关键组成部分：
- 事件（Events）：构成对话的基本单元，包括用户输入、代理响应、工具调用及工具输出。这些事件的结构类似于Gemini API中的Content对象列表，每个条目代表对话中的一个回合。
- 状态（State）：结构化的“工作内存”或草稿本，用于保存与当前对话相关的临时结构化数据，如购物车中的商品。
在生产环境中，会话管理面临三个主要挑战：安全隐私、数据完整性和性能。严格的数据隔离是确保安全的核心原则——每个会话由单一用户拥有，系统必须通过ACL等机制确保用户之间的数据隔离。处理个人身份信息（PII）的最佳实践是在数据写入存储之前进行脱敏，从而大大降低数据泄露的风险。
随着对话的进行，会话历史记录会不断增加，这带来了上下文窗口限制、API成本增加、延迟上升和质量下降等一系列挑战。因此，会话管理的一个核心技巧就是压缩策略。
会话压缩
正如精明的旅行者打包行李时的目标不是携带尽可能多的东西，而是只携带必需品一样，常见的会话压缩策略包括：
- 保留最近N轮对话（滑动窗口）
- 基于令牌的截断（例如不超过4000个令牌）
- 递归摘要（使用AI生成的摘要替换旧对话）
例如，ADK框架通过内置插件实现了会话截断功能：
from google.adk.apps import App
from google.adk.plugins.context_filter_plugin import ContextFilterPlugin
app = App(name='hello_world_app', root_agent=agent, plugins=[
# 保留最近10轮对话和最新用户查询
ContextFilterPlugin(num_invocations_to_keep=10),
])压缩触发机制的设计也非常关键，可以基于令牌数量或轮数阈值、时间（用户停止交互一段时间后）或事件（检测到任务完成时）。重要的是，成本较高的操作（如递归摘要）应该在后台异步执行，以免影响用户体验。
内存：AI的“档案库”
如果说会话是临时的工作台，那么内存就是精心整理的档案库。工作完成后，你不会把整个凌乱的桌面都塞进储藏室，而是审查材料，丢弃草稿，只将最重要的文件存入标有标签的文件夹中。内存是一种跨会话的长期持久性机制，它从对话中提取有价值的信息，为未来的交互提供连续的个性化体验。内存与会话之间存在着共生关系：会话是生成内存的主要数据来源，而内存则是管理会话规模的关键策略。
内存的价值体现在以下几个方面：
- 个性化：记住用户的偏好、事实和过去的交互
- 上下文窗口管理：通过创建摘要或提取关键事实来压缩历史记录
- 数据挖掘：分析多用户记忆以获得洞见（在保护隐私的前提下）
- 代理自我改进：创建关于自身性能的过程记忆
内存管理系统是由多个组件协同工作的结果：
- 用户提供原始数据
- 代理（开发者的逻辑）配置记忆的内容和时机
- 代理框架提供结构和工具
- 会话存储保存原始对话
- 内存管理器处理存储、检索和压缩
内存管理与RAG（检索增强生成）的关键差异及其应用
内存管理和RAG（检索增强生成）在功能上有着本质的区别。RAG类似于一个研究图书管理员的角色，它能够从一个静态且共享的知识库中检索出事实性的信息；而内存管理则像是一位私人助理，记录着每位用户的交互细节。为了成为一个高效的AI代理，这两种能力都是必不可少的——RAG提供了广泛的世界知识，而内存则帮助深入理解用户。
内存的生成：从数据到洞察的转化
内存生成是一个将原始对话数据转化为结构化、有深度见解的过程，可以将其理解为一种基于大语言模型的ETL（提取、转换、加载）流程。
提取阶段
这一阶段的核心问题是：“对话中的哪些信息值得被记住？”这不是简单的摘要过程，而是一个智能化的筛选过程，旨在区分重要的事实、偏好和目标（信号）与那些无关紧要的客套话和填充文本（噪声）。“有意义”这一概念完全取决于代理的具体应用场景。例如，客户支持代理需要记住的信息（如订单号、技术问题）与个人健康教练需要记住的信息（如长期目标、情绪状态）就截然不同。内存管理系统通过编程护栏和指令来定义提取的内容，常用的方法包括：
- 模式和模板提取（利用JSON模式或结构化输出）
- 自然语言主题定义
- 少样本提示（通过示例展示提取模式）
整合阶段
这是整个过程中最为复杂的一部分，涉及将新获取的信息整合进一个连贯、精确并且持续发展的知识库中。缺乏有效的整合，代理的内存可能会迅速变得混乱、矛盾且不可靠。整合阶段需要解决的主要问题包括信息的重复、冲突信息的处理、信息的演变以及旧记忆的相关性衰减。这一过程由大语言模型驱动，通过对比新提取的洞见与现有的记忆，决定是否更新、创建或删除某些条目，从而确保知识库的质量。
内存的来源可信度
内存的来源可信度极为重要。代理系统需要追踪每个信息来源的详细情况（例如来源类型和“新鲜度”），这些因素将影响在整合过程中的权重分配以及在推理时对特定记忆的依赖程度。常见的来源类型包括：
- 引导数据（从CRM等内部系统预先加载，具有高可信度）
- 用户输入（显式提供的信息如填写表单，具有高可信度；隐式提取的信息，可信度较低）
- 工具输出（来自外部工具调用的结果，通常较为脆弱且容易过时）
内存检索与推理：在正确时间找到正确信息
一旦建立了生成机制，智能检索策略就显得尤为重要。检索策略决定了哪些记忆应当被检索以及何时进行检索。对于一个记忆集合来说，检索是一个复杂的搜索问题，目的是在庞大的非结构化数据池中找到最相关、概念上最接近的信息。高级系统通常会从以下几个维度评估潜在的记忆：
- 相关性（语义相似性）：与当前对话概念上的关联度
- 新鲜度（基于时间）：记忆创建的时间距离现在有多远
- 重要性（显著性）：记忆在整个对话中的关键程度
仅仅依靠基于向量的相关性评分可能会导致找到的是概念上相似但已经过时或不重要的记忆。因此，最有效的策略是结合以上三个维度的综合方法。
检索时机
关于检索的最佳时机，主要有两种方法：
- 主动检索：在每次对话轮次开始时自动加载记忆，确保上下文始终可用，但可能会为无需访问记忆的轮次带来不必要的延迟
- 反应式检索（内存即工具）：赋予代理查询记忆的工具，使其能够根据需要自行决定何时检索上下文，这种方法更为高效，但需要额外的大语言模型调用
记忆的呈现方式
检索到的记忆需要战略性地放入模型的上下文窗口中。记忆可以通过以下两种方式呈现：
- 系统指令中追加：适合于稳定、“全局”的信息（如用户档案），给予记忆较高的权威性，并清晰地区分上下文与对话
- 对话历史中注入：将检索到的记忆直接加入逐轮的对话中，可以在完整对话历史之前或最新的用户查询之前插入
在特殊情况下，也可以通过工具调用来检索记忆，此时记忆会作为工具的输出直接包含在对话中。
生产环境考量：从原型到企业级应用
将支持内存的代理从原型过渡到生产环境时，需考虑企业级架构的问题。生产级别的系统不仅要具备智能，还要具备企业级的稳健性。
为了确保用户不会因计算成本高昂的内存生成过程而感到延迟，强大的架构设计需要将内存处理与主应用程序逻辑分离。这通常通过直接的、非阻塞的API调用至专门的内存服务实现，而不是通过自我管理的消息队列。
随着应用规模的增长，内存系统必须能够处理高频事件而不出现故障。面对并发请求时，系统需要避免多个事件试图同时修改同一块内存而导致的死锁或竞争条件。这些问题可以通过事务型数据库操作或乐观锁机制来缓解，尽管这可能在多个请求试图同时修改同一块内存时引入排队或限制。
内存服务还需具备处理瞬时错误的能力（故障恢复）。如果大语言模型调用失败，系统应采用指数退避的重试策略，并将永久性故障路由到死信队列以供后续分析。
对于全球范围的应用，内存管理系统应使用带有内建多区域复制功能的数据库，以确保低延迟和高可用性。客户端复制不可行，因为整合过程需要数据的单一、事务一致性视图以防止冲突。
安全与隐私：构建可信的内存系统
内存系统基于用户数据生成并存储，因此必须实施严格的数据隐私和安全控制。一个有用的比喻是将内存系统视为由专业档案管理员管理的安全企业档案库，其职责不仅是保护有价值的知识，还包括保护公司的信息安全。
该档案库的基本原则之一是数据隔离。就像档案管理员不会混淆不同部门的机密文件一样，内存也必须在用户或租户层面严格隔离。服务一个用户的代理不应访问另一个用户的记忆，这一点通过限制性访问控制列表（ACL）来强制执行。
在提交任何文件之前，档案管理员需执行重要的安全措施。首要步骤是对每一页进行仔细审查，以去除敏感的个人身份信息（PII），确保在保留知识的同时避免潜在的责任问题。此外，档案管理员接受过专门培训，能够辨识并销毁伪造或故意误导的信息，从而防止系统的污染。
当多个用户共享同一组记忆（如程序性记忆）时，可能存在信息泄露的风险。例如，若一用户的程序性记忆被用作另一用户的参考案例，档案管理员必须先实施严格的匿名化处理，以防止敏感信息在不同用户间泄露。
未来展望与开放议题
上下文工程，尤其是对话和记忆管理系统的开发，标志着人工智能代理发展的重大进步。随着这些技术的不断成熟，有几个核心问题值得深入研究：
多代理合作中的记忆共享标准
目前，由不同架构构建的代理因内部数据表达方式的差异，难以实现记忆的无缝共享。Agent-to-Agent (A2A) 通信等新型模式显示出了希望，但要实现真正的互操作性，还需要制定行业标准。
程序性记忆与陈述性记忆的整合
“如何做”的程序性记忆与“知道什么”的陈述性记忆的融合，构成了另一个前沿研究领域。尽管现有的记忆管理系统主要关注陈述性记忆，但程序性记忆——即提升代理工作流程和推理能力的机制——需要一套独立的算法生命周期。
评估框架的发展
尽管白皮书中提出了诸如精度、召回率和F1分数等质量指标，以及任务完成度指标，但如何全面评估记忆系统对代理整体智能的贡献，依然是一个未解之谜。
总之，上下文工程的成功不仅依赖于技术创新，还依赖于我们应对隐私、安全及伦理考量的能力。随着AI代理的记忆能力和个性化程度不断提高，确保这些系统能够透明且受控地运行变得尤为重要。
会话和记忆管理系统正推动着AI从单纯的对话工具向真正的个人助手转型。这一变革的核心在于理解智能不仅在于‘知道什么’，更在于‘记住谁’，以及如何运用这些知识提供有意义的情境感知帮助。对于开发者而言，掌握这些技术意味着能够创建出更加智能化、体贴且实用的AI体验。
近年来，经济形势下滑，IT行业面临着经济周期波动和AI产业结构调整的双重压力，许多人因此遭遇裁员或减薪，处境艰难。然而，行业的低谷往往伴随着上升的机会，目前AI大模型的发展势头良好。虽然大模型已成为热门话题，但许多初学者苦于找不到合适的入门途径。现在，我在此平台上发现了一份非常适合新手学习大模型的资料。有兴趣深入了解和学习大模型的朋友，可以通过此链接访问：查看学习资源。
京公网安备 11010802022788号
