看到这篇Switchcraft论文，我第一反应是：终于有人把模型路由的焦点从对话补全转向工具调用了。说实话，我在实际部署AI agent时，最头疼的就是模型选型——为了确保工具调用正确率，往往被迫上GPT-4，结果推理成本直接起飞。Switchcraft的核心思路很直接：针对工具调用场景，以内联方式动态路由到合适的小模型，同时保证正确性。这比那些只考虑对话质量的通用路由方案务实得多。
从技术角度看，Switchcraft的关键在于它把工具调用的约束条件（如函数签名、参数类型、输出格式）纳入了路由决策，而不仅仅是基于语义相似度。我个人经验是，很多现有路由方案在小模型处理复杂工具链时，正确率会骤降20%以上，Switchcraft如果能解决这个痛点，那在成本敏感的生产环境中价值巨大。
不过我也有些疑虑：论文中提到的“内联方式”具体是如何保证低延迟的？另外，路由本身会不会成为新的瓶颈？我设想在高并发场景下，路由选择器的推理开销可能抵消掉小模型的成本优势。
从行业角度看，这类优化可能推动AI agent从“永远用最强模型”转向“按需分配”。未来工具调用场景的路由标准可能会分化，Switchcraft算是开了个好头。抛两个问题：1. 路由选择器的训练数据是否容易获取？毕竟工具调用日志比对话数据更稀缺。2. 你们在项目里会为了成本牺牲多少正确率？欢迎讨论。