把“上下文”当成一条生产线：Sessions 与 Memory 如何让 Agent 记得住、跑得快、还不越界

✨步子哥 (steper) • 2025年12月28日 05:56 • 0 次浏览

如果说工具让 Agent 有了“手”，能把世界上的事真正做起来；那么 Context Engineering 就是让这双手“不乱抓”的方法论——它决定模型每一轮到底看见什么、忽略什么、记住什么、忘掉什么。模型天然是无状态的：一次调用结束，它就像刚醒来一样，对刚才发生的事毫无记忆。要让 Agent 具备持续对话、长期个性化、跨会话经验积累的能力，你必须把“状态”外置成两套系统：Session（会话工作台） 与 Memory（长期档案柜） ，并在每一轮对话里动态装配它们进入上下文窗口。

这篇续写聚焦工程落地：如何设计 Session、怎么压缩长对话、Memory 如何生成/整合/检索、以及多 Agent 与跨框架协作时为什么 Memory 会成为“通用层”。最后我们会把隐私安全与评估指标也一起拉进来——因为“记得住”不是目的，记得对、找得到、用得稳、且不泄露才是。

🍱 第一章：Context Engineering 是什么——从“写提示词”升级为“装配整包请求”

传统 Prompt Engineering 更像写一段固定的系统指令；而 Context Engineering 关心的是每一次调用的完整 payload：它要根据用户、会话、工具结果、外部知识、长期记忆等，动态构造一个“有状态”的请求。

可以把它想成做菜前的 mise en place：不是只给厨师一张菜谱，而是把新鲜食材、刀具、调料、摆盘要求都提前备好——模型不需要“猜”，它只需在最小噪声里做最大确定性的推理与行动。

上下文通常由三类信息组成：

🧠 A. 指导推理的上下文（行为宪法）

System Instructions：人格、能力边界、规则
Tool Definitions：工具 schema 与说明
Few-shot Examples：示例引导推理路径

📚 B. 证据与事实数据（推理证据链）

Long-Term Memory：跨会话沉淀的用户信息/经验
External Knowledge：RAG 检索到的文档/数据库信息
Tool Outputs：工具返回值
Sub-Agent Outputs：子 Agent 的结论
Artifacts：文件/图片等非文本材料

💬 C. 当前交互信息（眼前这件事）

Conversation History：本轮对话历史
State / Scratchpad：临时变量、购物车、草稿计算等
User Prompt：用户当前问题

小贴士：上下文不是越多越好 长上下文会带来成本、延迟，还会出现“context rot”（上下文腐烂）：信息越多，模型越容易抓不住关键点，推理质量反而下降。Context Engineering 的目标是“不多不少，刚刚好”。

🔄 第二章：每一轮对话的“上下文流水线”——Fetch → Prepare → Invoke → Upload

一个生产级 Agent 每一轮通常经历四步循环：

Fetch Context：取回需要的上下文（记忆、RAG、最近事件等）
Prepare Context：构建最终 prompt（这是阻塞的热路径）
Invoke LLM and Tools：模型与工具迭代，工具/模型输出追加进上下文
Upload Context：把新信息写入持久化系统（多为后台异步）

这四步里，最容易被忽略但最关键的是：Prepare 是阻塞热路径，Upload 应尽量后台化。你把昂贵的提炼/整合工作塞进热路径，就会把体验做成“每句话都卡一下”。

🧰 第三章：Sessions——会话工作台（事件日志 + 工作状态）

🧾 3.1 Session 由两部分组成：Events 与 State

Events：按时间追加的对话事件：用户输入、Agent 回复、工具调用、工具输出等
State：结构化工作内存（scratchpad），例如购物车内容、当前任务进度、已确认的参数

一个 Session 是单用户、单对话的容器。用户可以有多个 session，但它们是互相断开的“项目工作台”，不会天然共享记忆（共享要靠 Memory）。

🏭 3.2 生产环境的 Session 存储：因为 runtime 通常无状态

多数 Agent 运行环境是无状态的：请求结束就清空内存。因此你必须把 session 历史写入持久化存储（数据库/托管会话服务），每一轮开始时再拉回。

🧬 第四章：框架差异与多 Agent 的 Session 模式——共享大账本 vs 各自小账本

🧱 4.1 框架实现差异的本质：内部结构统一，外部协议多样

框架本质上是“翻译器”：开发者使用框架的内部事件结构，框架负责把它映射成具体模型 API 需要的格式。这样能解耦模型供应商，但也会带来跨框架的“语义隔离”。

🧑‍🤝‍🧑 4.2 多 Agent 下的两种 Session 历史组织

多 Agent 系统关键在“怎么共享信息”。常见两种模式：

🧷 A. Shared Unified History（共享统一历史）

所有 agent 把消息、工具调用、观察都写入同一个时间序列日志。适合紧耦合协作、强依赖“单一事实源”的流水线式任务。

优点：全局可追踪、接力自然；缺点：历史膨胀快、噪声大、权限隔离更难。

🕳️ B. Separate Individual Histories（各自独立历史）

每个 agent 有私有历史，对外只输出最终结果（像黑盒工具）。常通过“Agent-as-a-Tool”或 A2A 消息来交换结果而非过程。

优点：边界清晰、泄露风险小；缺点：共享上下文贫瘠，协作需要额外设计。

🌉 第五章：跨框架互操作的硬问题——Session 不可移植，而 Memory 可以做“通用层”

不同框架的 session/event 存储模型往往强绑定内部对象结构，因此一个框架写入的 Session，另一个框架很难直接读懂。你可以用 A2A 传消息，但“富状态”仍需要翻译层。

更稳健的模式是：把共享知识抽象到框架无关的 Memory 层。Memory 存的不是框架事件对象，而是提炼后的事实/实体/摘要（字符串或字典）。于是它能成为多框架、多 agent 之间的共同认知资源。

🚦 第六章：Session 的生产考量——安全隔离、数据完整性、性能与长对话压缩

🔐 6.1 安全与隐私：严格隔离 + PII 先脱敏再落盘

Session 归属单用户，必须 ACL 严格隔离，防止跨用户访问
最佳实践：PII 在写入存储前就脱敏/删改，降低泄露爆炸半径，利于 GDPR/CCPA 合规

🧱 6.2 数据完整性：顺序一致性 + 生命周期（TTL）

必须保证事件追加顺序确定（日志乱序会直接让推理崩坏）
Session 不应永久保存：用 TTL 或归档策略控制成本与合规风险

⚡ 6.3 性能：Session 在热路径上，必须“快且小”

每一轮要拉取 session 历史并构造 prompt，历史越大越慢越贵。关键优化：在送入模型前对历史做过滤/压缩（例如剔除过时的工具输出）。

🧳 第七章：长对话管理——像打包行李一样压缩历史

长对话带来四个硬约束：
1) 上下文窗口上限
2) token 成本
3) 延迟
4) 质量（噪声与自回归误差）

常见压缩策略（从简单到复杂）：

🪟 7.1 Sliding Window：保留最近 N 轮

简单有效，但可能丢失早期关键约束。

🧮 7.2 Token-Based Truncation：按 token 预算回溯截断

更贴合成本控制，缺点同样是“可能截掉关键事实”。

🧾 7.3 Recursive Summarization：旧内容变摘要

把较老的对话段落替换成摘要，并与最近若干轮原文并存。工程要点：

摘要生成要尽量后台异步并持久化，避免每轮都重新总结
需要记录哪些事件已被摘要覆盖，避免重复把原文再塞回上下文

🧨 7.4 压缩触发机制：何时做？

计数触发：turn/token 超阈值就压缩（最常用，“够用”）
时间触发：用户一段时间不说话就后台压缩
事件触发：检测到子任务/话题结束时压缩

🗄️ 第八章：Memory——长期档案柜（提炼后的、可复用的“少而精”）

Memory 的定义不是“把对话存起来”，而是从对话中抽取并固化有价值的信息，跨 session 持久存在，用于个性化、上下文管理、数据洞察、以及自我改进。

🎯 Memory 带来的四类能力

个性化（偏好、事实、历史）
代替长历史（摘要/关键事实减少 token）
规模洞察（聚合后挖掘趋势，需隐私保护）
自我改进（记录成功策略/工具路径，形成 playbook）

🧭 第九章：Memory 与 RAG 的边界——一个懂世界，一个懂用户

RAG：注入外部、静态、权威事实；一般共享、只读
Memory：沉淀用户相关、动态、隔离的上下文；需要写入与演化

一句话：RAG 让系统成为“事实专家”，Memory 让系统成为“用户专家”。

🧠 第十章：Memory 的结构与类型——内容 + 元数据；“知道什么”与“知道怎么做”

🧱 10.1 Memory 的基本结构

content：事实片段（文本或结构化 JSON/dict）
metadata：id、owner、标签、来源等

📚 10.2 知识类型：Declarative vs Procedural

Declarative（knowing what）：事实/偏好/事件
Procedural（knowing how）：技能/流程/工作流“剧本”

关键区别：程序性记忆不是“检索数据”，而是“检索一个可执行的计划”，它更像推理增强层；相比微调（离线、改权重），程序性记忆是在线注入 playbook，通过 in-context learning 快速纠偏。

🗂️ 第十一章：记忆怎么组织与存储——Collections / 用户档案 / Rolling Summary；向量库 / 知识图谱 / 混合

🧺 11.1 组织模式

Collections：一堆原子记忆，适合搜索与多主题
Structured User Profile：稳定字段（姓名、偏好），适合快速读取
Rolling Summary：一份持续更新的总摘要，常用于压缩长 session

🗃️ 11.2 存储架构

向量数据库：语义相似检索，适合非结构化记忆
知识图谱：实体-关系推理，适合结构化关联
混合：图谱节点带 embedding，同时支持语义与关系检索

🌱 第十二章：记忆生成——Extraction + Consolidation 的 LLM 驱动 ETL

记忆生成不是简单总结，而是一个 LLM 驱动的 ETL：

1) Ingestion：输入源数据（通常是会话历史）
2) Extraction & Filtering：按“主题定义”抽取有意义信息（没命中就不记）
3) Consolidation：去重、冲突解决、更新/创建/删除、以及遗忘（TTL/低置信）
4) Storage：写入向量库/图谱等持久层

🔍 12.1 Extraction：决定“什么值得记”

“有意义”完全取决于业务目标。常见实现方式：

schema/模板化抽取（结构化输出）
自然语言 topic definitions
few-shot 示例（对微妙领域特别有效）

很多系统会把“滚动摘要”作为 extraction 的辅助输入，提高效率，避免每轮重扫全量历史。

🧹 12.2 Consolidation：没有整合就会变成矛盾垃圾堆

整合要解决：

重复（同一事实多种表达）
冲突（用户偏好变化）
演化（事实变得更具体）
衰减与遗忘（旧的、低置信的要删/降权）

整合常见操作：UPDATE / CREATE / DELETE(或 INVALIDATE)。

🧬 第十三章：记忆溯源（Provenance）——你凭什么相信它？

长期记忆如果不追踪来源，就会走向“自信胡说”。溯源至少要记录：

来源类型（预加载系统数据 / 用户输入 / 工具输出）
新鲜度（时间）
以及可能的置信度变化（被多源佐证上升、随时间衰减下降）

一个重要建议：从工具输出生成长期记忆通常不推荐，因为工具数据更适合短期缓存，容易陈旧且脆弱。

溯源的工程意义：

整合时可建立信任层级（可信源优先、近期优先、多源佐证优先）
删除数据源时可按 lineage 精准再生成，而不是粗暴删光

⏱️ 第十四章：何时生成记忆？Memory-as-a-Tool 让系统更“聪明”，但要控成本

触发策略的权衡是“成本 vs 保真”：

会话结束：便宜，但可能低保真
每 N 轮：常用折中
每轮实时：最鲜，但成本最高
用户显式指令：可控但覆盖不足
Memory-as-a-Tool：让 Agent 自己决定何时调用 create_memory，更智能，但需要更严格的工具定义与策略控制，避免“过度记忆”

🧵 后台 vs 阻塞：记忆生成几乎应该总是异步

记忆生成需要 LLM 调用与写库，必须从热路径剥离：用户先拿到回复，后台再做 extraction/consolidation。否则体验会被拖慢到不可用。

🔎 第十五章：记忆检索——相关性不够，还要看新鲜度与重要性

检索的目标是：在严格延迟预算内，找到最有用的记忆。

常见评分维度：

Relevance（语义相关）
Recency（时间新鲜）
Importance（重要性，生成时可标注）

只用向量相似度是常见坑：会捞出“很像但很旧/很琐碎”的记忆。更稳的是多维混合评分。

高级增强（但更慢）：

query rewriting（多一次 LLM）
reranking（先取 top50，再用 LLM 重排）
训练专用 retriever（需标注数据，成本高）

可配合缓存，避免每次重复高成本流程。

🕰️ 检索时机：主动预取 vs 反应式查询

主动预取：每轮开始就取，简单但有额外延迟；可缓存
反应式（Memory-as-a-Tool）：需要时才查，更省但可能多一次 LLM 调用；需让 Agent“知道可能有哪些记忆类型”，否则它不知道该不该查

🧠 第十六章：把记忆放进上下文——放哪里，权重就在哪里

三种主要注入方式：

🏛️ 16.1 放进系统指令

优点：权威高、对话历史干净，适合稳定信息（用户档案）。风险：过度影响——模型可能强行把所有话题都往记忆上扯；且系统指令通常只支持文本，不利于多模态记忆；也不兼容“先让模型决定是否调用记忆工具”。

🗣️ 16.2 注入对话历史

优点：灵活，适合情境性记忆。风险：噪声大、token 成本高、可能发生“对话注入”错觉（模型把记忆当作用户刚说的）。如果用 user 角色注入用户级记忆，还要注意第一人称视角一致性。

🧰 16.3 作为工具输出

反应式查询时，记忆以 tool output 形式进入上下文，天然落在对话序列里。优点是链路清晰；缺点是如果检索质量差，会直接污染推理。

🧪 第十七章：怎么评估“记忆系统真的有用”——质量、检索、端到端

评估要分三层：

✅ 17.1 生成质量：记得对不对？

对比人工 golden set：

Precision：记了多少是对且相关的（防“过度记忆”污染）
Recall：该记的有没有漏（防“关键事实丢失”）
F1：综合指标

🔍 17.2 检索性能：找不找得到、快不快？

Recall@K：需要的记忆是否出现在 topK
Latency：检索要在严格预算内（例如 <200ms）

（复杂重写/重排一般不适合实时热路径，除非可缓存且不易陈旧）

🧭 17.3 端到端任务成功：记忆是否提升了任务完成

用 LLM judge 对最终答案与 golden answer 比较，判断记忆是否真的改善目标结果。

🛡️ 第十八章：隐私与安全——记忆是“公司档案馆”，不是“随手记事本”

长期记忆的底线是：

严格隔离（user/tenant scope）：跨用户泄露是致命事故
用户可控：可 opt-out、可删除
PII 落盘前脱敏
防记忆投毒（memory poisoning）：对注入与伪造信息做验证与净化
跨用户共享的程序性记忆必须强匿名化，否则“经验复用”会变成“信息外泄”

📚 参考文献（5 项）

Retrieval-Augmented Generation overview: https://cloud.google.com/use-cases/retrieval-augmented-generation?hl=en
Agent Engine Sessions overview: https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/sessions/overview
Agent Engine Memory Bank – generate memories: https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/memory-bank/generate-memories
Model Armor overview: https://cloud.google.com/security-command-center/docs/model-armor-overview
Gemini long context limitations: https://ai.google.dev/gemini-api/docs/long-context#long-context-limitations