Building the Missing Half

构建缺失的一半

专家观点

开放模型已准备好用于代理，但围绕它们的基础设施尚未完善。Otari 是一个网关，恢复了托管 API 静默处理的功能，如网络搜索和代码执行，使您在保留对提供商、凭证和沙盒的控制权的同时，应用程序仍能使用相同的工具接口。

#### David de la Iglesia Castro

2026年10月13日

—

2分钟阅读

早在7月，我就曾论述过开放模型已准备好用于代理，但它们的 API 尚未就绪。将我们的代理应用从专有前沿 API 迁移时，意味着需要围绕模型本身重建大量底层基础设施。本文将深入探讨当时未涉及的部分：实际构建缺失一半所需的要素。

目标

我们的目标看似“简单”：使用开放模型进行开发应与使用封闭替代方案一样无缝。

最具挑战性的部分并非人们讨论的显而易见的功能缺口，而是托管 API 在后台静默执行的微妙且隐形的功能，您的代码在无意识中依赖这些功能。

我们构建了 Otari 作为网关层，将这些缺失的能力重新引入，它恰好位于您的应用程序与所选模型主机之间。

为何选择开放

以网络搜索为例。当在 Claude 中启用时，查询会在后台某个搜索引擎上执行，而该搜索引擎的使用条款您从未直接同意过。您无法选择底层提供商、追踪数据保留情况，或在领域结果恶化时切换服务。同样的情况也适用于代码执行：用户文件在您未配置的沙盒中运行，托管位置无法验证。

使用 Otari 时，这些决策仍由您掌控。网络查询通过您明确配置的服务进行，使用您自己的凭证和合同。代码在您指定的沙盒环境中运行，遵循任何人都可实现的开放协议。您的应用程序体验完全相同的工具接口，但您保留完整的可见性和所有权。

未来方向

尽管仍有待实现和优化的功能，我们已在 octonous.com 上成功实现这一目标，这标志着重要的里程碑。

剩余的技术挑战对未围绕不同前沿 API 构建的开发者可能不显而易见：上下文压缩、提示缓存以及开发者可检查并跨模型迁移的持久化内存，而非将其锁定在专有孤岛中。

我们评估的关键基准是：专为商业前沿 API 设计的代理是否能通过 Otari 直接指向开放模型并完美运行。

欢迎在我们的 GitHub 仓库中提交问题，分享您的发现。