有没有人真正有效地解决了每提示词模型路由问题，还是我们都在靠直觉判断？

我每天都在处理实际工作中的智能体。内容生产线、代码，都是常规操作。但有一件事我始终无法干净利落地处理：决定哪个模型处理哪个请求。标准建议是“保持纪律，用便宜模型处理简单任务，把大模型留给困难任务。”理论上没问题。但我在实际选择模型时完全凭直觉，而我还算是个高级用户。如果连我都无法可靠地路由，那么这条建议其实是在悄悄假设困难部分已经解决了。但事实并非如此。仔细一想，问题更复杂。单位甚至不是任务到模型。一个任务包含廉价回合和昂贵回合。一个编码智能体大部分时间都在读取文件、运行命令、总结错误。这些无聊的工作像Qwen这样的小型本地模型就能处理得很好。但有一次确实需要推理一个棘手的bug，而那次就是需要昂贵模型的回合。所以真正的粒度是提示词到模型，按回合评估。目前没人能在那个级别进行路由。你只能为整个运行选一个模型，要么在简单回合上多花钱，要么在困难回合上表现不佳。显而易见的解决方案是分流层。一个小模型读取每个提示词，评估难度，转发给能够胜任的最便宜模型。概念上很清晰。我一直在等有人能完美实现它。然而，我始终无法绕过一个问题。分流模型本身对每个提示词都是一次付费调用。为了正确路由，它必须足够好以理解请求，这意味着它既不免费也不即时。那么，你到底是转移了成本，还是在它前面加了一个收费站？也许一个微型分类器足够便宜，节省下来的费用远超其成本。也许路由决策实际上比看起来更困难，便宜的分类器会把困难提示词发给便宜模型，导致质量下降。我不知道哪种计算成立，也没看到有人展示过他们的工作流程。我真诚地怀疑这一层尚未真正存在的原因，是固定费率计划消除了压力。当你是无限量套餐时，没人会感受到每提示词的价格，所以没人去构建优化它的东西。一旦这些计划改为按量计费，路由就会从可有可无变成核心产品。所以我问那些真正构建这些东西的人。有没有人在生产环境中按提示词路由，并且做对了？你的分流层成本是多少？计入它自身的调用后，它能赚回本吗？还是说每提示词自动路由是一个“差即是好”的陷阱，我们还不如选一个模型然后接受它？