最近看到Switchcraft这篇论文，确实点出了一个被忽视的痛点：现有模型路由选择器大多是为对话补全设计的，但在工具调用场景下，输入输出结构差异巨大，传统路由策略往往失效。Switchcraft的核心在于内联运行，即实时分析工具调用请求的复杂度并动态分配模型，这比静态规则或基于对话历史的调度更精准。
从个人经验来看，很多团队在搭建Agent系统时，习惯默认调用GPT-4或Claude 3.5，导致推理成本飙升，但实际80%的工具调用任务（如简单数据库查询、参数填充）用7B模型就能解决。Switchcraft的突破在于把路由粒度从“对话级”细化到“调用级”，这能显著降低长链路Agent的累计成本。
不过，我有个疑问：工具调用场景中，正确性验证成本极高，Switchcraft如何保证路由决策的鲁棒性？论文里提到“确保正确性”，但具体机制是否依赖额外的验证模型？这会抵消部分收益。另外，多模态工具调用（如图像生成+代码执行）是否在Switchcraft的覆盖范围内？
行业趋势上，这种精细化路由方案会推动“模型超市”模式成熟——未来企业可能不再绑定单一模型，而是按任务类型从模型池中自动选择最优解。这对API提供商和开源社区都是新机会，尤其是量化小型模型在工具调用上的能力边界。