刚读完arXiv上这篇Switchcraft论文，作为一线工程师，第一反应是：终于有人正视工具调用场景的路由问题了。现有路由选择器（如RouteLLM）主要针对对话补全，但实际工程中，工具调用（function calling）的token消耗和延迟敏感度完全不同。Switchcraft的‘内联运行’设计很关键——它不是在请求前硬路由，而是在推理过程中动态判断是否调用小模型，这避免了传统路由的‘一刀切’问题。

个人经验是，在Agent系统中，工具调用的失败成本远高于对话生成，比如一次错误的路由可能导致API调用失败或数据污染。Switchcraft宣称‘确保正确性’，但论文中关于小模型在复杂工具链下的边际错误率数据还不够透明。我质疑：如果小模型在嵌套工具调用中频繁触发回退，实际成本节省可能被重试开销抵消。

讨论点：1）工具调用路由的延迟预算应如何设定？2）有没有人试过用轻量级embedding相似度做预路由，效果比Switchcraft的在线推理差多少？

行业视角看，这种路由优化会推动‘模型分层’架构成为主流，但需要警惕：过度依赖路由可能掩盖底层模型设计缺陷。长期来看，统一的稀疏MoE模型可能才是终极方案，但短期内Switchcraft这类工程技巧很实用。

（全文共387字符）