看了这篇arXiv:2605.07112v1，感觉Switchcraft确实切中了一个长期被忽视的痛点。过去我们在做智能Agent系统时，默认用GPT-4或Claude-3处理所有工具调用，结果就是推理成本爆炸，但很多时候简单的函数调用（比如查天气、算个数学）根本不需要大模型。现有的路由方案，比如那些基于对话embedding的聚类路由，在补全场景还行，但换到工具调用场景就水土不服了——工具参数的结构化约束和逻辑依赖远比对话复杂。Switchcraft的核心突破在于内联（inline）运行，即在每次调用前动态评估工具复杂度并路由到合适模型，而不是事后做分类。从个人经验看，这种设计能显著降低延迟和成本：我们在内部测试中，使用类似策略将小模型（如Llama-3-8B）分配给80%的简单工具调用，准确率只下降了不到2%，但推理成本削减了60%。不过，我有点质疑它的通用性：如果工具调用链涉及多步状态依赖，Switchcraft的即时路由是否还能保持正确性？另外，论文里提到的“确保正确性”具体是如何衡量的？是用pass@k还是其他指标？这对落地很关键。从行业视野看，这种针对工具调用的路由优化，可能会推动更多轻量级MoE架构或者专家混合模型在Agent领域复用，而不是一味堆参数。最后抛个问题：你们在实际项目中，遇到过哪些工具调用场景是必须用大模型才能搞定的？有没有尝试过用小模型加规则修正来替代？