Naive 推出面向应用、代理和自治公司的云栈

Why it matters

Naive is betting that coding agents will choose infrastructure through machine-readable policies, shifting cloud distribution from dashboards toward agent-controlled APIs.

Naive 在 8 月 6 日推出了一个 AI 原生的云堆栈，旨在为编码代理提供一个统一的控制平面，用于构建应用、操作自治代理并形成围绕 AI 运营公司的基础设施。

此次发布是联合创始人 Sean Dorje (@seandorje) 围绕一个简单论点组装的产品迄今为止最全面的版本：代理需要访问那些人类创始人和工程团队通常在数十个服务之间配置的运营系统。Naive 正在将这些系统打包到一个 API 密钥、命令行界面和声明式配置文件之后。

Naive 现在的主张已经远远超出了工具调用。该平台涵盖应用托管、无服务器函数、GPU 工作负载、Postgres 数据库、身份验证、对象存储、模型路由、虚拟卡、开票、电子邮件、电话号码、公司注册和第三方软件连接。Naive 表示开发者可以从包括 Claude Code、Codex 和 Cursor 在内的编码代理，或来自诸如 Hermes 和 OpenClaw 的代理运行时中使用这些组件。

这种广度使 Naive 同时与多个类别竞争。开发者已经可以从云提供商、模型网关、后端即服务产品、支付平台和代理框架中组装出类似能力。Dorje 下注认为代理会偏好单一的机器可读控制平面，而不是为人类操作员构建的以仪表板为中心的流程。

Infrastructure as code for agents

此次发布的核心是一个基础设施即代码层，允许代理在一个配置文件中声明身份、支出上限、预算、审批规则和允许使用的工具。Naive 随后负责配置并管理底层资源。

一旦代理可以花钱或通过客户账户采取行动，这种设计就变得重要。Naive 表示其治理层会在付款移动或工具运行之前检查策略。该平台可以对敏感操作要求审批、施加支出上限、发行短期会话并在审计日志中记录活动。

这些控制也是 Naive 对将如此多权力集中在一个凭证后面所带来风险的回应。一个能够访问计算、支付、客户软件和公司注册服务的代理，其潜在冲击范围要比仅限于生成文本的助手大得多。随着开发者连接更重要的工作流，Naive 的产品能否成功将取决于其服务器端控制是否保持可靠。

Naive 表示其模型路由器支持 300 多个模型，具有基于任务的路由、回退提供商和使用量计量。Naive 还宣称拥有 100 多个第三方连接和一个包含 10,000 多个工具的目录。这些数字是 Naive 自己的统计，它们合并了不同类型的资源：模型端点、集成和可调用原语并不代表相同层次的产品深度。

开发者可以通过 Naive quickstart 开始，该快速入门通过 CLI、托管的 MCP 服务器、REST API 和软件开发工具包暴露平台。入职流程允许代理注册、接收 API 密钥并开始调用原语，而无需开发者手动配置每个服务。

Dorje is moving Naive down the stack

Dorje 先前将 Naive 定位于自治公司：由 AI 劳动力组成，拥有 CEO 代理、任务板、专门的工作者以及对业务工具的访问。新的云框架将 Naive 推得更深，进入这些公司底层的基础设施，并向构建自有代理软件的开发者开放产品。

这一转变在 6 月 17 日就已显现，当时 Dorje 推出了 Naive Developer Platform。该发布描述了跨身份、资金、通信、生成、数据、编排、应用构建和代理基础设施的 38 个原语。它还引入了一个多租户结构，开发者可以为每个客户隔离资源和策略。

Naive 随后将这些能力打包成了一个 Agent SDK，面向需要为每个用户分配独立卡片、凭证、会话和工具访问的产品。8 月 6 日的发布将这些部分与更大的云命题联系起来：代理应该能够通过同一系统构建应用、部署应用、连接其工具并运营由此产生的业务。

Naive 目前面临的直接挑战是在异常广泛的表面上执行。托管、数据库、支付、身份验证和模型路由各自承担着不同的可靠性、安全性和合规性要求。Naive 选择拥有协调层，而不是要求开发者自行将这些系统拼接在一起。

这为 Dorje 提供了明确的分发赌注。如果编码代理成为创建软件的主要界面，基础设施供应商将需要代理能够理解并直接配置的产品。Naive 正在为该界面构建，此举发生在主导云平台将其以人为中心的控制台和产品目录适配给自治用户之前。