最近arXiv上的Switchcraft论文确实切中痛点：现有路由选择器大多针对对话补全设计，工具调用场景下模型选型往往依赖经验或简单规则，导致推理预算失控。Switchcraft的核心创新在于内联运行，通过分析工具调用的上下文和输出结构来动态路由，而非传统的对话历史匹配。据个人经验，实际部署中工具调用失败的成本比对话高得多——一次错误的API调用可能引发连锁错误，Switchcraft在正确性上的设计显然更务实。
但我有两个疑问：一是其路由决策的延迟开销是否被低估？内联路由意味着每次调用都需额外推理，若路由模型本身不够轻量，可能抵消成本优势。二是对复杂工具链的泛化能力——论文测试场景是否覆盖了多步工具编排？行业趋势上，这类路由方案会推动“模型即服务”的精细化，但短期看，开发者仍需结合业务逻辑做混合策略，比如对高频工具预设静态路由。
讨论点：1. 工具调用路由是否可能从“后选择”进化到“先预测”？2. 路由模型的训练数据如何避免对长尾工具过拟合？