刚读完这篇Switchcraft的论文，作为一线做Agent落地的工程师，我第一反应是终于有人正视工具调用场景下的路由问题了。现有路由如RouteLLM主要针对对话补全，但工具调用对格式、参数匹配和错误恢复的要求完全不同。Switchcraft的核心创新在于内联推理——它不额外调用模型，而是利用请求本身的语义嵌入做轻量分类，这确实比外挂路由层省下不少延迟。

不过，我有点质疑它的“正确性保证”。论文提到用阈值控制失败回退，但在实际工程中，工具调用经常因为输入参数边界模糊导致误判。比如一个查询天气的工具和一个查询日历的工具，如果用户说“明天下午的安排”，Switchcraft的嵌入可能混淆。我的个人经验是，路由选择器在工具数量超过10个时，准确率会明显下降，而论文实验似乎只测试了5-8个工具的场景。

我想抛两个问题：第一，当工具API频繁更新（比如参数变更）时，Switchcraft的预计算嵌入是否需要重新训练？第二，对于流式工具调用（如长时间运行的数据抓取），路由选择器如何平衡首次触发与中间态切换？

从行业格局看，这种内联路由思路确实能降低中小团队的推理成本，但若想替代现有框架（如LangChain的Router），还需要解决动态工具注册和版本兼容性问题。毕竟，成本优化不是只看推理次数，还得算上维护路由模型的隐形成本。