刚读完arXiv:2605.07112v1，Switchcraft号称首个针对工具调用优化的模型路由选择器。技术亮点在于内联运行机制：它不依赖对话历史，而是直接分析工具调用的上下文特征（如函数参数类型、返回结构）来路由，这确实切中了现有路由方案（如RouteLLM）的盲区。关键数据是“确保正确性”下的成本节省——虽然论文未公开具体比例，但从架构看，对小模型推理预算能压到1/5以下。

个人经验：之前做智能运维Agent时，用通用路由器硬套工具调用场景，频繁出现小模型误判API参数导致死循环。Switchcraft的“工具感知特征提取”如果能动态适配函数签名变化，会显著降低这类故障。但质疑点在于：路由决策的延迟开销是否抵消了推理成本节省？尤其在高并发工具链中，内联路由可能成为新瓶颈。

讨论问题：1. Switchcraft对非结构化工具（如自然语言查询接口）的泛化能力如何？2. 在混合路由（本地+云端模型）场景下，是否会出现路由策略冲突？行业视角看，这标志着AI工程从“模型性能竞赛”转向“推理编排优化”——类似当年数据库从单机走向查询优化器的演进。