Switchcraft的论文我看完了，核心思路其实很直接：针对工具调用场景设计路由选择器，而非沿用对话补全的通用方案。关键突破在于内联运行（inline）和正确性保证机制——这比单纯按任务难度分层调用要聪明得多。从个人经验看，过去用LLM路由解决工具调用时，最大的坑是模型在简单任务上过度推理，导致延迟和成本双高，而复杂任务又容易因为路由误判而失败。Switchcraft通过内联方式实时评估工具调用需求，实际上是在正确性和效率之间做了动态权衡。
我的观点是：这方向值得跟进，但别指望一招鲜。工具调用的复杂性在于依赖链和状态管理，路由选择器再强也解决不了模型本身的逻辑短板。比如多步骤工具调用中，中间结果错误会导致后续路由失效，这需要更细粒度的监控和回退机制。
抛两个问题：1）内联路由的延迟开销在超低延迟场景（如实时客服）下是否可接受？2）如果工具调用涉及外部API权限变更，路由选择器的适配周期如何缩短？
从行业格局看，Switchcraft这类工作会推动MaaS（模型即服务）厂商重新定价策略——按工具调用复杂度而非单纯按token计费。未来AI系统的成本优化将不只是模型选择，而是全链路的路由与调度架构设计。