cloudflare-os
基于 Cloudflare Workers 的企业级 AI 工作台,把 agent 对话、沙箱内由 AI 即时生成的个人小应用(Gadget)和名为 Gatekeepers 的权限网关整合成一套可自行部署的系统。亮点是每个应用跑在独立沙箱里、外部服务按需引入授权,Gatekeepers 还能先本地模拟结果让 agent 继续跑、把审批攒起来异步批量处理,比常规 MCP 提前全量授权更可控。目前处于 early access 早期阶段,官方暂不接受外部代码贡献。
README
Cloudflare OS:一个 AI 生产力环境
Cloudflare OS 是一个为 AI 生产力打造的“操作系统”,最初是为 Cloudflare 内部使用而开发的。Cloudflare 的大部分员工——从工程团队到销售团队以及介于两者之间的各个岗位——每天都在使用 Cloudflare OS 来协助完成工作。

这不是传统意义上的计算机操作系统。我们使用“操作系统”这个词有两层含义:
- 一个面向公司的操作系统,让公司能以安全的方式用 AI 提升生产力,让安全团队晚上能睡得着觉。
- 一个面向 AI 工作负载的操作系统,类似于传统操作系统管理计算工作负载的那种含义。
Cloudflare OS 特别提供了三样东西:
- 一个 agent 聊天界面,你可以让 agent 执行任务,它预载了关于你公司如何运作的知识。
- 沙箱化的应用开发能力,你可以让 agent 构建“gadget”(小型个人应用),并安全地把你构建的东西分享给他人。
- 一套名为 Gatekeepers 的安全框架,为 agent 和应用施加护栏,使得非技术用户也能安全地“放飞自我”,而不会出任何乱子。
我们将 Cloudflare OS 开源,以便其他人可以复制它并为自己的公司定制。我们的想法并不是让你的公司使用 Cloudflare OS,而是让你把它做成“你的公司 OS”。
快速开始
要在本地快速运行 Cloudflare OS,先安装 pnpm,然后执行:
pnpm run-local
这会在本地基于 wrangler 和 workerd 运行整套技术栈。这不是为生产使用设计的,但可以让你快速了解这个产品的功能。
或者,你也可以部署到你的 Cloudflare 账户。
(更多选项见本 readme 末尾。)
可以试试什么
试试类似这样的提示词:
- “为我即将与客户的会议制作幻灯片。”(这会使用内置的 slides blueprint。)
- “做一个协作白板应用。”(这会从零创建一个新应用。)
- “做一个井字棋游戏。”接着再说“我下 X,你下 O。我已经走完第一步了,轮到你了。”
- “为这个 GitHub 仓库做一个 issue 看板。”(附加一个仓库;需要已配置 GitHub 集成。)
- “修正这个 Google Doc 里的错别字。”(附加一个文档;需要已配置 Google 集成。)
警告:早期访问
Cloudflare OS 正处于密集开发阶段。这个仓库实际上是 version 2,是一次彻底的重写,把我们从 version 1 中学到的东西放到一个全新基础上。
截至 2026 年 8 月的版本,Cloudflare OS v2 已经相当强大,但仍有许多粗糙之处。我们清楚这一点,也正在努力完善。就目前而言,请把它当作一个“早期访问”版本。
概览:Cloudflare OS 究竟是什么?
Gadgets:一种思考软件的新方式
Cloudflare OS 不只是又一个带连接器的聊天框。整个系统围绕一种全新的软件方式展开,即每个用户都运行自己那份生产力应用的副本。
当你在 Cloudflare OS 中创建一份幻灯片时,你并不是在调用运行在云端的某个 SaaS 软件。系统会专门为你创建一份幻灯片软件的私有实例。我们把这称为“gadget”。这个实例与所有人的幻灯片都运行在相互隔离的沙箱中。
这带来两个深远的影响:
- 幻灯片应用不可能出现一个安全漏洞,把你的幻灯片泄露给攻击者。Cloudflare OS 沙箱控制着对你这份应用私有实例的所有访问。
- 如果你愿意,你可以自由修改代码。如果幻灯片应用缺少你需要的功能,你可以直接让你的 agent 加上。而且因为有第 1 点,这样做完全安全。
这是对过去 25 年云架构和“软件即服务”模式的一次重大背离,但我们认为 AI 已经改变了游戏规则。当任何用户都能通过提示 agent 来添加自己需要的功能时,集中式的软件模式就不再说得通了。
Gatekeepers:一层基于能力的安全机制
Gatekeepers 就像是超级加强版的 MCP server。
当你把一个 agent 或 Gadget 引入到某个外部资源时,就会创建一个 Gatekeeper 来管理该访问。Gatekeeper 是针对每个外部服务的一段专门软件,它调节 Gadget 与该服务之间的连接。它:
- 为该服务提供一个干净的 Cap'n Web API(把该服务原生提供的任意 API 包装起来)。
- 处理授权(例如通过 OAuth)。
- 强制实施细粒度访问,只允许访问用户真正想要的那个特定资源。
- 记录 Gadget(或 agent)执行的每一个操作,供你审查。
- 对于任何有副作用的操作,给人类用户一个批准或拒绝该操作的机会(“human in the loop”,即人类在环)。
关于最后一点,Gatekeepers 实现了一项显著的技术进步。传统上,human-in-the-loop 机制要求人类同步批准操作。当 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 默认是私有的,但可以安全地共享,以便与你的团队或朋友协作。
就像办公文档一样,你可以拥有成千上万个,也可以心血来潮随时创建。
就像办公文档一样,你可以从“模板”——我们称为“Blueprints”——开始。但办公模板只是一些内容,而一个 Blueprint 规定的是一整个应用。
就像办公文档一样,你可以从你自己的文档(Gadgets)创建新的模板(blueprints)并分享给他人。但当你这样做时,你分享的是整个应用的代码。
它确实算得上是一个操作系统
“操作系统”这个说法并非完全是营销。Cloudflare OS 在技术层面上确实类似于一个操作系统。
| 普通 OS | Cloudflare OS |
|---|---|
| kernel | packages/workshop-backend |
| device drivers | packages/gatekeeper-* |
| shell | packages/workshop-frontend |
| processes | gadgets |
| executables | blueprints |
| users | users |
| ACLs | shared permissions |
| ??? | agents |
我们的“kernel”在 workshop-backend 这个包里。这个后端确实做了很多类似真实 OS kernel 的事情:它把用户连接到程序和设备(我们称之为 Gadgets 和 Gatekeepers),同时通过沙箱化应用和实施访问控制来实现安全。
在这个类比中,Gatekeepers——把用户和 agent 连接到外部服务——就像是驱动——把用户和程序连接到外部设备。
有一件事是传统 OS 今天并没有真正管理的,但 Cloudflare OS 管理了:AI agents。仔细想想,这其实是传统 OS 中真正缺失的一项能力。我们认为,AI agents 不能简单地被当作普通用户对待。它们必须对某个真人用户负责,同时又要有自己受限的权限。Agent 通过编写代码片段并即时执行来完成任务。对这一切而言,理想的安全模型是基于能力的安全(capability-based security),而不是访问控制列表。明白我的意思了吧?也许传统 OS 也应该给 AI agents 一些特殊待遇。
由 Workers 团队构建,运行于 Workers 之上
Cloudflare OS 构建于 Cloudflare Workers,尤其大量使用了 Durable Objects、Dynamic Workers 和 Facets。每个工作区都是一个独立的 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 上运行。事实上,workerd,即 Cloudflare Workers Runtime,本身就是开源的,Cloudflare OS 完全可以运行在你自己的服务器上、基于它之上。
功能特性
通用多用途 agent
Cloudflare OS 的 coding agent 实际上是一个完全多用途的 agent,可以执行任意任务;和其他流行的 coding agent 一样,你不一定非得用它来写代码。你可以用它来构建 Gadgets,但也可以跳过 Gadget,直接让 agent 执行任务。Cloudflare OS 的 agent 是一个 Code Mode agent——它通过编写并立即执行代码片段来完成任务。它可以通过 Gatekeepers 连接到外部资源(类似 MCP——见下文)。
用 AI 构建应用
虽然如果你愿意,也可以手写 Gadget 的代码,但预期是由 AI 来为你写。Cloudflare OS 内置了一个 coding agent,它会构建你要求的任何东西,为你测试,并调试错误。
你可以选择你的 LLM。Cloudflare OS 支持许多主流 AI 模型提供商以及自托管模型,并且提供商还在不断新增。
由于这个平台高度集成且经过简化,即使使用相同的底层 AI 模型,Cloudflare OS 的 coding agent 往往也能以更少的 token、更好更快地完成任务,胜过通用型 coding agent。
与 AI 协作
每个用 Cloudflare OS 构建的应用都会自动获得一个对 agent 友好的 API。这意味着,在你让 AI 构建应用之后,你还可以让 AI 在应用内部与你协作。无需构建 MCP server,也无需集成自定义的 agent loop。它默认就在那里。
这之所以可行,是因为 Gadget 的客户端部分和服务端部分必须通过 Cap'n Web RPC 通信。这是一个双赢:
- Cap'n Web 的样板代码极少,这让 agent 很容易上手。基本上,你只需在服务端定义一个方法,然后在客户端调用它,就像本地调用一样。
- 与此同时,这意味着服务端必然会暴露一个易于理解的 API,agent 可以直接调用它。AI Agent harness 使用 Code Mode 进行工具调用,因此可以直接把 Gadget 的 API 暴露给 agent 调用,轻而易举。
实时多人协作
你可以像在典型在线办公套件中共享文档一样共享你的 Gadget。你可以授予特定用户访问权限,也可以创建一个共享链接,让任何打开它的人都能访问。而且就像那些在线办公套件一样,你可以实时看到协作者的操作。
这之所以可行,是因为每个 Gadget 都由一个 Durable Object 支撑,Durable Object 是 Cloudflare 的有状态 serverless 原语,让实时多人协作变得轻松。轻松到 coding agent 无需被要求,就会默认实现它。
Blueprints:分享你的代码
如果你创建了一个可能对他人有用的 Gadget,但你又不想共享这个 Gadget 本身,你可以改为共享一个 Blueprint,让别人创建他们自己的 Gadget 副本。Blueprint 本质上就是一份代码副本。
听起来可能很简单,但 Blueprints 是对云软件传统的一次重大改变。传统上,如果你创建了一个想分享给其他用户的 web 应用,你会把应用托管在你的服务器上,用户连接到它。Blueprints 更像是移动应用和传统 PC 应用:每个用户运行自己那份软件副本。
在 AI 时代,这一变化至关重要。一方面,AI 让个人开发者能构建的东西比以往任何时候都多,但个人开发者要维护一项在线服务仍然很困难;而这消除了这种需求。另一方面——甚至更重要的是——允许每个用户运行自己那份软件副本,使得用户能够借助 AI 修改软件以满足自己的需求。无需提交功能请求,无需乞求开发者把它排上优先级。终端用户可以自己解决问题。
默认沙箱化且安全
每个 Gadget 都运行在一个安全沙箱中,未经你的明确同意,它完全无法与互联网通信。具体来说:
- 服务端运行在一个 Dynamic Worker 中,其对互联网的访问已被禁用。它只能通过 Workers Bindings 与你明确指定的特定外部资源通信。
- 客户端代码运行在一个沙箱化的 iframe 中。这个 iframe 只能通过一个经
postMessage()提供给父 frame 的 Cap'n Web RPC 会话与其服务端通信。除此之外,该 iframe 被阻止访问互联网(在浏览器允许的最大范围内,通过Content-Security-Policy和 iframe sandbox 设置实现)。
基于能力的访问控制
每个 agent、每个 Gadget 默认都没有任何访问权限。即使你已经为 Gadget Workshop 配置了对某些外部账户的访问,agents 和 Gadgets 也不会自动获得使用它们的权限。
相反,你必须把你希望它访问的每一个特定资源介绍给每个 agent(或 Gadget)。例如,你可以通过粘贴某个 GitHub 仓库的链接,或点击“添加资源”并在 UI 中选择它来引入该仓库。Agent 也可以主动请求引入它认为需要的某个资源,然后你可以提供或拒绝。
这不同于大多数 agent harness——在那些 harness 中,MCP server 是预先配置好的,让对你这所有服务的广泛访问在每个聊天中都是环境性地对 agent 可用的。基于能力的“介绍”机制让每个 agent 只限于它当前任务实际需要的访问权限。
开始使用
部署到你的 Cloudflare 账户
我们构建了一个在线流程,帮助你部署到自己的 Cloudflare 账户:
https://os.cloudflare.app/deploy
或者,如需更复杂的部署——带你自己的 gatekeepers,可能还有代码改动——请查看我们的部署 starter 仓库:
https://github.com/cloudflare/cloudflare-os-starter
本地运行
要在本地快速运行 Cloudflare OS,先安装 pnpm,然后执行:
pnpm run-local
这会使用 wrangler(Workers 开发者工具 CLI)运行 Cloudflare OS。这并不是在生产服务器上运行 OS 的正确方式,但用于在本机试用完全没问题。
你的数据会存储在一个名为 .wrangler 的子目录中。
使用 workerd 部署到你自己的服务器
即将推出
Cloudflare OS 完全可以运行在 workerd——Cloudflare 的开源 Workers runtime——之上。事实上,上面的“本地运行”说明在底层用的就是 workerd。我们仍在编写文档和工具,以帮助你顺利地把 OS 部署在你自己的服务器上、基于 workerd 之上。如果你喜欢冒险,可以阅读 workerd 配置的底层文档(或者让你的 agent 去读),然后试试看。
配置外部服务
许多 Gatekeepers 需要配置才能连接到第三方服务,包括为每个服务获取 OAuth 客户端凭证。遗憾的是,许多服务提供商有意不把这变得简单,因为 OAuth 的目标受众是开发者。
每个 gatekeeper 包里都包含如何设置它的说明:
- GitHub API
- Google API
- Cloudflare API
- Supabase API
- Notion API
- Confluence API
- Email Workers
- Home Assistant
- Slack API
- Spotify
- ZoomInfo API
开发
开发时,你会希望在两个终端中把前端和后端作为两个独立命令运行:
pnpm dev-server
pnpm dev-client
贡献
目前,我们不寻求外部贡献。
AI 已经让写代码变得容易。如今,难的部分不是写代码,而是审查代码、确保质量保持在高水准、并让产品保持连贯一致。从这个角度看,很遗憾,外部的代码贡献是在“捐赠”工作中容易的那部分,却制造了更多困难的工作。
话虽如此,我们乐意接受那些小而易于验证、修复某个问题的 PR。但是,我们请你不要提交低价值的 PR(例如修正错别字)或超过十几行左右的 PR。此类 PR 会被关闭,并附上本准则的链接。
如果你有一个大想法想让我们考虑,欢迎发起一个讨论。
这项政策可能会随着项目成熟而在未来改变。在此之前,感谢你的理解。
致谢
Cloudflare OS 有太多开源依赖,无法在此一一列举。但我们想重点提几个承担了特别繁重工作的:
- Pi(具体来说是
pi-agent-core),它让我们能够用一个 API 轻松支持所有 LLM 提供商。 - CodeMirror 提供了我们的代码编辑器 UI,以及用于同步实时编辑的 operational transform 实现。
- isomorphic-git 被用来实现 Gadget 代码的后端存储以及与外部 git 服务器的集成。
- Vite,它让开发循环如此愉快。