Build Hour：代理记忆模式

内容概要

在本期 Build Hour 中，OpenAI 的 Michaela 和 Emre Okcular 探讨了上下文工程 (Context Engineering) 在构建可靠、长运行 AI Agent 中的关键作用。视频涵盖了管理 Agent 记忆的核心策略，包括重塑上下文、隔离与路由信息，以及提取和检索记忆。Emre 深入剖析了如何避免常见的陷阱，如上下文爆发 (Context Bursting) 和上下文投毒 (Context Poisoning)，并使用 OpenAI Agents SDK 进行了现场演示。最后，他在问答环节解答了开发者关于扩展和评估记忆系统的问题。

目录

• 上下文工程 (Context Engineering)

• 上下文生命周期演示

• 上下文工程技术

• 重塑与适配 (Reshape + Fit) 演示

• 总结

• 问答环节

上下文工程 (Context Engineering)

Michaela： 大家好，欢迎回到新一期的 Build Hour。我是创业市场团队的 Michaela，今天我和两位解决方案架构师团队的成员在一起：演播室现场的 Emre，以及在线协助回答问题的 Brian。

Emre： 大家好，我是 Emre。我是 OpenAI 的解决方案架构师，主要支持数字原生客户构建包括长运行 AI Agent 在内的各种 AI 用例。

Michaela： 今天的主题是 Agent 记忆模式。这是我和 Emre 首次合作的 Build Hour，也是一个非常令人兴奋的话题。如果你一直关注我们的系列节目，我们从使用 Responses API 从零构建 Agent 开始，接着讲到了 Agent RFT (Refinement Fine-Tuning)，今天我们将探讨 Agent 的记忆模式。

往期所有视频都已上传至我们的 YouTube 频道。Build Hour 的宗旨是赋予大家最佳实践、工具和 AI 专业知识，帮助大家使用 OpenAI 的 API 和模型扩展公司业务。

今天的 Build Hour 将从介绍作为 Agent 记忆基础的上下文工程开始，然后 Emre 将通过几个现场演示来讲解记忆模式，如重塑与适配 (Reshape and Fit)、隔离与路由 (Isolate and Route) 以及提取与检索 (Extract and Retrieve)。最后我们将分享最佳实践、资源以及进行现场问答。

Emre： 谢谢 Michaela。大家好，我将从定义上下文工程开始。Andrej Karpathy 有一个很好的定义，我想强调的是，上下文工程既是一门艺术，也是一门科学。

说它是艺术，因为它涉及判断力。你必须决定在推理或行动过程的某个特定步骤中，什么信息最重要。说它是科学，是因为通过具体的模式、方法和可衡量的影响，可以让上下文管理变得更加系统化和可重复。我想强调的是，现代大语言模型 (LLM) 的表现不仅取决于模型质量，还取决于你提供给它的上下文。

上下文工程是一个比单一技术（如提示词工程或检索）更广泛的学科。它是一个上下文优化层的生态系统，共同塑造了模型看到和理解的内容。

核心原则包括：提示词工程 (Prompt Engineering)、结构化输出 (Structured Output)、RAG (检索增强生成)、状态和历史管理。记忆也是其中的关键部分，即使用持久或半持久的存储（如文件、数据库或记忆工具）来上传和检索关键信息。所有这些都包含在上下文工程这一更大的范畴内。

长运行且工具调用频繁的 Agent 会通过投毒 (Poisoning)、噪声 (Noise)、混淆 (Confusion) 和爆发 (Bursting) 等方式淹没 Token 并降低质量。因此，我们有三个核心策略：

1. 重塑与适配 (Reshape and Fit)： 适应上下文窗口。

2. 隔离与路由 (Isolate and Route)： 将正确的上下文路由给正确的 Agent。

3. 提取与检索 (Extract and Retrieve)： 提取高质量记忆以便在正确的时间检索。

此外，提示词和工具卫生 (Hygiene) 也是核心原则。保持系统提示词精简、清晰、结构化；使用少量且规范的少样本 (Few-shot) 示例；最大限度地减少工具重叠。我们的北极星指标是：旨在用最小的高信号上下文，最大化实现预期结果的可能性。

我们将这些技术视为一个工具包。大多数现实世界的 Agent 架构会根据用例和上下文预算组合多种策略：

• 重塑与适配： 上下文裁剪 (Trimming)、压缩 (Compaction) 和摘要 (Summarization)。

• 隔离与路由： 通过选择性移交，将上下文和工具卸载给特定的子 Agent (Sub-agents)。

• 提取与检索： 记忆提取、状态管理和记忆检索。

在讨论上下文工程时，区分短期记忆和长期记忆至关重要。前两类技术（重塑与适配、隔离与路由）通常属于短期记忆，即会话内 (In-session) 技术，旨在充分利用当前交互中的上下文窗口。而最后一类属于长期记忆，即跨会话 (Cross-session) 技术，旨在建立跨会话的连续性。

即使现在的 Agent 越来越强大，可以处理复杂任务、规划多步工作流，但底层仍存在瓶颈：上下文是有限的。我们添加到提示词中的每一条信息——指令、对话历史、工具输出——都在争夺固定的 Token 预算。

为了具体说明，我们可以对比一下“无记忆”和“有记忆”的情况。

• 无记忆： 用户向 IT 故障排查 Agent 提出了 Wi-Fi、电池和过热等问题。经过多轮对话后，Agent 忘记了早期的上下文，不得不重新询问用户已经提供过的信息。

• 有记忆： 即使经过多轮对话，Agent 依然记得最初的问题，能够拾起未解决的线索，并引用之前的操作（如固件更新），这让它看起来既智能又可靠。这种有状态 (Stateful) 的行为是长运行 Agent 的基础。

我们将失效模式分为四类：

1. 上下文爆发 (Context Burst)： 由于缺乏外部控制或调用增加，导致单个或多个组件突然出现 Token 激增。

2. 上下文冲突 (Context Conflict)： 上下文中存在相互矛盾的指令或信息。

3. 上下文投毒 (Context Poisoning)： 错误信息进入上下文并随对话轮次传播。这可能源于摘要、记忆对象或注入的状态对象。

4. 上下文噪声 (Context Noise)： 上下文中同时涌入过多（可能是冗余或过于相似的）工具定义。

例如，上下文爆发常见于工具密集型工作流，某一个轮次中突然注入大量工具 Token。上下文冲突可能发生在系统指令规定“保修失效不退款”，但某个工具返回信息说“VIP 客户可退款”，导致 Agent 产生困惑。上下文投毒则类似幻觉或不准确信息混入上下文（例如通过有损的摘要），并在后续轮次中被当作事实传播。

上下文生命周期演示

我准备了一个演示应用，这是一个基于 Next.js 和 OpenAI Agents SDK 构建的双 Agent 演示。这是一个处理软硬件问题的 IT 故障排查 Agent，连接了两个工具：get orders (获取订单) 和 get policy (获取政策)。

我同时向两个 Agent 发送消息。起初，它们的配置相同（相同的模型和推理级别），且都没有配置记忆功能。

当我输入“我的笔记本电脑风扇在玩游戏时有噪音，这正常吗？”并接着说“我想查看我的订单，订单号是 12345”时，模型会调用工具显示订单状态。在上下文生命周期视图中，我们可以看到系统指令、用户输入以及由模型生成的 Agent 输出（包括工具调用）是如何随时间积累 Token 的。

接下来我展示上下文爆发。我提到笔记本过热问题，然后说：“在此之前，我想看看我的 MacBook Pro 2014 的退款政策。” Agent 调用 get refund 工具，返回了大量的退款政策文本。

在生命周期视图中，我们可以看到在第 2 轮和第 3 轮之间出现了一个巨大的峰值。第 2 轮可能只有几百个 Token，但第 3 轮瞬间超过了 3000 个 Token，因为我们把大量信息倾倒进了上下文。这便是一个典型的上下文爆发案例。与其倾倒所有信息，我们应该更谨慎地定义工具和处理工具输出，只注入有价值的信息。

上下文工程技术

解决方案在于通过裁剪、压缩、状态管理和记忆等技术有效地管理上下文。

我们可以根据上下文概况将 AI Agent 分为三类：

1. RAG 密集型助手： 如报告分析、政策问答。上下文主要由检索到的知识和引用占据。

2. 工具密集型工作流： 上下文主要由频繁的工具调用和返回的负载 (Payloads) 占据。

3. 对话式管家： 如规划 Agent、教练 Agent。上下文主要由不断增长的对话历史占据。

在上下文中，系统指令、工具定义通常是静态的；而工具结果、检索到的知识、记忆和对话历史是动态的。我们主要针对动态 Token 应用控制技术。

提示词最佳实践（避免上下文冲突）：

• 明确且结构化： 使用清晰、直接的语言。

• 留出空间： 给模型留出规划和自我反思的空间（对于推理模型尤为重要）。

• 避免冲突： 保持工具集精简且互不重叠，避免模棱两可的定义。

应对上下文噪声：

• 更多的工具并不总是意味着更好的结果，应倾向于边界清晰的针对性工具。

• 从工具返回有意义的上下文。控制工具输出，仅返回高信号、语义上有用的字段。

工程技术详解：

1. 重塑与适配 (Reshape and Fit)：

   • 上下文裁剪 (Trimming)： 保留最近的 N 轮对话，丢弃旧的。这能带来新鲜的上下文和更快的处理速度，但可能会丢失早期信息。适用于工具密集型操作和短工作流。

   • 上下文压缩 (Compaction)： 保留对话消息，但丢弃旧轮次中的工具调用结果。这能保留对话流，同时去除冗长的工具数据。

   • 上下文摘要 (Summarization)： 将之前的消息压缩成结构化的摘要，并作为记忆对象注入回上下文中。这能保留关键信息（“黄金摘要”），便于后续查阅。

裁剪与摘要的对比：

• 裁剪： 简单、快速、无延迟，但会丢失信息。如果任务之间相互独立，裁剪是很好的选择。

• 摘要： 保留信息，建立连续性，但会增加延迟和成本（需要额外的模型调用）。如果任务相互依赖，建议使用摘要。

关于何时触发的启发式建议：

• 分析会话数据，查看平均 Token 大小。

• 不要在轮次中间 (Mid-turn) 裁剪，要以完整的用户-助手交互为单位。

• 不要等到撞上上下文上限才行动，可以设置 40% 或 80% 的阈值来触发这些操作。

重塑与适配 (Reshape + Fit) 演示

回到演示应用，我将展示这些技术。

裁剪演示： 我将 Agent P 的裁剪触发设置为“最大 3 轮”，并保留“最近 3 轮”。 我开始对话，查询退款政策，检查订单，然后报告网络连接问题。此时上下文中积累了大量工具 Token。当对话进行到第 6 轮时，由于触发了裁剪机制，之前的工具输出和旧消息被移除，上下文变得清爽。

摘要演示： 这次我启用摘要功能，设置触发阈值。我详细描述了我的设备情况：“MacBook Pro 14英寸，2014款，购于阿姆斯特丹，居住在美国，刚换过电池，上周更新到了 macOS Sequoia。” 我还列举了尝试过的步骤：“查过 FAQ，试过硬重启，但没用。”

Agent 给出建议后，我继续反馈 Wi-Fi 图标不亮的问题。此时，在第 4 轮和第 5 轮之间，系统执行了摘要操作。我们可以在界面上看到一个橙色的记忆组件 (Memory Component)。

这个记忆是通过一个精心设计的摘要提示词 (Summary Prompt) 生成的。我在提示词中要求模型：

• 注意矛盾，确保时间顺序，控制幻觉。

• 生成结构化的事实摘要，包括产品环境、报告的问题、已尝试的步骤（包括哪些有效、哪些无效）、关键时间节点和当前状态。

结果生成的摘要非常详实：它记录了设备型号、操作系统版本、购买地与居住地不一致、换过电池这一关键里程碑，以及已排除的故障步骤。

长期记忆 (跨会话) 演示： 现在我重置 Agent，但开启“跨会话”功能。这将把刚才生成的摘要注入到新会话的系统提示词中。 当我再次发送“Hi”时，Agent 回复：“很高兴再次见到你。你的 MacBook 在更新 macOS Sequoia 后还有网络连接问题吗？” 这展示了高度的个性化。当我问“如何更新到 macOS Tahoe”时，Agent 会根据已知设备型号（2014 款）给出针对性的建议，因为它“记得”我的硬件信息。

在记忆指令中，我添加了护栏：“不要存储机密信息”、“避免覆盖记忆”，并设置了优先级规则，防止模型过度关注记忆对象而忽略当前指令。

总结

Emre： 我还想简要介绍其他几项技术。

• 隔离与路由 (Isolate and Route)： 将特定的上下文和工具卸载给子 Agent。这能最大限度地减少上下文冲突和投毒。

• 记忆的形状： 记忆可以是多种形式。建议从简单开始，根据需要演进。可以使用 JSON、简短笔记，甚至是一个段落。

• 提取 (Extraction)： 使用记忆工具在实时对话中提取记忆（如保存为 JSON 或 Markdown）。

• 状态管理： 定义一个包含目标和信息的状态对象，并在轮次间或新会话中注入。

• 检索 (Retrieval)： 类似 RAG 方法。将记忆存储在向量数据库中，在实时对话中进行搜索、过滤、排序并注入回 Agent。

Agent 记忆设计的最佳实践：

1. 理解典型上下文： 定义什么对你的 Agent 是有意义的。

2. 决定何时记忆与遗忘： 将稳定的、可重用的事实升级为记忆；主动遗忘过时或低置信度的信息。持续清理、合并和整合记忆。

3. 评估 (Evals)： 运行评估以对比开启记忆功能前后的效果。针对长运行任务构建专门的记忆评估。

问答环节

Q1：是否有推荐的上下文工程库或包？ A： 本演示使用的是 OpenAI Agents SDK。它提供了很大的灵活性来实施裁剪、压缩和摘要等技术。虽然有很多库正在快速发展，但我建议以 OpenAI Agents SDK 为起点。

Q2：如何评估或衡量记忆功能是否提升了性能？ A： 1. 运行常规评估 (Evals)，对比有无记忆功能的指标（如完整性、点赞/点踩率）。 2. 构建基于记忆的评估。专门评估长运行任务和长上下文。 3. 评估记忆本身的质量（例如摘要是否准确、注入时间是否合理）。你需要准备一个“黄金数据集”作为标准。 4. 利用启发式方法找到裁剪和压缩的最佳平衡点。

Q3：我们是否应该使用分层上下文（如项目级上下文用于即时任务）？ A： 是的，这很有用。这涉及到记忆作用域 (Memory Scope) 的概念。

• 全局作用域： 关于用户的长期事实（如“用户住在与其，喜欢友好的语气”）。

• 会话作用域： 当前任务的具体偏好（如“这次旅行我想坐靠窗座位睡觉”）。 最佳实践是将两者分开，并随着时间推移将重要的会话记忆“毕业” (Graduate) 为全局记忆。

Q4：有什么策略可以保持记忆新鲜或修剪陈旧记忆？ A： 1. 时间标签 (Temporal Tags)： 给记忆打上时间戳。如果我两个月前说喜欢狗，今天说喜欢猫，模型会根据时间理解我的偏好变了，从而覆盖旧记忆。 2. 衰减函数 (Decay Function)： 对记忆应用权重衰减，优先考虑最近的记忆。 如果所有记忆都同等重要，使用时间标签和记忆整合（覆盖）；如果旧记忆不再重要，则使用衰减策略。

Q5：当有许多用户且包含个人及共享记忆池时，如何扩展 Agent 记忆系统？ A： 这主要取决于你采用的方法：

1. 如果使用基于检索的长期记忆（类似 RAG），你需要考虑向量数据库的扩展技术，如分片 (Sharding)、优化 Embedding 模型和检索过程。

2. 如果是基于摘要的存储，则更多是关于文本数据的存储管理。 对于像“生活教练”这样记忆极其丰富且快速演进的 Agent，扩展性挑战比简单的“旅行管家”要大得多，通常需要复杂的检索系统优化。

Michaela： 感谢大家的参与。我们在资源部分链接了上下文工程手册 (Context Engineering Cookbook) 和 Agents Python SDK。演示代码也会上传到 GitHub。这是我们今年的倒数几场 Build Hour 之一，请持续关注。感谢 Emre 的精彩分享！

Emre： 谢谢大家。希望大家学会了如何思考 Agent 应该记住什么、如何记住以及如何遗忘。这是一个不断发展的领域，请根据你的具体用例在这些设计权衡中找到平衡。下次见！