上下文工程：Sessions 与 Memory 的有状态 Agent 架构指南

本文目录29 个章节

大型语言模型（LLM）在单次 API 调用之外没有持续的对话状态。Agent 想保持连贯、记住用户偏好、调用外部资料并完成多步任务，就要在每一轮调用前重新组装可用信息。白皮书把这套动态选择、压缩和注入信息的工作称为上下文工程（Context Engineering）。

上下文工程处理的是完整请求载荷：系统指令、工具定义、示例、对话历史、工作状态、长期记忆、RAG 文档、工具输出、子 Agent 结果和用户当前问题。目标是让模型拿到完成当前任务所需的信息，同时控制无关内容、延迟和 token 成本。

上下文工程把每轮调用前的信息选择、Session 的即时状态和 Memory 的长期治理放在同一条工程链路里。

上下文工程如何把无状态 LLM 变成有状态 Agent

一次调用需要哪些上下文

上下文可以按作用分为三组。第一组负责约束推理和行动，包括系统指令、工具 schema 与 few-shot 示例；第二组提供模型要判断的事实，包括长期记忆、RAG 取回的外部知识、工具输出、子 Agent 输出和文件、图片等伴生产物；第三组描述当前任务，包括本轮对话历史、临时状态或 scratchpad，以及用户当前提示。

上下文组成	主要作用	生命周期
系统指令	规定角色、能力和约束	跨轮次或按请求动态生成
工具定义	描述可调用的 API、函数和参数	随 Agent 配置变化
Few-shot 示例	给出当前任务可参考的行为样例	按任务选择
长期 Memory	提供跨会话的用户或主题信息	长期持久化
外部知识与 RAG	提供文档、数据库或 API 中的事实	按查询动态取回
工具与子 Agent 输出	提供本轮执行产生的证据	当前任务内
Conversation History	还原当前会话的事件顺序	当前 Session
State / Scratchpad	保存购物车、计划、临时计算等工作数据	当前任务或 Session
用户提示	定义这一轮要解决的问题	当前请求

每轮请求都要经过四个阶段

上下文管理形成一条循环：

TEXT

取回上下文：Memory、RAG、最近事件与任务元数据
        ↓
准备上下文：框架组装本轮完整请求，属于 hot path
        ↓
调用 LLM 与工具：循环执行，持续追加模型和工具输出
        ↓
上传上下文：把适合长期保留的信息异步交给持久化管线

取回和准备发生在用户等待的路径上，必须控制延迟；记忆生成、整合和其他昂贵处理可以在响应返回后后台执行。对话越长，成本、延迟和“context rot”越明显，模型对关键内容的注意力也可能下降，因此历史需要选择性裁剪、摘要或压缩。

Session 保存当下的对话状态

事件与状态的分工

Session 是一个用户在单次连续对话中的自包含记录。它包含按时间追加的事件（events）和可变的工作状态（state）。事件记录用户输入、Agent 回复、工具调用和工具输出；state 保存当前任务需要的结构化临时数据，例如购物车内容、已确认的筛选条件或中间计算结果。

Session 部件	典型内容	处理方式
Events	用户消息、Agent 响应、工具调用、工具结果	按时间顺序追加
State	当前任务的结构化变量、工作记忆、scratchpad	由 Agent 逻辑读取和修改
持久化记录	一次会话的完整历史和元数据	存入可靠的 Session Store

生产 Agent 的运行环境通常在请求完成后不保留内存，因此 Session 历史必须放进持久化存储。开发阶段可以使用进程内存；生产环境需要可靠数据库或托管 Session 服务，并保证事件顺序稳定。

框架差异不应泄漏到业务层

不同 Agent 框架对 Session、Event 和 state 的定义并不相同。Google ADK 提供显式的 Session 对象，其中包含 Event 列表和独立的 state；LangGraph 直接把可变 state 作为 Session，消息历史和其他工作数据都放在同一个状态对象里。

框架负责把内部事件映射为具体模型 API 的请求格式。例如 Gemini 请求使用包含 role 和 parts 的 Content 列表。业务逻辑应依赖稳定的内部抽象，由框架负责转换，避免把某个模型或供应商的消息 schema 写死在应用代码中。

多 Agent 共享的是语义状态

多 Agent 协作时，每个 Agent 可以维护自己的私有历史，再把任务结果交给父 Agent；也可以共享更丰富的 Session 状态。A2A 消息适合传递结构化任务和结果，却无法自动解决不同框架之间的历史 schema 转换。

跨框架协作更适合增加一层框架无关的 Memory 数据层。它保存摘要、实体和事实等经过处理的规范化信息，使用字符串、字典或其他通用结构承载语义。Session 保留原始事件，Memory 提供多个 Agent 都能读取的共同知识层。

长对话为什么需要压缩

长上下文会同时推高四种成本

Session 历史每轮都可能从中心存储读出并发送给模型。历史不做处理时，窗口上限、API 费用、响应速度和答案质量会同时承压。

成本	具体表现	对应处理方向
上下文窗口	历史超过模型上限后，请求失败	控制 token 或执行摘要
API 费用	输入输出 token 增加，单轮费用上升	删除无关旧内容
延迟	传输和处理更多文本，响应变慢	缩短 hot path 载荷
质量	噪声变多，重要信息更难被关注	保留高价值事实和近期上下文

压缩的目标是把历史缩小到模型可处理的范围，同时保留当前任务仍需要的事实、决定和约束。历史存储和发送给模型的上下文可以分离：压缩只改变本轮使用的视图，或者把结果持久化为后续轮次可复用的摘要。

三种会话压缩策略

保留最近 N 轮：使用滑动窗口，只把最近若干轮发送给模型。实现简单、延迟低，适合旧内容价值有限的对话。
按 token 截断：从最新消息向前累加，直到达到预设 token 上限。它能直接控制载荷大小，但会突然丢掉更早的关键事实。
递归摘要：把较早消息替换为 LLM 生成的摘要，再与近期原文拼接。它能保留更长时间的任务脉络，却需要额外模型调用和摘要质量校验。

递归摘要等昂贵操作应在后台执行，并持久化摘要结果，避免每轮重复计算。系统还要记录摘要覆盖了哪些原始事件，确保已纳入摘要的长文本不会再次无意义地发送给模型。压缩可以按轮次、token 数、时间或任务完成等事件触发。

Memory 如何从对话中提炼长期信息

Memory 与 Session 的边界

Session 记录一段对话的即时工作面，Memory 保存从对话或其他来源提炼出的、可供未来交互使用的信息。两者相互作用：Session 是生成 Memory 的主要原料，Memory 又能帮助压缩 Session，减少跨轮传递的原始历史。

一条 Memory 通常由内容和元数据组成。内容应尽量使用框架无关的字符串、字典或 JSON；元数据记录记忆 ID、所属用户、来源、时间、标签和其他治理信息。Memory 记录的是已经发生或被明确表达的信息，默认采用描述性表达，不把推测性结论当成用户事实。

RAG 与 Memory 分工不同

RAG 和 Memory 都会向上下文提供信息，但数据来源、隔离级别和更新方式不同。RAG 适合共享的、稳定的外部事实；Memory 适合按用户隔离、从互动中不断更新的个性化信息。

维度	RAG Engine	Memory Manager
主要目标	把外部事实注入上下文	形成持续、个性化的用户状态
数据来源	PDF、Wiki、文档、API 等预索引知识库	用户与 Agent 的对话和明确输入
隔离级别	通常共享、只读	通常按用户或租户严格隔离
信息性质	静态、事实性、权威性较强	动态、用户相关，带有来源不确定性
写入方式	常见为离线批处理或管理员触发	按事件、会话结束或 Memory-as-a-Tool 触发
读取方式	Agent 按查询作为工具取回	自动预加载或由 Agent 按需调用
典型比喻	研究资料库，帮助 Agent 掌握事实	个人助理，帮助 Agent 了解用户

Memory Manager 不是只做向量相似度查询的数据库。它还要负责抽取、去重、冲突处理、更新和失效清理。RAG 让 Agent 掌握领域事实，Memory 让 Agent 延续用户关系。 两者可以同时出现在同一个上下文工程循环中。

记忆的类型和组织方式

按信息内容，Memory 可分为声明式记忆和程序式记忆。声明式记忆回答“是什么”，包括事实、历史和用户资料；程序式记忆回答“怎么做”，包括可复用的工作流、工具调用顺序和解决问题的策略。

按组织方式，常见设计包括三种：Collections 把多个独立事件或观察组成可检索集合；Structured User Profile 把姓名、偏好、账户信息等稳定事实放进持续更新的用户档案；Rolling Summary 将用户与 Agent 的关系压缩成一份持续演进的自然语言总结，常用于控制长 Session 的 token 数。

按存储架构，向量数据库适合基于语义相似度搜索自然语言原子事实；知识图谱适合表示实体和关系，支持结构化关联查询；混合架构把图结构与向量表示结合，同时保留关系推理和语义检索能力。

按生成方式，显式记忆来自用户直接下达的“记住这件事”指令；隐式记忆由 Agent 从对话中抽取，触发条件和可信度需要单独治理。按系统边界，内部 Memory 由 Agent 框架直接管理，适合快速起步；外部 Memory 使用专门服务处理生成、存储和检索，便于独立扩展。多模态输入可以先转成文本洞察，也可以保留图像、音频等媒体作为记忆内容，后者对存储、检索和模型接口提出更高要求。

记忆生成需要抽取、整合和溯源

四阶段记忆生成管线

Memory 生成可以看作由 LLM 驱动的 ETL 流程，但它会参与数据内容的判断：

Ingestion：接收对话历史、直接记忆或其他原始来源。
Extraction & Filtering：根据预定义主题抽取有意义的信息，只保留匹配主题的内容；没有符合条件的信息时不生成 Memory。
Consolidation：把新信息与现有记忆比较，处理去重、冲突和演进，决定更新、创建或删除。
Storage：把最终记忆写入向量数据库、知识图谱或其他持久化存储，供未来取回。

Consolidation 负责更新、冲突和遗忘

没有整合的 Memory 会变成一份充满重复和矛盾的日志。整合流程通常先取回与新信息相似的旧记忆，再由 LLM 对照判断要执行的操作：

UPDATE：用新事实或修正信息更新已有记忆。
CREATE：新信息与现有内容无关时创建独立记忆。
DELETE / INVALIDATE：旧信息已经错误、无效或完全失去相关性时删除或标记失效。
FORGET：结合信息新鲜度、置信度或 TTL，主动清理过期内容。

用户偏好和状态会变化，系统需要允许新信息覆盖旧信息，并保留足够的历史依据来解释变化。删除也要考虑派生关系：如果某条 Memory 来自多个来源，用户撤回其中一个来源的授权时，系统需要定位并处理受影响的派生记忆。

Provenance 决定记忆可以被信任到什么程度

Memory 的来源和演变历史会影响整合优先级，也影响推理时的使用权重。常见来源可按可信度和稳定性单独评估：

来源	典型特点	治理建议
Bootstrapped Data	从 CRM 等内部系统预加载，适合解决冷启动	标注系统来源和更新时间
用户明确输入	表单或直接指令，意图清晰	保留用户确认和撤回能力
对话隐式抽取	从自然对话推断，可能带有歧义	降低默认信任，保留证据链
工具输出	外部调用返回，容易过时或对当前任务有局部性	优先作为短期缓存，谨慎写入长期 Memory

当来源发生冲突时，可以优先选择更可信来源、更新的来源，或寻找多个数据点的交叉印证。Memory Poisoning 也是溯源治理要处理的风险：恶意输入可能把提示注入或虚假事实写入长期知识库，因此提交前需要验证、清洗和权限控制。

什么时候取回记忆、如何放进上下文

评分维度	要回答的问题	常见处理
Relevance	这条记忆与当前对话有多相关	语义检索、查询改写
Recency	这条记忆有多新	时间衰减或新鲜度权重
Importance	这条记忆对用户或任务有多重要	生成时标注，检索时融合

主动取回与工具取回

主动取回（proactive retrieval）在每轮开始时自动加载记忆，适合用户档案等稳定信息，代价是无需记忆的请求也会承担取回延迟。工具取回（reactive retrieval 或 Memory-as-a-Tool）把查询能力交给 Agent，由它判断什么时候需要 Memory，减少无效检索，却增加一次工具决策调用，而且 Agent 可能不知道某条相关记忆存在。

工具描述可以明确 Memory 中包含哪些信息类型，帮助 Agent 做出更准确的取回决定。无论采用哪种策略，都需要为每种记忆类型建立测试集，观察错误取回、漏取和延迟。

系统指令与对话历史的注入边界

稳定、全局、每轮都应存在的用户档案可以追加到 system instructions。这样能保持对话历史干净，也会赋予 Memory 较高的指令权重；风险是 Agent 可能把所有话题都强行关联到档案内容。系统还要支持每轮动态构建 system prompt，并处理多模态记忆无法直接塞进纯文本指令的问题。

短期、偶发、只与当前任务有关的记忆可以注入对话历史或作为工具输出返回。这样更灵活，也可能增加 token 噪声，并让模型误以为记忆内容是原始对话中实际说过的话。注入时要标注来源、视角和可信度，避免把 Memory 与用户原话混在一起。混合策略通常更容易在稳定档案和临时情境之间取得平衡。

Procedural Memory 记录执行方法

声明式与程序式记忆的差异

商业 Memory 系统大多擅长保存声明式信息，即用户偏好、历史事实和“是什么”。程序式记忆保存“怎么做”，需要把成功交互中的可复用策略提炼成 playbook。

程序式 Memory 也包含抽取、整合和取回三个阶段，但整合对象从事实变成工作流：吸收新的成功方法，修补已有步骤，淘汰过时或无效的流程；取回目标也从回答事实问题变成给 Agent 一份可执行计划。程序式记忆可能需要与声明式记忆不同的数据 schema 和评估标准。

程序式记忆与微调的边界

微调是修改模型权重的离线训练过程，周期较长，变更影响面也更广。程序式 Memory 通过在推理时注入合适的 playbook，让 Agent 进行快速的在线适应，不需要改动模型权重。它适合保存可更新的流程和策略，仍需要版本、来源、回滚和安全审核。

生产环境的安全、可靠性与评估

Session 与 Memory 的生产约束

Session 的生产治理需要同时处理安全隐私、数据完整性、生命周期和性能。每次访问都要基于用户或租户身份完成认证和授权，使用 ACL 做严格隔离；PII 最好在写入 Session 前完成脱敏；Session 应配置 TTL、归档和删除策略；事件需要按确定顺序追加。

Session 位于每轮响应的 hot path，读写、网络传输和上下文压缩都要有明确预算。Memory 生成通常需要 LLM 调用和数据库写入，适合由独立服务异步处理。 Agent 推送原始数据，服务后台完成抽取和整合，结果写入持久化数据库，Agent 在后续交互中按需检索。

高并发场景要处理同一 Memory 被同时更新的竞态，可以使用事务或乐观锁，并用队列缓冲高峰流量。瞬态错误需要指数退避重试，持续失败进入 dead-letter queue；全球部署还要让底层存储负责多区域复制，保留一个事务一致的逻辑数据视图。

三层评估指标

Memory 系统的评估要分别回答三个问题：记住的内容是否正确，取回时是否找得到，使用后是否帮助 Agent 完成任务。

评估层	指标	衡量内容
生成质量	Precision、Recall、F1-Score	是否记住正确且相关的信息，是否遗漏应保存的事实
检索性能	Recall@K、Latency	正确记忆是否出现在前 K 个结果内，取回是否满足热路径延迟预算
端到端效果	任务成功率、LLM Judge 与人工基准	使用 Memory 后，Agent 是否在真实任务上表现更好

可先建立一组人工维护的 golden set，再按基线、失败分析、提示词或检索算法调整、重新评估的循环推进。生成与整合虽然常在后台运行，也要测吞吐量、失败率和高并发下的稳定性。

一份最小落地清单

定义 Session、Event、State 和 Memory 的边界，写清哪些信息只在当前任务有效。
为每个 Memory 记录用户或租户范围、来源、时间、新鲜度、可信度和删除路径。
先用滑动窗口或 token 截断控制 Session，再按质量要求增加递归摘要。
把 Memory 生成、整合和清理放到非阻塞后台流程，记录原始事件与派生记忆的 lineage。
根据 Memory 类型选择系统指令、对话注入或 Memory-as-a-Tool，并显式标注来源。
用质量、检索、任务成功、延迟、吞吐和安全用例持续回归，验证每次架构改动的实际收益。

上下文工程把模型调用前的信息组装、Session 的即时状态和 Memory 的长期治理放进同一条工程链路。Session 负责当前对话的低延迟连续性，Memory 负责跨会话的持久化与个性化；可靠性来自合适的信息选择、可追溯的数据生命周期和持续评估。

REFERENCES