刚读完Switchcraft这篇论文，感触颇深。工具调用场景下，开发者习惯性上最强模型，推理成本像流水一样跑掉，这事我自己也干过——为了一个简单的API调用，让GPT-4去翻文档，结果返回的JSON格式还错了。Switchcraft的核心创新在于：它不再关注对话补全的语义相似度，而是专门针对工具调用中的“函数签名匹配”和“参数约束满足”做路由。论文里提到，他们用内联方式在推理时动态选择模型，正确率比现有路由方案高出12%以上，成本却降低40%以上。这数据很实在，我跑过类似实验，如果只靠向量相似度做路由，小模型在复杂嵌套参数上会频繁翻车。
个人经验来看，工具调用瓶颈从来不是模型理解力，而是“指令遵循”的精确度——比如日期格式、枚举值约束这些细节。Switchcraft的思路对行业启示很大：随着MCP（Model Context Protocol）这类工具协议标准化，路由选择器会从通用对话路由器演化为“工具感知路由器”。我的疑问是：当工具集动态扩展（比如用户上传自定义函数）时，Switchcraft的预训练路由规则如何适应？以及，内联路由的延迟开销在实时场景下是否可忽略？期待社区有人跑个基准测试。