2026年8月5日（美国时间），在 Cloudflare 称为“Agents Week”的发布周中，该公司同时发布了两篇关于内部平台“Cloudflare OS”的文章。第一篇是平台本身的发布公告“Cloudflare OS: an open platform for agents, apps, and work”（作者：Phillip Jones、Dan Carter），第二篇是该公司 CIO Sam Rhea 回顾内部落地历程的“How we’re rethinking work at Cloudflare with Cloudflare OS”。敝公司的网站也运行在 Cloudflare 上，而“如何把生成式 AI 交到每一位员工手中”这个问题对任何规模的组织都是共通的，因此本文基于原文将两篇文章合并梳理。

发布概要——重建内部平台并将其开源

发布的脉络如下。Cloudflare 于2026年5月向全体员工提供了第一版 Cloudflare OS，包括大量非工程岗位在内的数千人日常用它撰写文档和幻灯片、自动化重复性工作、构建数据可视化的小型应用。基于由此获得的经验教训（详见下文），公司在新的基础上重建了平台，如今将新版本作为开源软件发布。任何组织都可以把它部署到自己的 Cloudflare 账户中，接入内部系统使用。

关于 Cloudflare OS 是什么，发布公告在开头这样写道。

That’s why we created Cloudflare OS. It gives every person an agent and workspace built around their company: how it works, what it knows, and the systems it relies on.

（正因如此，我们创建了 Cloudflare OS。它为每个人提供一个围绕其公司组建的代理和工作空间——公司如何运转、知道什么、依赖哪些系统）

平台被描述为三个部件的组合。

  1. 代理工作空间：以公司积累的上下文与技能为根基，并拥有一个代理可以编写和运行代码的隔离运行时
  2. 安全与治理框架：在平台层面保障对内部数据和服务的安全访问
  3. 应用运行时：支撑个人构建、共享并可持续修改的“属于自己的”应用

设想的用法是：在浏览器里从一段对话开始，它可以变成一份文档、一个应用，或者一个在你不在时也持续运转的工作流。不要求使用者具备终端或开发工具的知识。

Cloudflare OS 工作空间的界面，展示了从浏览器对话出发、利用公司上下文和技能推进调研与文档撰写的样子

图1: 工作空间从浏览器中的对话开始，对话以公司积累的上下文和技能为根基（出处: The Cloudflare Blog）

列举的用途包括：利用公司上下文进行调研（代理编写代码来搜索、筛选、联结与分析，而不是把整个数据集灌进模型的上下文窗口）；创建文档、幻灯片和电子表格（不是静态文件——可以保持与源数据连接、随数据更新，同时仍能导出到 Google Drive 等服务）；为团队构建可协作的应用；以及运行确定性（deterministic）工作流。最后一点也是下文 v2 的关键，贯穿其中的理念是：许多工作是一串已知步骤，需要判断的地方只有一两处，可预测的部分交给代码，模型只用在能产生价值的环节。

安全——代理“一无所有”地开始

这次发布着墨最多的是访问控制。出发点是一个观察：人们在工作中开始使用 AI 时，最先提出的要求往往是公司系统的 API 密钥。密钥往往授予宽泛而长期的权限，难以收窄、难以安全共享、也难以审计——当前的通行做法是把凭证放进 MCP（Model Context Protocol）服务器、只公开工具，但 Cloudflare 认为这仍然不够。MCP 只能告诉你“代理可以调用哪些工具”，而不能告诉你“代理实际看到了哪些数据”。代理可以把多个系统的信息组合起来、发送到限制更宽松的地方，或者通过应用和产出物暴露给无权查看原始数据的人——授权必须考虑“数据接下来能去哪里”。

Cloudflare OS 的设计分三层回应这个问题。

第一，代理和应用从不持有任何访问权限的状态开始。入口由 Cloudflare Access（该公司的零信任认证）把守；在内部，代理请求访问某个特定资源，由人批准或拒绝。获批的资源以带类型的绑定（typed binding）交给生成的代码。

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

env.PROJECT 是一个能力（capability），代表“在特定策略下使用特定资源的许可”；凭证本身与代理和任何生成的代码完全隔离。服务器端代码运行在全面禁用对外网络的 Dynamic Worker 中，客户端代码运行在浏览器内沙箱化的 frame 中。除了通过明确授予的能力，二者都无法触达互联网。

第二，Gatekeeper（守门人）。这是为每个外部服务准备的 Worker，理解该服务的 API、资源和操作，立于 Cloudflare OS 与服务之间。把整个 GitHub 账户交给代理多半过于宽泛；Gatekeeper 可以只开放单个仓库、允许读取 Issue 但不允许读取源代码、遮蔽特定字段、施加速率限制、要求合并 Pull Request 前必须有人批准。它一手包办 OAuth 处理与凭证保管、读取记录，以及一切对外部产生可见副作用的操作的中介。代理一侧能看到的只是一个小小的 TypeScript API。

Gatekeeper 架构图。Gatekeeper 立于代理与外部服务之间，负责保管凭证、执行策略、记录读取

图2: Gatekeeper 作为面向每个外部服务的 Worker，一手承担凭证隔离与策略执行（出处: The Cloudflare Blog）

第三，策略跟随“代理看到过什么”。这是这次发布在设计上的核心。比如代理读取了数据仓库中的敏感表并生成了一个实时仪表盘，那么共享这个仪表盘绝不能成为把这张表分享给无权直接查看者的通道。Cloudflare OS 记录代理观测到的所有资源，这些观测记录持续附着在代理及其产出物上。当另一个人打开工作空间、与代理对话或查看其产出时，Gatekeeper 都会验证“这个人本人是否有权查看被观测过的资源”。同一份观测日志还被用于判断代理能否发起对外请求：读取过敏感数据的代理，可能被限制向特定目的地写入数据、邀请新的协作者、把工作移交给其他代理，或发起出站请求。

基于观测日志的访问验证示意图。代理看到过的资源记录附着在产出物上，查看者的权限会与该记录进行比对

图3: "谁能看什么"不是在产出物层面验证，而是对照代理观测过什么的记录来验证（出处: The Cloudflare Blog）

这些控制不需要应用作者或使用者各自实现，而是由平台代劳——“安全必须是平台的一部分，而不是每个构建应用或使用代理的人都必须正确实现的东西”，这被解释为运营 v1 得出的结论。

每个应用都是 Worker——“文件”变成属于自己的全栈应用

另一个特点是对应用的处理。传统生产力套件提供的是一组固定的应用程序——文档、电子表格、演示文稿；而在 Cloudflare OS 中，每个“文件”本身都可以是一个应用程序。代理编写客户端代码（在浏览器中渲染 UI）和服务器端代码（保存状态、实现行为）；服务器端按需作为 Dynamic Worker 加载，并实例化为 Durable Object Facet（两者都是为本项目打造的 Cloudflare 平台功能）。每个应用拥有自己专属的 SQLite 数据库，运行在轻量的 V8 隔离环境中，无需常驻的专用服务器或容器。

应用结构图：由客户端代码和服务器端代码组成，服务器端以 Dynamic Worker + Durable Object Facet 运行，拥有专属 SQLite

图4: 每个应用作为拥有客户端、服务器、API 和持久状态的全栈应用，在各自隔离的运行时中运行（出处: The Cloudflare Blog）

浏览器与服务器之间的通信使用 Cloudflare 开源的对象能力型 RPC 系统 Cap’n Web，服务器的方法可以像普通 JavaScript 函数一样调用。

const issues = await app.listIssues({
 status: "done",
});

重要的是，代理也能调用同样的方法。发布公告的表述是：如果你能为一项工作亲手打造工具，那么在你不在的时候，代理就能用你的工具完成这项工作。共享有两种方式：共享应用本身，其他人可以基于同一份状态实时协作；共享应用的设计图（blueprint），其他人可以创建属于自己的副本。从设计图实例化的应用包含原应用的代码，但不包含其 SQLite 数据、会话历史、凭证和已连接的资源——以独立的状态开始。

模型可以任选，所有推理调用都经过 Cloudflare AI Gateway。组织可以集中决定哪些模型可用、哪项工作交给哪个模型；每个请求都归属到发起它的个人、团队或工作空间，管理员因此能掌握推理开销的去向、设置预算和速率限制、决定触及上限时的行为。

CIO 讲述的落地历程——从一次 API 密钥的索取开始

第二篇文章是 CIO Sam Rhea 对内部落地过程的回顾。开篇颇具象征性：大约半年前，销售部门的一位成员来要 API 密钥——而且是复数。对方用 AI 构建了一个自称能改变整个市场团队的“SuperApp”，只需要 Cloudflare 约十来个记录系统的生产环境访问权，外加部署流水线的管理员权限。据文中所述，这正是意识到“我们有问题了”的时刻。2025年的 Cloudflare 对 AI 采取了相当谨慎的路线——部署信息型聊天应用、尝试用 AI 辅助编写样板代码——但在去年年底的短短几天里，“更好的模型和更强大的 harness 改变了这道算术题”：代理真的能干活了，数百名技术和非技术岗位的成员利用新年前后的安静时段开始了各种实验。

公司首先制定了原则。概括起来有五条。

  1. 用 AI 来增加与客户相处的时间、解决客户更多的问题（不为用 AI 而用 AI；先定义“要完成的工作”，再选择工具）
  2. 每个人都配得上超能力（不落下那些不使用开发工具的员工）
  3. 产出物的责任由人承担
  4. 组织的上下文比模型更重要
  5. 使用 AI 时，对记录系统的权限绝不能多于平时（把代理共享给别人时，对方由此获得的访问权反映的是对方本人的权限，而非共享者的权限）

关于第三条原则，原文这样写道。

We view AI as a tool and toolmaker, not a team member. We expect humans to take responsibility for defining the quality, testing, and workflows that rely on AI output.

（我们把 AI 视为工具和工具制造者，而不是团队成员。对于依赖 AI 产出的质量、测试和工作流的定义，我们要求由人来负责）

面向工程师，公司整备了一个称为“Cloudflare Engineering Codex”的上下文层。它不是罗列禁令的政策，而是指明“应该怎么做”的、刻意带有鲜明立场（opinionated）的指南，代码库的每个领域都设有责任人。把这个 Codex 嵌入开发生命周期的各个环节——代理审查每一个 Merge Request、实现开始前的技术设计、以及事故报告——之后，据该公司报告，最近4个月里这些代理标记了近25万个潜在问题，拦截了1.6万次合并，并在写下第一行代码之前就在约600份设计中发现了架构问题。

“魔法邮箱”——靠人力播下自动化的种子

面向非工程师的摸索是这篇文章最坦率的部分。最初的失误是“把工程师用的工具套上稍微友好一点的界面发给所有人”。把擅长写代码的 harness 工作空间发给每个人，得到的就是远超所需的代码——结果被形容为“一场四处寻找问题来解决的、凭感觉编出来（vibe coded）的应用洪水”。

于是公司反过来做。他们告诉全员：可以把不想做的工作发给一个“魔法 AI 邮件机器人”，它会回复你需要的成果。而幕后，是一个小团队用 AI 工具以人力应对这个邮箱。有趣的是，人们不太愿意把突发奇想的应用点子发给“以为是自动系统”的对象，却非常愿意把不想做的工作发过去——在人工处理数百乃至数千个会话的过程中，跨部门的、有真实自动化需求的例行工作模式逐渐清晰，技能文件与上下文文件、数据连接、所需产出的形态也随之齐备。原文写得很直白：“我们一心想停掉这项服务的人工运营。那是很悲惨的工作。”

魔法邮箱机制示意图：用户把不想做的工作用邮件发出，幕后由人工团队用 AI 工具应对

图5: "魔法邮箱"的幕后。看似自动化的窗口由人力运营，从中筛选出真正有需求的例行工作（出处: The Cloudflare Blog）

从 v1 到 v2——把烧 token 的工作变成代码

作为承接这些积累的平台，v1 是运行在 Cloudflare 基础设施容器中的一个简单 harness。从浏览器访问，经 Cloudflare Zero Trust 认证后即可使用，无需任何本地配置。云端的临时环境只能访问用户带入会话的数据，安全团队对环境拥有审计可见性和限制连接目的地的网络控制。数据连接经由 MCP Portal，用户会话所拥有的访问权被收窄到本人在各记录系统中的既有权限。推理经过 AI Gateway，可以复用 Secure Web Gateway 的 DLP（数据防泄漏）规则，从源头阻止特定数据集被发送给外部提供商。

Cloudflare OS v1 落地页截图

图6: 内部版 Cloudflare OS v1 的界面。仅凭浏览器即可使用，积累下来的技能文件一键执行（出处: The Cloudflare Blog）

但 v1 存在结构性的浪费：技能文件每次执行都会启动一个大量消耗 token 的推理会话。Rhea 本人的例子很具体。每天早上检查 IT 服务台工单队列的工作，在 v1 中是通过连接工单系统 MCP 服务器的技能文件来执行的——这意味着“每天早上烧掉数千 token，重新生成一份大体相同的报告”。在今天发布的 v2 中，用自然语言描述工作流，代理就会编写驱动它的代码，并支持按需、定时或由事件触发执行。同一份晨间报告如今以代码运行，初次加载的 token 消耗为零；推理只嵌入在需要判断的环节，比如为新到工单起草回复。共享做好的应用也不会跨越数据边界：对方通过同样的 Gatekeeper、以本人的权限完成认证。

工单队列仪表盘应用的界面，显示图表和工单列表

图7: 用 v2 构建的工单队列仪表盘。例行晨报由代码承担，推理只用在起草回复等需要判断的地方（出处: The Cloudflare Blog）

在推广上，公司没有新设专职 AI 团队，而是把各岗位的早期使用者组织成“冠军”（伦敦的销售负责人、得克萨斯的解决方案工程师、葡萄牙的投资者关系负责人、日本的业务拓展成员等），并以“用我们的 AI 工具把所在团队武装成全明星”为目标，把大批实习生（今年的接收目标是1,111人）嵌入各部门。公司列举的成果包括：每周数千名成员使用平台、日活跃用户在每个工作日持续增长；据估算，销售团队最近一个月在区域规划、方案撰写等原本手工的任务上节省了超过1万小时；30天内诞生了超过4,000个应用和工具。这些均为该公司自己的报告与估算，并非经第三方核实的数字。

定位与注意事项

  • 开源的范围：公开的是两个仓库——核心（cloudflare/cloudflare-os）和基于其内部运营的部署示例（starter，cloudflare/cloudflare-os-starter）。部署仓库在不修改核心的前提下承载配置、定制 UI、内部集成、分析和部署流水线；os.cloudflare.app 上还提供了演示
  • 运行前提：以部署到自己的 Cloudflare 账户为前提，Access 策略、AI Gateway 配置、数据与集成由各组织自备。Dynamic Worker 和 Durable Object Facet 这些为本项目打造的底层功能，作为 Cloudflare 的平台能力提供
  • 源代码只是起点：发布公告自己也明言，上下文、技能、工作流、内部系统和策略才是让 Cloudflare OS 发挥价值的东西。落地支持方面列出了 Presidio 和 Happy Cog 两家合作伙伴——这是开源代码与商业落地服务相结合的模式
  • 后续计划：把 Cloudflare OS 作为全托管产品整合进 Cloudflare 控制台、为开发工作流添加容器、把工作空间带入 Slack 等聊天工具，均已预告
  • 数字的解读：正文中的落地成果（25万次标记、节省1万小时等）都是该公司的自我报告。另一方面，文章连失败也一并记录——应用的洪水、人工运营邮箱的辛酸——就内部 AI 落地的实录而言，属于比较诚实的一类

小结

  • 2026年8月5日，Cloudflare 将一直向全体员工提供的 AI 代理平台 Cloudflare OS 开源，其结构为工作空间、安全与治理、应用运行时三层
  • 设计核心在于访问控制。代理从零权限开始；资源以隔离凭证的带类型绑定交付；面向每个服务的 Gatekeeper 执行策略；“代理观测过什么”被记录下来，共享产出物时，查看者本人的权限会与观测日志比对
  • 每个应用作为拥有客户端、服务器、API 和 SQLite 的全栈 Worker 隔离运行，人用的方法代理同样能调用。所有推理经过 AI Gateway，模型选择与成本由组织统一管理
  • CIO 的文章连同失败一并记录了整个历程：一次批量索取 API 密钥带来的警觉、五条原则、面向工程的 Codex 与审查代理、由人力运营的“魔法邮箱”摸清真实需求，再到从烧 token 的 v1 重建为以确定性工作流为中心的 v2
  • 公开的代码只是起点，实质在于整备各组织的上下文与技能、通过 Gatekeeper 接入内部系统。落地成果的数字均为该公司的自我报告，需留意这一点

参考资料