每个「文件」都是一个独立应用，自己的沙箱、自己的数据库

传统办公套件给你固定的几种文件：文档、表格、幻灯片。Cloudflare OS 把这个前提掀了，每个「文件」都可以是它自己的一个完整应用，由 Agent 为你一个人、一个项目、一个团队现写的。

仓库里管这东西叫 gadget（小玩意儿），对外的博客里翻译成了「app」，指的是同一样东西。它不是原型，不是那种得导出去另找地方部署的半成品：每一个都是完整的全栈应用，有前端代码、有后端代码、有接口、有存得住的状态。默认私有，能像文档一样分享出去。

它怎么做到「每人一份」还不烧钱，靠的是三块拼图：

前两块都是 Cloudflare 今年春天才加进 Workers 运行时的新特性。仓库 README 里点破了它们的来历：这几个特性就是为了做 Cloudflare OS 才专门加进运行时的，而且后面还有更多。

选了 Cap'n Web 之后，白捡了一个能力

第三块拼图带来一个副作用，也是这套设计最漂亮的地方。因为前端必须通过一套规规矩矩的方法接口去调后端，所以这套接口天然也能被 Agent 直接调。

你为自己写的那个小工具，Agent 在你不在的时候能拿去替你干活。不用另外写一个 MCP 服务器，不用再接一层 Agent 循环，白送的。官方架构图上把这句话印在了正中间：whatever the UI can do, the agent can do，界面能干的，Agent 都能干。

分享有两种：一起用同一个应用，或者给对方一份代码让他自己改

第一种是分享应用本身：大家进的是同一个应用、同一个 SQLite 库，谁改了别人实时看得见，跟在 Google Docs 里协作一样。

第二种是分享蓝图（blueprint）：对方拿到的是一份代码副本，自己生成一个全新的应用。原来那个应用的数据、对话历史、凭据、连着的资源，一样都不跟过去。两个人从此各跑各的。

第二种才是关键。它意味着别人拿到你的应用之后可以自己让 AI 去改，而不是给你提个需求、然后排进你的待办队列里等着。

仓库 README 把这件事拔得更高。过去 25 年 SaaS 的逻辑是：我把软件跑在我的服务器上，你连过来用；你缺个功能，得来求我排期。蓝图这套更像手机 App 和 PC 软件，每个用户跑自己那一份，缺什么自己让 AI 加。README 的说法是，AI 一方面让个人开发者能造出比过去多得多的东西，另一方面个人维护一个在线服务仍然很难，而蓝图正好把「维护服务」这件事从等式里消掉了。

Gatekeeper：Agent 一开始什么都碰不到，批准之后拿到的也不是密钥

今年 2 月前后，Cloudflare 一个销售部门的同事找到公司 CIO 要 API 密钥，要好几把。这人用 AI 攒了个自称能改造整个市场团队的「超级应用」，就差临门一脚：需要十来个公司核心业务系统的生产环境权限，外加一条部署管线的管理员权限。

这就是所有公司推 AI 都会撞上的那堵墙。AI 在公司里如果碰不到大家干活用的那些系统，它基本没用；可要让它碰，就得发密钥，而密钥这东西权限一给就是一大片、有效期还特别长，收不回来也审计不清。

MCP 已经算是往前走了一步：Agent 不直接拿密钥，MCP 服务器替它拿着，只暴露一组定义好的工具。但博客把 MCP 的盲区点得很准：

MCP 只告诉我们这个 Agent 能调哪些工具，不告诉我们它到底看到过哪些底层资源。

Cloudflare 博客《Cloudflare OS：一个面向 Agent、应用与工作的开放平台》

Agent 完全可以把好几个系统里的信息拼起来，送到一个管得没那么严的地方去，或者通过它做出来的应用和产物，泄露给根本没资格看原始数据的人。所以授权这件事不能只管「进门」，还得管数据接下来能流到哪儿。

Gatekeeper 就是为这个设计的。它是一个夹在 Cloudflare OS 和某个外部服务中间的 Worker，一个服务配一个，懂那个服务的接口、资源和能做的操作。它干四件事：拿着凭据、执行策略、记录读过什么、拦下所有对外有副作用的动作。

第一层：起步权限是零，批了也只给一张门禁卡

进 Cloudflare OS 这道门由 Cloudflare Access 管。进来以后，每个 Agent、每个应用初始权限是零。Agent 可以开口申请某个具体资源的访问权，你批或者不批。批了之后，它写的代码里拿到的是这么个东西：

const issues = await env.PROJECT.listIssues({
  teamId: "ENG",
  state: "open",
});

env.PROJECT 代表的是「在某条策略下使用某个具体资源」的一张通行证原文叫 capability（能力）。它跟密钥的区别在于：密钥是一串谁拿到谁就能用的字符，通行证是一个对象，能干什么早就框死在里面了，也没法复制出去给别人。。凭据本身跟 Agent 和它写的代码是完全隔离的，代码从头到尾摸不到密钥。

而且口子可以切得非常细。博客举的例子：把整个 GitHub 账号给 Agent 显然太宽了，Gatekeeper 可以只给它一个仓库、只让它读 issue 不让读源码、把某些字段打上码、加个速率限制，还可以规定合并 PR 之前必须人工点头。

底下还有两道墙：应用的服务端代码跑在 Dynamic Worker 里，全局出网被关掉了；前端代码跑在浏览器的沙箱 iframe 里。两边都只能顺着你明确给的通行证出去，别的路一条没有。

系统记着 Agent 读过什么，别人来看之前先查他有没有资格读这些

光管住第一次读取还不够。博客举了个例子，一看就懂：Agent 读了数据仓库里一张敏感的表，拿它做了个实时看板。分享这个看板，不能变成一条绕过权限、把那张表分享出去的路。

Cloudflare OS 的做法是，把 Agent 读过的每一个资源都记下来。这些「观察记录」跟着 Agent 和它的产物一起走。等到别人想打开这个工作区、想跟这个 Agent 对话、或者想看它产出的东西时，各个 Gatekeeper 会去核对一件事：这个人有没有资格直接读它读过的那些东西。有就放行，没有就拦。

仓库里的实现比博客说的狠

博客只说了「会核对」。开源仓库的 docs/observers.md 里，这套机制的完整样子是这样的，有三条博客没提：

一、对方得先接上他自己的账号。你把应用分享给同事，他打开的时候，得为这个应用依赖的每一个服务选一个他自己的账号（他自己的 Google、他自己的 GitHub）。系统拿他的身份去问 Gatekeeper：这些东西他能读吗？不能，就直接拒绝打开。他要是不肯选账号，也是拒绝。

二、通过之后他被登记成一个「观察者」，然后你的应用能力就被压住了。从他成为观察者那一刻起，这个应用再想读任何观察者没资格看的东西，那次读取会被当场拦下、抛出异常。你把应用分享给一位权限比你低的同事之后，你自己这个应用的读取范围就被压到跟他一样宽。想解开，只有一条路，把他的访问权撤掉。

三、他每次打开都要重新核一遍。防的是「上个月他还有权限，这个月调岗了」这种情况。

同一份观察记录还有第二个用处：管出网。读过敏感数据之后，Agent 再想往某些地方写数据、拉新的协作者进来、把任务交给另一个 Agent、或者发一个对外请求，都可能被禁掉。读什么，决定了接下来能做什么。

审批可以晚点再给：Gatekeeper 先编一个假 issue，让 Agent 一路跑完

凡是用过带权限确认的 Agent 工具的人，都熟悉下面这个场景。

传统的「人在环里」审批是同步的：Agent 要干一件有副作用的事，就停下来等你点确认。你给它派个任务，转身去接杯咖啡，回来发现它卡在第一步的审批弹窗上，一步没往前走。于是大家纷纷投降，把 Agent 设成全部自动批准，或者干脆加上跳过权限确认的参数。README 里直接把那个参数名点出来了：--dangerously-skip-permissions。这显然不安全，但比干等着强。

Gatekeeper 的解法是：动作不真做，但假装做完了。

Agent 说「建一个 issue」，Gatekeeper 不去 GitHub 建，而是把这个动作排进审批队列，同时编一个临时的假 issue 还给 Agent，让它以为建好了、可以接着往下干。给这个 issue 打标签、加评论、在别的地方引用它，全都行，Agent 一路跑到底不停顿。等你什么时候方便了，回来一次性看这一批动作，整批批准，或者一条条批，也可以拒。

去源码里验了一遍：createIssue 确实先排队，再返回一个临时 ID

我把仓库拉下来翻了 GitHub Gatekeeper 的实现。createIssue 这个方法确实是先把动作扔进 submitActionForApproval 排队，然后立刻返回一个带着 provisionalId（临时 ID）的 issue 对象给调用方。代码里还能看到临时编号的渲染格式，#~1 这种带波浪线的假编号，跟真编号一眼能分开。

接口注释里写明了设计意图：

建议 Gatekeeper 把尚未批准的动作「模拟」出来，也就是说，会话接口应该表现得像所有动作都已经生效了一样。这样应用就能继续干活，还能接着往下排更多依赖它的动作。

cloudflare-os 仓库 · packages/workshop-shared/src/gatekeeper.ts

代价也在注释里写着，三条

一、模拟是「建议」不是「强制」。紧跟着上面那段，注释补了一句：没有严格要求 Gatekeeper 必须做模拟，哪些动作值得模拟，由写这个 Gatekeeper 的人自己拿捏。所以不同服务的体验会不一样。

二、拒绝一个已经被模拟过的动作，可能得重启整个应用。因为状态已经顺着假结果往前跑了一截，回滚不干净会把 Agent 搞糊涂。接口里专门留了个 restart 标志干这事。代码里还有一段处理连锁反应的逻辑：你要是把「建 issue」这一步拒了，所有依赖这个 issue 的后续动作会跟着一起被拒。

三、撤销是选做的。Gatekeeper 可以不实现撤销，那样系统只能提示你自己手动去撤。注释里的说法是「高质量的 Gatekeeper 应该基本都实现它」，反过来读就是，现在不一定都实现了。

用哪个模型、谁花了多少钱，都从同一个网关过

所有的推理调用统一走 Cloudflare AI Gateway。好处是有一个地方能决定哪些模型可用、哪类任务派给哪个模型。

理由很实在：不是每个任务都值得上最贵的模型。每天早上帮你总结一遍未读邮件，用不着顶配的前沿模型。CIO 那篇说得更直白，不能让员工每小时花 20 美元去总结一遍收件箱。

每一次请求都会记到具体是谁、哪个团队、哪个工作区发起的。管理员能看见钱花在哪儿、设预算和速率上限、还能规定超限之后怎么办。

仓库里内置支持的四家

另外还留着本地 ollama 的口子。代码里有条待办注释挺有意思：他们想把 Claude Fable 也加进来，但得先做一个管理员开关，因为不少公司出于零数据留存的政策不让用；后面还补了一句「拿它来搭这些小应用本来也有点大材小用」。

托管版还有一层计费设计：每个用户每天有一份免费额度，默认 100 次模型调用。用完之后，要么连上自己的 Cloudflare 账户、拿自己的 AI Gateway 余额付（余额得在 2 美元以上），要么就被挡住。自己部署的话，这一层默认是关的，不受限制。

Cloudflare 内部这三个月：最近 30 天建了 4000 多个应用，也堆出一批废的

Cloudflare OS 的第一个版本在 2026 年 5 月开放给了全体员工。到今天开源，中间跑了三个月。

省下来的时间原本花在什么上？CIO 点名的是地盘划分和方案撰写这类原来靠手工的销售工作。

先讲翻车的那一次

一开始，他们给非技术岗位的同事发的就是同一套工具，只是界面友好了一点。结果他自己总结成了这么一句：

如果你给每个人一个特别擅长写代码的工作区，你最后会得到远超需要的代码。

Sam Rhea，Cloudflare CIO

冒出来的是一大堆「找不到问题去解决」的 vibe coding 应用。这也是第二版为什么要往确定性工作流那个方向走：并非每件工作都需要一个会写代码的 Agent。

CIO 自己那个例子，把三代做法摆在一起看

他每天早上要看 IT 帮助台的工单队列和几个服务指标。

最后那个「零」要看清前提：它成立是因为看板已经被写成了代码、数据靠 Gatekeeper 直连取回、加载的时候根本不经过模型。不是「用了 Cloudflare OS 就不烧 token」，他需要 AI 的地方（比如给新工单起草回复）照样嵌在应用里，那部分照样烧。

他们怎么找出该自动化什么：让全公司把不想干的工作发到一个「魔法邮箱」

这一段跟产品本身没关系，但我觉得是这次最能直接抄走的东西。

问题是这样的：你想知道公司里哪些工作值得自动化，直接问大家「你想自动化什么」，得到的答案往往没法用。Cloudflare 的做法是换个问法，他们告诉全公司，把你不想干的工作发到这个「魔法 AI 邮箱」，它会把你要的结果发回来。

邮箱背后其实没有什么自动系统，是一小队真人拿着 AI 工具在那儿一件件干。

妙就妙在人的心理。CIO 的原话是：不知道为什么，人们不太愿意把自己的 vibe coding 点子发给一个他们以为是自动系统的东西，但特别愿意把自己不想干的工作扔过去。

几百场、然后几千场会话跑下来，他们手工分拣这些请求，慢慢看出规律：哪些请求反复出现、需要连哪些数据、大家最后要的是什么形式的产物。看清楚之后，反过来做成技能文件和上下文文件，把数据源接好，把输出格式定死。攒够了，才上平台让大家自助。

这件事他们自己形容是「很痛苦」，一直很想停掉，硬撑到素材够了为止。

动手之前该知道的：这是早期版本，Gatekeeper 还得自己写

下面这几条大多来自仓库而不是发布博客，但它们决定你现在要不要动手。

一、README 自己挂着「早期访问」的警告。这个仓库其实是第二版，是吸取第一版教训后的完全重写。原话是：非常能打，但还有很多毛边；我们知道，正在修。

二、给一个服务写 Gatekeeper 是实打实的工程量。仓库里带了 16 个，覆盖 Google、GitHub、Slack、Notion、Linear、Confluence、Supabase、Home Assistant 这些常见服务。我数了一下各自的代码行数：

也就是说，你们公司那些没有现成 Gatekeeper 的自研系统，得有人一个个写，而且看这个量级，不是一下午能搞定的事。好消息是仓库带了 MCP 和 MCP Portal 两个桥接包，已经有的 MCP 服务器可以直接接进来，只不过那样就只有 MCP 那一层的管控力度，享受不到 Gatekeeper 那套细粒度策略。

三、不收外部代码贡献。贡献指南里的理由值得一读：

AI 已经让写代码变得容易了。今天真正难的是审代码、保证质量、让产品保持连贯。这么看的话，外部的代码贡献是把这份工作里简单的那一半「捐」给我们，同时制造更多难的那一半。

cloudflare-os 仓库 · CONTRIBUTING.md

他们只收小的、能一眼验证的修复；超过十来行的会被直接关掉并附上这条规矩。有大想法可以去开个讨论帖。

四、自己拿 workerd 部署在自有服务器上，文档还标着「即将推出」。技术上跑得通，本地开发模式底下用的就是 workerd，但工具和文档还没齐，现在想这么干只能自己啃底层配置。

官方给的下一步是三件：把 Cloudflare OS 做成 Cloudflare 控制台里的托管产品、给开发工作流加上容器、把工作区接进 Slack 之类的聊天工具。

怎么试：本地一条命令，或者一键部署到自己的 Cloudflare 账户

最省事的是本地跑一遍：装好 pnpm，执行 pnpm run-local，然后打开 localhost:8787。整套东西会在你机器上跑起来，数据落在本地的 .wrangler 目录里。这个模式不是给生产环境用的，但看清楚它到底是个什么产品足够了。

想部署到自己的 Cloudflare 账户，有个在线流程：os.cloudflare.app/deploy。要是打算改得深一点，走 cloudflare-os-starter 这个示例仓库，它是照 Cloudflare 内部部署方式做的，特点是消费核心而不给核心打补丁，配置、自定义界面、内部集成、数据分析、部署管线全放在这一层，核心升级的时候不打架。

README 里给了几条试玩的提示词，照抄过来：

• 「给我明天见客户的会议做套幻灯片。」（会用到内置的幻灯片蓝图）
• 「做个协作白板应用。」（从零现造一个）
• 「做个井字棋游戏。」然后接一句「我执 X 你执 O，我下完第一步了，该你了。」
• 「给这个 GitHub 仓库做个 issue 看板。」（要先配好 GitHub 那个 Gatekeeper）
• 「把这份 Google 文档里的错别字改掉。」（要先配好 Google 那个 Gatekeeper）

不想自己折腾的话，Cloudflare 的两家战略合作伙伴 Presidio 和 Happy Cog 提供落地服务，帮着接内部系统、攒公司的上下文和技能库、配安全和成本策略。

今年 2 月，Cloudflare 一个销售同事拿 AI 攒了个「超级应用」，跑去找公司 CIO 要 API 密钥，好几把，还要十来个核心业务系统的生产环境权限。AI 碰不到大家干活用的系统就没用，要碰就得发密钥。

密钥握在中间一个叫 Gatekeeper（守门人）的小程序手里，一个服务配一个，替你拿凭据、执行策略、记录 Agent 读过什么、拦下所有对外有副作用的动作。粒度能细到给某些字段打码、规定合并代码前必须人工点头。

管住第一次读取还不够：Agent 读了数据仓库一张敏感的表、拿它做成实时看板，分享这个看板不能变成一条绕过权限、把那张表也递出去的路。Cloudflare OS 把 Agent 读过的每个资源都记下来，这份记录跟着产物一起走。

传统审批是同步的：Agent 要干真会改到外面的事，在 GitHub 建一条 issue（任务条目）、发条消息，就停下来等你点确认。你派完任务去接杯咖啡，回来发现它卡在第一步。于是大家纷纷设成全部自动批准，或者加上 --dangerously-skip-permissions 跳过确认。Gatekeeper 的解法是：动作不真做，但假装做完了。

第一版 2026 年 5 月对全体员工开放，到今天开源中间跑了三个月。下面的规模数字都是 Cloudflare 自评口径，工时那个他们自己标了「估算」，今天刚发，还没有任何第三方复现。

• README 自己挂着「早期访问」的警告。这个仓库是吸取第一版教训后完全重写的第二版，原话是「非常能打，但还有很多毛边，我们知道，正在修」。
• 你们公司没有现成 Gatekeeper 的自研系统，得有人一个个写。仓库带了 MCP（给 AI 接外部服务的通用接口标准）桥接包，已有的 MCP 服务器能直接接进来，只是那样就只有 MCP 那一层的管控力度。
• 不收外部代码贡献，理由是 AI 已经让写代码变容易，今天难的是审代码保质量；只收小的、能一眼验证的修复。整套跑在自有服务器上这条路，文档还标着「即将推出」。