上下文压缩机制

API 厂商计费规则

在深入探讨上下文压缩机制之前，有必要先厘清大模型厂商的计费逻辑。

目前，主流厂商均以 token 作为计费单位。但这里存在一个常见误解：每次请求的 token 消耗，是否仅等于当前输入与输出 token 之和？

答案是否定的。

实际计费依据是 每次请求中传入的 messages 总字符数 ，而非单轮对话的输入长度。由于大模型本身不具备记忆能力，为了维持上下文连贯性，每次请求都必须将完整的历史对话记录 一并传递。因此，随着对话轮次增加，messages 累计长度持续增长，单次请求的 token 消耗呈线性增长，这也是长上下文场景下成本压力的主要来源。

此外，是否命中缓存，也会显著影响计费标准。

这里的"命中缓存"，特指 GPU 侧的计算缓存 。其核心匹配规则为前缀匹配（Prefix Matching） ------这是工程侧最为关注的命中策略。当请求的前缀（通常是系统提示词或前几轮对话）与缓存中的历史请求完全一致时，模型可跳过重复的推理计算，从而大幅降低响应延迟与计算成本。

理解了上述计费规则与缓存命中机制后，我们便可以围绕这两点，正式展开上下文压缩机制的设计思路与实现方案。

好的，这段内容技术细节很扎实，我帮你润色成一版结构更清晰、工程术语更精准、逻辑递进更自然的版本，适合放在技术博客或设计文档中。

上下文压缩核心逻辑

无论采用何种压缩策略，都需要锚定以下三条基本原则：

信息优先保留 ：在尽可能不丢失关键信息的前提下，大幅缩短 messages 的总长度。
缓存前缀不可动 ：由于系统采用前缀缓存机制，system prompt 及用户初始几轮对话不得压缩------这部分通常是完整对话的"锚点"，承担着上下文定位的作用。
压缩强度渐进：策略执行顺序应遵循"从轻到重"的原则，优先采用低成本的裁剪手段，避免直接对上下文进行摘要式压缩，以防关键信息被过度抽象而失真。

压缩方式

当前主流的 Agent 框架，通常沿着两个方向进行上下文压缩：规则裁剪 与 LLM 摘要 。执行顺序上，优先尝试规则裁剪，仅当裁剪后的 token 数量仍超出阈值时，才会触发 LLM 摘要作为兜底手段。

规则裁剪

当请求的 token 数超过预设阈值时，系统会对历史工具调用结果进行占位符替换，但需遵守以下约束：

保护近一轮数据：最近 1 轮的工具调用结果不参与替换，确保当前决策所需的最新上下文完整可用。
历史数据持久化：被替换的原始内容将落盘存储，并在占位符中注明对应的磁盘路径，以便必要时追溯或恢复。
减少输入冗余：通过占位符替代长文本工具结果，有效降低单次请求的 token 输入量。

LLM 摘要

当规则裁剪不足以将 token 控制在阈值以内时，触发 LLM 摘要。执行摘要时需遵循三条原则：

工具调用隔离：摘要过程中禁止调用任何工具，避免引入副作用或产生额外计费。
前置裁剪联动：执行摘要前，先对老旧工具调用结果进行占位符替换，进一步压缩输入长度，同时过滤低价值信息，提升摘要质量。
头尾保留策略 ：保留对话的首尾各 3 轮（即最近 3 轮和最前面 3 轮），对中间的历史对话内容进行摘要压缩。头尾各保留 3 轮，以平衡上下文连贯性与压缩效率。