上下文工程：生产级智能体的记忆、压缩与工具清理

大多数生产环境中的 AI agent 失败并不是因为模型耗尽了上下文。它们发生的原因是模型在达到限制之前很久就已经发生了 漂移 (drift)。Forrester 将 “agent 漂移” 称为 AI 加速开发的隐形杀手 —— Forrester 2025 年的研究显示，近 65% 的企业级 AI 失败都可以追溯到多步推理过程中的上下文漂移或记忆丧失，而不是单纯的 token 耗尽。

这种区别至关重要。硬性的上下文限制是很清晰的：API 拒绝请求，agent 停止，你会收到一个可以处理的错误。上下文腐烂 (Context rot) 则是隐蔽的：模型继续运行，继续生成输出，但性能却在悄然下降。仅根据信息在上下文窗口中所处的位置，GPT-4 的准确率就会从 98.1% 下降到 64.1%。你不会收到错误信号 —— 你只会得到微妙的错误答案。

本文涵盖了在生产级 agent 中管理上下文的三种主要工具 —— 压缩 (compaction)、工具结果清理 (tool-result clearing) 和外部记忆 (external memory) —— 以及在你的 agent 发生漂移之前应用它们的实际策略。

为什么上下文管理不仅仅关乎长度

天真的心理模型是：上下文窗口 = token 预算。如果你在限制之内，你就没问题。

现实情况是：模型的 有效 上下文窗口比宣传的限制要小得多。对于目前大多数模型，超过约 128K token 后，注意力机制就开始退化 —— 技术上存在于窗口中的信息所获得的权重比例会降低。这就是上述准确率下降背后的机制。

还有一个容易被低估的复合可靠性效应。在 20 步的工作流中，如果每步的可靠性为 95%，综合成功率将下降到仅 36%。早期引入的 2% 偏差 —— 可能是因为关键指令在不断增长的历史记录中丢失了 —— 会在运行结束时复合成 40% 的故障率。你原本 95% 可靠的 agent 最终只能完成三分之一的任务。

经济因素强化了这一点。生产级 agent 的输入 token 与输出 token 比例约为 100:1。一个不受限制的软件工程 agent 每项任务的成本为 5 到 8 美元。如果每天有 10,000 次交互，一个未经优化的客服 agent 每年成本超过 25 万美元。60% 的压缩削减可以将该成本降至 10.2 万美元。上下文管理和成本管理其实是同一个问题。

三种工具，三种不同的权衡

现代 agent 平台 —— 尤其是 Anthropic API —— 提供了三种不同的上下文管理机制，每种机制都有不同的成本/保真度特征。

压缩 (Compaction)：带推理成本的有损摘要

压缩会将整个对话历史通过 LLM 运行，并用类型化的摘要块替换之前的所有轮次。它在可配置的 token 阈值（默认 15 万 token，最小 5 万）处触发。你需要支付推理成本。结果是对之前发生的所有事情的高保真但有损的表示。

这种权衡是真实存在的。一个 335,279 token 的研究 agent 上下文 —— 其中 96% 是文件读取结果，不到 2% 是实际推理 —— 可以压缩为约 2,800 token 的摘要。这大约是工具输出 120:1 的压缩比。但信息丢失了。哪些信息能保留下来取决于摘要提示词 (prompt) 的编写方式。

这就是自定义指令 (custom instructions) 发挥作用的地方。默认的摘要提示词会对显著性做出通用决策。如果你的任务需要保留每个定量数据及其来源，或者考虑过的每个决策分支，你需要明确指定。自定义指令会完全 替换 默认提示词，因此它们也承担着涵盖默认提示词本应捕捉内容的全部责任。

JetBrains Research (SWE-bench Verified, 2025 年 12 月) 的一项重要发现是：LLM 摘要矛盾地使轨迹长度增加了 13-15%。摘要掩盖了自然的停止信号，导致 agent 在超过其最佳停止点后仍继续尝试。在该研究中，摘要成本超过了每个实例总支出的 7%。这并不意味着要避免压缩 —— 而是意味着单靠压缩并不是一个完整的策略，当你启用它时，你应该监测轨迹长度。

工具结果清理 (Tool-Result Clearing)：机械修剪，无推理成本

工具结果清理更简单且更便宜：它用占位符 [cleared to save context] 替换旧的工具结果，同时保留工具调用记录。Agent 仍然知道进行了调用，但完整的结果已经消失。不涉及 LLM，没有推理成本。

配置项包括：

• trigger: 何时触发（通常是 token 阈值）
• keep: 保留多少个最近的完整结果
• clear_at_least: 每次触发清理的最少 token 数，以确保缓存失效的 ROI (投资回报率)
• exclude_tools: 永远不应清理其结果的工具（记忆、认证 token、任务状态）

关键的设计决策是排除哪些工具。文件读取结果、API 响应、搜索结果 —— 都可以根据需要重新获取，清理它们是安全的。有状态的结果 —— 记忆工具输出、凭据、累积的任务上下文 —— 必须受到保护。

JetBrains 的发现非常有启发性：观察掩码 (observation masking)（一种滚动窗口，仅保留最后 N 个工具结果，并用占位符替换旧结果）实现了 50% 以上的成本节约。对于 Qwen3-Coder 480B，与全上下文方法相比，它在成本降低 52% 的情况下，解决率反而 提高 了 2.6%。目前的最佳实践似乎是：将工具结果清理作为主要机制，将压缩预留给需要跨长对话保留推理逻辑的场景。

外部记忆：窗口之外的持久化状态

记忆工具向智能体（agent）提供其发起的外部存储读写访问权限。操作通常包括查看、创建、替换、插入、删除和重命名。智能体决定存储什么内容；这些存储在上下文重置和会话重启后依然存在。

这是 Claude Code 在长时间会话中使用的 NOTES.md 文件等模式背后的机制。智能体会定期将重要的决策、发现和状态写入外部文件，然后在开启新会话或上下文重置后将其检索。工作记忆窗口保持有限，而情节记录（episodic record）则是无限的。

这三种机制是正交的，旨在相互组合：

• 外部记忆捕获跨会话的学习成果和持久状态
• 工具结果清理在工作累积时保持会话内窗口的有界性
• **压缩（Compaction）**在长对话历史“腐烂”之前对其进行总结

在一个长时间运行多步任务的生产级智能体中，你通常需要同时具备这三种机制。

记忆架构：超越三种工具

了解这三种 API 机制是必要的，但还不够。在它们背后是一个更广泛的记忆分类学，它决定了你如何构建智能体的状态管理架构。

上下文内工作记忆是实时的上下文窗口——访问速度最快，但容量有限。上述所有内容都是关于管理这一层的。

外部情节记忆是基于文件或数据库支持的存储。智能体通过记忆工具显式地进行读写。这是长期状态存在的地方：已做的决策、修改的文件、调用的 API、发现的用户偏好。Mem0 是目前生产中该模式最成熟的独立框架。

分层语义记忆则更进一步，将状态组织为图——节点代表实体（人、文件、任务、决策），边代表关系。MemGPT 开创了这种架构：模型本身管理图，决定存储什么、总结什么以及忘记什么。记忆在调取时会增强，在未使用时会衰减——这是一种刻意模仿人类的遗忘机制。2025 年中期推出的 Amazon Bedrock AgentCore Memory 为生产部署抽象了这种模式，而无需团队自己实现图机制。

通用原则是：上下文内记忆是 RAM，外部记忆是硬盘。工具结果清理和压缩是你的记忆管理层。你既需要硬件，也需要操作系统。

实践配置策略

来自生产部署的一些具体准则：

设置预腐烂阈值，而非硬性限制。 不要等到上下文耗尽才触发压缩——应在有效窗口达到约 70% 时触发（对于有效窗口为 128K 的模型，大约在 90K–100K token 左右）。一旦上下文开始“腐烂”，摘要本身也会质量下降，因为生成摘要的模型已经受损。

显式分配 Token 预算。 通用任务智能体的一个合理初始分配比例：

• 系统指令：10–15%
• 工具定义和 Schema：15–20%
• 检索到的知识背景：30–40%
• 对话历史：20–30%
• 缓冲区预留：10–15%

缓冲区预留不是可选的。没有它，在性能退化开始前你将没有任何余地。

尽量减少工具数量。 研究一致表明，超过一定阈值后，工具越多反而害处越大。在相同的上下文窗口中，对于量化模型，19 个设计良好的工具表现优于 46 个。无关工具选项带来的决策瘫痪会消耗本应分配给任务推理的注意力预算。

采用即时检索而非预加载。 与其在任务开始时将所有可能相关的文件加载到上下文中，不如维护轻量级的标识符（路径、URL、查询词）并按需获取。这实现了渐进式披露：需要时加载内容，完成后清理。

积极缓存静态元素。 系统提示词、工具定义以及在每一轮对话中都会出现的其他静态上下文，应结构化处理以命中 Prompt 缓存（Prompt Cache）。工程良好的缓存可以达到 95% 以上的命中率，将输入成本降低约 90%，并将首字延迟（prefill latency）降低 75%。关键的实现细节是：如果你通过 RAG 动态注入工具定义（每轮选择包含哪些工具），你就会破坏缓存的局域性。稳定位置上的稳定工具集性能优于动态选择。

对隔离工作应用子智能体模式。 子智能体消耗 10,000+ token 进行专注的深度工作，但只向编排器（orchestrator）返回 1,000–2,000 token 的摘要。编排器的上下文保持有限，而专门工作的知识则被记录在摘要中。这是应用于智能体上下文管理的 MapReduce 模式。

衡量问题

如果没有仪表化（instrumentation），这些策略都无法发挥作用。上下文管理决策是优化问题；没有衡量的优化只是猜测。

需要衡量的指标：

• 每个轮次、每个会话、每个智能体类型的 Token 使用情况
• 压缩频率和压缩率
• 工具结果清理频率和回收的 Token 数量
• 决策点处按上下文大小细分的任务成功率
• 启用压缩前后的轨迹长度（注意“总结导致轨迹延长”的效应）
• 每项任务的成本，追踪粒度与成功率一致

最重要的衍生指标：任务完成率作为任务中点上下文大小的函数。这能确切地告诉你智能体的有效窗口在哪里——不是 API 的上限，而是任务成功率开始下降的那个点。

研究框架如 ACE（Agentic Context Engineering，斯坦福/伯克利）和 ACON 将上下文管理视为优化问题并进行实证解决——通过成对的轨迹分析识别智能体失败时丢失了哪些信息，然后迭代总结指南。ACE 报告称，在智能体基准测试中，相比强基准线，平均收益为 10.6%。这种方法比大多数生产团队最初需要的更复杂，但其基本原则——衡量与上下文相关的失败并迭代你的修剪策略——适用于任何规模。

快速上手

如果你处于构建执行多步任务的 Agent 的早期阶段：

1. 从第一天起，就为每一次 LLM 调用添加 Token 预算追踪
2. 对所有可重新获取的工具输出使用工具结果清理机制，并将窗口阈值设为 60–70%
3. 为任何需要在上下文重置后保留的状态添加外部记忆（哪怕只是一个 Markdown 文件）
4. 将压缩（Compaction）预留给必须保留对话推理的场景 —— 而不是将其作为主要的管理机制

如果你已经有一个处于生产环境中的 Agent 在长任务中失败，请先从失败时的上下文大小入手。如果失败集中在上下文填充超过 60–70% 的任务上，那么你遇到了上下文管理问题。如果失败是均匀分布的，那么问题可能出在其他地方。

上下文窗口不是一个你可以忽视并指望模型自行处理的资源。它是你 Agent 的一等架构组件。在第 12 步就开始跑偏的 Agent 与能够可靠完成任务的 Agent 之间的区别，几乎总是取决于你对它的管理有多么用心。

---