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

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

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

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

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

Otari 能帮开发者做什么

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

具体能做什么？

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

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

Otari 不是单独出现的

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

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

• any-llm：统一接口调用不同模型
• any-agent：不同 agent 框架的抽象层
• mcpd：管理 MCP server
• any-guardrail：给模型调用和 agent 行为加规则约束
• llamafile：把开源模型打包成单个可执行文件，本地跑模型更省事

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

为什么偏偏是这个时候

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

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

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

• 同一个应用里，有的请求走 OpenAI，有的走 Claude，有的走本地 Qwen，怎么统一调度？
• 不同团队、不同项目的预算怎么硬隔离？
• Agent 调用外部工具时，权限边界怎么管？
• 某个模型挂了，怎么自动切到备用模型？

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

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

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

• Microsoft：把 Azure AI Foundry 和 Copilot Studio 组合成 agentic 栈
• Google：推 Vertex AI Agent Builder，继续完善 ADK
• AWS：把 Bedrock AgentCore 作为多模型 agent 的托管入口
• Anthropic：除了力推 MCP，还在 5 月收购了 Stainless，把 SDK 和 MCP server 生成工具链握在手里
• OpenAI：推出 Agent Builder 和 Swarm 编排原语

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

开发者可以关注什么

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

品类	解决什么问题	代表
LLM Control Plane	把模型调用当成需要治理的资源，统一管理路由、预算、权限、故障切换	Otari
多模型抽象层	不同模型的 API 格式不一样，切换成本高	any-llm
MCP 管理	管理大量 MCP server、控制权限、监控成本	mcpd
Agent 抽象层	不同 agent 框架切换或组合困难	any-agent
本地模型打包	降低本地跑开源模型的门槛	llamafile

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

上手前要注意什么

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 抽象层这些新品类的能力边界，比盲目追新更重要。