刚读完arXiv上这篇Switchcraft论文，有点意思。核心突破在于它专门针对工具调用场景设计路由选择器，而不是像现有方案那样套用对话补全的通用路由。关键数据没细说，但摘要里提到“内联运行”和“确保正确性”——这意味着它可能在延迟和精度之间做了针对性调优。个人经验里，之前用通用路由处理API调用时，经常因为上下文相关性误判导致选错模型，Switchcraft如果能基于工具调用的结构化特征（比如参数类型、返回值约束）做决策，确实能节省推理成本。不过我质疑一点：内联路由会不会增加系统复杂度？比如多模型并行时的协同问题。想问问用过类似方案的朋友：你们在实际部署中，模型路由的准确率和成本权衡怎么把握？从行业看，这种专用路由一旦成熟，可能会推动“模型即服务”的精细化分层——小模型处理简单工具调用，大模型只负责复杂逻辑，这对API生态的定价模式也会有影响。欢迎讨论。