你的编程助手中途"换脑子"了，这事儿到底靠不靠谱

你有没有遇到过这种情况：用便宜的 AI 模型跑一个复杂的编程任务，跑到一半发现它明显不太行了，卡在某个 bug 里出不来，于是你切换到更贵、更聪明的模型，让它接着干。

这个操作现在几乎是所有编程 AI 工具的标配功能。Kiro、Codex、Claude Code 这些产品里都有一个 `/model` 命令，你随时可以按下它，把接力棒交给另一个模型。用户的直觉很简单：便宜模型不行了就升级，贵模型把难点啃完了就降级省钱。听起来天经地义，对吧？

但这里有一个问题一直没人认真研究过：当新模型接手的时候，它读到的是别人写了一半的工作记录。它没有经历过之前的思考过程，却要在这些思考的废墟或者成果上继续往前走。这种"接盘"到底会发生什么？是新模型能无缝衔接，还是它会被前任的错误思路带偏，或者反过来被前任的进度拖累？

AWS 的一组研究人员做了一件挺硬核的事情：他们把这个问题拆开，系统性地测了个遍。这篇论文的结论会让很多习惯性升级模型的人重新想想自己的操作是不是划算。

先把问题讲清楚：交接的代价是什么

先解释两个贯穿全文的缩写。

低成本模型（LC，Low-Cost）和高能力模型（HC，High-Capability）：论文里用这两个词分别指代便宜但能力弱一些的模型，和贵但能力强的模型。实验中对应的是 Claude 家族的 Haiku 4.5（LC）和 Opus 4.7（HC），以及 GPT 家族的 GPT-5.6 Luna（LC）和 Sol（HC）。

研究团队定义了两种切换方向。一种叫升级（escalation），从 LC 开始跑，跑不动了换成 HC 接着干。另一种叫降级（downshift），从 HC 开始跑，觉得难的部分搞定了，换成便宜的 LC 收尾省钱。

这两种操作听起来都很合理。但研究者敏锐地意识到一个被大家忽略的细节：模型正常生成内容的时候，是在延续自己的思路，自己的措辞习惯，自己的工具调用方式，甚至自己走过的弯路。而一旦发生模型切换，接盘的模型面对的是一段它自己根本不会产生的对话记录。这段记录里可能包含它压根不会做出的推理，也可能包含它本来不会犯的错误。

这就带出了论文的核心问题。切换方向会不会决定这段"遗产"是助力还是包袱？HC 模型接手 LC 的烂摊子，会不会被 LC 走错的方向带偏？LC 模型接手 HC 的半成品，是能顺势躺赢，还是会因为要延续超出自己能力的推理而彻底翻车？

为了回答这些问题，研究团队在 SWE-bench Verified 这个基准上做了大规模实验。

SWE-bench Verified：一个基于真实 GitHub issue 的代码修复测试集，每个任务都是让 AI 去修复一个真实项目里报告的 bug，修复完之后用可执行的测试用例判断成功还是失败，还标注了任务难度。

他们设计了三个变量维度：切换方向（升级还是降级）、切换时机（在任务进行到百分之多少的时候切换）、以及最关键的一个变量，交接接口，也就是新模型到底能看到多少前任留下的信息。

交接接口一共设计了四种。原始交接（Raw）是把前面所有的对话记录原封不动地全部传给新模型，包括所有的推理过程、工具调用、观察结果。压缩交接分两种，一种是让前任模型自己把工作总结成一段摘要再交给继任者（Compact_pre），另一种是让继任者读完前任的完整记录后自己写摘要（Compact_suf）。第四种叫轨迹丢弃（Traj-drop），就是干脆什么对话记录都不传，新模型只能看到代码仓库现在的状态（哪些文件被改过），完全不知道之前发生了什么对话。

这四种接口有一个共同点：无论传不传对话记录，代码仓库里已经修改的文件永远会保留下来。变量只有一个,新模型脑子里到底装了多少"前情提要"。

这套实验的规模相当惊人。两个模型家族，每个家族 58 种配置组合，跑了 58000 次完整的智能体运行，产生了 200 万次模型 API 调用，处理了 360 亿个 token。这不是随便测几个案例就下结论的水平。

升级：多花钱，却没多解决多少问题

先说升级这个方向的结果,这可能是整篇论文里最反直觉的部分。

论文用了两个指标衡量效果。质量恢复率（QRec）衡量的是升级之后，新模型追回了多少 HC 和 LC 之间原本的能力差距,0 表示完全没追上，100 表示彻底追平了 HC 单独跑的水平。成本节省保留率（CSRet）衡量的是升级过程中还保留了多少 LC 原本的省钱优势，100 表示花的钱跟 LC 差不多，0 表示花的钱跟 HC 一样多，负数则表示比直接用 HC 从头跑还贵。

结果是这样的：在两个模型家族里，最标准的"原始交接"方式，也就是把完整对话记录直接甩给继任模型，追回的质量差距都不到一半。Claude 这边是 47%，GPT 这边是 36%。

这已经够让人意外了,你花了额外的钱升级模型，结果它连一半的能力差距都补不上。但更狠的还在后面。

对于 Claude 这一对模型来说，原始交接的花费比直接从头用 HC 跑一遍还要贵超过两倍（1.61 美元对 0.72 美元）。研究者进一步做了个对照实验：如果你把 LC 跑到一半的工作全部扔掉，代码修改也不要了，纯粹当作沉没成本，然后让 HC 从零开始重新跑一遍任务，会发生什么?

答案是，即使把这笔"扔掉的 LC 花费"也算进总账，重新开始跑仍然比继续原始交接更便宜，而且解决的问题更多。也就是说，对 Claude 这对模型，原始交接的升级操作在经济上完全说不通,你不如假装刚才什么都没发生，直接找 HC 重新做一遍。

这里有个日常场景可以帮你理解这个现象。想象你请了一个装修师傅来给房子刷墙，刷了一半你发现他手艺不够好，墙面坑坑洼洼，于是你换了个更贵的老师傅来接手。这个老师傅面对的选择是两种：要么彻底铲掉重刷，要么在原来那层坑洼的底子上继续刷。如果他选择继续刷，他得先花时间搞清楚之前那层墙到底出了什么问题，判断哪些地方能保留哪些地方必须处理，这个诊断成本本身就相当高,而如果他一开始就铲了重来，反而更快更干净。论文里 Claude 的情况正是这样：继任模型花在"读懂并纠正前任遗留问题"上的成本，比它自己从零开始干还要贵。

那既然原始交接不划算，改变一下继任模型能看到的信息量会不会有帮助？答案是肯定的，而且方向很清楚,减少继任模型看到的前任信息，反而能改善升级效果。

研究者测了不同程度的信息削减。让前任模型自己写一份摘要（Compact_pre），效果最好的地方在于省钱：Claude 这边成本节省保留率从 -285% 直接拉回到 -11%，几乎跟 HC 单独跑的成本打平了。而更激进的做法,直接把对话记录整个丢掉，只保留代码仓库里已经改过的文件（Traj-drop）,则在质量恢复上表现最好：Claude 这边质量恢复率从 47% 提升到 64%，GPT 那边更夸张，从 36% 直接跳到 84%。

这个现象背后是什么机制？研究者做了进一步拆解，发现原始交接之所以贵，主要不是因为继任模型需要跑更多步骤，而是因为每一步的成本更高了。具体数字是这样的：相比压缩交接，原始交接下 HC 模型每一步的平均花费要贵 2.2 倍（Claude）和 1.6 倍（GPT），而两种方式所需的步骤数其实差不多。

这说明了什么?

那些完整传递过去的对话记录，本身就成了一种沉重的负担，让继任模型每次思考都要多咀嚼一大堆不属于它自己的推理内容，处理这些冗长上下文本身就很烧钱。

这里还有个细节值得单独说一说。研究者发现难度会改变结论,前面说的"Claude 升级不划算"这个结论，在简单和中等难度任务上确实成立，但在难任务上会发生反转。在难任务这个子集里，那三种做过信息削减的交接方式，成本都比直接用 HC 从头跑还便宜，同时质量恢复率能达到 65% 到 74%，反而是最原始的完整交接方式没能完成这个转变，依然比 HC 单独跑更贵。

也就是说，难度越高，前任模型留下的"半成品状态"（代码仓库里已经改动的部分）越有价值，因为这些改动本身包含了对问题的初步探索，即使推理过程被丢掉了，代码层面的进展依然是有用的踏脚石。不过研究者也坦承，这个难任务子集样本量比较小（平均每格大约 24 个任务），所以这个发现更多是探索性质的，还不能算是跨模型家族都成立的铁律。

降级：省钱效果不错，但别把前任的功劳一起扔了

升级这边的结论让人有点泄气，那降级方向情况会不一样吗？

答案是,是的，情况完全不同，而且方向反过来了。

在降级场景里，原始交接（把完整对话记录传给便宜模型）反而是一个相当划算的选择。以 Claude 为例，从 HC 降级到 LC 之后，采用原始交接的通过率从 LC 单独跑的 54.6% 提升到 65.6%，而成本只从 0.41 美元涨到 0.51 美元，保留了 LC 原本 80% 的省钱优势。GPT 那边表现出不同的平衡点：原始交接保留了 HC 79% 的质量优势，但只保留了 LC 14% 的省钱优势。

换句话说，两个模型家族的 LC 接盘模型都能把 HC 前期的努力转化成一个介于两者之间的甜蜜点,比 HC 单独跑省钱，比 LC 单独跑更好用。只是 Claude 这对模型更偏向省钱，GPT 这对模型更偏向保留质量。

那降级过程中，到底是代码仓库的改动重要，还是对话记录本身重要?

研究者用轨迹丢弃这个接口来做隔离实验：保留代码改动，但把对话记录彻底删掉。结果非常明确,轨迹丢弃在升级场景里是表现最好的接口，但在降级场景里却变成了表现最差、最贵的选项。

具体数字是这样的：Claude 这边，轨迹丢弃只能恢复 28% 的质量差距，而原始交接能恢复 50%，压缩交接能恢复 56%，同时轨迹丢弃保留的成本优势也只有 59%。GPT 那边情况类似，轨迹丢弃只恢复 53% 的质量差距，原始交接能恢复 79%。

这说明前任模型留下的对话记录，对接盘的 LC 模型来说是至关重要的引导。这里可以拿一个具体场景来打比方。想象你是一个刚接手项目的实习生，前面负责这个项目的资深工程师已经把大部分架构搭好了，但突然要出差了。如果他只留给你一份代码，什么口头交接都没有，你自己去猜他当初为什么这么设计，哪些地方是刻意为之，哪些地方是权宜之计，你很可能会浪费大量时间重新摸索甚至走弯路。但如果他留下一份详细的交接笔记，哪怕只是简单说明"这个模块我试过两种方案，第二种更稳定"，你接手起来的效率会完全不一样。降级场景里的 LC 模型，恰恰扮演了这个"实习生"的角色,它自身能力有限，非常依赖前任留下的推理线索来理解"接下来该怎么做"，如果这些线索被抹掉，它就得自己从头摸索，往往要多走不少步骤。

研究者对这一点也做了机制层面的验证。相比压缩交接，轨迹丢弃在降级场景下需要多花 1.6 倍（Claude）到 2.0 倍（GPT）的步骤数，而每一步的花费其实差不多。这跟升级场景的机制刚好相反,升级场景里贵在"每一步更贵"，降级场景里贵在"步骤更多"。这个对比本身就说明了两种方向下继任模型面临的困境完全不同：HC 接手 LC 的烂摊子，负担来自消化冗余的错误推理；LC 接手 HC 的半成品，困难来自缺少足够线索去理解已经做到哪一步。

一个反常识的发现：交接信息的价值居然是方向性的

把升级和降级的发现放在一起看，会得到一个挺有意思的对称结构。

在升级方向上，减少 LC 留下的对话记录能帮助 HC 表现得更好。

在降级方向上，删掉 HC 留下的对话记录会明显损害 LC 的表现。

也就是说，同一份"前任留下的对话记录"，对不同能力的接盘者来说，价值截然相反。对于能力更强的 HC 来说，读到能力较弱的 LC 走过的弯路和错误推理，反而是一种干扰，删掉它能让 HC 轻装上阵。而对于能力较弱的 LC 来说，能力更强的 HC 留下的推理过程恰恰是宝贵的指南，删掉它会让 LC 迷失方向。

这个发现其实提示了一个更深层的问题：我们平时默认"信息越多越好"这个直觉，在这里并不总是成立。信息的价值取决于接收者的处理能力和它跟信息来源的能力落差,如果接盘者比前任更强，前任的思考过程可能就是杂音；如果接盘者比前任更弱，前任的思考过程就是救命稻草。

论文还专门做了一个小实验来验证：是不是只要告诉 HC 模型"这段对话是别的模型生成的"，就能缓解升级场景里的问题？研究者在原始交接的基础上，加了一句提示语，明确告诉继任模型前面的工作来自不同的模型。结果显示，这种"仅仅告知"的做法确实带来了轻微的质量提升，但成本反而略微上涨了，整体表现依然远远落后于压缩交接和轨迹丢弃这两种接口。这说明问题不在于"知不知道换了模型"，而在于对话记录本身携带的冗余信息量。

换个场景测试：任务类型会改变结论吗

到这里，所有结论都建立在 SWE-bench 这个代码修复场景上,一个任务需求一开始就完整写清楚，只是代码仓库的状态在执行过程中不断变化。研究者想知道，如果换一种任务类型，需求本身是逐步揭露出来的，或者信息是靠一步步搜索积累出来的，结论会不会不一样。

他们额外测了两个场景。

Lost in Conversation（简称 LiC）：一个多轮对话基准，任务的完整需求被拆成好几个片段，每一轮对话才透露一小部分，模拟真实用户"边聊边补充要求"的场景。

在这个场景里，覆盖代码、数据库查询、函数调用、数学题和数据转文本五类任务，结果显示出一个反转：升级恢复了 86% 的质量差距，同时保留了 36% 的成本优势；降级只恢复了 31% 的质量差距，虽然保留了 53% 的成本优势。

这跟代码任务场景的结论正好相反,这里升级反而效果更好。原因不难理解：因为需求是逐步揭露的，任务只有等到最后一个信息片段出现才算真正完整，所以谁来处理"最后一块拼图"决定了整体表现。如果把这个关键时刻交给能力更强的 HC 来处理，自然更容易把任务做对。

另一个场景是 BrowseComp,一个需要联网搜索才能回答的高难度问答基准，题目一开始就完整给出，但答案需要靠一步步搜索去拼凑证据。

在这个场景里，升级几乎追平了 HC 单独跑的质量水平（质量恢复率高达 95.8%），但依然没能省钱,成本节省保留率是 -30%，甚至比直接放弃 LC 前面的工作、重新用 HC 跑一遍还要贵。降级则再次表现出一个折中的甜蜜点，恢复了 56.7% 的质量优势，同时保留了 76.8% 的成本优势。

这几个场景放在一起，其实揭示了一条更普遍的规律：交接是否划算，不仅取决于两个模型的能力差距，还取决于任务本身"信息什么时候变得完整"这个特性。如果任务信息一开始就摆在桌面上，只是执行过程留下痕迹（比如代码仓库），前任积累的探索成果价值有限,但如果任务信息本身是逐步展开的，谁负责处理"信息完整之后的那一刻"就变得格外关键。

写在后面

读完这篇论文，最让我意外的一点是，"升级模型"这个几乎所有人下意识觉得理所当然的操作，在最主流的原始交接方式下，居然经常是亏本买卖。我们平时用编程助手切模型的时候，脑子里的默认假设是"贵的模型肯定能兜住便宜模型留下的烂摊子"，但论文里 Claude 那组数据说得很直白：继续用原始交接方式接盘，比直接认赔重来还要贵。这个反差感挺强的。

还有一点值得单独拎出来说：论文把"交接接口"当成一个独立于"该不该切换模型"之外的设计变量，这个视角本身就挺有启发性。我们平时讨论 AI 模型路由的时候，聊的往往是"什么时候该切换到哪个模型"，很少有人认真想过"切换的时候到底该传递多少上下文"这件事本身也需要精心设计，而且这个设计的最优解还会随方向反转。这提醒我，很多系统设计问题里，"要不要做一件事"和"怎么做这件事"其实是两个维度，容易被我们混为一谈。

论文里没有解决的问题也很明显：如果连续切换好几次模型会怎样？如果切换发生在同一次对话内部而不是任务级别会怎样？这些问题留白挺大的，也让人好奇。

Q&A

Q1：什么是"Handoff Tax"（交接税）？

A：这是论文提出的核心概念，指的是当一个 AI 模型接手另一个模型跑到一半的编程任务时，由于要理解和延续一段自己没有生成的对话记录，会产生额外的质量损失或成本浪费。实验发现，标准的完整交接方式在升级场景下追回的能力差距不到一半，却要多花好几倍的钱。

Q2：升级模型（换成更贵更强的模型）到底划不划算？

A：如果用最常见的"直接传递完整对话记录"方式，往往不划算。以 Claude 这对模型为例，这样操作甚至比直接放弃前面的工作、重新用贵模型跑一遍还要贵。但如果减少传递给新模型的历史信息（比如只传一份摘要，或者干脆只保留代码改动不传对话记录），情况会明显改善。

Q3：降级模型（换成便宜模型收尾）值得推荐吗？

A：相对来说更值得。降级场景下，便宜模型能够借助贵模型留下的对话记录，取得一个介于两者之间的性价比甜蜜点，既比单纯用贵模型省钱，又比单纯用便宜模型效果更好。但要注意，千万不能把贵模型留下的对话记录直接删掉，那样会显著拉低便宜模型接手后的表现。