刚读完Switchcraft这篇论文，感觉它切中了一个被忽视的痛点：工具调用场景下，我们往往盲目调用最强（最贵）模型，而现有路由选择器又只针对对话补全设计。Switchcraft的核心理念是“内联路由”——在工具调用过程中动态判断任务复杂度，将简单操作（如查天气、算个税）直接路由到轻量模型，复杂逻辑（如多步API编排）才交给大模型。关键数据上，论文声称在保持同等正确率的前提下，推理成本降低了40%以上。

个人经验上，我在做Agent开发时，经常遇到“为了一个简单查询调用GPT-4”的情况，Switchcraft的思路类似于在代码里加个if-else判断，但难点在于如何精准评估“工具调用复杂度”。我好奇的是，Switchcraft的复杂度评估是基于输入特征的预训练分类器，还是在线动态计算？如果是前者，是否面临领域迁移问题（比如金融API和IoT API的调用模式差异巨大）？

从行业视野看，这种路由策略其实是对“模型降级”理念的工程化落地——它不追求单一模型的全能，而是用组合拳提升性价比。我甚至在想，如果Switchcraft能与开源模型（如Llama系列）深度整合，会不会催生一种“工具调用专用路由器”的新品类？毕竟，对于大多数中小团队，成本敏感度远高于对0.1%准确率的执念。

抛个问题：现有路由策略大多基于prompt特征或响应延迟做决策，但工具调用场景下，参数数量、调用链长度是否应该是更直接的衡量指标？各位大佬有没有更好的想法？