小模型和开源，正在成为 AI 落地的两条主线

从两条新闻说起

今天有两条不算"爆炸性"、但方向高度一致的新闻。

一条是 Meta 发布了 Muse Ember，官方口径是"迄今最小的模型"，主打 agent 场景里的重复性任务。另一条是美团开源了 LongCat-2.5，用的是 MIT 协议，明确允许商用。

把这两件事放在一起看，指向的是同一个变化：AI 落地正在从"参数竞赛"转向"够用就好"。

小模型为什么开始吃香

过去一年，评价模型常用"跑分"。但真到了工程里，标准会换一套：延迟能不能压到几百毫秒、单次调用贵不贵、一台机器能不能并发几十路。

一个 agent 如果一天要跑几千次"读文件、改字段、拼参数"这类重复动作，全程调用最大的模型其实很浪费。Muse Ember 把定位放在"agent 的重复任务"上，等于承认了一件常识：日常绝大多数调用，并不需要最强的推理能力。

协议比模型本身更有分量

LongCat-2.5 选择 MIT 而不是"仅限研究""商用需授权"这类自定义协议，这个决定的分量可能比模型本身更重。

对企业来说，能不能商用、能不能改、能不能私有化部署，直接决定它能不能进生产环境。MIT 意味着法务成本接近零，试错门槛一下就降下来了。反过来，一个跑分再高的模型，如果协议里塞满限制条款，多数团队也只能看不能上。

一个现实的架构选择

两条线合起来，其实就是很实用的一套组合：用开源的中小模型承接高频、低价值的调用，把大模型留给真正需要推理的关键路径。成本控住了，效果也保住了。

我最近做小工具时体会更深。真正卡住进度的往往不是"模型不够聪明"，而是调用太慢、太贵、部署链路太长。把模型降到合适的一档、把协议换成宽松的，整体体验反而明显变好。

当然，小模型不是万能的。需要多步推理、长上下文理解的任务，还是得交给大模型。选型的依据应该是任务本身需要多少智能，而不是排行榜上的名次。先想清楚这一步要什么，再决定用哪个模型，通常比追着新模型跑更划算。

出处：橘鸦AI早报（2026 年 11 月 10 日刊）

参考原文：Meta 官方博客关于 Muse Ember 的发布帖、美团开源 LongCat-2.5 的官方公告