AI之Course之Context Engineering：会话与记忆 —— 学习构建能记住历史交互、保持上下文的AI智能体。掌握短期与长期记忆的实现方式，以创建能够处理复杂多轮任务的鲁棒智能体—构建有状态 LLM Agent 的会话（Sessions）与记忆（Memory）全栈指南
导读：本文章聚焦如何把无状态的大语言模型（LLM）构造成“有状态、可记忆、可协作”的智能体（Agent）。核心命题是：仅靠单次 prompt 已无法支撑长期化、个性化与跨任务的智能行为，必须把“上下文工程（Context Engineering）”作为系统化工程——在每次调用前动态构造上下文（system 指令、会话历史、工具定义、外部事实与记忆片段），并在调用后把有价值信息提炼回写为长期记忆，用以支撑未来决策与个性化体验。
>> 技术要点与工程实践亮点—白皮书在工程层面给出了一整套可落地方法：
把上下文处理拆成 Fetch → Prepare → Invoke → Upload 的热/冷路径流水线；
把会话（Sessions）视为包含事件流与短期 state 的工作台，强调会话持久化、PII redact、顺序一致性与 compaction（滑动窗口、token 截断、recursive summarization）策略；
把记忆（Memory）视为可检索的语义单元，细分声明性/程序性/多模态类型，提出用 schema/few-shot 指导抽取、用合并策略解决冲突、用多维排序（semantic + recency + importance + provenance）优化检索，并强调生产化要点（异步生成、溯源、置信度、隐私/删除策略及性能/成本权衡）。
此外，针对多 agent 与跨框架场景，白皮书建议以 framework-agnostic 的 Memory 层作为语义中介，避免直接共享框架特有的事件 blob，从而实现互操作与治理。
>> 受众与落地建议—本白皮书既适合技术决策者与平台工程团队（构建 Agent 平台、Session/Memory 服务与 Control Plane），也对产品经理、数据科学家与安全/合规人员有直接参考价值。落地上建议：先做小规模试点（内部 Registry + 若干被封装的工具/能力），在 MCP/工具/记忆功能之上引入 Gateway/审计/权限策略；并把“上下文规范（Context Spec）”、“记忆抽取 schema”与“compaction 策略”作为项目启动必交件，以便在扩展时保持可观测性、可审计性和成本可控。
目录
Context Engineering：会话与记忆 —— 学习构建能记住历史交互、保持上下文的AI智能体。掌握短期与长期记忆的实现方式，以创建能够处理复杂多轮任务的鲁棒智能体—构建有状态 LLM Agent 的会话（Sessions）与记忆（Memory）全栈指南
1、Introduction
核心要点：
经验 / 实战技巧：
2、Context Engineering
核心要点：
经验 / 实战技巧：
3、Sessions
核心要点（总体）：
经验 / 实战技巧（总体）：
3.1 Variance across frameworks and models
核心要点：
经验 / 实战技巧：
3.2 Sessions for multi-agent systems
核心要点：
经验 / 实战技巧：
3.2.1 Interoperability across multiple agent frameworks
核心要点：
经验 / 实战技巧：
3.3 Production Considerations for Sessions
核心要点：
经验 / 实战技巧：
3.4 Managing long context conversation: tradeoffs and optimizations
核心要点：
经验 / 实战技巧：
4、Memory
核心要点（总体）：
经验 / 实战技巧（总体）：
4.1 Types of memory
核心要点：
经验 / 实战技巧：
4.1.1 Types of information
4.1.2 Organization patterns
4.1.3 Storage architectures
4.1.4 Creation mechanisms
4.1.5 Memory scope
4.1.6 Multimodal memory
4.2 Memory Generation: Extraction and Consolidation
核心要点：
经验 / 实战技巧：
4.2.1 Deep-dive: Memory Extraction
4.2.2 Deep-dive: Memory Consolidation
4.2.3 Memory Provenance
4.2.4 Triggering memory generation
4.3 Memory Retrieval
核心要点
经验 / 实战技巧：
4.3.1 Timing for retrieval
4.4 Inference with Memories
核心要点：
经验 / 实战技巧：
4.4.1 Memories in the System Instructions
4.4.2 Memories in the Conversation History
4.5 Procedural memories
核心要点：
经验 / 实战技巧：
4.6 Testing and Evaluation
核心要点：
经验 / 实战技巧：
4.7 Production considerations for Memory
核心要点：
经验 / 实战技巧：
4.7.1 Privacy and security risks
5、Conclusion
Context Engineering：会话与记忆 —— 学习构建能记住历史交互、保持上下文的AI智能体。掌握短期与长期记忆的实现方式，以创建能够处理复杂多轮任务的鲁棒智能体—构建有状态 LLM Agent 的会话（Sessions）与记忆（Memory）全栈指南
1、Introduction
问题背景：LLM 本质上是无状态的“模式预测器”，要实现有“记忆”、可个性化的 agent，必须在每次调用前动态构造上下文——即Context Engineering。白皮书把 Sessions（单次交互工作台）与 Memory（跨会话长时记忆）作为两大核心构件。
核心要点：
>> LLM 的运行只依赖单次调用的 context window，外部持久化与检索是实现长期状态的必要条件。
>> Context Engineering扩展了传统 prompt engineering，变为“动态组装整个 payload”，包含 system instructions、few-shot、外部知识、会话历史、工具定义与 memory 等。
>> 会话（Session）和记忆（Memory）互补：Session 管理即时对话与临时 state，Memory 负责提炼并在未来注入长期上下文。
经验 / 实战技巧：
>> 在项目启动阶段先定义“Context 样板”（哪些元素必须注入：system prompt、最近 N-turn、必要 memory、必用工具），把 Context 构造列为热路径。
>> 把“上下文准备 → LLM 调用 → 后台上传/合成”视为循环流水线，尽量把耗时的 compaction/生成工作异步化。
2、Context Engineering
提出 Context Engineering 的概念、目标与操作流程（Fetch → Prepare → Invoke → Upload），以及构成上下文的具体要素与取舍原则（相关性优先、最少必要信息原则）。
核心要点：
>>构成要素：system instructions、tool definitions、few-shot 示例、evidential/factual data（RAG）、session history、state/scratchpad、memory、artifacts（非文本数据）。
>>热路径/冷路径划分：构造上下文（Prepare Context）通常是请求的热路径，必须低延迟；memory consolidation 等可后台异步执行（Upload Context）。
>>动静分离：为避免 context bloat，优先检索与选择最相关片段并对历史进行压缩/摘要。
经验 / 实战技巧：
>>先做“Context Spec”规范：列出所有可能注入的上下文类型、优先级与最大 token 配额（便于 runtime 策略决策）。
>>把外部数据（RAG）与 user-specific memory 做清晰分层：RAG 用于事实性查询，Memory 用于用户个性化信息，检索策略对两者分别优化。
Figure 1. Flow of context management for agents
3、Sessions
Session 是单次连续对话的容器，包含事件（events）（用户消息、模型回复、tool calls、tool outputs 等）与state（working memory / scratchpad）。生产系统要将会话持久化并考虑安全、数据完整性与性能。
核心要点（总体）：
>> Session 既是即时工作台（短期 context）也是生成 memory 的主要数据源；生产环境应使用持久化存储（数据库/managed session store），不能仅靠内存。
>> 事件是 append-only 日志的基本单元；state 用于短期、可变的数据（例如购物车）。
经验 / 实战技巧（总体）：
>> 生产环境使用可靠的 session 存储（保证顺序性、鉴权、ACL），在写入前对 PII 做 redact（如用 Model Armor）。
>> 热路径优化：把会话过滤/压缩作为发送给模型前的标准步骤，尽量减少网络传输与 token 花费。
3.1 Variance across frameworks and models
不同 agent 框架（例如 ADK、LangGraph）对 session/event/state 的表示与可变性差异显著——有的把 Session 作为独立对象（ADK），有的把整个 state 当作 session（LangGraph）。这些实现差异影响 compaction、互操作与迁移成本。
核心要点：
>> ADK：显式 Session object（events + state）； LangGraph：state 即 session，且可变（非 append-only），方便在内部做 compaction/转换。
>> 框架抽象是“翻译器”——将内部事件映射为模型接受的 Content（role + parts），减少 vendor lock-in。
经验 / 实战技巧：
>> 选择框架时考虑“会话导出/迁移能力”与“事件模型可读性”，以便未来跨框架互通或数据回放。
>> 如果需跨框架互操作，优先把语义数据（memory）中心化，而非直接共享框架专用的会话 blob。
Figure 2: Flow of context management for agents
3.2 Sessions for multi-agent systems
多 agent 系统中会话历史的管理有两种主流模式：共享统一历史（single shared log）与独立私有历史 + 显式通信（每 agent 保持私有日志，通过明确消息交换）。白皮书指出选择取决于任务耦合度与审计需求。
核心要点：
>>共享历史：所有 agent 写入同一 chronology log，适合强耦合任务（单一真相）。可在 sub-agent 传递前做过滤/标注。
>>独立历史 + A2A / Agent-as-a-Tool：每 agent 保留私有日志，仅通过明确 message / tool 调用交换最终输出，便于隔离与审计。A2A 协议支持跨框架消息传递。
经验 / 实战技巧：
>> 对安全/合规高的场景（含敏感数据）优先采用“独立历史 + 明确接口”模式并在 agent-to-agent 通信中加验证与签名。
>> 对高度协作、步骤链式的任务（如复杂规划），采用共享历史以保证可追踪的单一事件流，但同时在日志中标注 agent 来源与敏感度。
Figure 3: Different multi-agent architectural patterns
3.2.1 Interoperability across multiple agent frameworks
不同框架的内部数据模型导致持久化的会话记录不可直接互读。解决方案是把共享知识抽象为框架中立的 Memory 层——用 canonical（简单字符串/字典）表示的记忆实现跨框架互操作。
核心要点：
Session storage 通常耦合框架内部 schema，直接移植成本高；Memory 层作为语义中介能实现真正的跨框架协作。
经验 / 实战技巧：
在多框架系统设计早期就引入 memory manager（framework-agnostic），把共享事实/实体写入 memory 而不是会话事件。这样后续 agent 可用统一 API 检索。
3.3 Production Considerations for Sessions
生产化需关注三大领域——安全与隐私、数据完整性与生命周期、性能与可扩展性。白皮书推荐使用 managed session stores 并采取 TTL、ACL、PII redact 等措施。
核心要点：
>> 安全/隐私：严格隔离（session-level ACL）、鉴权/授权、对 PII 在写入前做 redact。
>> 数据完整性：保证事件的确定性顺序、定义保留/归档/删除策略（TTL）。
>> 性能：会话是热路径，读取/写入必须低延迟；采用过滤/压缩策略减少传输体积。
经验 / 实战技巧：
在写会话前运行 PII 探测与 redact（Model Armor 等工具），并将该流程纳入 CI。
设计 session store 的分层缓存（本地短期 cache + 中央持久层）以降低热路径延迟。
3.4 Managing long context conversation: tradeoffs and optimizations
随着对话增长，token 成本、延迟和“context rot”会影响质量。白皮书列出常见 compaction 策略（sliding window、token-based truncation、recursive summarization）与触发机制（count/time/event）。并强调昂贵操作应后台异步执行并持久化结果。
核心要点：
>>三大策略：保留最近 N turns、基于 token 截断、递归摘要（对旧段落自动摘要并替换）。
>>触发机制：计数（token/turn）、时间（非活跃）、事件（语义/任务完成）。
>>异步化：递归 summarization 等昂贵操作必须在后台运行并将摘要持久化，同时记录摘要覆盖的原始事件以便溯源。
经验 / 实战技巧：
>>推荐“滑动窗口 + 后台递归摘要”组合：热路径仅发送最近 N turns，后台并行生成并持久化旧段摘要，必要时在上下文中注入摘要。
>>记录 compaction 元数据（包含哪些事件被摘要、摘要版本），以便审计与可回溯。
4、Memory
Memory 是从会话与其他数据源中提取并持久化的“有意义信息片段”，用于跨会话的个性化、上下文管理与 agent 自我改进。Memory 管理器（Memory Bank 等）负责 extraction、consolidation、storage 与 retrieval。
核心要点（总体）：
>>Memory 与 RAG 的区别：RAG 面向静态事实库（shared），Memory 面向用户特定、动态信息（isolated per-user）。两者互补。
>>Memory 的基本单元包含 content（结构化或非结构化）与 metadata（id、owner、source、timestamp、confidence）。
>>Memory 管理需关注 provenance（溯源）、confidence（置信度）、合并/冲突解决与遗忘（pruning / TTL）。
经验 / 实战技巧（总体）：
>> 优先把频繁精确查询的字段用结构化 profile 保存（快速查找），复杂语义关联用 collection + vector search。
>> 对 memory 的每条记录保留 source_type（bootstrapped / user / tool）与 confidence，用作合并与推理权重化。
4.1 Types of memory
按形式与功能可分多类：结构化 vs 非结构化；声明性（declarative，“知道什么”） vs 程序性（procedural，“知道如何”）；按 scope 分为 user-level、session-level、application-level。
核心要点：
>> 声明性（what）：事实、偏好、实体。常用于个性化回复。
>> 程序性（how）：工作流或 playbook，辅助 agent 决策与行动序列（更接近“技能”）。白皮书指出管理程序化记忆需要专门流程。
>> 多模态：多数 memory managers 将多模态输入转换成文本洞见保存；对于直接保存二进制媒体需严格访问控制。
经验 / 实战技巧：
把用户偏好等高价值字段存为结构化 profile（快速注入 system prompt）；对程序性记忆设计专门 schema 并保持可执行/可审计。
4.1.1 Types of information
4.1.2 Organization patterns
4.1.3 Storage architectures
4.1.4 Creation mechanisms
4.1.5 Memory scope
4.1.6 Multimodal memory
4.2 Memory Generation: Extraction and Consolidation
Memory 生成是一个 LLM 驱动的 ETL：Ingest → Extract/Filter → Consolidate → Store。Extraction 用 topic definitions / schema / few-shot 指导 LLM 提取。Consolidation 负责去重、冲突解决、合并或删除。
核心要点：
>> Extraction：用 JSON schema / topic definitions / few-shot 示例引导 LLM 精准提取“有意义”信息（按 agent 目的定制）。
>> Consolidation：检索相似记忆并通过 LLM 决定 UPDATE/CREATE/DELETE，保持语义一致性与演化。
>> Pipeline：内置 memory manager（Agent Engine Memory Bank 等）可自动化上述流程并提供 API（背景/异步执行）。
经验 / 实战技巧：
>> 为关键话题准备 few-shot 示例与 schema，提升抽取准确率并降低噪声。
>> Consolidation 阶段记录溯源（哪些源贡献、时间、confidence），并把删除/更新操作作为事务执行以保持一致性。
4.2.1 Deep-dive: Memory Extraction
4.2.2 Deep-dive: Memory Consolidation
4.2.3 Memory Provenance
4.2.3.1 Accounting for memory lineage during memory management
4.2.3.2 Accounting for memory lineage during inference
4.2.4 Triggering memory generation
4.2.4.1 Memory-as-a-Tool
4.2.4.2 Background vs. Blocking Operations
4.3 Memory Retrieval
检索目标不是简单相似匹配，而是多维评分（语义相关度 + recency + importance + provenance/confidence）。检索时机可为预检（每 turn 加载）或按需（Memory-as-a-Tool）。
核心要点
>>多维排序：仅靠向量相似度会导致旧或琐碎记忆被召回，需加 recency/importance/provenance。
>>Timing：预检保证连贯但增加延迟；按需检索更节省但 agent 需有能力判定何时检索（并可能增加额外 LLM 调用）。
经验 / 实战技巧：
>> 使用“静态少量注入 + 按需深检”的混合策略：热路径注入最关键信息，其余 memory 用按需工具拉取。
>> 对于 collection 型 memory，训练或微调专用 retriever（如向量检索器或基于标签的检索）能提升 Recall@K 与质量。
4.3.1 Timing for retrieval
4.4 Inference with Memories
记忆在推理时可注入为 system instructions、conversation history、或作为 tool output。白皮书分析了各自利弊（system 指令控制性强但不支持 memory-as-a-tool；直接注入对话可能造成注入/角色混淆）。
核心要点：
>>System Instruction 注入：适合行为/persona 调整，但不易动态触发 memory-as-a-tool。
>>Conversation History 注入：简单直观，但会增加 token 并可能引发“对话注入”（模型把 memory 当作实际对话语句）。
经验 / 实战技巧：
>> 对事实型短 memory 放在 System Instructions（并标注 confidence）；对程序性或工具执行流程把 memory 作为 procedural injection 或提前加载。
>> 将低置信或敏感 memory 降权或不直接展示给用户，改由模型在内部权衡使用（注入时带 confidence 元数据）。
4.4.1 Memories in the System Instructions
4.4.2 Memories in the Conversation History
4.5 Procedural memories
程序性记忆（“如何做”）不同于声明性记忆，其提取、合并与使用更接近行为/策略管理，能让 agent 在线改进决策而无需 fine-tuning。提取/合并流程需要专门设计。
核心要点：
>>提取：需要专门 prompt 模板来把成功交互转化为可重复的 playbook。
>>合并：聚合成功策略、去除失败步骤并维护最佳实践库。
经验 / 实战技巧：
对关键业务流程（如“下单流程”）定义结构化 procedural schema，并周期性用 RLHF / 仿真数据验证其有效性。
4.6 Testing and Evaluation
Memory 系统需要多层评估：memory 生成质量（precision/recall/F1）、检索性能（Recall@K、latency）、以及端到端任务成功率（LLM judge + 人工复审）。白皮书强调将用户负反馈自动化为回归测试用例。
核心要点：
>> 生成质量：用人工标注的 golden set 做 precision/recall 测评。
>> 检索指标：Recall@K、检索延迟是关键（需在严格的 latency budget 内）。
>> 端到端：最终以任务成功度量系统是否因 memory 而变好。
经验 / 实战技巧：
>> 把用户负反馈（thumbs-down / error tickets）自动转为回归测试用例并纳入 CI，避免记忆回归导致用户体验下降。
4.7 Production considerations for Memory
生产化关注安全/隐私（PII、溯源与删除请求）、性能（检索延迟、缓存）、一致性（并发合并/事务）与成本（生成频率）。白皮书建议 memory 生成大多异步执行并维护详尽的 provenance 链路。
核心要点：
>> 隐私：在写入前 redact PII；对用户撤回请求提供再生成或精确删除策略（避免过度删除）。
>> 效率：memory generation 以后台异步为主（避免阻塞响应），并避免重复处理同样事件。
>> 溯源：每条 memory 应记录来源、时间与置信度，用于合并与推理时权衡。
经验 / 实战技巧：
>> 实施 per-source lineage 跟踪：当某数据源被撤回，仅重建受影响的 memories（替代全删）。这虽昂贵但更精确。
>> 对高成本场景采用混合触发（事件驱动 + 周期性批处理）来平衡新鲜度与成本。
4.7.1 Privacy and security risks
5、Conclusion
Context Engineering 是实现有状态 agent的核心工程实践——它把 prompt engineering 扩展为“动态、分层且可治理的上下文构造”。
>>Sessions 与 Memory各司其职且相互依赖：Sessions 管理短期事件与工作 state，Memory 负责跨会话持久化与个性化。两者的分层设计利于多 agent 协作与跨框架互操作。
>>工程实践侧重点：把昂贵操作异步化；在热路径严格控制 token 与 latency；用 schema/few-shot 提高 memory 抽取精准度；对生产系统实施强鉴权、PII redact、溯源与审计。
>>治理与互操作：跨框架协作建议以 framework-agnostic memory 为交换层，同时对多 agent 消息/工具调用实施严格信任与权限控制。
