agent-loop-prompt-caching-compaction-">Agent Loop性能优化技术选型：Prompt Caching与Compaction怎么选

一、选型背景：为什么Agent Loop需要性能优化选型

Agent Loop（智能体循环）通常指智能体在“感知—推理—行动—观察”之间反复迭代的执行模式。随着对话轮次增加、工具调用增多、上下文不断累积，每一轮推理都需要携带越来越长的提示词，由此带来两个直接问题：成本随轮次线性甚至超线性增长，以及上下文膨胀导致的处理效率下降。

在这样的背景下，性能优化不再是“锦上添花”，而是决定Agent Loop能否长期稳定运行的关键。常见的优化方向包括Prompt Caching（提示词缓存）与Compaction（上下文压缩/精简）。两者解决的问题不同、适用条件不同，选型时不能简单比较“哪个更好”，而应判断“在当前业务规模、对话特征、成本结构和团队能力下，哪个更适配、如何组合使用”。

本文要帮助读者完成的选型判断是：在Agent Loop场景中，何时应优先引入Prompt Caching，何时应引入Compaction，二者如何互补，以及落地时需要验证哪些关键条件。

二、需求拆解：先弄清你的Agent Loop在为什么买单

在讨论方案之前，需要先把业务需求拆成可判断的维度：

• 对话长度与轮次特征：是短对话为主，还是长会话、多轮工具调用为主？长对话是成本爆炸的主要来源。
• 提示词结构稳定性：系统指令、few-shot示例、工具定义等静态内容是否占据提示词的大部分？静态占比越高，缓存收益越明显。
• 变量内容分布：用户特定信息、动态检索结果、实时状态等变量内容位于提示词的哪个位置？
• 成本敏感度：成本压力主要来自重复处理长前缀，还是来自上下文总量过大？
• 延迟要求：业务对首字节延迟、每轮响应时间是否有硬性约束？
• 系统复杂度承受能力：团队是否愿意引入额外的上下文管理逻辑、摘要生成逻辑与状态维护机制？
• 一致性要求：压缩是否会引入信息损失，业务能否接受摘要式上下文带来的精度折损？

这些维度决定了选型的起点。脱离需求谈方案，容易陷入“技术堆叠但收益有限”的困境。

三、选型对象说明：两类优化技术分别解决什么问题

3.1 Prompt Caching：用“前缀匹配”摊薄重复成本

Prompt Caching的核心思想是前缀匹配：当多次请求的提示词存在完全相同的前缀时，该前缀部分的处理结果可以被复用，从而以更低的边际成本处理长对话。它解决的是“重复内容被反复计算”带来的成本爆炸问题。

关键约束在于：缓存命中仅适用于提示词内的精确前缀匹配。这意味着提示词的结构布局直接决定缓存收益。一个通用最佳实践是：

• 将静态内容（如系统指令、工具定义、示例、固定格式约束）放在提示词开头；
• 将变量内容（如用户特定信息、动态检索结果、实时状态）放在末尾。

这样，静态前缀在多次请求间保持一致，更容易命中缓存；变量部分即使变化，也不破坏前缀的稳定性。

伪代码示意（通用示例）：

prompt = [
  STATIC_SYSTEM_INSTRUCTIONS,   # 固定不变，放最前
  STATIC_TOOL_DEFINITIONS,      # 固定不变
  STATIC_FEW_SHOT_EXAMPLES,     # 固定不变
  DYNAMIC_USER_CONTEXT,         # 每次变化，放末尾
  DYNAMIC_RETRIEVED_DOCS,       # 每次变化
  CURRENT_QUERY                 # 每次变化
]

需要强调的是，缓存命中依赖“精确前缀”，任何在前缀区域内的细微变动（如时间戳、随机ID、顺序调整）都可能导致缓存失效。因此，选型时要评估团队是否具备稳定提示词模板管理的能力。

3.2 Compaction：用“上下文精简”控制总量膨胀

Compaction指的是对累积的上下文进行压缩、摘要或裁剪，降低单次请求携带的上下文总量。它解决的是“上下文本身过大”带来的处理负担与成本问题，尤其适用于超长会话、多轮工具调用、历史记录不断堆积的场景。

Compaction的选型关注点与Prompt Caching不同：它更依赖信息取舍策略——哪些历史需要保留、哪些可以摘要、哪些可以丢弃。这会引入信息损失风险，需要业务判断可接受程度。

四、核心评估维度：建立选型评估框架

评估维度	Prompt Caching关注点	Compaction关注点
功能定位	复用重复前缀，降低重复处理成本	压缩上下文总量，控制膨胀
适用条件	提示词存在稳定静态前缀	上下文持续累积且可精简
成本结构	收益随前缀复用次数增加而放大	收益随上下文压缩比例增加而放大
延迟影响	命中时可降低前缀处理开销	可降低单次请求上下文规模
信息风险	低（不改变内容语义）	中（摘要/裁剪可能损失信息）
实现复杂度	中（需模板管理与前缀稳定性）	中高（需摘要策略与状态管理）
运维要求	需监控缓存命中率与失效原因	需监控压缩质量与信息完整性
团队能力	提示词工程与模板治理	上下文管理与策略调优

从表中可以看出，两类技术并非替代关系，而是不同层面的优化：Prompt Caching优化“重复计算”，Compaction优化“总量规模”。

五、方案适配分析：不同条件下如何侧重

• 如果对话以长会话、多轮工具调用为主，且提示词中静态指令与工具定义占比高：应优先评估Prompt Caching，重点验证前缀稳定性与缓存命中率。
• 如果上下文总量持续膨胀，单次请求携带的历史记录过长，且业务可接受摘要式信息：应优先评估Compaction，重点验证压缩比例与信息损失的可控性。
• 如果成本压力主要来自重复处理相同前缀：Prompt Caching的边际收益更直接。
• 如果成本压力来自上下文整体规模过大，且静态前缀占比较低：单纯依赖缓存收益有限，需结合Compaction。
• 如果团队提示词模板管理能力较弱、变量内容常混在前缀区域：直接上线Prompt Caching可能命中率不理想，应先做提示词结构治理。
• 如果业务对信息精度要求极高、不容忍摘要损失：Compaction需谨慎引入，或以“裁剪+保留关键原文”的保守策略为主。

六、决策路径：从需求确认到方案验证

1. 确认成本来源：统计长对话中重复前缀占比与上下文总量占比，判断主要矛盾。
2. 评估提示词结构：检查静态内容是否可稳定前置，变量内容是否可集中后置。
3. 判断信息容忍度：业务能否接受压缩带来的信息损失。
4. 选择优先方案：前缀重复为主选Prompt Caching；总量膨胀为主选Compaction；两者并存则组合使用。
5. 小范围验证：在灰度流量中观察命中率、成本变化、延迟变化与输出质量。
6. 建立监控与回退机制：监控缓存命中率、压缩比例、异常输出，准备回退策略。

七、验证方法：用指标降低选型风险

• 缓存命中率：观察前缀稳定后命中率是否达到预期，分析失效原因是否来自前缀区域变动。
• 单位请求成本变化：对比优化前后的成本结构，确认收益来源符合预期。
• 延迟分布：关注P50/P95延迟变化，避免优化引入额外处理开销。
• 输出质量对比：Compaction场景下需抽样对比压缩前后输出一致性，评估信息损失。
• 异常与回退演练：验证缓存失效、压缩异常时的系统行为与回退路径。

八、落地注意事项

• 提示词模板治理：将静态内容固化为模板，避免时间戳、随机ID等破坏前缀稳定性。
• 变量内容后置：把用户特定信息、动态检索结果统一放到提示词末尾。
• 压缩策略可配置：Compaction的保留比例、摘要粒度应可调，便于按业务调优。
• 权限与数据安全：缓存与压缩涉及上下文内容，需关注数据隔离、日志审计与访问控制。
• 成本与运维平衡：优化本身也带来管理与监控成本，需评估团队运维能力。
• 组合使用：先做提示词结构治理以提升缓存收益，再按需引入压缩控制总量。

九、总结：回到选型目标

Prompt Caching与Compaction是Agent Loop性能优化的两类互补技术。选型的核心不是判断谁更优，而是回答三个问题：成本主要来自重复前缀还是上下文总量？提示词结构是否支持稳定前缀？业务能否接受压缩带来的信息损失？ 在此基础上，优先选择与主要矛盾匹配的方案，并通过小范围验证与监控指标确认适配度。对于百度智能云相关能力，可将其作为云服务选项之一，结合自身需求客观评估，而非依赖单一结论。