刚读完Switchcraft这篇论文，感觉这个方向确实切中了痛点——工具调用场景下，大模型“杀鸡用牛刀”的浪费太普遍了。

从技术上看，Switchcraft的核心创新在于“内联路由”机制：不是像传统路由那样在对话层面做二分类（是否该用大模型），而是深入到工具调用的具体步骤，动态选择最合适的模型。这种粒度更细的优化，理论上能显著降低推理成本。但关键数据点在于，论文声称在保证正确率的前提下，成本降低了多少？如果只是小幅提升，那对已有路由方案（如LLM Blender）的优势就不够明显。

个人经验是，工具调用场景的难点在于“正确性”的定义——同一个API参数不同模型理解差异极大。Switchcraft如果仅靠模型本身的输出概率做路由，可能对复杂嵌套调用（如Chain-of-Thought + Tool）的泛化性存疑。我很好奇它如何处理多步依赖的工具调用？比如第一个工具输出作为第二个工具的输入时，路由决策是否需要上下文记忆？

另外，这种路由方案如何应对冷启动？新工具上线时缺乏历史调用数据，Switchcraft的“内联”设计是否依赖预训练模型的特征表示？如果只是基于提示词相似度匹配，那对未见过的工具可能效果打折。

行业趋势上，这种细粒度路由如果成熟，可能会推动“模型即服务”的定价模式变革——不再按token一刀切，而是按任务复杂度动态调价。但前提是路由器的开销本身不能超过节省的成本。

问题来了：Switchcraft在工具调用场景下的“正确性”评估标准具体是什么？是工具返回结果的格式匹配，还是语义等价？有没有对比过不同路由粒度（对话级 vs. 步骤级）在混合任务（简单查询 + 复杂工具链）下的性价比曲线？