看到Switchcraft的论文摘要，第一反应是“终于有人开始认真考虑工具调用的路由优化了”。作为在MCP（Model Context Protocol）生态里折腾过一段时间的人，我深知现有路由方案在工具调用场景下的割裂感——传统路由选择器大多基于对话历史或语义相似度做分类，但工具调用往往涉及结构化参数、多步依赖和状态副作用，简单复用对话路由的代价就是要么全用大模型烧钱，要么用小模型频频翻车。
Switchcraft的核心思路是“内联路由”，即在推理过程中动态判断何时切换模型。这种做法的技术难点在于如何在不显著增加延迟的前提下，实时评估任务复杂度与模型能力的匹配度。论文没有公布具体延迟对比数据，但我个人经验里，工具调用场景的延迟敏感度往往比对话更高（比如用户等一个API返回时），如果路由本身引入了额外开销，可能就是取舍了。
我比较好奇的是：Switchcraft的“正确性”指标如何定义？工具调用失败可能源于格式错误、参数缺失、逻辑歧义，甚至外部服务异常。如果路由只关注模型输出格式匹配而忽略下游状态一致性，那实际收益可能会打折扣。另外，对于混合调用（如一次请求中同时需要工具操作和自然语言回复）的场景，Switchcraft是否还能保持优势？
从行业角度看，这篇工作指向了一个更本质的趋势：模型路由正在从“粗粒度模型选择”走向“细粒度任务感知”。如果Switchcraft能开源并提供一套基准测试集，或许能推动MCP规范中路由层的标准化。不过目前看，它更适合对成本敏感、且任务边界清晰的内部系统，不太能直接套用于需要多模型混编的复杂Agent框架。