Claude 长对话压缩与摘要策略

上下文压缩的通用技术（滑动窗口、摘要压缩、RAG 替换等）在《上下文压缩 5 种策略对比》已经讲得很全面。本文不重复这些通用方法，而是聚焦 Claude 生态下的具体实践——Claude Code 的自动摘要机制是怎么工作的、API 场景下如何设计摘要 Prompt、以及超长上下文窗口出现后，“要不要压缩”这个问题本身发生了什么变化。

一、Claude Code 里的自动压缩：先理解它在解决什么问题

用过 Claude Code 的人都遇到过这种情况：一个编程任务聊了很长时间，工具调用、文件读取、命令输出不断累积，上下文逐渐逼近窗口上限。这时候如果没有自动处理机制，要么对话直接报错中断，要么后续回复质量因为窗口过载而下降。

Claude Code 的做法是：当对话长度接近阈值时，自动把此前的对话历史压缩成摘要，同时保留最近的、还未处理完的上下文，让任务可以不间断地继续。用户也可以主动触发这个过程（/compact 命令），在感觉上下文已经积累了大量无关内容时手动清理。

这个机制对开发者的启发是：压缩不必是”要么全存要么全丢”的二选一，而应该是自动化、阈值触发、且对用户透明的持续过程。自己设计长对话系统时，与其人工判断”什么时候该压缩”，不如直接设定 token 占用比例阈值（比如占用窗口 70-80% 时触发），交给系统自动执行。

二、摘要压缩要保留什么：不是”变短”而是”变对”

单纯把对话历史丢给模型说”帮我总结一下”，效果往往不理想——通用摘要容易丢失任务型对话中最关键的信息：当前未完成的目标、已经尝试过但失败的方案、用户明确表达过的约束条件。

针对编程或任务型场景，摘要 Prompt 建议明确指定保留的信息类型，而不是让模型自由发挥：

请把以上对话压缩成摘要，必须包含以下几类信息，其余内容可以省略：

1. 用户最初的任务目标（原样保留，不要改写）
2. 已经完成的步骤及其结果
3. 尝试过但失败的方案，以及失败原因（避免重复踩坑）
4. 用户明确提出的约束条件（技术栈限制、格式要求、禁止事项）
5. 当前未解决的问题或下一步计划

不需要保留：寒暄、探索性讨论中被否决的方向、已经在代码里体现的实现细节。

这种结构化摘要模板比自由摘要更可靠，因为它把”哪些信息重要”的判断从模型的自由发挥变成了明确指令，减少压缩后关键信息丢失导致后续对话”失忆”的情况。

三、API 场景下手动实现摘要压缩的基本模式

如果是自己通过 Claude API 构建长对话应用（而不是用 Claude Code），压缩逻辑需要自己实现。基本模式：

def maybe_compress(messages, token_threshold=100_000):
    current_tokens = estimate_tokens(messages)
    if current_tokens < token_threshold:
        return messages

    # 保留最近 N 轮不压缩，其余历史送去摘要
    recent = messages[-6:]
    to_summarize = messages[:-6]

    summary = call_claude_for_summary(to_summarize)

    return [
        {"role": "user", "content": f"[历史对话摘要]\n{summary}"},
        {"role": "assistant", "content": "已了解上述背景，继续协助。"},
        *recent,
    ]

几个实践中容易踩坑的细节：

摘要本身要单独调用一次模型，不要和当前正在进行的任务调用混在一起，避免摘要指令干扰当前任务的回复
摘要生成建议用更便宜的模型（如果任务复杂度允许），因为摘要是纯粹的信息压缩任务，通常不需要旗舰模型的推理能力
保留最近几轮不压缩，这些是模型正在处理的”活跃上下文”，过早压缩容易丢失正在进行中的推理链条

四、超长上下文窗口出现后，压缩还有必要吗

这是个值得单独讨论的问题。Claude 提供了百万级 token 的超长上下文选项，直觉上似乎”窗口够大就不用压缩了”。但实际工程中，压缩依然有价值，原因有三点：

成本依然线性增长：窗口再大，每次调用依然按实际 token 数计费，不压缩意味着每一轮对话都要为全部历史付费
注意力分散问题不完全随窗口增大而消失：超长上下文中，模型对中间部分信息的利用率通常低于开头和结尾，这在《LLM 长上下文 Needle 测试》里有更详细的讨论
延迟随输入长度增长：即便窗口容得下，超长输入本身会拉长首字延迟，对交互式应用体验不友好

更合理的判断框架是：超长上下文窗口降低了”必须压缩”的紧迫性，但没有消除”压缩带来的成本和体验收益”。对于成本敏感或延迟敏感的应用，即便窗口够用，主动压缩依然值得做；对于偶发的、对成本不敏感的深度分析任务，可以放心利用大窗口不压缩，减少工程复杂度。

五、压缩与 Prompt Caching 的配合

如果对话历史的前半部分相对稳定（比如系统设定、项目背景），可以把这部分内容通过 Prompt Caching 缓存，压缩逻辑只作用于真正频繁变化的中间对话部分。这样设计的好处是：稳定内容不需要反复摘要、反复计费，只有动态增长的部分才进入压缩流程。具体的缓存收益测算方法可以参考《Claude Prompt Caching 成本收益分析》。

六、什么时候不该压缩

压缩不是万能药，以下场景建议谨慎使用或直接跳过：

法律、医疗等对完整记录有审计要求的场景：摘要意味着信息有损，原始记录应该单独完整保留（落库存档），压缩只作用于送入模型的上下文，不代表可以丢弃原始数据
任务对精确数值、代码片段高度敏感：摘要容易在转述数字或代码时引入偏差，这类信息建议原样保留或用结构化方式单独提取，而不是塞进自然语言摘要里
对话轮次本身不多：如果整个任务几轮就能完成，压缩带来的额外调用成本可能比它节省的成本还高，不值得引入这层复杂度

七、相关阅读

如果需要同时对比 Claude 与其他模型在长对话摘要任务上的成本表现，通过 YoTradeApi 一个接口即可调用多家模型,方便做横向测试。