💡 一句话总结：DualTune 把「工具调用」这件事拆成「选工具」和「填参数」两个子任务，各训一个专门的 LoRA、推理时分阶段切换。一个简单的解耦，就让端侧小模型的工具调用准确率从不可用拉到了可用区间，而且和 4-bit 量化兼容。
一、问题：端侧 agent 卡在工具调用这道坎上
把 agent 跑在本地，是 2026 年最热的工程方向之一——隐私不出端、零 API 成本、低延迟。但凡真动手做过的人都会撞到同一堵墙：本地小模型的工具调用太不靠谱。
DualTune 这篇论文把这堵墙拆开看，发现失败集中在两个地方：
-
工具选择错误：agent 挂着一长串工具（几十甚至上百个），小模型从工具描述列表里选不准。相似的工具尤其容易混——
search_web和search_docs、get_user和get_user_profile，小模型经常选错那个。 -
参数生成错误：就算选对了工具，按它的 schema 填参数又是另一道坎。复杂的嵌套结构、严格的类型约束、必填字段缺失、JSON 格式非法——这些都是小模型的高发错误。
前沿大模型（GPT、Claude 这个级别）靠模型规模硬把这两件事一起做好了，但端侧根本跑不起那么大的模型。于是端侧 agent 陷入两难：用小模型，工具调用不可用；用大模型，端侧跑不动。
二、洞察：工具调用是两个不同的任务
DualTune 的核心洞察很简洁：工具调用不是一个任务，是两个。
- 工具选择本质是个分类问题：给定用户意图和工具列表，选出最合适的那一个。它考验的是判别和匹配能力。
- 参数生成本质是个结构化生成问题：给定选中的工具及其 schema，生成符合约束的参数。它考验的是格式遵循和细节填充能力。
这两种能力的「脑回路」不一样。把它们塞进同一个模型、用同一套权重一起学，训练时两个子任务的梯度会互相干扰——优化选工具的能力可能损害填参数的能力，反之亦然。结果是两个子任务都学得半吊子。
这就是为什么单纯对小模型做整体微调，提升有限。相关数据点也印证了这一点：传统微调能把工具调用准确率从十几个百分点提到三十几个百分点，有改善但远不够用——天花板就卡在「一个模型同时学两件事」上。
三、方法：解耦微调（Decoupled Fine-Tuning）
DualTune 的解法顺理成章——既然是两个任务，就分开训、分开用。
训练阶段，把工具调用数据拆成两路：
- 一路训练工具选择 LoRA：输入是用户 query + 候选工具列表，输出是选中的工具名。这是个偏分类的目标。
- 一路训练参数生成 LoRA：输入是用户 query + 选中工具的 schema，输出是符合 schema 的参数 JSON。这是个结构化生成的目标。
两个 LoRA 共享同一个冻结的基座模型，各自只在自己的子任务上优化，互不干扰。
推理阶段，串成一个两阶段管线：
用户请求
│
▼
[阶段一] 加载「工具选择 LoRA」
→ 从工具列表中选出目标工具
│
▼
[阶段二] 加载「参数生成 LoRA」
→ 针对选中工具的 schema 生成参数
│
▼
执行工具调用关键在于：基座模型只加载一份，两个 LoRA 按阶段热插拔。LoRA adapter 本身很轻（几 MB 到几十 MB），切换开销远小于重载整个模型。
💡 提示：这套结构天然适配 vLLM 的 multi-LoRA 能力——基座常驻显存，多个 adapter 动态挂载。工程上不需要起两个模型实例。
四、为什么解耦有效：各司其职
解耦带来的提升来自三个层面：
第一，消除子任务间的梯度干扰。每个 LoRA 只优化一个目标，不再被另一个任务的梯度拉扯，于是各自都能学到更优的解。
第二，缩小每个子任务的输入复杂度。工具选择阶段不用操心参数格式，参数生成阶段不用从一长串工具里挑——每个阶段面对的问题都更聚焦，小模型更容易学好。
第三，与量化正交。论文强调一个对端侧极其重要的点：LoRA 的低秩适配在 4-bit 量化的基座上依然有效。量化压缩基座权重、LoRA 在低秩空间补回任务能力，两者不冲突。这意味着你可以把基座量化到能塞进边缘设备的体积，再叠两个轻量 LoRA，得到一个「小 + 会用工具」的 agent。
按论文给出的消融，从「不微调」到「传统微调」再到「解耦微调」，准确率是台阶式上升的——解耦微调相比传统整体微调有明显的额外增益，这部分增益正是「分开学」省下来的、原本被任务干扰浪费掉的能力。
五、工程意义：端侧 agent 的一条务实路径
抛开论文,DualTune 给端侧 agent 落地提供了一套可直接抄的方法论：
- 不必追大模型。与其把希望寄托在「下一代小模型会更强」，不如用解耦的方式把现有小模型的工具调用能力榨出来。
- 数据构造是关键。复刻这套方法的难点不在训练，而在数据。工具选择那份数据要覆盖足够多的工具组合，参数生成那份要覆盖足够多的 schema 变体——否则泛化不到训练时没见过的新工具。
- 两阶段是可接受的代价。多一次前向推理换来的是「调用成功率」。在端侧，一次失败的工具调用意味着重试，反而更慢更耗电；宁可两阶段稳一点。
六、局限与思考
DualTune 不是银弹，几个值得留意的点：
- 新工具泛化：参数生成 LoRA 见过的 schema 越多越好，但面对结构完全陌生的工具，仍可能填错。这是所有微调方法的共同软肋。
- 多工具编排：论文聚焦单次工具调用的「选 + 填」，对「一个任务需要串联调用多个工具」的复杂编排场景，解耦思路要怎么扩展，还需要更多工作。
- 两阶段延迟：对延迟极度敏感的场景，两次前向可能成为瓶颈，需要权衡。
但瑕不掩瑜。DualTune 最大的价值是给了一个清晰且可复制的认知：当一个任务用单模型学不好时，先问问它是不是其实是两个任务。这个「解耦」的思路，远不止能用在工具调用上。