小模型能干的活比多数人以为的多，但也就四类：分类、抽取、格式化、路由。这四类吃掉了 agent 日常流量里的大头，延迟差距大到不用做 A/B 就能感觉出来。剩下的——多步推理、需要世界知识的判断、长上下文整合——小模型接不住，硬接就是埋雷。所以真问题不是「小模型行不行」，是「值不值得为省下的延迟，多养一套 prompt 和一套评测」。
能接的四类活，共同点是答案空间小
分类、抽取、格式化、路由，它们的共同点不是任务简单，是输出空间可枚举。
抽取看着自由，其实你要的是 schema 里的那几个字段：订单号、金额、诉求类型。Schema 定死了，模型再小也飘不到哪去，因为错的余地本来就没多少。格式化更极端——把一段自由文本塞进固定 JSON，这是模板活，不是推理活。
路由值得单独说。生产环境里做客服 agent 的，第一步几乎都是意图识别，这一层没什么人用大模型。Screen Before You Serve 那篇讲 140M 量级的 CX 场景时，把「检测意图、遵守运营政策、可靠调工具」并列成三件事，前两件都不需要大模型的脑子，需要的是稳定和快。
先别信网上流传的那些比例。自己拿一周的真实请求跑一遍：同一批输入分别打给小模型和大模型，看 P95 和准确率。我见过的大多数业务里，差距不是百分之几十的事，是一眼能看出来的事。
接不了的三类，硬上会错得看不出来
多步推理。跨三个文档对账、算一笔带条件的折扣，这类要的不是知识，是链条不能断。小模型经常在第二步就悄悄拐弯，最后给你一个格式漂亮、逻辑崩掉的答案。
需要世界知识的判断。这条退款该不该批——政策在一份文档里，先例在历史工单里，模型得同时握住两边再权衡。小模型不是答得差一点，是答得很有底气。
长上下文整合。把一周的会议记录压成一个决策，得记住谁在第几次会上反对过什么。这类活对上下文的要求是结构性的，不是换个 prompt 能补的。
这三类的共同麻烦是：错得不明显。分类错了你能对标签，推理错了你得重新推一遍才知道哪步崩的。
拆法：小模型当路由器，大模型当执行器
Jev-Mobile 的做法就是这个思路——VLM 低频做规划，高频动作交给轻量执行器。别让同一个模型既想又做，那是把钱和延迟一起烧掉。
我更认同 Requirement-Bound Verified Commissioning 的措辞：冻结的四千亿参数以下那类本地小模型，只当「候选生成器」，放行权在外部验收层。这个结构比「小模型做决策」健康得多——小模型提三个可能，规则或者大模型挑一个。出错的时候你知道错在哪一层。
HEXIS 走得更远，直接把技能编译成扩展有限状态机，控制流根本不经过模型。不是所有东西都该让模型决定下一步。
落地时有两条我踩过的坑。第一，router 输出枚举，不要自由文本；枚举值越少越好，多一个分支就多一份评测负担。第二，别让 router 解释为什么选这个分支——解释就是推理，推理就该交给大模型。
反面：拆完就是两套东西要养
两套 prompt、两套评测、两套失败模式。最难受的是 router 的错误是静默的：请求被送进错误分支，日志里一切正常，用户看到的是答非所问。这种 bug 比大模型答错难查得多，因为没人会先怀疑路由。
三人以下的团队，我的建议是别拆。人少的时候你的时间该花在把一条路径做对，不是把两条路径都做到及格。路由的价值随请求量增长，随团队规模增长，不随架构优雅程度增长。
什么时候拆？按我现在看，两个条件得同时满足。一是历史流量里少数几个类别确实吃掉了大部分请求——拿离线数据标一遍就知道，别猜。二是有人能固定盯路由的评测集，每周看混淆矩阵。少一个都别动。
我的判断，和可能被打脸的地方
这周素材挺配合这个命题：Jev-Mobile、冻结小模型做候选生成、HEXIS，三篇在说同一件事——把「想」和「做」分开。但也别读成小模型要取代大模型。它取代的是大模型里那些本来就不需要推理的调用，AX 这类编排层再花哨，也改变不了这个分工。
不确定的地方在这：如果小模型的指令遵循再强一代，路由和抽取的边界会往外扩，说不定「需要世界知识的判断」也能挪一部分过去。多步推理那类，按我现在看还是别碰。也许半年后回头，这句会被打脸。