AI 智能体的有效上下文工程

2025 年，近 65% 的企业级 AI 失败归因于多步推理过程中的上下文偏移（context drift）或记忆丢失 —— 而非模型能力问题。如果你的智能体（agent）在执行长任务时决策失误或失去连贯性，最可能的原因不是模型，而是上下文窗口（context window）中的内容。

“上下文工程”（context engineering）一词正在迅速普及，但其背后的学科内容是具体明确的：即在智能体运行轨迹的每一个推理步骤中，主动、刻意地管理进入和离开 LLM 上下文窗口的内容。它不是一段提示词（prompt），而是一个由工程师设计、供智能体遍历的动态信息架构。上下文窗口的作用类似于 RAM —— 有限、昂贵，且如果你不进行刻意管理，就会出现抖动（thrashing）。

本文涵盖了生产级智能体在长任务中保持连贯性的四种核心策略：外部化写入状态、选择性调取上下文、压缩累积内容以及跨多个智能体隔离工作。这些策略并非互斥 —— 最稳健的智能体通常会结合使用这四者。

为什么提示词工程还不够

提示词工程是一个离散的行为：你编写指令，发送出去，然后等待回复。对于单轮查询，这种模式没问题。但对于运行数十甚至数百轮的智能体 —— 涉及浏览、写作、执行代码、委派子任务 —— 挑战则完全不同。

上下文窗口不是一份记录，而是一个工作空间。Transformer 计算 Token 之间的两两关系；每增加一个 Token，计算成本都会呈二次方增长，且随着容量增加，注意力质量也会下降。研究人员称之为“上下文腐烂”（context rot）：随着上下文长度的增长，模型召回和推理窗口中间位置特定细节的能力会下降。这种失效是渐进的而非突发的，这使得调试变得尤为危险。

工程问题不在于“写一个更好的系统提示词”。而是在多步智能体运行轨迹的每一步，确保窗口包含信号量最大的内容和最少的噪音。这需要架构设计，而不仅仅是文案创作。

策略 1：写入 —— 将智能体稍后需要的内容外部化

最基础的上下文工程技术就是停止将所有内容都留在上下文窗口内。通过将结构化笔记写入外部存储（文件、数据库、专用记忆工具）的智能体，可以精准检索所需内容，而不是无限期地携带完整的历史记录。

这在两个时间尺度上发挥作用。

会话内状态的草稿垫（Scratchpads）：设计良好的智能体在执行过程中会将结构化的中间输出 —— 计划、部分结果、未解决的问题 —— 写入外部存储。这不是日志记录；而是对智能体工作状态的有意识序列化，以便在同一次运行的后续步骤中以聚焦、精简的形式检索。

跨会话的长期记忆：在实践中起作用的三种类型是情节记忆（episodic，所需行为的少样本示例）、程序记忆（procedural，如项目特定配置文件等长期指令）和语义记忆（semantic，事实和项目知识）。这三者都可以通过智能体的反思增量生成，将过去运行中的观察结果综合成持久且可检索的形式。

一个有用的测试：如果你追踪智能体运行 50 轮后上下文窗口中的每个 Token，其中有多少比例对于当前步骤仍然是必要的？如果答案低于 50%，那么该智能体正在积累本应外部化的状态。

策略 2：选择 —— 在正确的时刻拉入相关信息

与预先加载上下文相对的方案是即时（just-in-time）检索。智能体不是在初始化时将整个代码库、文档库或对话历史预处理到窗口中，而是维护轻量级的引用 —— 文件路径、查询字符串、标识符 —— 并在运行时动态获取所需内容。

这种模式被称为即时上下文加载（just-in-time context loading），它模仿了优秀人类的工作方式：我们使用索引，而不是背诵百科全书。智能体知道去哪里看，而不需要随身携带可能用到的一切。

几个实际应用点：

基于工具的检索是一等策略：文件读取器、语义搜索和数据库查询等工具不仅仅是任务执行器，它们也是上下文注入机制。设计好这些工具意味着它们能以不因样板文件而导致上下文膨胀的格式，返回必要性最高、相关性最强的内容。

RAG 同样适用于工具，而不只是知识：生产团队已将检索增强生成（RAG）应用于工具描述 —— 动态呈现与当前任务最相关的可用工具子集。这减少了歧义，也降低了模型在评估无关选项时必须消耗的认知负荷。

新鲜度至关重要：即时加载避免了预先计算嵌入并忘记更新的系统常遇到的索引陈旧问题。权衡之处在于每次检索调用都会增加延迟，这值得进行明确的测量。

一个粗略的原则：始终加载稳定的且必需的内容（程序记忆、高层指令）；按需检索容量大且仅偶尔相关的内容（项目文件、历史片段、用户偏好）。

策略 3：压缩 —— 缩减累积的内容

即使在仔细编写和选择性加载的情况下，上下文依然会累积。30 个步骤前的工具输出、早已解决的错误消息、子智能体（sub-agent）长达数段的响应 —— 除非你主动移除，否则这些内容都会留在窗口中。压缩策略的目的就是在不丢失智能体所需信息的前提下，管理这些累积的内容。

在生产环境中，有两种压缩技术占据主导地位：

摘要（Summarization）：将消息历史传递给模型，并附带明确指令，要求生成一个高保真的摘要。该摘要需保留架构决策、未解决的 bug、文件修改和待处理的子任务，同时丢弃冗余的工具输出以及不再具有执行价值的中间推理过程。设计的关键在于决定保留什么。文件路径、特定的错误消息以及已做出的决策通常是需要明确保留的高价值项目。

来自大规模生产代码库的评估数据表明，结构化摘要（包含会话意图、文件修改、已做出的决策和后续步骤的明确章节）在表现上明显优于简单的截断（naive truncation），尤其是在与交付物（artifact）追踪相关的准确性指标上。普遍存在的薄弱环节是在压缩过程中追踪文件修改历史；这需要专门的处理，而非通用的摘要。

工具结果清理（Tool result clearing）：这是最轻量级的干预。一旦工具输出被消耗并且相关信息已被提取，就将其从上下文中清除。三个轮次前获取的 50KB 文件列表几乎没有任何价值，却占据了大量的上下文空间。

这里优化的目标至关重要：如果简单的压缩导致智能体重新获取已经拥有的信息，那么效率提升就会被抵消。正确的指标不是“单次请求消耗的 token”，而是“完成每个任务步骤消耗的 token”。

针对长周期智能体任务的上下文压缩研究发现，当压缩决策基于下游任务结构而非统一应用时，峰值 token 使用量可减少 26–54%，同时基本保持任务性能。

策略 4：隔离 —— 将工作分配到干净的窗口中

当一项任务真正超出了单个上下文窗口所能连贯处理的范围时，答案不是塞进更多内容，而是拆分工作。多智能体架构将专门的子智能体分配给专注的子任务，每个子智能体都在干净的上下文窗口和狭窄的范围内运行。

在实践中行之有效的模式是：主智能体（lead agent）维持任务的宏观视图，并将专注的子任务委托给子智能体。每个子智能体可以在其自身的窗口内进行广泛探索（产生数万个 token 的中间工作），但向主智能体返回一个压缩后的摘要（通常为 1,000–2,000 个 token）。这创建了一个清晰的信息层级：细节在边缘处理，综合在中心完成。

两种交互模式值得区分：

将智能体视为工具：主智能体调用子智能体的方式就像调用任何工具一样 —— 传递专注的提示词而不带入祖先历史。子智能体不知道更广泛的任务上下文；它解决一个狭窄的问题并返回结果。这是最干净的隔离，但需要主智能体在不同抽象层级之间进行转换。

智能体交接（Agent handoff）：完全的控制权转移，并伴随可配置的上下文包含。生产团队通过惨痛教训学到的一个实现细节是：在交接期间，先前的 "Assistant" 轮次应被重构为带有归属标记的叙述性上下文（例如 “前一个智能体尝试了 X”），而不是逐字传递。传递原始的 assistant 轮次会导致接收端的智能体将前一个智能体的行为误认为是其自身的能力。

多智能体架构消耗的总 token 量显著高于单智能体运行 —— 常见的数据是 10–15 倍。这是一项必须考虑的实际成本。其合理性在于实现了在单个窗口内无法完成的任务分解，以及并行运行子智能体的能力。

系统提示词设计：“金发姑娘”问题

系统提示词设计处于上述四种策略的交汇点。设计拙劣的系统提示词会造成持续的上下文压力 —— 脆弱、过度指定的指令必须随每个边缘情况进行更新；或者模糊的指令导致模型为了填补本应明确的信息而进行昂贵的推理调用。

失败模式是对称的：

太具体：用自然语言编写硬编码逻辑，一旦系统发生变化就会失效。维护负担重。泛化能力低。

太模糊：模型做出的假设与系统的实际约束不符，产生的输出需要纠正，并消耗额外的上下文进行修复。

实际的折中方案：使用明确的结构化标记将系统提示词组织成不同的部分 —— 背景、指令、工具指南、输出格式。提供所需行为的多样化典型示例（canonical examples）而不是详尽地罗列边缘情况。示例比规范更有价值：它们向模型展示了理想的行为模式，而不仅仅是描述它。

将工具设计视为上下文工程

工具模式（Tool schemas）会消耗 token。模糊的工具设计消耗得更多 —— 当模型无法确定哪个工具适用于当前情况时，它要么胡乱猜测（产生错误），要么浪费推理 token 来解决歧义（将上下文消耗在非任务工作上）。

测试一个设计良好的工具集的标准是：给定一个场景，你是否能毫无歧义地确定该使用哪个工具？如果不能，智能体的表现也会成比例地变差。工具之间的功能重叠是上下文效率的低下，而不仅仅是设计上的不便。

工具响应的设计同样重要。当智能体只需要一个函数定义，而工具却返回了整个大文件的内容时，这就是上下文工程的失败。工具应该返回最少必要且最大相关的内容，并进行格式化以避免无关的框架或样板代码。

分层上下文模型

最连贯的生产级框架将上下文视为分层状态系统上的编译视图，而不是一个随着每一步操作不断追加内容的易变字符串。

在成熟的实现中出现的层级结构：

• 工作上下文 (Working context)：单次调用的编译提示词 —— 系统指令、筛选后的历史记录、此步骤相关的工具输出。
• 会话存储 (Session store)：持久的时序事件日志 —— 将每条消息、工具调用和控制信号记录为结构化记录。
• 记忆存储 (Memory store)：长期的可搜索知识 —— 偏好、过去的决策、项目事实。
• 制品存储 (Artifact store)：通过句柄引用的具名、版本化的大型对象，从不直接嵌入。

上下文编译 —— 将持久的会话和记忆存储转换为单次调用的工作上下文 —— 变成了一个显式、可观察的流水线步骤。流水线中的每个处理器都是过滤、压缩、缓存和路由的插入点。这用可测试和可调试的机制取代了临时的提示词模板化。

这种模型带来的一种结构优化是：将工作上下文分为稳定前缀（系统指令、长期摘要）和变量后缀（最新的用户轮次、新的工具输出）。稳定前缀可以在模型提供商级别进行缓存，对于在每个调用中都会出现相同系统指令的长时间运行智能体，这显著降低了推理成本。

需要设计的失败模式

上下文出错有四种截然不同的方式，每种都需要不同的缓解措施：

上下文污染 (Context poisoning)：幻觉进入上下文窗口并破坏下游推理。解决方法是在插入点进行验证和纠正，而不仅仅是在输出端。

上下文分心 (Context distraction)：上下文的数量超过了模型的有效注意力跨度，导致推理质量下降 —— 即使所有信息在技术上都是相关的。压缩和隔离是主要的缓解措施。

上下文混乱 (Context confusion)：多余或切向的信息导致模型锚定在无关的细节上。选择性加载和即时 (JIT) 检索减少了这种故障的发生面。

上下文冲突 (Context clash)：窗口内的矛盾信息产生不一致或反复无常的输出。这需要结构化的冲突解决（显式的仲裁规则）或作用域可见性 —— 确保只有兼容的信息出现在同一个窗口中。

结论

上下文工程不是一种提示词技巧。它是一门应用于通过 LLM 上下文窗口的信息流的系统工程学科。那些在漫长、复杂的任务中表现可靠的智能体 —— 那些值得在生产环境中部署的智能体 —— 都是其设计者仔细考虑过什么信息进入窗口、什么被外部化、什么被压缩以及工作在哪里被隔离的智能体。

更大的上下文窗口减轻了压力，但并没有消除问题。架构选择 —— 写入、选择、压缩、隔离 —— 无论模型能力如何，都是承重的核心。将上下文视为托管资源而非被动存储的工程师，正在构建能够扩展的智能体。其他的工程师则是在调试那些看起来像模型问题但其实不是的故障。