引言
2025年11月，Google联合Kaggle发布五篇系统性AI Agent白皮书，标志着人工智能从“对话范式”正式迈入“软件工程范式”。五篇白皮书内容为：
1、《Introduction to Agents》
2、《Agent Tools and Interoperability with MCP》
3、《Context Engineering: Sessions & Memory》
4、《Agent Quality》
5、《Prototype to Production》
本文围绕《Context Engineering: Sessions & Memory》核心内容，聚焦“Context Engineering”（上下文工程），进入Agent 系统设计的核心深水区：如何使原本无状态的大语言模型具备持续性、个性化与可进化能力。其本质并非依赖更长的上下文窗口或更复杂的 Prompt 设计，而是通过工程化方法，对会话（Session）、记忆（Memory）与上下文（Context）进行分层建模与协同管理。
一、从Prompt Engineering 到 Context Engineering 的范式升级
传统Prompt Engineering 将系统指令固化为静态文本，类似提供一份固定菜谱。而Context Engineering 是一种动态编排过程，在每次LLM 调用前，实时组装三类关键资产：
1、引导推理的“大脑”，包括 System Prompt 与可用工具定义；
2、支持决策的“事实”，来源于长期记忆（Memory）与检索增强（RAG）；
3、锚定当前任务的“现场”，即本轮对话的历史片段与用户最新输入。
该过程遵循标准四步闭环：Fetch（获取数据）、Prepare（构造上下文）、Invoke（调用模型）、Upload（持久化更新）。其中，“Prepare Context”处于热路径（Hot Path），其性能直接影响用户感知延迟，必须保障毫秒级响应，而Upload 操作应异步执行，避免阻塞主流程。
二、Session：面向单次交互的临时工作台
Session 并非简单的聊天记录集合，而是为单次用户会话建立的隔离式运行环境。其结构包含两个核心组成部分：
1、Events：按时间顺序追加、不可篡改的原始对话日志；
2、State：结构化的临时状态空间，用于存储如购物车内容、任务进度等中间变量。
需明确区分Session History 与 Context：前者是完整、永久的原始档案，后者是为本次 LLM 调用专门裁剪后的输入载荷。将全部历史直接注入 Context，将导致 Token 消耗剧增、响应延迟升高，并引发上下文腐烂（Context Rot）——即无关信息稀释关键指令，显著降低模型输出质量。
在生产环境中，Session 必须实现持久化存储（如 Redis 或专用 Agent Engine），不可依赖无状态运行时的内存变量。其工程实践需遵守三项基本原则：
1、严格隔离：不同用户的Session 必须通过访问控制策略（ACL）实现物理或逻辑隔离；
2、敏感信息脱敏：个人身份信息（PII）须在写入存储前完成清洗，以控制数据泄露影响范围；
3、确定性顺序保证：高并发场景下，Events 的写入顺序必须严格遵循时间逻辑，确保状态一致性。
此外，Session 应设置合理的生存时间（TTL），防止无限增长带来的性能衰减。
三、Compaction：面向上下文窗口约束的信息提纯
随着对话延长，Session 规模持续扩大，但将全部历史送入 LLM 并不可行。除 Token 成本与延迟问题外，更关键的制约在于信息密度下降所引发的质量退化。因此，Compaction 不是简单删减，而是以提升信噪比为目标的信息提纯过程：保留对当前任务具有直接价值的信号，剔除寒暄、过期中间态及冗余细节。
实践中存在三类主流压缩策略：
1、滑动窗口法：仅保留最近N 轮对话，实现成本最低，但易丢失长期上下文；
2、Token 倒序填充法：从最新消息开始逆向累积，直至填满上下文窗口，平衡性较好；
3、LLM 递归摘要法：调用模型对历史对话生成结构化摘要，并置于上下文前端，智能化程度最高，但计算开销大。
无论采用何种策略，Compaction 操作均不得置于热路径中。正确做法是：先向用户返回初步响应，再于后台异步执行压缩，并将结果持久化供后续使用。
四、Multi-Agent 协作中的上下文协同机制
在多智能体系统中，各Agent 通常基于不同框架开发（如 LangGraph 与 Google ADK），其 Session 数据结构存在强框架耦合性，无法直接互通。此时，Session 反而成为协作障碍，而 Memory 才是真正意义上的通用语义层。
Memory 以框架无关的形式（如 JSON 或纯文本）存储结构化知识，屏蔽底层实现差异。多 Agent 协作应围绕 Memory 层展开：各 Agent 将自身提取的知识沉淀至共享 Memory 存储，再按需检索使用。该模式既保障了解耦性与可扩展性，也避免了因直接传递原始 Session 所导致的语义失真与兼容性问题。
五、Memory：从日志到知识的系统性提炼
Memory 并非聊天记录的备份，而是从 Session 中主动萃取、持续演化的结构化知识快照。例如，Session 记录“我下周要去巴黎出差”，而 Memory 应抽象为“用户近期行程：巴黎；出发时间：下周”。二者关系可类比为“矿石”与“精炼金属”。
Memory 管理系统本质上是一条由 LLM 驱动的 ETL 流水线，包含四个关键阶段：
1、Ingestion：接入原始对话流；
2、Extraction：依据预设规则（如 JSON Schema 或自然语言描述）识别并提取有效事实；
3、Consolidation：将新提取信息与已有记忆融合，处理冲突（如地址变更）、去重与版本更新；
4、Storage：持久化最终结果。
其中，Consolidation 是核心能力所在，要求系统能依据来源可信度（Provenance）与信息新鲜度（Freshness）动态判断知识优劣，确保 Memory 库始终维持单一真实状态。
六、Memory 与 RAG 的定位分工
RAG 与 Memory 在 Agent 架构中承担互补角色：
1、RAG 提供外部世界知识（如“巴黎是法国首都”），属于静态、公开、广域的事实库；
2、Memory 存储用户专属知识（如“用户偏好巴黎旅行”“用户下周出差”），属于动态、私有、深度个性化的认知基底。
二者不可替代：仅依赖RAG，Agent 缺乏人格温度。仅依赖Memory，Agent 难以应对开放域问题。成熟 Agent 系统需同时建设两类知识基础设施。
七、Memory 的工程实现要点
一条Memory 实体应包含内容（content）与元数据（metadata）两部分：
1、content 必须采用跨框架兼容格式（推荐 JSON 或纯文本），禁止序列化语言特定对象；
2、metadata 至少涵盖唯一标识符、创建时间、来源类型等字段，支撑高效检索与溯源。
根据认知科学分类，Memory 可分为两类：
1、陈述性记忆（Declarative Memory）：描述“是什么”，如用户饮食禁忌、品牌偏好；
2、程序性记忆（Procedural Memory）：描述“怎么做”，如为特定用户订票的标准操作流程。当前多数系统仅覆盖前者，而高阶 Agent 需支持后者以实现任务复用。
在组织形式上，常见方案包括：
1、Collections：松散集合，适用于非结构化洞察的存储与模糊匹配；
2、Structured User Profile：表格式画像，适用于高频查询的稳定属性；
3、Rolling Summary：滚动式摘要，适用于长周期对话中人设的动态凝练。实际部署中常组合使用。
存储技术选型正趋向混合架构：以向量数据库（Vector DB）实现语义层面的广度召回，以知识图谱（Knowledge Graph）支撑关系推理与深度挖掘，二者协同提升 Memory 的表达力与实用性。
八、Memory 的检索与上下文注入策略
Memory 的价值最终体现于检索与注入环节。高效检索不应仅依赖语义相似度（Relevance），还需综合考量新鲜度（Recency）与重要性（Importance），形成三维评分机制，确保在有限延迟预算内召回最相关、最新鲜且最关键的信息。
检索时机存在两种典型策略：
1、主动预加载（Proactive）：每轮对话启动前统一检索，响应快但可能引入冗余；
2、按需触发（Reactive）：由 Agent 自主判断是否需要调用 Memory，更精准但增加一次 LLM 调用开销。生产环境应依据延迟容忍度与业务场景权衡选择。
注入位置亦影响效果：
1、注入System Instructions 区域，适用于长期稳定画像（如用户身份、核心偏好），权威性高、不易混淆；
2、注入Conversation History 区域，适用于即时性细节（如刚确认的航班号），但存在 Dialogue Injection 风险，即模型难以区分该信息来自用户输入还是自身记忆。
九、评估与安全治理
Memory 系统的有效性需通过两项核心指标衡量：
1、Precision：所存储知识的准确性；
2、Recall@K：关键记忆在 Top-K 检索结果中的命中率。
安全性方面，必须落实三项基本要求：
1、访问控制隔离（ACL）：确保用户间 Memory 严格隔离；
2、敏感信息脱敏：所有PII 字段须在入库前完成清洗；
3、抵御记忆投毒（Memory Poisoning）：对用户输入的隐含事实需设置交叉验证或显式确认机制，防止错误信息污染知识库。
结语
Context Engineering 是连接无状态 LLM 与可持续智能体的关键桥梁。它超越了 Prompt 工程的表层技巧，转向对 Session、Memory 与 Context 的系统性建模与工程化治理。唯有厘清三者边界、明确各自职责、建立闭环演进机制，才能真正赋予 Agent 以连续性、个性化与可进化能力。
AIintech（www.aiintech.net）是国内最早一批专注于人工智能领域的综合技术平台，构建了涵盖AI工具生态、前沿技术社区与人才招聘社区的AI综合生态，汇聚了数千名技术极客。
我们致力于将AI前沿技术应用于各行各业，现已在能源、金融、医疗、消费、智能制造等行业实现数十个AI和自动化应用案例。
AIintech与我们生态的技术伙伴致力于使用AI基础大模型、自动化控制工具、智能硬件设备等方式提供一站式系统化AI解决方案。
