Cloudflare 开源 Forge：自动生成 API SDK 和文档

Cloudflare 宣布推出一款开源工具，可以根据 API 定义自动生成 SDK、命令行工具、文档以及其他用于与 API 交互的接口。

这款工具名为 Forge，采用 Apache 2.0 许可证发布，无需向 Cloudflare 支付任何费用即可私下运行和修改。Cloudflare 的 Dimitri Mitropulos、Matt Taylor 和 Samuel MacLeod 在周一发布的博客文章中指出，该项目仍处于早期阶段：它已经能为 Cloudflare 的 cf CLI 生成所需输出——cf 是用于跨 Cloudflare 平台工作的统一命令行接口——该公司的 API 文档和 SDK 将在未来几个月内迁移过来。

"我们认为，为 API 构建工具是互联网的核心部分，你应该能够在不需要 SaaS 产品的情况下做到这一点。"

"我们认为，为 API 构建工具是互联网的核心部分，你应该能够在不需要 SaaS 产品的情况下做到这一点，"作者写道。

当你的 SDK 生成器消失时

Cloudflare 的发布公告恰逢 Google 做出类似举动 11 天之后——Google 宣布与 API 工具公司 Speakeasy 合作，在 AGPLv3 许可证下开源后者的 OpenAPI 代码生成套件。

Google 在 9 月 17 日发布的博客文章中表示，其决定是在 SDK 生成服务突然中断后做出的，此前该服务提供商被收购并"突然宣布关闭"。这发生在 Google 正准备推出新 API 之际。

"这一突发中断表明，专有、闭源的生成器会产生不可接受的平台风险。"

"这一突发中断表明，专有、闭源的生成器会产生不可接受的平台风险，"Google 在文章中写道。"如果行业依赖 OpenAPI 来定义接口，那么将这些接口编译成客户端库、CLI 和代理工具的工具应该是开放基础设施。"

Google 所指的提供商是 Stainless。Anthropic 于 5 月 18 日收购了这家 SDK 和 MCP 工具公司，之后 Stainless 表示将逐步停止其产品运营，包括用于在 API 变化时保持客户端库更新的 SDK 生成器。

正如 The New Stack 当时报道的那样，此次关闭影响了一大批客户，包括 OpenAI、Google 和 Cloudflare。这些公司保留了 Stainless 已经为他们生成的 SDK，但失去了用于在 API 演进时重新生成和更新这些 SDK 的共享服务。

就 Cloudflare 而言，它此前已经开始构建将成为 Forge 的一部分的机制。今年 4 月，该公司发布了 cf 的技术预览版——这是一款新的统一命令行接口，旨在最终通过一组一致的命令向开发者和 AI 代理暴露 Cloudflare 的产品。彼时 Cloudflare 表示，它创建了一个新的基于 TypeScript 的模式和生成系统，以保持 CLI 命令、配置、绑定和其他接口与 API 同步。

此前的预览版功能有限，但 cf 现在已进入开放测试阶段，支持 Cloudflare 全系列 API。Forge 读取 Cloudflare 为其产品维护的 OpenAPI 描述，并用它们来创建 cf 的命令，使该公司能够从 Wrangler 的大约 280 个功能扩展到 Cloudflare API 的 3000 多个操作。Cloudflare 打算用 cf 取代 Wrangler：测试版结束后，该公司计划发布 Wrangler 的最后一个主要版本，然后将这个较旧的工具转入维护支持，为期 18 个月。

值得指出的是，Cloudflare 正在大力推广 cf，尤其针对 AI 代理：一款 CLI 现在可以用于部署和监控 Worker、配置 Cloudflare Access、购买域名或管理 WAF 防护。它还默认输出 JSON，并包含自然语言命令搜索功能，旨在帮助代理在不完全加载数千个可能命令的情况下找到正确的操作。

这也是对 Forge 用途的一个很好的说明。Cloudflare 不必将 SDK、CLI 命令和文档作为独立的实现来维护，而是可以从相同的底层 API 定义生成它们。当该 API 发生变化时，相应的开发者——或代理——接口可以从同一源重新生成，减少了必须保持同步的手动维护工具的数量。

为什么 Cloudflare 要构建自己的生成器

虽然 Stainless 是 Cloudflare 在生产环境中依赖的托管生成产品之一，但 Cloudflare 并没有特别点名它，而是阐明了 Cloudflare 对托管生成器这一大类工具不满的原因。

部分问题在于规模：Cloudflare 表示，它现在拥有超过 3500 个 API 操作，由数百个由不同工程团队维护的服务支撑。因此，生成器必须准确地将该庞大 API 生态系统中的变化反映在客户使用的工具中，同时不将每次更新变成公司内部的协调工作。

Cloudflare 还希望工程师能够在底层代码合并之前，看到 API 更改将对生成的 SDK、CLI 和文档产生什么影响。此外，它希望同一个系统能够超越传统 SDK，延伸到 MCP 服务器和 Cap'n Web 绑定等领域——后者允许应用程序通过 Cloudflare 基于 TypeScript 的 RPC 系统调用远程服务，就像调用本地函数一样。

使用外部服务已被证明这很困难。Cloudflare 表示，其 API 某一部分引入的问题可能只有在另一个团队稍后尝试发布时才暴露出来，导致工程师不得不通过他们不完全控制的系统追踪故障，然后在公司和供应商之间协调修复。

"我们尝试过几种试图解决这个问题的托管产品，并在生产环境中依赖过其中一些，"作者写道。"没有一个为我们解决了这个问题，有些已经完全关闭了。"

开源因素

因此，Stainless 的逐步关闭在某种程度上解释了 Cloudflare 为什么将 Forge 开源。Stainless 的生成器是专有的，以托管服务的形式提供，使客户依赖于该公司继续运营它。Forge 宽松的 Apache 2.0 许可证意味着开发者可以在自己的基础设施上运行它、修改它，或者 fork 项目并独立于 Cloudflare 继续使用它。

AI 代理进一步提高了赌注，因为它们越来越依赖 SDK、CLI 和 API 绑定来了解软件能做什么以及如何与之交互。如果这些接口落后于底层服务，代理可能基于不完整或过时的能力描述来工作。

这是 Cloudflare CTO Dane Knecht 在解释为什么保持这些接口最新比以往任何时候都更重要时强调的担忧。

"API 一直是软件连接的方式，但 AI 代理使 SDK、CLI 和 API 绑定的质量变得更加重要，"Knecht 通过电子邮件告诉 The New Stack。"如果那一层是陈旧的或不完整的，代理不仅仅是拥有更差的开发者体验，它可能会误解服务能做什么。"

最终，Cloudflare 创建 Forge 是因为 SDK 和 CLI 生成已经"变得过于重要"，不能游离于其内部开发流程之外。

"Cloudflare 需要一条管道，让我们的团队能够运行、测试和扩展它，我们认为其他开发者也应该能够访问这种开放的、供应商无关的基础，"Knecht 说。

当然，Forge 仍有大量需要证明的地方。该项目仍处于早期阶段，cf 是其第一个生产输出，Cloudflare 表示其 API 文档和现有 SDK 将在未来几个月内迁移过来。它讨论的几种输入格式和生成目标也是未来工作。

但时机非常耐人寻味。在 11 天内，Google 和 Cloudflare——都是前 Stainless 客户——在依赖的专有服务消失后，公开地将他们的影响力投向了开源 SDK 生成基础设施。Google 将这种依赖描述为"不可接受的平台风险"。Cloudflare 现在正通过 Forge 试图从自己的技术栈中消除同样的风险。