为什么中途换模型会“降智”你是否遇到过这个提示它的大意是任务做到一半时切换模型后续表现可能变差。奇怪的是聊天记录、代码和 TODO 明明都还在。为什么换了模型它却开始重复搜文件、追问已经回答过的问题甚至重走刚被排除的路把它想成一次临时换人就好理解了Model B 拿到了完整的会议记录却没参加前面两个小时的讨论。它知道大家做了什么却不一定知道为什么这样做。记录可以继承前一个模型形成的计算与判断不能默认继承。1. 聊天记录还在它为什么突然不在状态Model A 已经在项目里调查了半小时。它搜过入口文件读了调用链改了两处代码跑测试后又撤回其中一处。此时换成 Model B聊天和文件都交过去了。B 当然能看见结果但它未必知道为什么先查这个入口哪个猜测已经被日志否掉那处改动为什么要撤回。于是 B 重新搜索、重新提问还可能重试已经失败的方案。重复调查不等于模型必然变笨。更常见的原因是它接手了结果却没有接上前面的判断过程。提示里写的是“可能”。模型能力、上下文裁剪、工具实现和切换时机都会影响实际表现。2. 换了一个新大脑但只拿到了会议记录Coding Agent 外面通常有一层 Harness。这里的 Harness 可以理解为整套工作台它管理对话、文件、工具、任务列表也负责把当前材料整理后交给模型。如果中途换模型Harness 能继续保留很多东西聊天里明确写出的结论当前工作区里的文件终端输出和工具结果TODO、计划和已完成项。这些东西很像会议记录。记录越完整新来的人越容易接手。不过会议记录很难装下讨论现场的全部判断。有人看了三个报错后对某条线索提高了警惕有人把五个方案比较过一遍觉得第二个最稳有人刚试过一条近路发现会破坏兼容性。这些判断如果没有明确写出来新人只能重新推。模型也有类似差别。旧模型在连续生成、读取工具结果和调整计划的过程中形成了当下这一步的计算状态。换模型后新模型拿到的是 Harness 能保存并重新呈现的材料。它需要根据这些材料重新理解项目无法直接接走前一个模型的全部内部计算。“换了一个新大脑”只是便于理解的比喻。模型没有人的意识。技术上更准确的说法是外部任务状态可以保存模型侧的计算需要重新形成。3. Context 是旧模型收拾过的工地Context 看起来只是资料形成过程却带着旧模型走过的痕迹。假设最初的代码库是一块空工地。Model A 进来后会不断做选择决定搜什么 ↓ 决定读哪些文件 ↓ 决定修改哪里 ↓ 根据测试结果继续或撤回到了第 50 轮工作区和聊天记录早已不是“原始项目 全部资料”。它们是 Model A 沿着一条具体路线调查、修改、排除后留下的现场。Model B 从半路进来看到脚印、路障和已经拆开的墙却不一定清楚每个东西为什么在这里。它可能更习惯另一种搜索顺序或者会采用不同的代码抽象。即使所有材料都能读到接手仍然会别扭。我把这种现象叫作“轨迹错配”。这是本文为了方便解释使用的说法不是学术界已有的统一术语。它指的是新模型接手了旧模型决策轨迹塑造出的现场却没有自然经历那条轨迹。这也是为什么一句“上下文都还在”没有回答完问题。Context 保存了能被交出去的内容过去几十轮里那些没有落成文字的取舍仍需要新模型重新建立。4. 真正断掉的是哪一层把一次 Coding Agent 长任务拆开大致能看到四种连续性。任务状态通常最容易保留。文件、Git diff、测试结果和 TODO 都在外部世界里只要 Harness 没有清掉它们新模型就能重新读取。输入表示会重新构造。同一段聊天需要经过具体产品的消息结构、工具结果格式、chat template 和 tokenizer才变成模型真正收到的输入。换模型或换服务后这层不一定完全相同。模型计算会重新形成。旧模型当前的注意力计算、缓存和服务内部保存的 reasoning state不能被默认视为跨模型通用资产。决策轨迹最需要人为交接。哪些路试过为什么放弃哪条假设还没证实往往散落在几十轮对话里。它们明明很重要却最容易被“聊天记录还在”这句话掩盖。所以“降智感”更适合解释为连续性断层能留下的层仍在需要重建的层没有得到足够交接。5. 实际使用时怎样安全地换模型最省事的办法是在一个小阶段刚结束时换。例如调查已经完成、准备开始实现实现已经完成、准备统一测试主任务已交付、准备做 review。此时旧模型刚好能把自己的判断收束成一份清楚记录新模型也有明确的起点。反过来如果 Agent 正在追一条复杂调用链、刚修改一半或者正在根据连续几次失败缩小范围此时切换最容易丢掉现场感。切换前我会先让当前模型停手生成一张 Handoff 交接卡我要切换模型了。请先停止继续修改并生成一份交接卡只写 1. 当前目标 2. 已完成的工作 3. 已验证事实 4. 排除过的路线及原因 5. 仍依赖的关键假设 6. 已修改和正在关注的文件 7. 下一步最小动作 8. 如果下一步失败从哪里恢复 不要继续执行任务。这张卡和普通摘要的差别在于它会保留“为什么”。只写“修改了 parser.ts测试还有一个失败”新人仍要猜。补上“尝试直接改正则会破坏转义字符因此改为先分词当前失败只出现在空输入”接手成本会低很多。新模型进来后也别急着改代码。先让它复述当前目标、已证实的事实、不能重走的路和下一步。如果复述有偏差几句话就能校正等它改出一大串文件再纠正现场已经更乱了。如果你只想解决使用问题到这里已经够了尽量在语义断点换模型切换前留下包含依据和排除路线的 Handoff。想继续深挖再往下看从这里开始讲技术细节。6. 同一份任务为什么会变成不同输入我们平常说的 Context容易把两件事混在一起。第一件是外部任务状态磁盘文件、Git diff、数据库记录、终端输出。第二件是 model-visible context也就是模型这次采样时真正收到的 token 序列。Anthropic 的 context engineering 文章也采用后一种口径模型能在一次采样里看到的 token 集合。Harness 需要把外部状态挑选、排序并序列化才能交给模型。消息角色怎样标记工具调用和工具结果怎样编码系统指令放在哪里都由 adapter 或 chat template 决定。Hugging Face 的 chat template 文档直接提醒不同聊天模型可能期待不同格式即使它们从同一个基础模型继续训练。接着才轮到 tokenizer。不同 tokenizer 可能把同一句话切成不同 token。它只能解释输入差异的一部分模板、截断、工具序列化和模型对长上下文的利用方式也会参与。聊天界面里看着相同的记录换到另一个模型后可能产生不同的 model-visible context。模型怎样使用这些输入也会跟着变化。7. KV Cache 丢了主要伤的是性能Transformer 生成内容时会为已经处理过的 token 保存 Key 和 Value后续生成可以复用这就是 KV Cache。它省掉重复计算让长对话继续生成时更快。KV Cache 和具体模型的层数、隐藏维度、权重计算紧密相关。换到另一个模型后通常不能把旧模型的缓存直接接过去。新模型需要重新处理保留下来的输入。这里要把“重新算一遍”和“变笨”分开。Cache miss 最直接的代价是重复计算、延迟和成本。如果输入内容完全保留新模型仍然可以重新计算只是要花时间。只有当系统为了预算裁剪了内容或者新模型没有得到关键依据输出质量才会进一步受影响。OpenAI 关于 GPT-5.6 工程优化的说明也把 prompt caching、KV 管理与长任务效率联系在一起。它能支持“为什么切换后可能变慢或更贵”不能单独证明模型智力下降。8. Persisted reasoning 让边界更复杂过去常见的一句话是“模型每轮都只看消息没有别的状态。”现在需要加上产品和 API 的限定。OpenAI 的 GPT-5.6 文档公开了 persisted reasoning在 Responses API 的特定用法里reasoning items 可以随 previous_response_id 在多轮之间延续手动管理历史时也需要保留相应输出项。官方 Builders Guide 还说明跨轮保留 reasoning 能改善长任务的连贯性。这说明有些服务会在聊天文本之外保存模型侧的推理材料。它也让“切模型会丢什么”变成实现相关的问题状态由谁保存生命周期多长新模型是否兼容都要看具体服务。这里的 reasoning items 不能直接写成可读思维也不能等同于 raw hidden state。官方文档说明的是某个 API 流程里的持久化能力并没有承诺任意模型之间都能无损搬运这份状态。因此讨论 Codex、Cursor 或其他 Agent 时最好先问清产品是否保留这类状态、模型切换后怎样处理。没有实现证据时只能确认聊天和外部任务状态仍在不能替服务端补写一套机制。9. 研究能证明什么不能证明什么围绕多模型路由、跨模型提示迁移和 Agent 轨迹已经有一些很接近这个问题的研究但每一篇只能支撑其中一小段。Software Engineering Agent Trajectories 把软件工程 Agent 的 thought、action 和 result 序列当作分析对象。最终答案之外行动路径本身也可以被比较和研究。本文把这类路径用于解释接手体验仍属于作者推论。DialRouter 把多轮对话里的模型选择视为长时序决策这一轮选谁会改变之后看到的状态和累计结果。它支持“路由不能只看当前一轮”的判断研究场景却不是 Coding Agent 中途交接因此不能直接证明 Coding Agent 中途换模型一定会降智。PromptBridge 研究同一提示在不同模型之间迁移时出现的性能漂移说明输入存在模型适配问题。同一份表达交给 Model B适配效果可能和 Model A 不同。Context Rot 关注长上下文搜索任务中模型利用越来越长历史时的退化。它提醒我们“材料放进上下文”不代表模型稳定使用了材料。论文测试的是特定开源模型和任务结论不能直接外推到所有 Coding Agent。把这些证据拼在一起可以得到一个工程判断模型选择、输入表示、历史长度和既有轨迹都会影响后续表现。至于某一次实际“降智”由哪一项造成仍要看当时的产品实现和任务记录。10. Context 告诉它知道什么Handoff 告诉它在哪里回到最开始的会议。新来的人可以拿到会议记录知道大家讨论过哪些事实。可要让他立刻接着做还得告诉他现在卡在哪哪条路刚试过为什么没走通下一步准备验证什么。Coding Agent 也是如此。Context 负责携带材料Handoff 负责标出当前位置和行动依据。切换模型时我们不需要 Model B 模仿 Model A 的思路只需要把当前世界交代清楚让它从一个稳定断点重新建立判断。Context 告诉它知道什么Handoff 告诉它在哪里。完整参考资料、普通 Markdown、Word 和离线 HTML请看博客网站https://aiarchblog-6hz4s01hv.maozi.io/articles/model-switch-continuity-gap/ 为什么中途换模型会“降智”？
为什么中途换模型会“降智”你是否遇到过这个提示它的大意是任务做到一半时切换模型后续表现可能变差。奇怪的是聊天记录、代码和 TODO 明明都还在。为什么换了模型它却开始重复搜文件、追问已经回答过的问题甚至重走刚被排除的路把它想成一次临时换人就好理解了Model B 拿到了完整的会议记录却没参加前面两个小时的讨论。它知道大家做了什么却不一定知道为什么这样做。记录可以继承前一个模型形成的计算与判断不能默认继承。1. 聊天记录还在它为什么突然不在状态Model A 已经在项目里调查了半小时。它搜过入口文件读了调用链改了两处代码跑测试后又撤回其中一处。此时换成 Model B聊天和文件都交过去了。B 当然能看见结果但它未必知道为什么先查这个入口哪个猜测已经被日志否掉那处改动为什么要撤回。于是 B 重新搜索、重新提问还可能重试已经失败的方案。重复调查不等于模型必然变笨。更常见的原因是它接手了结果却没有接上前面的判断过程。提示里写的是“可能”。模型能力、上下文裁剪、工具实现和切换时机都会影响实际表现。2. 换了一个新大脑但只拿到了会议记录Coding Agent 外面通常有一层 Harness。这里的 Harness 可以理解为整套工作台它管理对话、文件、工具、任务列表也负责把当前材料整理后交给模型。如果中途换模型Harness 能继续保留很多东西聊天里明确写出的结论当前工作区里的文件终端输出和工具结果TODO、计划和已完成项。这些东西很像会议记录。记录越完整新来的人越容易接手。不过会议记录很难装下讨论现场的全部判断。有人看了三个报错后对某条线索提高了警惕有人把五个方案比较过一遍觉得第二个最稳有人刚试过一条近路发现会破坏兼容性。这些判断如果没有明确写出来新人只能重新推。模型也有类似差别。旧模型在连续生成、读取工具结果和调整计划的过程中形成了当下这一步的计算状态。换模型后新模型拿到的是 Harness 能保存并重新呈现的材料。它需要根据这些材料重新理解项目无法直接接走前一个模型的全部内部计算。“换了一个新大脑”只是便于理解的比喻。模型没有人的意识。技术上更准确的说法是外部任务状态可以保存模型侧的计算需要重新形成。3. Context 是旧模型收拾过的工地Context 看起来只是资料形成过程却带着旧模型走过的痕迹。假设最初的代码库是一块空工地。Model A 进来后会不断做选择决定搜什么 ↓ 决定读哪些文件 ↓ 决定修改哪里 ↓ 根据测试结果继续或撤回到了第 50 轮工作区和聊天记录早已不是“原始项目 全部资料”。它们是 Model A 沿着一条具体路线调查、修改、排除后留下的现场。Model B 从半路进来看到脚印、路障和已经拆开的墙却不一定清楚每个东西为什么在这里。它可能更习惯另一种搜索顺序或者会采用不同的代码抽象。即使所有材料都能读到接手仍然会别扭。我把这种现象叫作“轨迹错配”。这是本文为了方便解释使用的说法不是学术界已有的统一术语。它指的是新模型接手了旧模型决策轨迹塑造出的现场却没有自然经历那条轨迹。这也是为什么一句“上下文都还在”没有回答完问题。Context 保存了能被交出去的内容过去几十轮里那些没有落成文字的取舍仍需要新模型重新建立。4. 真正断掉的是哪一层把一次 Coding Agent 长任务拆开大致能看到四种连续性。任务状态通常最容易保留。文件、Git diff、测试结果和 TODO 都在外部世界里只要 Harness 没有清掉它们新模型就能重新读取。输入表示会重新构造。同一段聊天需要经过具体产品的消息结构、工具结果格式、chat template 和 tokenizer才变成模型真正收到的输入。换模型或换服务后这层不一定完全相同。模型计算会重新形成。旧模型当前的注意力计算、缓存和服务内部保存的 reasoning state不能被默认视为跨模型通用资产。决策轨迹最需要人为交接。哪些路试过为什么放弃哪条假设还没证实往往散落在几十轮对话里。它们明明很重要却最容易被“聊天记录还在”这句话掩盖。所以“降智感”更适合解释为连续性断层能留下的层仍在需要重建的层没有得到足够交接。5. 实际使用时怎样安全地换模型最省事的办法是在一个小阶段刚结束时换。例如调查已经完成、准备开始实现实现已经完成、准备统一测试主任务已交付、准备做 review。此时旧模型刚好能把自己的判断收束成一份清楚记录新模型也有明确的起点。反过来如果 Agent 正在追一条复杂调用链、刚修改一半或者正在根据连续几次失败缩小范围此时切换最容易丢掉现场感。切换前我会先让当前模型停手生成一张 Handoff 交接卡我要切换模型了。请先停止继续修改并生成一份交接卡只写 1. 当前目标 2. 已完成的工作 3. 已验证事实 4. 排除过的路线及原因 5. 仍依赖的关键假设 6. 已修改和正在关注的文件 7. 下一步最小动作 8. 如果下一步失败从哪里恢复 不要继续执行任务。这张卡和普通摘要的差别在于它会保留“为什么”。只写“修改了 parser.ts测试还有一个失败”新人仍要猜。补上“尝试直接改正则会破坏转义字符因此改为先分词当前失败只出现在空输入”接手成本会低很多。新模型进来后也别急着改代码。先让它复述当前目标、已证实的事实、不能重走的路和下一步。如果复述有偏差几句话就能校正等它改出一大串文件再纠正现场已经更乱了。如果你只想解决使用问题到这里已经够了尽量在语义断点换模型切换前留下包含依据和排除路线的 Handoff。想继续深挖再往下看从这里开始讲技术细节。6. 同一份任务为什么会变成不同输入我们平常说的 Context容易把两件事混在一起。第一件是外部任务状态磁盘文件、Git diff、数据库记录、终端输出。第二件是 model-visible context也就是模型这次采样时真正收到的 token 序列。Anthropic 的 context engineering 文章也采用后一种口径模型能在一次采样里看到的 token 集合。Harness 需要把外部状态挑选、排序并序列化才能交给模型。消息角色怎样标记工具调用和工具结果怎样编码系统指令放在哪里都由 adapter 或 chat template 决定。Hugging Face 的 chat template 文档直接提醒不同聊天模型可能期待不同格式即使它们从同一个基础模型继续训练。接着才轮到 tokenizer。不同 tokenizer 可能把同一句话切成不同 token。它只能解释输入差异的一部分模板、截断、工具序列化和模型对长上下文的利用方式也会参与。聊天界面里看着相同的记录换到另一个模型后可能产生不同的 model-visible context。模型怎样使用这些输入也会跟着变化。7. KV Cache 丢了主要伤的是性能Transformer 生成内容时会为已经处理过的 token 保存 Key 和 Value后续生成可以复用这就是 KV Cache。它省掉重复计算让长对话继续生成时更快。KV Cache 和具体模型的层数、隐藏维度、权重计算紧密相关。换到另一个模型后通常不能把旧模型的缓存直接接过去。新模型需要重新处理保留下来的输入。这里要把“重新算一遍”和“变笨”分开。Cache miss 最直接的代价是重复计算、延迟和成本。如果输入内容完全保留新模型仍然可以重新计算只是要花时间。只有当系统为了预算裁剪了内容或者新模型没有得到关键依据输出质量才会进一步受影响。OpenAI 关于 GPT-5.6 工程优化的说明也把 prompt caching、KV 管理与长任务效率联系在一起。它能支持“为什么切换后可能变慢或更贵”不能单独证明模型智力下降。8. Persisted reasoning 让边界更复杂过去常见的一句话是“模型每轮都只看消息没有别的状态。”现在需要加上产品和 API 的限定。OpenAI 的 GPT-5.6 文档公开了 persisted reasoning在 Responses API 的特定用法里reasoning items 可以随 previous_response_id 在多轮之间延续手动管理历史时也需要保留相应输出项。官方 Builders Guide 还说明跨轮保留 reasoning 能改善长任务的连贯性。这说明有些服务会在聊天文本之外保存模型侧的推理材料。它也让“切模型会丢什么”变成实现相关的问题状态由谁保存生命周期多长新模型是否兼容都要看具体服务。这里的 reasoning items 不能直接写成可读思维也不能等同于 raw hidden state。官方文档说明的是某个 API 流程里的持久化能力并没有承诺任意模型之间都能无损搬运这份状态。因此讨论 Codex、Cursor 或其他 Agent 时最好先问清产品是否保留这类状态、模型切换后怎样处理。没有实现证据时只能确认聊天和外部任务状态仍在不能替服务端补写一套机制。9. 研究能证明什么不能证明什么围绕多模型路由、跨模型提示迁移和 Agent 轨迹已经有一些很接近这个问题的研究但每一篇只能支撑其中一小段。Software Engineering Agent Trajectories 把软件工程 Agent 的 thought、action 和 result 序列当作分析对象。最终答案之外行动路径本身也可以被比较和研究。本文把这类路径用于解释接手体验仍属于作者推论。DialRouter 把多轮对话里的模型选择视为长时序决策这一轮选谁会改变之后看到的状态和累计结果。它支持“路由不能只看当前一轮”的判断研究场景却不是 Coding Agent 中途交接因此不能直接证明 Coding Agent 中途换模型一定会降智。PromptBridge 研究同一提示在不同模型之间迁移时出现的性能漂移说明输入存在模型适配问题。同一份表达交给 Model B适配效果可能和 Model A 不同。Context Rot 关注长上下文搜索任务中模型利用越来越长历史时的退化。它提醒我们“材料放进上下文”不代表模型稳定使用了材料。论文测试的是特定开源模型和任务结论不能直接外推到所有 Coding Agent。把这些证据拼在一起可以得到一个工程判断模型选择、输入表示、历史长度和既有轨迹都会影响后续表现。至于某一次实际“降智”由哪一项造成仍要看当时的产品实现和任务记录。10. Context 告诉它知道什么Handoff 告诉它在哪里回到最开始的会议。新来的人可以拿到会议记录知道大家讨论过哪些事实。可要让他立刻接着做还得告诉他现在卡在哪哪条路刚试过为什么没走通下一步准备验证什么。Coding Agent 也是如此。Context 负责携带材料Handoff 负责标出当前位置和行动依据。切换模型时我们不需要 Model B 模仿 Model A 的思路只需要把当前世界交代清楚让它从一个稳定断点重新建立判断。Context 告诉它知道什么Handoff 告诉它在哪里。完整参考资料、普通 Markdown、Word 和离线 HTML请看博客网站https://aiarchblog-6hz4s01hv.maozi.io/articles/model-switch-continuity-gap/