看到 Manifest 那条博客时，我第一反应不是"又一个工具凉了"，是"终于有人敢拿生产数据承认这件事了"。3 月上线，6 月弃用，9 月关停，中间是 7000 个用户帮你踩了四个月的坑。这路由器死得一点都不冤——不是参数没调好，不是时机不对，是"路由"这个概念本身在 LLM 场景里就立不住。
原因不用往深里找：它要在入口做一个判断，可这个判断需要的信息，在入口处根本不存在。任务复杂度不在 prompt 里。Manifest 自己把这句话写出来了："提示词本身无法体现任务的全部复杂度，许多关键上下文是在工具调用或网络搜索等后续环节中才出现的。"翻译成白话就是：它只看第一幕的台词，就要预测整部戏的结局。
一个真实的对话过程，你只有跑起来才知道它有多复杂。用户随口问一句，模型觉得要查数据库，调一次工具，拿回结果发现不够，再调一次，来回三轮才把答案攒出来。复杂度是由中间这些跳转决定的：多少次工具调用、中途要不要改方向、数据长什么样。所有这些信息，在入口的时候一个都不存在。路由器手里只有那个最初的 prompt——一层壳。拿壳定级，就是拿封面猜书的内容。
所以那个四档设计从根上就是假的。简单、标准、复杂、推理，四个静态格子。可复杂度是过程的属性，不是输入的属性。同一个 prompt，今天缓存是热的，一次调用完事；明天缓存清了撞上数据迁移，五轮都跑不回来。同一个输入，复杂度不是一个值。拿一个静态分类器去锚一个动态展开的过程，锚不住。
这个边界连人都定不了。你拿同一个 prompt 给十个工程师打复杂度分，能打出八种意见。你凭什么相信一个塞在网关里的分类器比人更懂？
就算它判断准了又怎样？它想省的那点钱，有一个根本不用预测的省法——KV cache 复用，这是我在上一篇文章里就想说的点。系统提示和对话历史本来就是整段重复的 token，命中一次读取成本比未缓存输入低 75% 到 90%，而且没有猜错的可能。一个靠猜，一个靠存。在工程里，只要复用办得到，就永远比预测便宜，因为预测要付错误成本。
但我不打算停在这。路由器这件事最让我不舒服的，不是技术上的错位，是它背后那种冲动：有人不想做判断了。
选择用一个路由器，等于你默认了"该用哪个模型"可以被抽象成一个通用服务，塞进网关里，一劳永逸。可模型选择恰恰是工程里最不该被抽象掉的那一环——它跟你的任务、你的数据、你的上下文缠在一起，它泛化不了。你要亲手碰过才知道，而不是交给一个分类器。
Manifest 博客里那句"工程师应该像工匠了解工具一样理解模型间的权衡与细微差别"，我读了两遍，倒回去确认没看错。这话从一家刚把路由器拆掉的公司嘴里出来，分量是加倍的——等于承认这个方向从根上就是错的。
这个剧本我们不陌生。想让 AI 拍板架构，想让 AI 代替代码审查，现在连"用哪个模型"都想让路由器替你想。每回的理由都一样：更快、更省。那省下来的时间，拿去干嘛了？追下一个新工具吗？
这话我说得有点重。但道理没变：判断力是唯一不能外包的东西，因为它靠错误喂大。你选错过模型，才知道为什么这个任务不适合它；你调过路由参数，才知道复杂度根本不看 prompt 的脸色。这些坑不用全踩——但至少你要理解机制，而不是躲在一个黑盒后面假装问题不存在。
我的态度很明确：LLM 路由器这个方向，不是做得不够好，是从一开始就歪了。先把系统提示和对话历史的结构吃透，把 KV cache 这个最扎实的降本手段做扎实——它不需要预测任何东西，它只需要记住读过的内容——再来谈动态选择。顺序反了，就是给烂地基刷漆，刷得再亮，住进去还是要塌。
路由器的故事结束了。但"把判断交给一个更便宜的东西"这种冲动不会。下一次再看到某个组件号称能替你做决定，多问一句：做这个决定需要的信息，此时此刻到齐了吗？没到齐，它就只是个赌徒——赌的还是你的钱。
