长对话上下文工程与记忆管理实战指南

发表于 分类于 本文字数： 2.5k 阅读时长 ≈ 9 分钟

2026 年，Agent 领域的瓶颈已经从「如何让模型答对」转移到了「如何让模型持续答对」。

多轮对话中，每一次工具调用、每一次检索结果、每一段用户追问都在累积消耗上下文窗口。当对话进入第 10 轮、第 20 轮，Token 预算耗尽、有效信息被噪声淹没、关键上下文消失在长序列中间——这些不是边缘情况，而是生产环境中每天都会遇到的现实问题。

Andrej Karpathy 在 2025 年 6 月给出了一个精辟的类比：LLM 是 CPU，上下文窗口是 RAM，工程师的工作就是操作系统，负责在每一步加载正确的信息。 当任务从单轮问答变成多轮 Agent 工作流时，真正决定成败的不再是提示词写得有多巧，而是整个上下文管道设计得有多好。

上下文工程与长对话记忆管理

上下文工程：从 Prompt Engineering 到 Context Engineering

2026 年 AI 工程界出现了一个显著的概念迁移：从 Prompt Engineering（提示词工程）到 Context Engineering（上下文工程）。

Anthropic 工程团队将 Context Engineering 定义为：「在 LLM 推理过程中，精心策划和维护最优 Token 集合的策略，包括所有可能进入上下文的、提示词之外的信息。」

维度 Prompt Engineering Context Engineering
范围 单个指令字符串 推理时的完整 Token 集合
状态 无状态 / 单轮 有状态 / 多轮 / 持续数小时
优化目标 更好的措辞、更少的歧义 上下文窗口内的信噪比
失效模式 模型误解任务 信息太多、太少、或错误

区分两者的最简单标准：如果你的改进来自改写措辞，你还在做 Prompt Engineering；如果你的改进来自改变 Agent 检索什么数据、以什么顺序、何时压缩、何时丢弃——你已经进入了 Context Engineering。

上下文工程的四大支柱

Sourcegraph 在 2026 年 5 月的实践中，将 Context Engineering 归纳为四个支柱，每个支柱回答一个不同问题：

1. Instructions / System Prompt

指令层是模型在见到用户第一条消息之前就知道的角色、约束和输出格式。核心技巧是找到「金发姑娘区」——既不够具体到变成僵化的 if-else 规则，也不至于模糊到让模型自由发挥。最常见的失效不是指令太长，而是与模型训练时的默认行为冲突。

2. Retrieval

检索是外部数据进入上下文窗口的通道。包括经典 RAG（向量数据库）、结构化 SQL 查询、文件系统读取，以及 Anthropic 提出的 just-in-time retrieval——只有当需要时才将底层内容拉入上下文。生产环境中，检索质量通常是幻觉和非地面化回答的最大来源。

3. Memory

Agent 记忆分为两个物种：

  • 短期记忆：当前对话历史，包括工具调用和结果
  • 长期记忆：跨会话持久化的信息，如用户偏好、项目约定、历史对话摘要

生产系统中的记忆通常两者兼具，并在上下文开始填满时执行压缩步骤，将旧轮次压缩为摘要。Anthropic 描述的 structured note-taking 模式让模型将草稿写到上下文窗口外的文件中作为持久记忆，需要时再读回。

4. Tools

可用工具是 Agent 可调用的可执行表面。这是 Context Engineering 中最无情的层面——每个工具定义消耗 Token，每个工具调用返回结果消耗 Token，模糊的工具集让模型浪费轮次在几乎相同的工具之间做决定。Anthropic 的经典观察：「如果人类工程师无法明确判断在给定情况下应该用哪个工具，就不应该期望 AI Agent 做得更好。」

上下文失效的四大模式

Context Rot（上下文腐败）

Chroma 的研究团队在 2025 年发表的 Context Rot 论文表明：随着输入 Token 数量增加，模型准确召回信息的能力会下降。 即使使用稀疏注意力和 Flash Attention 优化，更大的上下文窗口仍然意味着更高的延迟、更高的成本，以及检索困难。这不是模型 bug，是 Transformer 架构的数学属性。

Lost in the Middle（中间迷失）

Liu 等人 2023 年的经典论文发现：模型对上下文开头和结尾的信息表现最好，中间的信息显著退化——即使在专门训练为长上下文的模型中也如此。这意味着上下文组装的顺序至关重要：把高信号内容放在最前面或最后面，而不是埋在 30K Token 的检索块中间。

Context Distraction（上下文干扰）

太多无关材料挤占了重要上下文的空间。实践中的一个典型场景：Agent 在单轮中检索了 50 个候选块，把所有内容都塞进上下文，效果反而不如用重排序器精挑出 top-5。

Budget Exhaustion（预算耗尽）

Token 预算耗尽是最直观的失效模式。但更危险的是「渐进式耗尽」——每次调用工具后都追加结果到历史中，从不裁剪。Arize AI 在构建其 Agent Alyx 时遇到的就是一个典型案例：当上下文超过 Provider 限制时，Agent 报错退出，但导致问题的 Span 仍然在会话中。下次运行时得到相同的超大上下文，加上新的内容，陷入死循环。

记忆管理策略对比

记忆管理策略对比

中间截断 + 外部存储（推荐）

Arize AI 在 Alyx 实践中落地的方案：截断中间而非边缘，保留有意义的首尾片段，同时为每个截断块分配 ID，将完整版本存储在外部内存中，并给 Agent 提供检索工具。

1
2
3
原始：[首段 500 字符]...[中间 5000 字符]...[尾段 500 字符]
截断后：[首段 500 字符]  [truncated: id=abc123, 5000 chars]  [尾段 500 字符]
Agent 按需调用：fetch_full(id=abc123)

这种方式的优点：大多数情况下首尾信息足够回答问题，少数需要详细信息时数据仍在，只是不在上下文中占位置。

LLM 摘要压缩（理论好，实际差）

Arize AI 坦率承认：用 LLM 对消息历史进行摘要压缩看起来非常诱人，但实践中站不住脚。问题是它本质上有损，而且损失不可预测。模型并不能一致地识别出哪些信息之后会重要，做出看起来合理的判断，结果却是用户三轮后引用某个具体内容时 Agent 已经遗忘了。Arize 的结论：结构化的方法（中间截断、内存工具、子代理隔离）目前远比概率性压缩可靠。

子代理隔离（最干净方案）

Arize AI 认为这是他们找到的最强大的上下文管理技术：将重数据任务移到主对话之外。搜索子代理是一个典型案例——搜索任务可能涉及阅读十几个网页、运行多次关键词查询、抓取内容并评估相关性，这些数据几乎都不需要在主对话线程中留存。子代理完成工作后返回一个摘要，其上下文消失，不会在主线程中累积。

立即可用的实践清单

对于正在构建或优化 Agent 的用户，以下是可以直接落地的做法：

  1. 不要在每次迭代中重发 System Prompt：System Prompt 只需在会话开始时发送一次，之后它已经在上下文中了。重复注入只是浪费 Token。

  2. 工具调用去重：如果同一个工具用相同参数被调用两次，只保留最后一次结果。没必要把两份相同输出带到后续的每一个轮次中。

  3. 工具结果用后即弃：一旦工具结果被整合进计划或回复中，原始响应不需要留在消息历史中——信息已经反映在 Agent 的后续行为里。

  4. 截断中间，而非首尾：保留足够的开头和结尾作为信号，中间部分用 ID 索引到外部存储。这比简单地截取前 100 个字符有用得多。

  5. 用文件系统思维管理大数据：当工具返回数十万 Token 的 traces 或 spans 时，不要在上下文中塞入完整数据。存储完整版本，给 Agent 一个预览和一个稳定句柄（如 json_id），让 Agent 按需拉取目标切片。这改变了 Agent 的工作模式：从「记住一切」到「知道如何检索」。

  6. 评估上下文管理效果：上下文管理 bug 很难复现。一个会话刚开始工作正常，到第 11 轮就出问题了。Arize 的教训是：扩展评估框架以支持长会话模拟——预加载 10 轮对话，然后在第 11 轮运行评估。

总结

Context Engineering 不是 Prompt Engineering 的升级版，而是不同的工程层次。Prompt Engineering 教你如何在单次 LLM 调用中说清楚一件事，Context Engineering 教你如何为持续运行的 Agent 构建信息管道。

当模型拥有 200 万 Token 的上下文窗口时（如 Gemini），更大的窗口缓解了部分压力，但并未消除根本问题——Context Rot、Lost in the Middle、Context Distraction 仍然存在。无论窗口多大，Agent 都应该只看到当前任务需要的信息，而不是把整个宇宙塞进去。

未来属于那些懂得设计上下文管道的人，而不仅仅是写得好的提示词。