夜雨聆风
Google AI Agents 白皮书的深度解读(三)
各位好，欢迎回到 Google AI Agents 白皮书深度解读的第三篇文章。
前两篇的内容，我们构建了 Agent 的四要素架构，并深入了工具与互操作性。这篇文章，我们要进入一个决定 Agent 是“玩具”还是“系统”的分水岭——Context Engineering：上下文工程与记忆系统。
如果问“为什么大多数 Agent Demo 无法变成产品？”答案十有八九，就藏在这篇文章的主题里。我们将揭示如何让无状态的 LLM，进化成拥有持久记忆的可持续 Agent。
一、LLM 的无状态本质与 Context Engineering 的诞生
我们要认清一个残酷的事实：LLM 天生无状态。 模型没有海马体，每一次 API 调用对它来说都是一次全新的初恋。所谓的“记忆”，本质上是我们每次强行把历史记录重新塞进请求载荷的产物。而模型的智商边界，也被严格锁死在单次 Context Window 之内。
所以，Context Engineering 的核心任务，就是从过去写静态 Prompt，走向系统化地动态编排每一次请求所携带的上下文。就像大厨做菜前的备菜，我们需要在运行时，动态拼凑出最完美的信息载荷。
一个完整的 Payload 包含三大信息源：
-
推理引导：系统指令、工具定义、少样本示例。
-
证据事实：长期记忆、RAG 检索到的外部知识、工具执行返回的结果。
-
即时对话：对话历史、上一轮的思维草稿、当前用户的提示词。
这些信息，共同构成了本次推理的原材料。而 Context Engineering，就是对这些原材料进行精心地选择、包装和控制。
但我们必须警惕长上下文陷阱。Token 数量线性增长，不仅带来账单爆炸和首字延迟飙升，更致命的是“上下文腐烂”——模型的注意力被噪声稀释，丢掉了对中间关键信息的感知。因此，上下文管理的本质，就是在有限窗口内最大化信噪比。
二、Session：单次对话的“工作台”
理解了上下文，我们再深入一级——Session，会话。
Session 是单次对话的工作台，它由两类核心组成：
-
Events：不可变的日志，包括用户输入、模型回复、工具执行结果。
-
State：可变的草稿纸，存放结构化的当前状态，如任务进展、关键字段，随对话实时更新。
这里有一个关键辨析：Session History 和 LLM Context 是两码事。Session History 是完整的档案库，是仓库，无限增长、永久存储。而 LLM Context 是从档案中精选出来的，端上桌的成品菜，受窗口限制，必须精心剪裁和拼装。
在生产环境，Session 面临严峻的持久化挑战。本地 Demo 可以把 Session 放在内存里，但进程一销毁，记忆清零。在生产环境，外部存储是刚需——要用 Redis 或 Agent Engine，把状态外挂，确保即使 Runtime 用完即焚，记忆也永存不灭。
同时要守住三道红线：严格隔离，A 用户绝不可以读到 B 的上下文；PII 脱敏，落库前必须擦除敏感信息；完整性，高并发下 Events 必须严格按序追加、保证逻辑闭环。此外，TTL 策略和避免 Session I/O 阻塞主线程，是保障性能稳定的必要条件。
三、Compaction 压缩策略：长对话不翻车
既然上下文窗口不是无限资源，我们需要对 Session 进行“瘦身”，这就是 Compaction 压缩策略。
我们面临四大硬约束：物理触顶会直接 OOM 报错，Token 线性计费让账单爆炸，Prompt 变长带来 TTFT 飙升，而上下文腐烂直接导致推理质量雪崩。我们必须最大化信噪比——保留关键事实，丢弃无关寒暄。
压缩策略有多种：
-
滑动窗口：只保留最近 N 轮，简单粗暴，但容易丢掉远期关键记忆。
-
计数/时间/事件触发压缩：在特定节点启动压缩，精确控制时机。
-
递归摘要：用 LLM 将历史重写为摘要，保留核心语义，成本高昂但效果最好。
关键原则：压缩是昂贵且缓慢的操作，必须异步执行，跳出用户等待的热路径。 我们先秒回用户，再在后台静默完成压缩和持久化，体验第一，计算第二。
四、多 Agent 协作与互操作：Memory 才是通用语
到了一个关键分野：Session 不好共享，它的 Schema 往往与框架强耦合，形成 Vendor Lock-in。LangGraph 读不懂 ADK 的方言，直接导致通信阻断。
所以 Agent 之间传递的统一语言，不是 Session，而是 Memory。 Memory 是提炼后的、框架无关的信息资产，用纯字符串和字典就能流通，成为打破孤岛的基础通用层。
五、Memory：把 Agent 变成长期系统
现在进入今天的核心高地——Memory。
首先必须澄清一个最致命的误区：Memory ≠ Log。 Log 是全量的原始对话流水账，充满冗余的数据流。而 Memory 是提取后的、有意义的信息快照，它是经过提炼、结构化并跨会话持久保存的。
整个记忆系统的本质是一场数据炼金术：Session 是海量矿石，我们从中提取出 Memory 这块高纯黄金，再把它作为高质量上下文注入新一轮推理，从而降低重复问询，大幅节省 Token。
这套系统必须是一个主动的 ETL 全生命周期管线，而不只是“存完不管”的被动向量库。它包括：
-
摄取：全量读入原始 Session 数据。
-
提取：识别并提取关键信号。
-
整合：解决记忆冲突，自我修正，完成增删改。
-
存储：持久化至向量库或图数据库。
-
检索与注入：按需将记忆送回到上下文中。
在工程落地上，记忆结构要框架无关，用 JSON 同时承载内容和元数据，实现解耦。记忆类型二元分为：
-
声明式记忆（Knowing What）：事实与显性知识，比如用户画像。
-
过程式记忆（Knowing How）：技能与执行流程，比如任务 SOP。
组织模式上，三种主流架构是：
-
Collections（集合）：像便利贴墙，存散点信息。
-
User Profile（结构化画像）：像个人档案卡，记录核心属性。
-
Rolling Summary（滚动摘要）：实时更新的用户人设传记。
存储架构选型上，向量数据库做语义相似性召回，知识图谱做复杂关系推理，混合架构方为未来趋势，成年人不做选择题。
六、记忆的生成、检索与注入
记忆的核心壁垒在于提取与整合。提取有三类范式：直接提取事实、偏好与目标；噪音（寒暄）必须被丢弃。
整合则是记忆的自编辑，保证知识库的唯一真理性，它遵循：
-
Create：遇见新实体、新属性时建立节点。
-
Update：对已有偏好进行补充或精度提升。
-
Delete：处理事实冲突与失效信息，旧地址必须被作废。
信任体系建立在Provenance 与 Lineage 之上：每一条记忆必须追溯来源。当信息冲突时，用户显式输入的权重大于模型隐式推断，新鲜度高的信息大于陈旧信息。
检索并非简单的向量搜索，而是多因子排序：相关性、新鲜度、重要性综合加权。检索模式也需权衡：
-
Proactive 预加载：每轮自动检索，响应极快，但可能带入噪声。
-
Reactive 工具化检索：Agent 自主按需调用，精准但增加延迟。
而注入策略同样是巧妙活：全局、稳定、高权威的用户画像等信息适合放在 System Instructions 中作为上帝视角；局部、动态的情节细节则适合放在对话历史中。同时必须用明确分隔符防止模型混淆记忆引用与当前指令。
七、安全与评估：生产的红线
最后，任何记忆系统一旦上线，必须守住生产级红线：
-
严格隔离：用户级 ACL 是底线，记忆绝不可跨用户泄露。
-
隐私与遗忘权：强制 PII 脱敏，支持数据删除。
-
防记忆投毒：防止恶意用户诱导存储错误事实，必须进行写入前验证。
-
效果评估：不仅要看存得对不对，更要生成结果是否精准命中记忆上下文。
结语：从单次对话到长期主义
各位，这篇文章我们从 LLM 的无状态本质出发，通过 Session 管理、Compaction 压缩、多 Agent 互操作，一直深入到 Memory 的全生命周期工程。Context Engineering 是智能体的分水岭——它让 Agent 从单次对话进化为真正的长期主义系统。
下一篇我们将分享——Quality & Eval：质量内建与评测体系。 拒绝幻觉，用可观测性和“模型当裁判”，为 Agent 装上精密仪表盘。敬请期待。