Claude Code 跑任务跑到一半换模型：什么会断、什么还能接上

在 Claude Code 这类终端 AI 编程助手中，任务执行到一半更换后端模型是常见需求，比如因为额度、速率限制或想对比不同模型的输出。但切换模型不像切换 API key 那么简单——有些状态能自动延续，有些会断掉需要手动处理。下面以一次真实的会话为例，拆解哪些部分能接上、哪些必须重发。

对话历史：通常能完整延续

Claude Code 把整个对话历史作为上下文发送给后端模型。如果你通过聚合站切换模型，只要请求体里仍然包含完整的 messages 数组，新模型就能看到之前的所有对话轮次。这意味着：

• 之前讨论过的需求、约束、错误信息都会保留。
• 模型已经「知道」的代码片段（作为文本）不会丢失。
• 但新模型对历史的理解方式可能不同，尤其是不同厂商的模型在指令遵循和上下文窗口管理上有差异。

注意：如果聚合站或客户端在切换时清空了历史（有些实现会这样），就需要手动重新提供关键上下文。建议切换前先确认客户端是否保留历史。

工具调用：进行中的调用会中断

Claude Code 的工具调用（如执行 shell 命令、读写文件）是模型输出的一部分。如果切换发生在工具调用执行期间：

• 已经发出的工具调用请求会完成（因为客户端已经开始执行），但结果可能不会被新模型正确接收，除非客户端把结果追加到历史中。
• 尚未发出的工具调用计划会丢失，新模型需要重新生成调用指令。
• 如果工具调用是长时间运行的命令（如测试套件），切换后新模型不会自动等待或获取结果，需要手动把输出粘贴回对话。

因此，切换的最佳时机是在一轮工具调用全部完成、结果已追加到历史之后。

文件编辑：已写入磁盘的更改不受影响

Claude Code 通过工具直接修改文件。已经写入磁盘的编辑是持久的，切换模型不会回滚它们。但要注意：

• 新模型不会自动知道哪些文件被修改过，除非你在历史中提及或它主动读取。
• 如果编辑是分步进行的（比如先改 A 文件再改 B 文件），切换后新模型可能重复修改或遗漏，建议在切换时明确告知「已完成 X，接下来做 Y」。
• 未提交的更改仍然在工作区，新模型可以通过读取文件感知到。

任务执行进度：需要显式同步

模型本身不维护任务状态，进度完全依赖对话历史中的描述。切换后，新模型可能：

• 忘记之前设定的计划步骤，需要你重新概述当前进度。
• 对「下一步做什么」产生不同判断，尤其是不同模型对同一问题的解决路径不同。

建议在切换后的第一条消息中，用简洁的语言同步：当前目标、已完成事项、待办事项、已知问题。这比让新模型自己从历史中推断更可靠。

系统提示与工具定义：兼容性需检查

不同模型对系统提示的格式要求不同（比如某些模型要求 system 角色单独放置）。如果聚合站做了统一转换，通常没问题；但工具定义的 JSON Schema 在跨模型时可能被不同地解释。切换后如果工具调用频繁失败，检查是否因为新模型不支持某些参数或格式。

切换前的检查清单

为了减少中断，切换前可以快速确认：

• 当前轮次的工具调用是否全部完成，结果是否已加入历史。
• 是否有长时间运行的任务尚未返回结果。
• 对话历史是否会被客户端保留。
• 是否需要手动记录当前进度和下一步计划。

总结

换模型时，对话历史和已落盘的文件编辑通常能延续；进行中的工具调用和未显式记录的任务进度容易断掉。最稳妥的做法是：在一轮工具调用结束后切换，并在新会话的第一条消息里同步进度。这样即使后端模型变了，任务也能平稳接上。