火狐团队为开发者下场卷 AI 工具链,开源 AI 进入下半场?

当 Llama、Qwen、DeepSeek 把开源模型的可用性拉上来之后，开发者真正头疼的问题变了。

模型不再稀缺，真正让人头疼的是：一堆模型摆在那儿，怎么管、怎么切、怎么控制成本、怎么不被某一家绑死？

火狐背后的 Mozilla.ai 最近推出了 Otari，一个开源的 LLM Control Plane。

它的功能很直接：把多个模型接到同一个入口，统一管理路由、预算、权限和故障切换。开发者不用再为每个应用单独维护 API key、路由逻辑和预算控制。

Mozilla.ai 把它放进已有的「Choice-first Stack」工具矩阵里，背后的判断是：开源 AI 的竞争重心，可能正在从模型本身转向模型之上的工具链。

如果只看名字，Otari 很容易被当成又一个 LLM gateway。但它解决的其实是管理问题，而不是连接问题。

具体能做什么？

• 统一路由：把 OpenAI、Anthropic、Google Gemini、本地 llamafile 等 40 多个 provider 接到同一个入口
• 预算控制：给不同 workspace 或项目设定硬上限，防止某个月账单失控
• 权限治理：谁能调用哪个模型、哪个项目用什么 key，集中管理
• 自动 failover：某个模型挂了，自动切到备用模型
• agent harness：给 agent 应用提供统一的工具和编排能力

这些能力单独看都不新鲜，但打包成一个 Control Plane 之后，对多模型、多团队、多 agent 的场景会更实用。开发者不需要在每个项目里重复写路由、预算、权限这套逻辑。

Mozilla.ai 这次推 Otari，并不是把它当成一个孤立产品，而是放进了一个更大的叙事里：开发者应该有选择权，不应该被某一家模型或平台绑死。

围绕这个思路，Choice-first Stack 里还包括一些已经存在的工具：

Otari 是这次新推出的，其他几个是之前就有的工具。但放在一起看，Mozilla.ai 的意图很明显：在模型层之上搭一层治理和抽象层，让开发者能自由切换、组合，而不是被某一家绑死。

因为模型层正在从稀缺走向过剩。

以前，开源模型和闭源模型之间还有明显差距。现在，7B、13B、70B 的开源模型在越来越多场景里已经够用。

模型变多之后，新的工程痛点自然浮现：

这些问题不是模型本身的问题，而是模型之上的治理问题。

谁能在这一层提供好用、开放、不被单一厂商锁定的方案，谁就有机会成为开发者的新基础设施。

这种趋势也不只是 Mozilla.ai 看到了。2026 年，尤其是最近几个月，几家大厂都在模型层之上加码工具链：

它们的具体产品和 Mozilla.ai 的 Choice-first Stack 不尽相同，但指向同一个判断：模型越来越商品化，真正的竞争正在转向怎么管理、编排、治理这些模型。

对于正在搭多模型应用或 agent 平台的团队，几个新品类正在成型：

这些工具不是为了替代现有模型或框架，而是为了把「用多个模型、多个工具」从手搓胶水代码，变成可维护的工程实践。

Mozilla 在开发者社区有很深的信任积累，这是 Otari 的优势。但评估一个新工具链时，有几个现实因素需要理性看待：

Otari 发布时间很短，文档和生态都不成熟。现在上生产，需要团队有容错能力。

Mozilla.ai 是 Public Benefit Corporation（公共利益公司），未来出现 enterprise tier 或收费功能，完全可能。

代码开源，不代表部署、运维、排障成本低。self-hosted 方案尤其要算清楚工程投入。

any-llm、any-agent 这些抽象层能降低切换成本，但也会增加复杂度。如果项目里只用一两个模型，硬上抽象层反而可能得不偿失。

开源 AI 的上半场，拼的是模型能不能打。

下半场，拼的可能是谁能帮开发者把一堆模型、框架和工具管明白。

Mozilla.ai 这次下场做工具链，赌的就是这个转折。Otari 能不能成，现在下结论还太早。

但对开发者来说，这是一个值得开始关注的信号：理解 LLM Control Plane、MCP 管理、agent 抽象层这些新品类的能力边界，比盲目追新更重要。