claude-code-compact-session-resume · ZH · 2026-10-26

在聚合站 key 上让 Claude Code 的 /compact 后还能接着干:换后端时哪些上下文真的活下来

长任务跑到 /compact 后,Claude Code 的会话摘要状态在不同后端重放时会暴露出模型行为差异。本文解释哪些上下文真正跨后端存活、哪些只是表面兼容,并给出在聚合站一把 key 切换模型时安全续跑的做法。

长任务跑到 /compact,往往是最容易出问题的时候:你以为上下文已经被压缩成一份摘要,换个后端继续应该一样,结果发现模型对同一段摘要的反应完全不同。这篇文章讲清楚在聚合站用一把 key 调不同模型时,/compact 之后的会话里哪些东西会真正活下来。

先理解 /compact 到底做了什么

/compact 不是把历史消息原样塞给模型,而是让当前模型对已有对话做一次总结,用这段总结替换掉原始消息历史,然后接着往下走。

这意味着压缩之后,客户端手里的“上下文”变成了两层:

  • 摘要文本:一段自然语言,由当时的模型生成。
  • 压缩后的消息骨架:摘要消息 + 系统提示 + 工具定义 + 最近若干轮原始消息(取决于客户端实现)。

关键点在于:摘要文本是模型写的,不是确定性的序列化结果。换一个后端,摘要本身可能一致,但模型如何解读它、如何调用工具、如何延续风格,都会变。

哪些上下文真正跨后端存活

跨后端能稳定活下来的,基本只有客户端控制的那部分:

  • 系统提示与工具定义:由 Claude Code 自己拼装,换后端时通常原样重发。聚合站把请求转发给不同模型时,这部分结构不变。
  • 压缩摘要的文本内容:作为一条消息存在客户端会话里,重放时文本一致。
  • 最近未被压缩的原始消息:如果客户端保留了最近若干轮,这些会原样保留。
  • 文件路径与工具调用结果:如果摘要里记下了“改过哪些文件、跑过什么命令”,这些描述会存活;但模型能否正确使用它们,取决于它读摘要的能力。

换句话说,活下来的是文本,不是模型的内部状态。压缩前那个模型“心里”的推理链、它对项目风格的隐性把握,在压缩那一刻已经丢了一次;换后端等于再丢一次。

哪些只是表面兼容

下面这些东西在换后端后经常“看起来还在”,实际已经失效:

  • 工具调用格式的隐含约定:摘要里可能写着“用 Bash 跑了 X”,但新模型未必按同样的参数结构发起调用。
  • 代码风格与命名偏好:摘要可以记下“遵循现有风格”,但不同模型对“现有风格”的解读差异很大。
  • 任务分解的粒度:原模型可能已经规划到第 4 步,摘要里只写了前 3 步,新模型会从自己的理解重新规划。
  • 失败与回退的教训:摘要常省略“试过但失败”的路径,新模型可能重走一遍。
  • 对当前工作目录的“体感”:比如它记得某个报错的具体堆栈,摘要里只留了一句“有个类型错误”。

这些差异不是 bug,而是上下文压缩本身的损耗在不同模型上被放大。

在聚合站一把 key 切换后端的实际影响

聚合站的特点是同一个 API key 可以指向 Claude、GPT、DeepSeek、Qwen、GLM、Kimi 等不同后端,按官方价 ×1.3 扣费。对 Claude Code 这类客户端,切换后端通常意味着改一下 base URL 或模型名,会话文件留在本地。

这带来一个具体场景:你在 Claude 上跑到 /compact,然后想换一个更便宜或更快的后端继续。此时会发生:

  • 客户端把同一份压缩后的消息数组重发给新后端;
  • 新后端对摘要的解读不同,工具调用可能不符合 Claude Code 的预期格式;
  • 最明显的是编辑类工具和多步任务:一个模型可能倾向于大块重写,另一个倾向于小步 diff。

如果你贡献 key 换 USDC,按官方价 ×1.1(优质 ×1.2)返,这属于另一条路径,和会话重放无关;但同一把 key 多后端的能力,让“中途换模型”变成默认选项,所以需要把重放差异当成常态处理。

让压缩后换后端更稳的做法

没有万能方案,但可以降低损耗:

  1. 压缩前先落盘:在 /compact 之前,让 Claude Code 把当前计划、已改文件、待办写成仓库里的一个文件(比如 PLAN.md 或任务注释)。文件是跨后端最可靠的上下文载体。
  2. 摘要里强制留“约束”:压缩时提示模型保留不可协商的约束,例如“不要改公共 API”“只动 src/ 下文件”。约束比风格更容易跨模型传递。
  3. 换后端后先小步验证:续跑时先给一个低风险任务(读文件、跑测试、改一行),观察工具调用是否正常,再放开大步。
  4. 把“试错记录”外置:失败路径写进仓库或 issue 备注,不依赖摘要保留。
  5. 接受重新规划的成本:换后端后模型重读一遍关键文件,通常比硬接旧摘要更划算。

一个可复现的检查清单

换后端续跑前,按顺序确认:

  • 压缩后的会话里,系统提示和工具定义是否仍由客户端完整发送;
  • 摘要里是否包含明确的约束与当前待办;
  • 最近未压缩消息是否覆盖了最后一个动作;
  • 先在只读任务上验证新后端的工具调用格式;
  • 关键状态(计划、失败记录、待改文件)是否已经落到仓库文件。

这些做完,你至少知道哪些上下文是“真活下来”的,哪些只是摘要里的字面残留。