AgentBaton: 智能体任务中的高效模型协作

1. 问题与价值

这篇论文解决的核心问题是：在长程智能体任务中，昂贵的能力模型和便宜的效率模型能否在同一个任务内部协作，从而在保持任务准确率的同时大幅降低 API 成本。

这个问题之所以重要，是因为长程智能体任务需要模型与环境多轮交互，每轮都要调用模型推理。能力模型虽然可靠，但反复调用会产生很高的推理成本；效率模型虽然便宜，但单独使用时任务准确率明显偏低。传统的 query-level routing 只在任务开始前根据初始问题做一次模型选择，无法利用任务执行过程中产生的动态状态信息。

受益方很直接：任何需要大规模运行编码智能体或终端智能体的团队。例如，一个用 GPT-5.6 Sol 跑 DeepSWE 的团队，如果采用 AgentBaton 在合适时机切换到 Qwen 3.8 27B，可以在准确率从 68.1% 降到 60.2%（相对损失 11.6%）的同时，把单任务平均 API 成本从 5.32 美元降到 1.02 美元，降幅 80.8%（原文 Table 3 中「能力模型 GPT-5.6 Sol、接收模型 Qwen 3.8 27B」那一行）。如果切换到更强的 GPT-5.6 Luna，损失更小：同一张表里 Sol 组切到 Luna 那一行的交接点同样是 26.6%（表注写明「Handoff is the mean detected progress (%), shared across receiving models for a given source」，同一源模型的所有接收模型共用这个交接点），切完准确率 67.3%、相对 68.1% 只损失 1.2%，成本从 5.32 美元降到 1.39 美元（降幅 73.9%）。注意 67.3 是准确率不是进度 —— 它恰好与另一行 Claude Opus 5 单独跑时的准确率 67.3 同值，很容易读串。

2. 已有工作的不足

在 AgentBaton 之前，处理异构模型协作的主流做法集中在两个层面。

第一类是 query-level routing 和 cascading，代表方法有 FrugalGPT、RouteLLM、RouterDC、Route to Reason。这些方法在单个请求到达时，根据初始 query 决定用哪个模型，或者按成本从低到高级联调用。它们的不足在于：长程智能体任务中，智能体的动作会修改工作区、产生动态反馈，真正需要的能力是随回合演化的，而不是在任务开始前就能确定的。论文明确说“assigning a task to a model solely based on its initial query falls short in long-horizon agentic tasks”。

第二类是 multi-round routing 和 orchestration，代表方法有 MTRouter、Router-R1、ToolOrchestra、SkillOrchestra、Agent-as-a-Router。这些方法在任务执行过程中逐轮选择模型或工具。MTRouter 是论文直接对比的基线，它用交互历史做 turn-level routing。论文指出这类方法的问题在于：频繁切换会累积轨迹错误，能力模型必须反复消耗精力去恢复。实验上，AgentBaton 相对 MTRouter 在四个设置中把 API 成本降低了 46.7% 到 86.6%，同时准确率持平或更高。

与本文最接近的还有 The Handoff Tax，它研究了 handoff 方向、时机和轨迹转移接口对编码智能体的影响，但它的切换点是预定义的，没有学习何时切换。AgentBaton 的增量在于把“何时切换”本身变成一个可学习的在线检测问题。

3. 重建作者的思考路径

如果我是作者，面对第 2 项里的不足，我会先问一个最朴素的问题：既然 query-level routing 不够，那能不能让两个模型在任务中途交换控制权？这自然引出两个方向。

第一个分叉：谁先谁后。 直觉上，让效率模型先跑、遇到困难再交给能力模型，似乎能最大化节省成本，因为能力模型只在“必要”时介入。这个想法很诱人，我会先试这个方向。但一跑实验就撞上矛盾：效率模型先跑，能力模型接手时，要么准确率保不住，要么成本没省下来。以 DeepSWE 上 Qwen 到 GPT-5.6 Sol 的 30% 进度切换为例（logfile 方式转移，原文 Table 1），准确率 70.8% 比 GPT 单独跑的 68.1% 还高一点，但成本 5.00 美元对 5.32 美元，只降了 6.1%。这说明“晚点叫能力模型”并不能稳定地既省钱又不掉准确率。更深层的原因是：效率模型早期产生的轨迹可能把任务带偏，能力模型接手后要花额外精力纠偏，这个恢复成本抵消了节省。

第二个分叉：反过来，能力模型先跑，效率模型收尾。 这个方向一开始并不显然，因为效率模型单独跑时准确率很低，凭什么它能在后半段接手？但实验给出了一个反直觉的结果：能力模型先建立实现、拿到反馈、把剩余工作收窄到局部修复之后，效率模型居然能接得住。比如 GLM-5.3 在 30% 进度切换给 Qwen，准确率 61.1% 和 GLM 单独跑持平，成本降了 82.4%。这让我意识到：任务的前半段和后半段对能力的需求是不对称的。前半段需要选方案、搭骨架，这是能力模型的价值所在；后半段往往是局部诊断、修复、验证，效率模型在“已有正确骨架”的前提下可以胜任。

第三个分叉：历史怎么传。 直接塞进上下文最直观，但会拉长 prefill 和后续每轮的输入长度，而且前任的推理和动作可能带偏继任者。写进 log 文件让继任者按需查看，省 token 但多了一层“继任者愿不愿意去查”的不确定性。实验结果是方向相关的：效率到能力方向，logfile 普遍更好；能力到效率方向，取决于源模型是否暴露推理轨迹。GLM 和 Kimi 暴露 CoT，in-context 更好；GPT-5.6 Sol 不暴露完整 CoT，logfile 在多数情况下更好。这个发现说明上下文转移不是一个统一答案，而是和“继任者能从历史里读到什么”强相关。

第四个分叉：谁来决定何时切换。 有了“能力到效率、在合适时机切换”这个方向后，最自然的实现是让能力模型自己决定。我试了 prompt-based handoff，结果很分裂：Kimi K3 一次都不交棒，GLM-5.3 只在 113 个任务里交棒 6 次，GPT-5.6 Sol 每次都交棒但成本仍然偏高。这说明把决策权交给执行模型不可靠——它要么不愿意放弃控制，要么乱交棒。于是只能引入一个独立的轻量检测器，专门判断“当前进度是否适合交棒”。

第五个分叉：检测器学什么信号。 如果只学过回合数或进度百分比，那就是固定阈值，没有泛化能力。我需要从轨迹里找可泛化的模式。回看成功和失败的切换案例，发现三个反复出现的信号：有实质性的实现或工件；这个工件已经被真实执行或测试过并产生了反馈；剩余工作已经收窄到局部诊断、修复、验证或最终输出准备。关键洞察是：反馈不一定是正面的，失败的执行如果能把问题定位清楚，也算“准备好交棒”。这三点后来成为标注协议的核心。

与论文实际路径的差异：我猜的路径和论文实际走的路径在大方向上一致，但有一个重要差异。我最初会倾向于把“效率到能力”和“能力到效率”当作两个对等的候选方向去调优，而论文通过 checkpoint 实验更早地确立了方向不对称性，并且明确把“per-turn routing 不实用”作为一个结论，而不是一个待验证的假设。另一个差异是：我可能会先尝试用强化学习或更复杂的策略来学切换点，而论文选择了监督学习加一个 2B 的小模型，用 Codex 标注的轨迹做训练，这个选择更务实，也更容易复现。

4. 核心 intuition

用一个日常类比：资深工程师搭骨架，初级工程师收尾。

想象一个软件团队。资深工程师负责理解需求、选技术方案、搭出能跑的主干代码，并跑通第一轮测试。这个阶段需要全局判断力和经验，初级工程师做不了。但一旦主干代码存在、测试反馈已经指出问题在哪，剩下的工作就变成“修这个路径处理的 bug”“验证这个坐标变换对不对”“把编码器重写一遍”——这些是局部、有明确目标的工作。此时把任务交给初级工程师，他不需要重新理解整个项目，只需要在已有的骨架上做局部修补。

这个类比能对上机制，因为论文的三个 handoff-readiness 条件正好对应“骨架已搭好”“骨架已被真实测试过”“剩余工作已收窄到局部修补”。效率模型之所以能在后半段接手，不是因为它变强了，而是因为任务状态本身被能力模型改造得更简单了。能力模型的价值在于把“开放性问题”转化成“局部问题”，这个转化一旦完成，效率模型就能接手。这也解释了为什么效率到能力方向不划算：效率模型没有能力完成这个转化，能力模型接手时面对的是一个可能已经被带偏的开放问题，省下的钱不够弥补纠偏成本。

5. 方法 pipeline 举例

以 DeepSWE v1.1 上的一个任务为例，源模型是 GPT-5.6 Sol，接收模型是 Qwen 3.8 27B，使用 logfile transfer。

输入任务：修复一个 Python 项目中“带空格的引号路径处理失败”的 bug，要求所有测试通过。

第 1 步：能力模型开始执行。 GPT-5.6 Sol 从任务描述出发，先读代码、定位相关模块，然后写了一个初步实现和测试。此时工作区里有了实现和测试文件，但带空格的引号路径仍然失败。

第 2 步：AgentBaton 逐轮检测。 每轮结束后，AgentBaton 读取当前轨迹（系统指令、原始任务、每轮的工具调用和工具响应），输出一个 JSON 判断。在实现刚写完但还没跑测试时，它输出 HANDOFF_NOT_READY，因为虽然有了工件，但还没有真实反馈。在测试跑完、失败信息明确指向引号路径处理后，它仍然输出 HANDOFF_NOT_READY，因为剩余工作还不够局部——可能还需要定位具体是哪一行的问题。

第 3 步：能力模型继续推进。 GPT-5.6 Sol 复现了带空格引号路径的失败，定位到路径匹配的引号规范化逻辑，并修复了它。此时工作区里包含了这个修复。

第 4 步：AgentBaton 检测到切换点。 在修复完成后的那一轮，AgentBaton 输出 HANDOFF_READY。判断依据是：实质性实现存在；它已经被真实执行并产生了失败反馈；剩余工作已经收窄到“验证修复、跑额外测试”。

第 5 步：切换。 控制权转移给 Qwen 3.8 27B。工作区原样继承，包括修复后的代码。执行历史被写入一个 .jsonl log 文件，每条记录包含回合索引、模型响应、动作列表、每个动作的命令和工具输出（返回码、stdout、stderr）。Qwen 3.8 27B 收到原始任务指令、log 文件路径和字段 schema，并被指示先看最后几条记录了解最新状态。

第 6 步：效率模型收尾。 Qwen 3.8 27B 用 cat 或 grep 查看 log 的最后几条记录，理解修复内容，然后运行额外测试，确认任务通过，提交最终结果。

成本对比：GPT-5.6 Sol 单独跑这个任务假设花费 5.32 美元。AgentBaton 平均在轨迹的 26.6% 处交接（表注：handoff 指平均检测进度），此后由 Qwen 3.8 27B 接手、本地部署按论文口径记零成本，单任务平均 API 成本约 1.02 美元，降幅 80.8%。准确率从 68.1% 降到 60.2%，相对损失 11.6%。

6. 核心数学推导

论文没有给出一个传统意义上的核心数学公式，它的核心机制是一个分类器的监督学习目标。我把它拆解如下。

设一条轨迹有 T 个工具回合，记为 t = 1, 2, ..., T。标注协议给出一个最早合适切换点 h，表示在第 h 个回合结束后，三个 readiness 条件首次同时成立。如果整条轨迹都没有这样的点，则标记为 no_clear_handoff_point，不参与 h 的监督。

AgentBaton 是一个参数为 θ 的模型，输入是到当前回合 t 为止的轨迹前缀，记为 x_t = (系统指令, 原始任务, 动作_1, 工具响应_1, ..., 动作_t, 工具响应_t, 之前的判断_1, ..., 之前的判断_{t-1})。输出是一个二分类判断 y_t ∈ {HANDOFF_NOT_READY, HANDOFF_READY}。

对于标注切换点为 h 的轨迹，监督信号是：

• 对 t < h，目标标签是 HANDOFF_NOT_READY；
• 对 t = h，目标标签是 HANDOFF_READY；
• 对 t > h，额外构造训练样本：把当前回合的目标标签设为 HANDOFF_READY，之前所有判断的目标标签设为 HANDOFF_NOT_READY，并且之前判断不参与 loss 计算。

这个构造的含义是：如果检测器在 h 之前漏判了，它应该在后续某个回合 t > h 仍然触发切换。这模拟了“错过机会后补触发”的场景，同时平衡了正负标签比例。

训练目标是标准的交叉熵损失，对每个参与 loss 的回合 t：

L_t(θ) = -log Pr[ y_t^* ∣ x_t ; θ ]

其中 y_t^* 是该回合的目标标签。总损失是所有参与 loss 的回合的 L_t 的平均。

一句话总结：这个公式在算的是“给定到当前回合为止的执行轨迹，检测器输出正确切换判断的对数似然”，训练目标是让检测器在标注的最早合适点及之后任何回合都能识别出 HANDOFF_READY，而在之前识别为 HANDOFF_NOT_READY。

推理时的决策规则是：从 t = 1 开始逐轮检测，第一个输出 HANDOFF_READY 的回合触发切换，之后不再检测。如果直到任务结束都没有触发，则相当于能力模型单独跑完全程。

7. 实验设计

数据集：两个长程智能体基准。Terminal-Bench 2.1 覆盖终端工作流，包括软件工程、科学计算、系统管理；DeepSWE v1.1 聚焦有挑战性的长程软件工程任务，用程序化 verifier 评估。训练数据来自 SWE-rebench V2 的 2000 个随机采样任务，每个任务用两个不同的能力模型各跑一次，共 4000 条轨迹，用 Codex 标注最早合适切换点。

模型：能力模型包括 GPT-5.6 Sol、Kimi K3、GLM-5.3、Claude Opus 5、Gemini 3.8 Flash；效率模型包括 Qwen 3.8 27B（本地部署，成本计为零）和 GPT-5.6 Luna（低成本云端模型）。AgentBaton 本身从 Qwen 3.5 2B 初始化。

基线：单模型能力模型执行、单模型效率模型执行、MTRouter（per-turn routing）、固定进度切换、固定回合切换、prompt-based handoff。

指标：任务准确率（百分比）和平均 API 成本（美元每任务）。成本只计云端模型的 token 费用，本地部署的 Qwen 3.8 27B 计为零成本。

消融：上下文转移方法（in-context vs logfile）在两种切换方向上分别比较；切换进度从 15% 到 90% 六个档位；AgentBaton 与固定进度、固定回合、MTRouter 的对比；推理努力程度从 low 到 max 的 sweep。

实验能否支撑结论：核心结论“能力到效率的一次性切换能在保持准确率的同时大幅降成本”有较充分的支撑，因为它在 11 个模型对、两个基准上重复出现。但有几个缺口。第一，成本核算把本地模型计为零，这忽略了本地硬件的折旧、能耗和部署成本，实际成本优势会被高估。第二，AgentBaton 的训练数据来自 SWE-rebench V2，而评估在 DeepSWE 和 Terminal-Bench 上，跨基准泛化有体现，但训练集和测试集的领域差异没有被系统消融。第三，AgentBaton 是从 Qwen 3.5 2B 初始化的本地检测器，按论文「本地可部署模型记零成本」的约定，它 338ms 中位延迟背后的算力没有进入成本比较 —— 这不是遗漏，而是口径；但它和第一条缺口是同一件事的两面，读的时候容易漏掉。第四，准确率在部分设置下有明显下降，比如 GPT-5.6 Sol 到 Qwen 在 DeepSWE 上相对损失 11.6%，论文用“largely preserving”来概括，但这个损失是否可接受取决于应用场景。

8. take-aways

1. 能力到效率的切换方向明显优于效率到能力：在 DeepSWE 上，GLM-5.3 在 30% 进度切换到 Qwen 3.8 27B 时准确率 61.1% 与 GLM 单独跑持平，成本降 82.4%；而效率到能力方向，Qwen 到 GPT-5.6 Sol 在 30% 进度切换时成本只降 6.1%。

1. 上下文转移方法的选择取决于切换方向：效率到能力方向 logfile 普遍更好；能力到效率方向，暴露 CoT 的 GLM-5.3 和 Kimi K3 用 in-context 更好，不暴露完整 CoT 的 GPT-5.6 Sol 用 logfile 在多数情况下更好。

1. 切换时机比切换方法更关键：固定进度切换虽然能访问未来信息（源模型的最终轨迹长度），但准确率与 AgentBaton 接近，而 AgentBaton 成本更低或持平；固定回合切换的准确率则一致低于 AgentBaton。

1. 更强的接收模型可以逆转准确率损失：在 DeepSWE 上，五个能力模型切换到 GPT-5.6 Luna 时，有四个超过了能力模型单独跑的准确率，例如 Claude Opus 5 从 67.3% 提升到 76.1%，同时成本降 70.5%。

1. 推理努力程度和模型切换是互补的算力分配手段：Kimi K3 在 high effort 下切换到 GPT-5.6 Luna 达到 79.6% 准确率、1.60 美元成本（原文 Table 6 的 Kimi 组那两行），超过了 sweep 中最高的单模型准确率 75.2%（Claude Opus 5 在 xhigh effort 下，成本 8.90 美元）。这里的源模型是 Kimi K3，与前面 Sol 组切 Luna 是两个不同设置。

9. 最脆弱的假设

最脆弱的假设是：能力模型前半段建立的进展可以被效率模型可靠地继承和利用，且这种继承不会因为模型间的行为差异而产生系统性偏差。

这个假设一旦不成立，整个“能力到效率切换”的框架就会崩塌。具体来说，它包含两个子假设。第一，效率模型能够正确理解并信任能力模型留下的工作区状态和 log 历史，而不会被前任的推理风格、代码习惯或未言明的假设带偏。论文在 Section 1 里自己提到了这个风险：“exposing the receiving model to its predecessor's reasoning and actions may bias its subsequent decisions, potentially carrying forward unproductive assumptions or strategies”。第二，切换点之后的任务确实已经收窄到效率模型能处理的局部工作，而这个“收窄”是可从轨迹中检测的。

论文给出的证据是间接的。案例研究（Figure 4）展示了三个成功切换的例子，说明在某些任务上这个假设成立。但论文没有系统量化“切换失败中有多少是因为继承偏差，有多少是因为切换太早”。标注协议里有一条值得注意：“If later work introduces a regression or substantially rewrites the implementation, the earlier point is retained and the instability is noted”，这说明论文自己观察到了切换后可能发生回归，但没有进一步分析这种回归的频率和影响。此外，AgentBaton 在部分设置下准确率明显下降（如 GPT-5.6 Sol 到 Qwen 在 DeepSWE 上相对损失 11.6%），这些下降有多少来自继承偏差、有多少来自效率模型本身能力不足，论文没有拆解。

10. 一周最小复现

只有一张 24GB 消费级显卡和一周时间，最核心的结论是“能力到效率的一次性切换能在保持准确率的同时大幅降成本”。复现步骤如下。

第 1 天到第 2 天：搭环境和跑单模型基线。 安装 mini-SWE-agent v2.4.0，准备 Terminal-Bench 2.1 的一个小子集（比如 50 个任务，优先选软件工程类）。用 GPT-5.6 Sol（或任何可用的强云端模型）单独跑这 50 个任务，记录准确率和 API 成本。再用 Qwen 3.8 27B 本地跑同样的 50 个任务，记录准确率。24GB 显卡跑 27B 模型需要 4-bit 量化，推理速度会慢，但 50 个任务在一周内可完成。

第 3 天到第 4 天：实现固定进度切换。 不需要训练 AgentBaton，先复现论文 Table 4 里的 fixed-progress baseline。对每个任务，让能力模型跑到其单独执行轨迹的 30% 和 75% 两个 checkpoint，然后切换到 Qwen 3.8 27B 继续。上下文转移用 logfile transfer，因为实现最简单：把历史写成 .jsonl 文件，让 Qwen 用 cat 和 grep 查看。记录准确率和成本。预期结果：在 30% 到 75% 之间的某个 checkpoint，准确率接近能力模型单独跑，成本大幅下降。这个结果本身就验证了论文的核心主张，不需要训练检测器。

第 5 天到第 6 天：实现一个简单的在线切换规则。 如果时间允许，用一个基于规则的检测器替代固定进度：当轨迹中同时出现“有实现文件被创建或修改”和“有测试或执行命令被运行且产生了输出”时触发切换。这个规则是论文三个 readiness 条件的简化版。对比规则切换和固定进度切换的准确率和成本。

第 7 天：分析。 统计切换点前后的任务状态，验证“切换后剩余工作是否确实收窄到局部修复”。预期指标：在 Terminal-Bench 2.1 的 50 个任务子集上，能力到效率切换的成本降幅应该在 40% 到 80% 之间，准确率损失在 5 到 15 个百分点之间，具体取决于 checkpoint 选择。

这个复现方案跳过了 AgentBaton 的训练（需要 4000 条标注轨迹和 16 张 H100），但抓住了论文最核心的实证发现：切换方向的不对称性和切换时机的重要性。

11. 反例设计

设计一个实验，若成功即可推翻本文核心主张“能力到效率的一次性切换能在保持准确率的同时大幅降成本”。

实验设计：选一组任务，其特点是“后半段需要的能力不低于前半段”。具体构造方式：从 DeepSWE v1.1 中筛选出那些在能力模型单独执行时，最后 30% 的回合里仍然发生了重大架构变更或核心算法替换的任务。判据是：在能力模型轨迹的最后 30% 回合中，是否出现了对核心实现文件的大规模重写（比如单轮 diff 超过 200 行，或者重写了任务的核心函数）。

操作：对这些任务，用 AgentBaton（或固定进度切换）在 30%、45%、60%、75% 四个 checkpoint 切换到 Qwen 3.8 27B，记录准确率和成本。

判据：如果在这类“后半段仍然需要高强度能力”的任务上，能力到效率切换的准确率显著低于能力模型单独跑，且这个差距无法通过调整切换点来弥补，那么论文的核心主张就被削弱。更强的判据是：如果在这类任务上，效率到能力切换（即后半段才引入能力模型）的准确率反而高于能力到效率切换，那就直接推翻了“能力到效率方向普遍更优”的结论。

为什么这个实验有杀伤力：论文的三个 readiness 条件隐含假设“任务的前半段是开放性的，后半段是局部性的”。但这个假设是经验性的，不是所有长程任务都满足。如果存在一类任务，其困难集中在后半段（比如先做简单脚手架、后做复杂算法设计），那么能力模型前半段建立的进展对效率模型没有帮助，效率模型在后半段会失败。论文在 Terminal-Bench 上的结果已经显示出这种不一致性：Figure 6 中能力到效率切换的准确率曲线在不同模型和 checkpoint 之间波动很大，不像 DeepSWE 上那样稳定。这说明任务类型确实会影响切换的有效性，而论文没有按任务类型做分层分析。

12. 落地判断

能否用于“抢占式 GPU 自托管 27B 模型做多智能体脚手架”：能，而且这个场景和论文的设置高度吻合。论文里的 Qwen 3.8 27B 就是本地部署、成本计为零的模型，正好对应自托管 27B 模型。抢占式 GPU 的间歇性可用性也适合这种“能力模型先跑、效率模型收尾”的模式，因为效率模型的任务是局部修复和验证，对连续可用性的要求低于从头跑一个完整任务。

怎么用：把 AgentBaton 部署为一个轻量检测器，在能力模型每轮执行后判断是否切换到本地 27B 模型。能力模型用云端 API（如 GPT-5.6 Sol 或 Kimi K3），本地 27B 模型用 vLLM 或 llama.cpp 部署在抢占式 GPU 上。上下文转移建议用 logfile transfer，因为自托管模型可以自由控制文件系统，而且 logfile 避免了把长历史塞进上下文导致的 prefill 成本。如果本地模型是 Qwen 系列且源模型暴露 CoT，可以考虑 in-context transfer。

成本量级：以 DeepSWE 为例，GPT-5.6 Sol 单独跑平均 5.32 美元每任务，切换到本地 Qwen 3.8 27B 后降到 1.02 美元，降幅 80.8%。如果一天跑 100 个任务，日成本从 532 美元降到 102 美元，节省 430 美元。本地 GPU 的成本另计：一张 24GB 消费级显卡的云租用价格大约 0.3 到 0.5 美元每小时，如果 100 个任务的后半段总共需要 10 小时 GPU 时间，本地成本约 3 到 5 美元，相比节省的 430 美元可以忽略。但要注意，论文把本地模型成本计为零，实际部署中 GPU 租用费、电费和运维成本应该计入，只是在这个量级下仍然远低于云端能力模型的 API 费用。

最大的坑：抢占式 GPU 的抢占风险。如果本地 27B 模型在收尾阶段被抢占，任务会中断，而论文的框架是一次性切换、不回头，没有定义“效率模型失败后怎么办”。在自托管场景中，你需要额外实现一个恢复机制：要么在 GPU 恢复后从 checkpoint 继续，要么在效率模型失败时回退到能力模型。论文没有覆盖这个失败模式，因为它的实验假设本地模型始终可用。另一个坑是上下文转移格式的兼容性：如果能力模型是 GPT 系列，它的工具调用格式和 Qwen 不同，转换过程中可能丢失信息，论文提到“当源模型不暴露 CoT 时，省略 reasoning_content 字段”，这个省略在复杂任务上可能导致效率模型对前任意图的理解不完整。