Agent 记忆危机：如何优雅解决上下文爆炸与“摘要漂移”？

大家好，我是你们的老朋友，一名在 AI 工程化领域摸爬滚打多年的程序员。

最近在和很多开发者交流时，大家最常问的一个问题就是：“为什么我的 Agent 聊着聊着就‘失忆’了？或者随着对话变长，响应越来越慢，甚至开始胡言乱语？”

这其实触及了构建智能 Agent 最核心的痛点——Memory（记忆）管理。

今天，我们就深入聊聊 Memory 的本质，以及在实际工程中，我们是如何通过架构设计来解决**上下文爆炸（Context Explosion）和摘要漂移（Summary Drift）**这两个棘手问题的。

一、 什么是 Memory？让 Agent “记住过去”

很多初学者容易把 Memory 简单理解为“聊天记录”。但在 Agent 系统中，Memory 的本质是一个上下文管理系统。

如果没有 Memory，LLM（大语言模型）每次交互都是“失忆状态”。它就像《记忆碎片》里的主角，每一轮对话结束后，大脑就被清空。

为什么 Agent 必须需要 Memory？

因为真实世界的任务从来不是单轮问答，而是复杂的连续过程：

• 多轮对话：用户会说“帮我继续分析昨天那个患者”，如果没有记忆，Agent 根本不知道“那个患者”是谁。
• 长任务执行：比如编写一个完整的项目，需要记住之前的代码结构和决策。
• 状态恢复：中间步骤的工具调用结果、用户的长期偏好等。

核心观点：Memory 不是简单的 Log 存储，它是 Agent 的“工作区”和“知识库”。

二、 短期记忆的困境：为什么会“爆炸”？

在 Agent 架构中，我们通常将记忆分为两类：

1. Short-term Memory（短期记忆）：当前任务的上下文，如最近几轮对话、工具调用结果。
2. Long-term Memory（长期记忆）：跨会话保留的信息，如用户画像、历史偏好，通常存储在向量数据库中。

我们今天重点讨论短期记忆。

在主流的 ReAct（Reasoning + Acting）范式下，Agent 的每一轮思考都包含三个部分：

Thought: 我在想什么...
Action: 我要调用什么工具...
Observation: 工具返回了什么...

随着对话轮次增加，这些内容会不断追加到 Prompt 中。这就导致了上下文爆炸：

• Token 暴涨：直接导致 API 成本飙升。
• Latency 变高：处理超长文本的速度显著下降。
• 注意力分散：LLM 的注意力机制在过长上下文中会衰减，导致“大海捞针”效应，关键信息被淹没。

三、 传统解法及其缺陷

面对上下文爆炸，业界最初有两种常见的处理方式，但它们都有明显的短板。

1. 滑动窗口（Sliding Window）

原理：只保留最近的 N 轮对话（例如最近 5 轮），旧的内容直接丢弃。

• 优点：实现极其简单。
• 缺点：丢失长期依赖。如果第 1 轮提到的关键约束在第 10 轮才用到，滑动窗口会导致 Agent 完全忘记这个约束。

2. 全量摘要（Summarization Memory）

原理：当上下文超过阈值时，调用 LLM 将旧对话压缩成一段摘要，替换原始对话。

• 优点：节省了 Token，保留了大致语义。
• 缺点：摘要漂移（Summary Drift）。这是最致命的问题。

什么是“摘要漂移”？

想象一下你把一张 JPEG 图片压缩保存，然后再打开这张压缩后的图片再次压缩。重复多次后，图片会变得模糊不清，失真严重。

同理，**“摘要再摘要”**会导致信息层层丢失。

• 第一轮摘要：“用户关注 CRP 指标。”
• 第二轮摘要：“用户关注血液指标。”
• 第三轮摘要：“用户关注健康数据。”
• …最后 Agent 只知道用户关心健康，却丢了最关键的医疗细节。

四、 企业级解决方案：分层与结构化

为了解决上述问题，现代企业级 Agent 架构不再采用单一策略，而是组合拳。核心思想是：不是“全记”，而是“有选择地保留”。

以下是四种经过实战验证的高效策略：

1. 分层记忆架构（Hierarchical Memory）

不要试图用一个 Summary 概括所有历史，而是将记忆分层：

• Recent Memory（近期记忆）：保留最近 N 轮的原始对话。保证当前交互的精准度。
• Episodic Summary（阶段摘要）：按任务阶段进行总结。例如，“阶段1：完成 LIS 数据分析；阶段2：完成感染风险评估”。这种摘要粒度更粗，但保留了任务脉络。
• Long-term Facts（长期事实）：从对话中提取稳定的事实（如“患者有糖尿病史”），存入结构化存储或向量库，不随对话窗口滚动而消失。

2. 结构化摘要（Structured Summary）

避免使用纯自然语言进行摘要，因为自然语言冗余度高且难以解析。推荐使用 JSON 或 Key-Value 结构来存储核心状态。

错误示范（自然语言）：

“用户之前提到了病人A123，他的CRP有点高，我们一直在监控。”

正确示范（结构化 JSON）：

{
  "patient_id": "A123",
  "risk_level": "high",
  "abnormal_metrics": ["CRP", "WBC"],
  "current_status": "monitoring",
  "last_action": "ordered_lab_test"
}

优势：信息密度极高，几乎无损耗，且方便程序直接读取和使用。

3. 选择性记忆（Selective Memory）

Agent 不应该记录所有的废话。我们需要一个“过滤器”：

• 保留：用户明确偏好、最终结论、关键的工具 Observation（观察结果）、高价值的推理步骤。
• 丢弃：中间的试错过程、重复的 Thought、无效的寒暄、错误的工具调用尝试。

4. 记忆检索（Memory Retrieval / RAG for Memory）

这是最高级的玩法。不要把所有历史都塞进 Prompt。

流程如下：

1. 用户发起新 Query。
2. 将 Query 转化为 Embedding 向量。
3. 在向量数据库（Vector DB）中检索与当前 Query 最相关的历史记忆片段。
4. 只将这些相关的片段拼接到 Prompt 中。

这样，无论对话历史有多长，Prompt 的长度始终控制在合理范围内，且包含的信息高度相关。

五、 架构全景图

一个健壮的企业级 Agent 记忆系统，通常是以下组件的组合：

六、 最佳实践建议

如果你正在开发一个 Agent 应用，建议遵循以下步骤构建记忆模块：

1. 起步阶段：使用 Sliding Window + Structured State。先用 JSON 对象维护核心业务状态，这比任何摘要都可靠。
2. 进阶阶段：引入 Selective Memory。在写入记忆前，加一个 LLM 判断节点：“这条信息重要吗？值得存入长期记忆吗？”
3. 高级阶段：引入 Memory Retrieval。当对话超过一定长度（如 20 轮），启用向量检索，动态加载相关历史。
4. 避坑指南：
   • 严禁无限递归摘要。如果需要更新摘要，请基于“原始对话 + 旧摘要”生成新摘要，而不是仅基于“旧摘要”。
   • 区分“事实”与“观点”。事实（如姓名、日期）应结构化存储；观点和分析可放入向量库。

总结

Memory 是 Agent 的灵魂。解决上下文爆炸的核心，不在于“如何存得更多”，而在于**“如何更聪明地遗忘和检索”**。

通过分层管理、结构化存储和按需检索，我们可以让 Agent 既拥有短期的敏锐反应，又具备长期的知识积累，同时避免陷入“摘要漂移”的失真陷阱。

希望这篇博客能为你构建下一代 AI 应用提供清晰的架构思路。如果有具体的技术实现问题，欢迎在评论区交流！

参考资料：

• LangChain Memory Documentation
• Microsoft Semantic Kernel Memory Concepts
• Paper: Generative Agents: Interactive Simulacra of Human Behavior