为什么中途换模型会“降智”？

今天的唯一目标

从会议记录和旧模型收拾过的工地出发，解释模型切换时任务状态、输入表示、模型计算和决策轨迹之间的连续性断层，并给出可直接使用的 Handoff 方法。

你是否遇到过这个提示？

它的大意是：任务做到一半时切换模型，后续表现可能变差。

奇怪的是，聊天记录、代码和 TODO 明明都还在。为什么换了模型，它却开始重复搜文件、追问已经回答过的问题，甚至重走刚被排除的路？

把它想成一次临时换人就好理解了：Model B 拿到了完整的会议记录，却没参加前面两个小时的讨论。它知道大家做了什么，却不一定知道为什么这样做。

记录可以继承，前一个模型形成的计算与判断不能默认继承。

1. 聊天记录还在，它为什么突然不在状态？

Model A 已经在项目里调查了半小时。它搜过入口文件，读了调用链，改了两处代码，跑测试后又撤回其中一处。此时换成 Model B，聊天和文件都交过去了。B 当然能看见结果，但它未必知道：为什么先查这个入口，哪个猜测已经被日志否掉，那处改动为什么要撤回。

于是 B 重新搜索、重新提问，还可能重试已经失败的方案。重复调查不等于模型必然变笨。更常见的原因是：它接手了结果，却没有接上前面的判断过程。

提示里写的是“可能”。模型能力、上下文裁剪、工具实现和切换时机都会影响实际表现。

2. 换了一个新大脑，但只拿到了会议记录

Coding Agent 外面通常有一层 Harness。这里的 Harness 可以理解为整套工作台：它管理对话、文件、工具、任务列表，也负责把当前材料整理后交给模型。

如果中途换模型，Harness 能继续保留很多东西：

聊天里明确写出的结论；
当前工作区里的文件；
终端输出和工具结果；
TODO、计划和已完成项。

这些东西很像会议记录。记录越完整，新来的人越容易接手。不过，会议记录很难装下讨论现场的全部判断。有人看了三个报错后对某条线索提高了警惕；有人把五个方案比较过一遍，觉得第二个最稳；有人刚试过一条近路，发现会破坏兼容性。这些判断如果没有明确写出来，新人只能重新推。

图Harness 能交接聊天、文件、工具结果和 TODO，Model A 没写下来的判断不会自动搬家

模型也有类似差别。旧模型在连续生成、读取工具结果和调整计划的过程中，形成了当下这一步的计算状态。换模型后，新模型拿到的是 Harness 能保存并重新呈现的材料。它需要根据这些材料重新理解项目，无法直接接走前一个模型的全部内部计算。

“换了一个新大脑”只是便于理解的比喻。模型没有人的意识。技术上更准确的说法是：外部任务状态可以保存，模型侧的计算需要重新形成。

3. Context 是旧模型收拾过的工地

Context 看起来只是资料，形成过程却带着旧模型走过的痕迹。

假设最初的代码库是一块空工地。Model A 进来后会不断做选择：

text可复制后修改

决定搜什么
↓
决定读哪些文件
↓
决定修改哪里
↓
根据测试结果继续或撤回

到了第 50 轮，工作区和聊天记录早已不是“原始项目 + 全部资料”。它们是 Model A 沿着一条具体路线调查、修改、排除后留下的现场。

图Model A 经过搜索、读文件、修改和测试塑造了当前现场，Model B 从轨迹末端接手

Model B 从半路进来，看到脚印、路障和已经拆开的墙，却不一定清楚每个东西为什么在这里。它可能更习惯另一种搜索顺序，或者会采用不同的代码抽象。即使所有材料都能读到，接手仍然会别扭。

我把这种现象叫作“轨迹错配”。这是本文为了方便解释使用的说法，不是学术界已有的统一术语。它指的是：新模型接手了旧模型决策轨迹塑造出的现场，却没有自然经历那条轨迹。

这也是为什么一句“上下文都还在”没有回答完问题。Context 保存了能被交出去的内容，过去几十轮里那些没有落成文字的取舍，仍需要新模型重新建立。

4. 真正断掉的是哪一层？

把一次 Coding Agent 长任务拆开，大致能看到四种连续性。

任务状态通常最容易保留。文件、Git diff、测试结果和 TODO 都在外部世界里，只要 Harness 没有清掉它们，新模型就能重新读取。

输入表示会重新构造。同一段聊天需要经过具体产品的消息结构、工具结果格式、chat template 和 tokenizer，才变成模型真正收到的输入。换模型或换服务后，这层不一定完全相同。

模型计算会重新形成。旧模型当前的注意力计算、缓存和服务内部保存的 reasoning state，不能被默认视为跨模型通用资产。

决策轨迹最需要人为交接。哪些路试过，为什么放弃，哪条假设还没证实，往往散落在几十轮对话里。它们明明很重要，却最容易被“聊天记录还在”这句话掩盖。

所以，“降智感”更适合解释为连续性断层：能留下的层仍在，需要重建的层没有得到足够交接。

5. 实际使用时，怎样安全地换模型？

最省事的办法，是在一个小阶段刚结束时换。

例如：调查已经完成、准备开始实现；实现已经完成、准备统一测试；主任务已交付、准备做 review。此时旧模型刚好能把自己的判断收束成一份清楚记录，新模型也有明确的起点。

反过来，如果 Agent 正在追一条复杂调用链、刚修改一半，或者正在根据连续几次失败缩小范围，此时切换最容易丢掉现场感。

切换前，我会先让当前模型停手，生成一张 Handoff 交接卡：

text可复制后修改

我要切换模型了。请先停止继续修改，并生成一份交接卡，只写：
1. 当前目标
2. 已完成的工作
3. 已验证事实
4. 排除过的路线及原因
5. 仍依赖的关键假设
6. 已修改和正在关注的文件
7. 下一步最小动作
8. 如果下一步失败，从哪里恢复
不要继续执行任务。

图在调查完成、准备实现的语义断点生成 Handoff，再由 Model B 继续

这张卡和普通摘要的差别，在于它会保留“为什么”。只写“修改了 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 告诉它在哪里。

---