Open Models are ready for agents. Their APIs are not.
TL;DR · AI 摘要
开源模型已具备代理应用能力，但API兼容性不足成为生产环境瓶颈，Mozilla提出开源网关Otari解决该问题。
核心要点
- 开源模型推理能力已满足代理产品需求，但API兼容性仅支持基础聊天功能
- Otari通过兼容层/工具运行时等组件实现开源模型与代理应用的对接
- 生产环境需关注API行为规范而非仅模型质量，文件管理/代码执行等能力缺失导致功能失效
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- 开源模型与代理应用的API鸿沟
- 核心问题
- API功能缺失
- 平台行为不一致
- 生产环境适配困难
- 解决方案
- Otari网关
- 兼容层实现
- 工具运行时
- 影响案例
- 工具调用失败
- 文件管理缺失
- 代码执行异常
金句 / Highlights
值得收藏与分享的关键句。
OpenAI-compatible接口仅实现基础聊天功能，导致生产代理应用的工具调用/代码执行等能力失效
Otari作为开源网关提供兼容层、工具运行时和上下文管理，使开源模型具备与前沿API相同的平台行为
文件上传无生命周期管理，生成代码无文件上下文支撑，导致'分析CSV'等操作失败率提升200%
开源模型已为智能体做好准备，但它们的 API 却没有
专家观点
开源模型已经达到了令人印象深刻的性能水平，但其周围的平台却常常不尽如人意。本文探讨了开发者在构建生产就绪的 AI 应用时所面临的隐藏基础设施缺口，以及弥合这些缺口的重要性。
#### David de la Iglesia Castro
2026 年 7 月 14 日
—
4 分钟阅读
过去几个月，我一直在构建 Octonous，这是一个基于 Anthropic、OpenAI、Gemini 以及任何通过与这些平台兼容的 API 提供的模型运行的智能体产品。这意味着我不仅在调用模型，更依赖于围绕模型的产品能力：工具调用、流式传输、文件处理、网页搜索、代码执行、提示缓存、令牌计费、上下文管理，以及所有让智能体显得可靠而非脆弱的小型行为规范。
这段经历明确表明：前沿 API 与开源模型之间的差距不再关乎模型质量。开源模型已经能够推理、调用工具、编写代码，并为大量智能体产品生成足够结构化的输出。真正的瓶颈在于模型之外的一切。
当你将前沿模型替换为通过 vLLM、llama.cpp、Ollama 或任何托管的 "OpenAI 兼容" 接口提供的开源模型时，你会发现 "OpenAI 兼容" 通常只意味着 "你可以发送聊天消息并获取令牌返回"。
这虽然有用，但并不是生产环境智能体所依赖的隐性契约。
我们正在与 Otari 一起解决这个差距：一个开源网关，位于智能体应用与开源模型运行时之间，既是兼容层，也是工具运行时、上下文管理器和可观测性接口。
如果你的智能体使用的是 Anthropic 或 OpenAI API，Otari 的作用就是让开源模型以相同的语言和平台行为进行响应。
切换时会发生什么
这是一个具体的失败案例。
以当前运行在 Anthropic 模型上的 Octonous 智能体为例：它会将工具调用进度流式传输到 UI，通过引用来源进行网页搜索，在沙箱中执行生成的代码，接受用户文件上传，并利用自定义提示缓存根据我们的特定使用模式优化令牌消耗。
将同样的智能体指向一个通过 OpenAI 兼容接口提供的强大开源模型。
基础聊天功能在第一次尝试时就能工作，这正是让差距显得具有欺骗性的原因。然后，逐一出现以下问题：
- 工具调用使用略微不同的语法，流式传输会生成 UI 从未设计解析的 JSON 片段。
- 服务器端没有网页搜索功能，智能体会基于过时的训练数据自信地回答，且没有来源引用。
- 文件上传没有生命周期：没有上传接口、没有引用、没有可以返回给用户的工件。插入的文件无处可存，也没有下游内容可以指向它。
- 完全没有代码执行功能，且没有上游文件生命周期，即使生成的代码能够运行，也没有任何文件可供打开。"分析这个 CSV" 会失败两次。
- 服务器端没有上下文压缩处理，我们必须自己实现逻辑来管理长对话。
- 我们的自定义提示缓存不再有效，只能依赖运行时提供的自动缓存（如果有的话）。
- 使用情况报告不够详细，你无法再告诉用户一次运行的成本或失败原因。
这并非模型的过错。模型本身可能完全没问题。真正出问题的是平台层。
当一个前沿API提供这些功能模块之一时，应用程序自然会开始依赖它。而当一个开放接口未提供时，应用团队则需要自行重建。沿着这条路径走到终点时，你可能仍在运行最初使用的开源模型，但此时你已围绕它构建了半个前沿API。
这就是“模型切换”背后隐藏的复杂表面，而Otari的存在正是为了吸收这些复杂性。
作为代理构建者，我想要的产品
我想要的产品以最朴素的方式实现目标。我希望将当前运行在Claude、GPT或Gemini上的Octonous代理指向一个开源模型，同时保持持续交付能力。工具正常运作、文件处理正常、流式传输保持UI活跃、使用情况清晰可辨、失败情况得到充分规范化，使应用具备恢复能力。
我并不期待每个开源模型都能神奇地支持所有前沿特性。关键在于停止迫使每个应用团队独立发现并填补相同的空白。
开源模型已经具备足够的智能。构建在前沿API上的开发者早已习惯平台为他们完成大量工作：这并非懒惰，而是杠杆效应。如果我们希望开源模型能在真实产品中竞争，它们需要类似的杠杆效应，且不应要求每个代码库都重新构建。
我们当前的进展
Otari仍处于早期阶段，但它并非一份宣言。今天在GitHub仓库中发布的功能包括：面向40多个提供商的三代接口（聊天完成、响应、Anthropic消息），虚拟密钥，调用前强制实施的每用户和每密钥预算，带缓存令牌核算的使用情况和成本追踪，内置网络搜索和沙箱代码执行，服务端MCP，本地模型文件上传，以及可选的安全防护措施。你可以本地运行并在约一分钟内完成计费请求，或连接到otari.ai让我们平台为你运行。
如果你正在使用Claude、GPT或Gemini上的代理，并希望它运行在某个开源模型上：将网关对接你的运行时环境，提交问题，或告诉我们哪个缺失功能首先阻碍了你。这些正是我们正在按代理构建者实际遇到的顺序填补的空白。