真正可扩展的智能体上下文工程：四大策略

生产环境中的智能体存在一种失效模式，大多数工程师都是通过惨痛的教训才发现的：你的智能体在最初的几步表现良好，但在任务执行到一半时开始出现幻觉，遗漏了开头明确给出的细节，或者发出了一个与二十步前的指令相矛盾的工具调用。模型没有变。任务没有变难。上下文变了。

长时间运行的智能体积累历史记录的方式就像浏览器标签页消耗内存一样——无声无息、永不停歇，直到崩溃。每一个工具响应、观察结果和中间推理轨迹都会被追加到窗口中。模型会看到这一切，这意味着它在后续的每一步都必须对所有内容进行推理。随着上下文的增长，精度会下降，推理能力会减弱，模型会遗漏本应捕获的信息。这就是“上下文腐烂”（context rot），也是生产级智能体最常见的失效模式之一。

上下文工程（Context engineering）——即决定什么内容在什么时候以何种形式进入智能体的上下文窗口的学科——已成为智能体 AI 开发的核心能力。一种被广泛传阅的说法将其描述为“构建 AI 智能体的工程师的首要任务”。解决这个问题有四种基本策略：将上下文写入外部存储、从该存储中选择上下文、压缩已在窗口中的上下文，以及在独立的智能体进程中隔离上下文。每种策略解决不同的失效模式。理解何时使用哪种策略以及如何组合它们，是让智能体在第 50 步就开始退化还是在第 500 步依然稳健的分水岭。

策略 1：将上下文写出窗口

防止上下文腐烂最直接的方法是根本不让它累积。将信息写入外部存储，并在活跃上下文中仅保留一个轻量级引用。

这有几种形式。最简单的是“草稿垫”（scratchpad）——一个专门的笔记文件或结构化状态字段，智能体在工作时会将关键发现记录在其中。Claude Code 通过待办事项列表和工作笔记文件实现了这一点。智能体不需要重新读取之前每一个工具的响应来记住它学到了什么；它只需阅读自己的笔记。

对于大型工具输出，基于阈值的方法更有效。LangChain 的 Deep Agents 框架在工具响应超过 20,000 个 token 时会触发自动转储——内容被保存到文件系统中，上下文则接收一个文件路径加上前十行的预览。智能体在需要时可以检索完整内容，但不会在后续的每一步中都带着它。

Manus，一个自主通用智能体，通过文件系统操作采取了类似的方法。当智能体浏览网页时，它可以保存相关内容，然后从上下文中清除网页——保留 URL 作为轻量级指针，而不是全文。这种“删除但保留指针”的模式具有惊人的威力。信息保持可恢复状态，而不占用注意力预算。

这里的心理模型是传统操作系统中的 RAM 与磁盘。快速、有限、昂贵的内存用于活跃推理；较慢、较便宜的存储用于其他一切。如果智能体将上下文窗口视为 RAM 而不是只许追加的日志，它们的反应会保持得长久得多。

策略 2：即时选择上下文

“写入”策略移除了内容。“选择”策略则在需要时带回正确的子集。

最原始的版本是检索增强生成（RAG）：对存储的内容进行向量化，在需要时按相似度查询，并注入排名最高的结果。这对于简单的查找有效，但在复杂的智能体任务中表现挣扎，因为内容的关联性往往取决于尚未发生的推理。

更复杂的选择策略是在上下文中保留轻量级标识符——文件路径、文档 ID、URL——并按需检索内容。智能体不是在会话开始时预加载每个可能相关的文档，而是在工作过程中发现自己需要什么，并通过有针对性的工具调用来获取。这就是“即时检索”（just-in-time retrieval）模式。

对于编码智能体，结合了传统 grep 和抽象语法树（AST）解析与语义相似度的混合检索，往往优于纯嵌入（embedding）搜索。智能体可以根据结构进行搜索（查找此函数的所有调用者）以及根据含义进行搜索（查找与身份验证相关的代码），重排序（re-ranking）则协调这两种方法。

工具描述本身也是一个选择问题。当智能体可以访问数十个工具时，在每一步都呈现所有描述可能会在用户发送第一条消息之前就消耗掉 50,000 个 token。渐进式披露（Progressive disclosure）解决了这个问题：工具注册时仅带有简短的发现性描述，只有当智能体第一次调用某个工具时，才会加载完整的 Schema。Anthropic 在 2025 年底规范化了这一模式，随后被 OpenAI、Google、GitHub 和 Cursor 迅速采用。

策略 3：压缩现有内容

有时内容无法被外置，因为智能体需要访问它——但如果保持原样，它又会撑爆窗口。压缩弥补了这一差距。

显而易见的方法是 LLM 摘要化：在继续之前让模型压缩先前的对话历史。这行之有效，但基准测试揭示了一个违反直觉的代价。纯粹的摘要化会使总执行时间增加 13% 到 15%。原因是轨迹延长——摘要步骤消耗了 Token 和时间，智能体必须对摘要进行推理，而且简短的摘要往往丢失了足够的细节，导致后续推理需要更多步骤。你虽然节省了每一步的 Token，但增加了总步数。

在大多数长期运行的智能体基准测试中，观察屏蔽（Observation masking）的表现优于纯摘要化。这种技术的工作方式不同：它不是重写旧内容，而是用占位符 Token 替换旧的观察结果——智能体自身的推理和动作保持完整，但轨迹早期冗长的工具输出则会消失。智能体仍然可以看到它决定了什么以及为什么这样做；它只是看不到 15 个步骤之前的原始网页内容或测试日志。

基准测试结果具有启发性。在 SWE-bench-Verified 上使用大型编码模型，仅靠观察屏蔽就降低了超过 50% 的成本。混合方法——以屏蔽作为主要机制，对关键部分有选择地应用摘要——比单独屏蔽又降低了 7% 的成本，比纯摘要化降低了 11%。任务成功率比未管理的基准提高了约 2.6%。在整个基准测试运行中，优化与未优化的上下文管理之间的成本差异达到了数十美元——这在成千上万次生产智能体运行中会产生巨大的规模效应。

当用量达到可用窗口的 95% 时，Claude Code 会触发自动上下文压缩，应用这种混合方法的一个版本。从几个独立系统中得出的核心见解是：让模型控制压缩决策，而不是应用基于规则的启发式方法。经过训练以识别哪些内容可以安全压缩的模型表现优于固定窗口大小规则，因为对于任务而言，重要的并不总是最近的内容。

策略 4：在智能体之间隔离上下文

有些任务确实需要比任何单个上下文窗口所能容纳的更多信息，无论如何压缩都是如此。多智能体架构通过分散负载来解决这个问题。

标准模式是：一个协调者智能体分解任务并将子问题委派给专门的工作者。每个工作者在专注且有界的上下文中运行——仅包含与其负责的那部分问题相关的信息。只有结果会流回协调者，而不是填满工作者窗口的完整推理踪迹和中间观察。协调者的上下文保持在可控范围内，因为它接收的是摘要，而不是转录文本。

这本质上是一种应用于注意力的分而治之策略。一个如果让单个智能体同时进行 10 个文档分析就会使其不堪重负的研究任务，当每个文档分析都在其独立的隔离上下文中运行时，就会变得易于处理。

状态模式（State schemas）提供了一种更细粒度的隔离方案。Pydantic 模型定义了在每一步中哪些字段对 LLM 可见，而不是在每个提示词中都暴露智能体的完整运行时状态。处理大型文档的智能体可能只能访问当前章节、已积累的发现和下一个目标——而不是整个文档或完整的历史记录。模式（Schema）是一个过滤器，而不不仅仅是一个容器。

隔离的局限性在于协调开销。多智能体系统引入了其特有的失败模式：当子智能体的结果相互矛盾时，协调者层面会出现上下文污染；当智能体拥有不同版本的共享状态时，会出现同步错误；当子智能体调用按顺序链接时，会产生复合延迟。隔离解决了上下文长度问题，但创造了一致性问题。架构需要两者兼顾。

将策略整合在一起

这四种策略并不是替代方案——它们是一个完整方案中互补的层级。

为以后可能需要但现在不需要留在活动窗口中的所有内容编写上下文。准时化（Just-in-time）选择上下文，维护轻量级指针而不是预加载全部内容。压缩那些尽管采用了其他策略但仍积压的内容，以观察屏蔽作为主要工具，并对关键推理进行选择性摘要。当任务确实超出单个智能体的能力时，隔离上下文。

这四种策略的共同点是刻意性（Intentionality）。一个未经管理的智能体上下文是一个仅追加日志，它不断增长直到模型无法清晰地进行推理。而一个管理良好的上下文更像是一个工作记忆——它是有限的、经过策划的，并在整个任务过程中得到积极维护。

那些将上下文视为一等架构关注点（而不是在智能体“跑通”后再去解决的实现细节）的工程师，能够构建出在生产环境中经得起考验的系统。而那些不这样做的工程师会发现，他们智能体性能的天花板就是上下文窗口在开始失效前所能承受的任务长度。