Agent上下文工程：缓存、压缩与子Agent实战

当AI Agent从演示走向生产，开发者遇到的最大瓶颈往往不是模型能力，而是上下文管理。上下文窗口有限，而Agent的对话历史、工具调用结果、检索文档却在不断膨胀。如何让Agent在有限窗口内保持高效、准确、低成本地运行？答案在于上下文工程（Context Engineering）。

Anthropic和OpenAI都在API层面提供了关键的控制手段。本文拆解五种核心策略——缓存、压缩、工具结果清理、检索和子Agent——并给出可落地的API参数。

为什么上下文工程是Agent的核心难题

Agent与普通聊天机器人的本质区别在于多轮工具调用。每一次工具调用都会产生结果，这些结果被追加到对话历史中。一个复杂任务可能涉及数十次工具调用，每次返回的JSON或文本可能长达数千token。很快，上下文窗口就会被填满。

问题的严重性体现在三个层面：成本——按token计费，冗余上下文直接推高费用；延迟——更长的上下文意味着更慢的推理；质量——无关信息稀释注意力，模型更容易出错。上下文工程的目标就是在三者之间找到平衡点。

策略一：Prompt Caching——让重复前缀不再重复付费

Prompt Caching是成本优化最直接的手段。核心思想很简单：如果多次请求共享相同的前缀（如系统提示词、工具定义、长文档），就缓存这部分计算结果，避免重复处理。

Anthropic的实现：通过cache_control字段标记缓存断点。可以在系统提示、工具定义或消息块上设置{"type": "ephemeral"}。缓存命中的token按更低价格计费，写入缓存则有额外费用。适合系统提示词稳定、但对话持续进行的场景。

OpenAI的实现：自动缓存超过1024 token的提示前缀，无需显式标记。命中缓存的输入token享受折扣。开发者只需保持提示前缀稳定即可受益。

两者的差异在于控制粒度：Anthropic允许开发者精确指定缓存位置，OpenAI则更自动化。实践建议是将稳定的系统提示和工具schema放在最前面，动态内容放在后面，最大化缓存命中率。

缓存断点的工作原理：在Anthropic的API中，cache_control标记的缓存断点会将此前所有内容（包括系统提示、工具定义和之前的消息）作为一个可缓存的前缀。缓存有效期默认为5分钟，期间相同前缀的请求可直接复用计算结果。写入缓存需支付约25%的额外费用，而缓存命中的token仅按基础价格的10%计费。因此，对于多轮对话或高频调用的Agent，缓存能显著降低成本。但需注意，缓存前缀必须完全一致，任何细微改动（如时间戳、随机ID）都会导致缓存失效。

OpenAI的自动缓存：OpenAI对超过1024 token的提示自动启用缓存，无需开发者干预。命中缓存的输入token按50%折扣计费。其缓存基于提示前缀的哈希值，同样要求前缀稳定。开发者可通过将静态内容前置、动态内容后置来最大化命中率。两者的核心差异在于控制粒度：Anthropic允许精确控制缓存位置，适合复杂场景；OpenAI更自动化，但灵活性较低。

策略二：Compaction——把历史对话折叠成摘要

当对话历史过长时，压缩（Compaction）成为必要手段。做法是让模型将早期对话总结成一段精炼的摘要，用摘要替换原始历史，只保留最近几轮完整对话。

这本质上是一种有损压缩：丢失细节，保留语义。关键在于摘要的质量——好的摘要保留任务目标、已完成的步骤、关键发现和未解决的约束；差的摘要丢失关键信息，导致Agent重复劳动或做出错误决策。

实现上，可以在历史长度超过阈值时触发一次专门的摘要调用，将前N轮对话压缩为一段系统消息。Anthropic的上下文窗口管理文档建议保留最近的工具调用结果和用户指令原文，只压缩中间过程。

有损压缩的权衡：Compaction本质上是一种有损压缩，在减少token的同时可能丢失细节。为了平衡信息保留与压缩率，可以采用分层摘要策略：先对早期对话生成粗粒度摘要，再对近期对话生成细粒度摘要，形成摘要的摘要。另一种做法是保留关键实体（如用户目标、约束条件、已确认的事实）的原文，仅压缩推理过程和工具调用细节。Anthropic建议在上下文使用率达到70%-80%时触发压缩，避免临近窗口上限时仓促处理。压缩后的摘要应作为系统消息插入，并明确标注“以下为历史摘要”，以区别于原始对话。

策略三：Tool-result Clearing——用完即弃的工具结果

工具调用的返回结果往往是上下文膨胀的主要来源。一个网页抓取可能返回上万token的HTML，一次数据库查询可能返回大量行。但这些结果在Agent提取出关键信息后，原始内容就不再需要了。

Tool-result Clearing的策略是：在Agent处理完工具结果、提取出所需信息后，将原始结果从上下文中移除或替换为简短标记。这比Compaction更激进，但也更高效。

风险在于：如果后续步骤需要回溯原始结果，清理后就无法恢复。因此需要判断哪些工具结果是一次性的（如搜索结果摘要），哪些可能需要反复引用（如配置文件内容）。

清理策略的粒度控制：Tool-result Clearing并非简单删除所有工具结果，而是需要根据工具类型和后续需求进行粒度控制。例如，对于搜索结果，可保留标题和摘要，删除完整网页内容；对于数据库查询，可保留聚合统计和关键行，删除原始数据集。实现上，可以在工具定义中增加ephemeral标记，指示该工具结果可在提取后清理。同时，应保留工具调用的元数据（如调用时间、参数、结果摘要），以便追溯。对于可能需要回溯的结果，可将其存储到外部存储，并在上下文中保留引用ID，需要时再通过检索工具取回。

策略四：Retrieval——按需取用而非全量加载

与其把所有可能相关的文档都塞进上下文，不如让Agent在需要时主动检索。Retrieval策略将外部知识库与上下文解耦，Agent通过工具调用按需获取片段。

这要求设计好检索工具：查询接口、返回格式、片段粒度。返回结果应包含足够的元数据（来源、相关性分数），帮助Agent判断是否需要进一步检索。Anthropic的Agent构建指南强调，检索工具应返回精简片段而非整篇文档，并支持分页或过滤。

Retrieval与Tool-result Clearing天然互补：检索结果被提取后即可清理，上下文始终保持精简。

策略五：Subagents——用独立上下文隔离复杂子任务

当某个子任务需要大量探索性工具调用时，与其让主Agent的上下文被这些过程污染，不如启动一个子Agent在独立上下文中完成任务，只将最终结果返回给主Agent。

Subagents的价值在于上下文隔离。子Agent可以尽情调用工具、试错、检索，其冗长的中间过程不会影响主Agent的决策空间。主Agent收到的只是精炼的结论。

代价是协调开销：需要定义清晰的输入输出契约，子Agent的失败需要处理，多Agent之间的状态同步也需要设计。Anthropic的多Agent研究系统展示了这种模式在复杂研究任务中的效果，但也指出token消耗会显著增加。

子Agent的通信契约：主Agent与子Agent之间需要明确的输入输出契约。输入应包括任务描述、可用工具列表、约束条件和期望的输出格式；输出应是结构化的结果（如JSON），包含结论、置信度和引用来源。子Agent的上下文完全独立，不继承主Agent的历史，因此需要在输入中提供足够的背景信息。主Agent应设置超时和重试机制，处理子Agent的失败。此外，子Agent的token消耗会计入总成本，需监控其使用效率。Anthropic的研究表明，子Agent模式在需要多步探索的任务中效果显著，但应避免用于简单任务，以免增加不必要的开销。

组合使用：没有银弹，只有权衡

五种策略并非互斥，生产级Agent通常组合使用。一个典型的架构是：系统提示和工具定义使用Prompt Caching；长对话定期Compaction；工具结果提取后Clearing；外部知识通过Retrieval按需获取；复杂子任务交给Subagents隔离。

每种策略都有代价：缓存有写入成本，压缩有信息损失，清理有回溯风险，检索有延迟，子Agent有协调开销。上下文工程的本质是在成本、延迟、质量之间做工程权衡，而非追求某个单一指标的最优。

理解这些API层面的控制手段，才能让Agent在真实场景中稳定运行，而不是在上下文溢出时崩溃。