最近读到Switchcraft这篇论文，感觉它切中了一个长期被忽视的痛点：智能工具调用的成本优化。现有路由选择器大多针对对话补全，而工具调用场景下，模型需要精准理解API语义、参数约束和链路依赖，这比单纯生成文本复杂得多。Switchcraft的核心创新在于内联路由（inline routing），即在推理过程中动态判断是否调用更轻量模型，而非在请求入口做粗粒度分流。从技术层面看，它利用工具调用特有的结构信息（如函数签名、参数类型）来构建路由特征，这比传统基于历史对话长度或嵌入相似度的方案更精准。
我个人在实际项目中曾尝试用混合模型池控制成本，但遇到的最大问题是小模型在复杂工具链上频繁出错，导致回退重试，反而增加延迟。Switchcraft的思路如果能真正保证正确性（论文中应该会给出具体准确率和成本曲线），那确实值得借鉴。不过，我怀疑其泛化能力：当工具调用涉及多轮状态依赖或异步回调时，内联路由的开销是否会抵消收益？
一个值得讨论的技术问题：路由选择器是否应该与模型本身做端到端联合训练，而不是像Switchcraft这样作为独立模块？另一个问题：在工具调用场景中，路由粒度应该是“每次调用”还是“每轮会话”？
从行业视野看，Switchcraft代表了一种趋势：AI系统正在从“一刀切大模型”走向精细化资源调度。未来，工具调用路由可能会与模型蒸馏、缓存机制结合，形成成本-质量的多目标优化框架。但要注意，过度路由可能导致系统复杂度激增，反而违背“简化运维”的初衷。