cloudflare/cloudflare-os

来源：https://github.com/cloudflare/cloudflare-os

Cloudflare OS：AI 生产力环境

Cloudflare OS 是一套面向 AI 生产力的“操作系统“，最初是为 Cloudflare 内部使用而开发的。Cloudflare 有相当一部分员工——从工程到销售，几乎涵盖所有岗位——每天都在使用 Cloudflare OS 来完成工作。

Cloudflare OS 中的一个 Q3 规划工作区，其中包含一份由 AI 生成的幻灯片

这不是一个传统的计算机操作系统。我们之所以使用“操作系统“这个词，是因为它有两层含义：

• 它是整个公司借助 AI 提高生产力的操作系统，并且是以安全的方式进行，让安全团队晚上能睡得着觉。
• 它是管理 AI 工作负载的操作系统，这与传统操作系统管理计算工作负载的方式类似。

Cloudflare OS 尤其提供了三样东西：

1. 一个 Agent 聊天界面，你可以在其中让 Agent 去完成任务，它预先内置了关于贵公司运作方式的知识。
2. 沙箱化的应用开发环境，你可以让 Agent 去构建“小工具“（Gadgets，即个人小应用），并安全地与他人分享你构建的成果。
3. 一套名为 Gatekeepers 的安全框架，它为 Agent 和应用都施加了防护措施，使非技术用户也可以放心地“放飞自我“，而不会发生任何糟糕的事情。

我们将 Cloudflare OS 开源，以便其他人可以复制它并根据自身公司进行定制。我们的想法并不是让你的公司直接使用 Cloudflare OS，而是让你打造属于自己的“贵公司 OS“。

快速开始

要快速在本地运行 Cloudflare OS，请先安装 pnpm（https://pnpm.io/），然后执行：

pnpm run-local

接着访问：http://localhost:8787

这会在本地的 wrangler 和 workerd 上运行整套系统。这并不是为了生产环境使用，而是一种快速了解产品功能的方式。

另一种方式是部署到你的 Cloudflare 账户（https://os.cloudflare.app/deploy）。

（文末还有更多选项。）

值得一试的提示词

试试这些提示词：

• “为我即将与客户举行的会议制作幻灯片。”（这会使用内置的 slides 模板。）
• “制作一个协作白板应用。”（这会从零开始创建一个新应用。）
• “制作一个井字棋游戏。” 然后说：“我走 X，你走 O。我已经落子了，轮到你了。”
• “为这个 GitHub 仓库制作一个 issue 仪表盘。”（需要附加一个仓库；前提是已配置 GitHub 集成。）
• “修正这个 Google Doc 中的错别字。”（需要附加一个文档；前提是已配置 Google 集成。）

警告：抢先体验阶段

Cloudflare OS 目前处于快速开发阶段。这个仓库实际上是版本 2，是一次彻底的重写——我们把从版本 1 中学到的经验，构建在了全新的基础之上。

截至 2026 年 8 月的发布版本，Cloudflare OS v2 已经相当强大，但仍然存在不少粗糙之处。我们知道这一点，并且正在改进。目前，请将其视为一个“抢先体验“版本。

概述：Cloudflare OS 究竟是什么？

Gadgets：一种全新的软件思维

Cloudflare OS 不只是又一个带连接器的聊天框。整个系统围绕着一种全新的软件模式展开：每个用户都运行自己那一份生产力应用。

当你在 Cloudflare OS 中创建幻灯片时，你并不是在调用某个运行在云端的 SaaS 软件。系统会专门为你创建幻灯片软件的私有实例。我们把这称为一个“小工具“（Gadget）。这个实例运行在与他人的幻灯片完全隔离的独立沙箱中。

这带来了两个深远的影响：

1. 幻灯片应用不可能存在会把你的幻灯片泄露给攻击者的安全漏洞。Cloudflare OS 的沙箱掌控着对你该应用私有实例的所有访问。
2. 如果你愿意，可以随意修改代码。如果幻灯片应用缺少你需要的功能，你只需让 Agent 帮你加上即可。而且由于第一点，这样做完全是安全的。

这是对过去 25 年的云计算架构和“软件即服务（SaaS）“模式的一次重大背离，但我们认为 AI 已经改变了游戏规则。当任何用户都能通过提示词让 Agent 添加自己需要的功能时，软件的集中式模式就不再说得通了。

Gatekeepers：基于能力的安全层

Gatekeepers 就像是增强版的 MCP 服务器。

当你把一个 Agent 或 Gadget 接入某个外部资源时，系统会创建一个 Gatekeeper 来管理这项访问。Gatekeeper 是针对每个外部服务定制的软件，负责协调 Gadget 与该服务之间的连接。它会：

• 为该服务提供一套干净的 Cap’n Web API（封装该服务原生提供的各种 API）。
• 处理授权（例如通过 OAuth）。
• 强制执行严格的访问控制，只允许访问用户真正想要的那一个资源。
• 记录 Gadget（或 Agent）执行的每一个操作，供你审阅。
• 对于任何会产生副作用的操作，为人类用户提供批准或拒绝该操作的机会（“人在环中”）。

在最后一点上，Gatekeepers 实现了当前技术水平上的重大进步。传统的人在环中机制要求人类同步地批准操作。当 Agent 想要做某件事时，它必须停下来等待批准，然后才能继续。这很烦人：你给 Agent 一个任务，然后走开去泡杯咖啡，结果回来发现 Agent 卡在第一步的审批上，毫无进展。于是人们常常会妥协，把 Agent 设置为“自动批准“，或者使用 --dangerously-skip-permissions，这显然是不安全的。

Gatekeepers 提供了更好的方式：当 Agent（或 Gadget）执行一个需要审批的操作时，Gatekeeper 会在本地模拟操作结果，让 Agent 继续执行，并把更多操作排队等待。Gatekeeper 会告诉 Agent 操作已完成；如果 Agent 试图读回结果，Gatekeeper 就把模拟结果交给它。等 Agent 执行完毕后，用户可以批量批准或拒绝这些操作，也可以逐个批准或拒绝——无论哪种方式，都可以等到方便的时候再处理。

在实现层面，每个 Gatekeeper 都作为一个独立的 Worker 来实现。展望未来，我们设想 Gatekeeper 服务将与 OS 实例分别部署和维护，不过具体细节还有待确定。目前，本仓库中提供了几个有意思的 Gatekeeper，你可以将其与你自己的 OS 实例一起部署。

把它想成一套办公套件

Cloudflare OS 的基本用户体验类似于 Google Docs 或 MS Office 这样的在线办公套件。但是，请想象一下：不再是一组固定的文件类型（文档、表格、幻灯片），而是每一个文件——或者说“小工具“（Gadget）——都可能是一个由 AI 编写的、专门满足你需求的定制应用。

就像办公文档一样，每个 Gadget 默认都是私有的，但可以——安全地——共享，以便与你的团队或朋友协作。

就像办公文档一样，你可以拥有成千上万个 Gadget，随时随地创建它们。

就像办公文档一样，你可以从“模板“开始——也就是我们所说的“蓝图“（Blueprint）。但办公模板只是一些内容，而一份蓝图定义的是一个完整应用。

就像办公文档一样，你可以从自己的文档（Gadget）中创建新的模板（蓝图），并分享给他人。但当你这样做时，你分享的是整个应用的代码。

它在某种意义上确实是个操作系统

“操作系统“这个说法并非完全是营销话术。Cloudflare OS 在技术层面确实与操作系统有着相似之处。

我们的“内核“位于 workshop-backend 包中。这个后端确实做了很多与真正的操作系统内核类似的事情：它把用户与程序和设备（也就是我们所说的 Gadgets 和 Gatekeepers）连接起来，同时通过沙箱化应用和强制访问控制来实现安全性。

在这个类比中，Gatekeepers——将用户和 Agent 连接到外部服务的组件——就相当于驱动程序——将用户和程序连接到外部设备的组件。

有一点是传统操作系统目前并不真正管理的，但 Cloudflare OS 管理了：AI Agent。仔细想想，这其实是传统操作系统缺失的一项功能。我们认为，AI Agent 不能简单地被当作用户来对待。它们必须对某个人类用户负责，同时又拥有自己受限的权限。Agent 的工作方式是编写代码片段并即时执行。这一切最理想的安全模型是基于能力（capability）的安全模型，而不是访问控制列表。你明白我的意思了吗？或许传统操作系统也应该对 AI Agent 给予特殊对待。

由 Workers 团队基于 Workers 构建

Cloudflare OS 构建在 Cloudflare Workers（https://workers.cloudflare.com）之上，尤其大量使用了 Durable Objects（https://developers.cloudflare.com/durable-objects/）、Dynamic Workers（https://blog.cloudflare.com/dynamic-workers/）和 Facets（https://blog.cloudflare.com/durable-object-facets-dynamic-workers/）。每个工作区（Workspace）本身就是一个 Durable Object，每个 Gadget 都运行在 Dynamic Worker Facet 中，Gatekeepers 也会在每个工作区中安装 facet，以管理对远程服务的访问。

Cloudflare OS 实际上正是由开发 Workers 本身的那批人打造的。它使用了 Workers Runtime 的前沿特性——事实上，Dynamic Workers、Facets 以及另外几项特性，就是为了支持 Cloudflare OS 而专门添加到 Runtime 中的，未来还会有更多。研读 Cloudflare OS 的源代码，是理解 Workers Runtime 团队心目中 Workers 应该如何使用的绝佳方式。

构建在 Workers 之上并不意味着 Cloudflare OS 只能运行在 Cloudflare 上。事实上，Cloudflare Workers Runtime workerd 本身就是开源的（https://github.com/cloudflare/workerd），Cloudflare OS 可以完全在你自己服务器上的 workerd 之上运行。

功能特性

通用的多用途 Agent

Cloudflare OS 的编码 Agent 实际上是一个完全多用途的 Agent，可以执行任意任务；就像其他流行的编码 Agent 一样，你不一定要用它来写代码。你可以用它来构建 Gadget，但也可以跳过 Gadget，直接让 Agent 执行任务。Cloudflare OS Agent 是一个 Code Mode（https://blog.cloudflare.com/code-mode/）Agent——它通过编写代码片段并立即执行来完成任务。它可以借助 Gatekeepers 连接到外部资源（类似 MCP——见下文）。

用 AI 构建应用

虽然如果你想的话，也可以手动编写 Gadget，但我们预期的是由 AI 来为你编写代码。Cloudflare OS 内置了编码 Agent，它会构建你要求的任何东西，为你测试，并调试错误。

你可以选择自己的 LLM。Cloudflare OS 支持多家主流 AI 模型提供商和自托管模型，并且不断增加新的提供商。

由于平台紧密集成、结构简洁，即使使用相同的底层 AI 模型，Cloudflare OS 的编码 Agent 往往也比通用编码 Agent 表现得更好、更快，且消耗的 token 更少。

与 AI 协作

每一个使用 Cloudflare OS 构建的应用，都天然具备对 Agent 友好的 API。这意味着，在你让 AI 构建好应用之后，你还可以让 AI 在应用内部与你协作。无需构建 MCP 服务器，也无需集成自定义的 Agent 循环，它开箱即有。

之所以能做到这一点，是因为 Gadget 的客户端和服务器端必须通过 Cap’n Web RPC（https://github.com/cloudflare/capnweb）进行通信。这是一个双赢的结果：

1. Cap’n Web 的样板代码极少，非常便于 Agent 使用。你基本上只需在服务器端定义一个方法，然后在客户端调用它，就像调用本地函数一样。
2. 与此同时，这也意味着服务器必然会暴露一个易于理解、可被 Agent 直接调用的 API。AI Agent 框架使用 Code Mode（https://blog.cloudflare.com/code-mode/）进行工具调用，因此直接向 Agent 暴露 Gadget 的 API 供其调用是轻而易举的事。

实时多人协作

你可以像在典型的在线办公套件中分享文档一样分享你的 Gadget。你可以授予特定用户访问权限，也可以创建一个分享链接，让任何打开链接的人都能访问。而且就像那些在线办公套件一样，你可以实时看到协作者的操作。

之所以能做到这一点，是因为每个 Gadget 背后都有一个 Durable Object（https://developers.cloudflare.com/durable-objects/）作为支撑——这是 Cloudflare 的有状态无服务器原语，让实时多人协作变得非常容易。容易到什么程度呢？编码 Agent 甚至不需要你特别要求，就会默认实现这一功能。

Blueprints：分享你的代码

如果你创建了一个对他人可能有用的 Gadget，但又不想直接分享 Gadget 本身，那么你可以改为分享一份 Blueprint（蓝图），让其他人能够创建属于他们自己的那份 Gadget 副本。本质上，Blueprint 就是代码的一份副本。

这听起来可能很简单，但 Blueprint 是对云计算软件传统的一次重大变革。传统上，如果你想与其他用户分享一个你创建的 Web 应用，你会把它托管在你自己的服务器上，用户则连接到那里。而 Blueprint 更像是移动应用和传统 PC 应用：每个用户运行的都是属于自己的那份软件副本。

在 AI 时代，这一变革至关重要。一方面，AI 让单个开发者能够构建比以往更多的东西，但单个开发者要维护一个在线服务仍然很难；Blueprint 消除了这种需要。另一方面——而且更加重要的是——允许每个用户运行自己那份软件副本，能够让用户借助 AI 去改造软件，以满足自己的需求。无需提交功能请求，无需哀求开发者优先处理。最终用户可以自己解决问题。

默认沙箱化、默认安全

每个 Gadget 都运行在安全的沙箱中，在未经你明确同意的情况下，它根本无法与互联网通信。具体来说：

• 服务器端运行在一个 Dynamic Worker（https://blog.cloudflare.com/dynamic-workers/）中，其互联网访问已被禁用。它只能通过 Workers Bindings（https://blog.cloudflare.com/workers-environment-live-object-bindings/）与你明确指定的特定外部资源通信。
• 客户端代码运行在一个沙箱化的 iframe 中。这个 iframe 只能通过父框架通过 postMessage() 提供的 Cap’n Web RPC 会话与其服务器通信。除此之外，iframe 被阻止访问互联网（通过 Content-Security-Policy 和 iframe sandbox 设置，达到浏览器所允许的最大程度）。

基于能力的访问控制

每个 Agent 和每个 Gadget，默认情况下都无法访问任何东西。即使你已经为 Gadget Workshop 配置了外部账户的访问权限，Agent 和 Gadget 也不会自动获得这些访问权限。

相反，你必须把每个 Agent（或 Gadget）“介绍“给你希望它访问的资源。例如，你可以通过粘贴链接来介绍一个 GitHub 仓库，或者点击“添加资源“并通过界面选择它。Agent 也可以主动请求被介绍给某个它认为自己需要的资源，然后由你决定提供还是拒绝。

这与大多数 Agent 框架不同——在那些框架中，MCP 服务器是预先配置好的，这意味着你所有服务的广泛访问权限会隐性地存在于每一次对话中，供 Agent 使用。基于能力的“介绍“机制，让每个 Agent 只被限制在……