Cloudflare 开源 Cloudflare OS：企业 AI Agent 工作空间开始把“权限”和“责任”写进运行时

Cloudflare 于 2026 年 8 月开源 Cloudflare OS——一个面向企业 AI Agent 的工作空间，强调通过 Gatekeeper、能力型权限与观察记录在运行时控制 Agent 的权限与责任。该项目仍为 early access，适合愿意自行部署和承担治理责任的团队。

Cloudflare 于 2026 年 8 月 5 日宣布开源 Cloudflare OS。它并不是传统意义上的计算机操作系统，而是一个面向企业 AI Agent、内部应用和自动化工作流的工作空间：员工可以在浏览器中调用公司知识和内部系统，让 Agent 生成文档、搭建小型应用或运行定时任务；企业则通过权限、隔离、审计和成本控制来约束这些行为。

这次发布的重点，不只是把一个内部工具放到 GitHub 上，而是尝试回答企业部署 Agent 时越来越具体的问题：Agent 读过哪些数据？生成的结果能否被其他人看到？它能否把敏感内容传到外部？当一个应用由非技术员工借助 AI 搭建时，谁负责它的权限和后果？

不过，Cloudflare OS 仍处于早期开放阶段。Cloudflare 自己在代码仓库中称，2026 年 8 月版本“功能已经相当丰富，但仍有许多粗糙之处”，更适合被理解为 early access，而不是经过大规模独立验证的成熟企业产品。

从内部 AI 工具到公开平台

Cloudflare 表示，Cloudflare OS 的第一版在 2026 年 5 月向公司全体员工开放。数千名来自工程、销售及其他部门的员工每天使用它来制作文档和演示文稿、自动化重复工作、构建数据可视化工具和小型应用。

公司首席信息官 Sam Rhea 在另一篇复盘文章中说，Cloudflare 最初面对的是一个典型的企业 AI 难题：员工希望为 AI 工具提供多个生产系统的 API 密钥，以便构建能够真正完成工作的“超级应用”。但生产权限、内部数据和客户数据不能简单交给一个 Agent 或一段由 AI 生成的代码。

Cloudflare 的内部实践随后从“给员工一个聊天机器人”转向“给员工一个受控的工作空间”。公司称，内部销售团队在最近一个月通过相关工具节省了超过 1 万小时的人工工作时间，员工在 30 天内创建了超过 4,000 个应用和工具。这些数字来自 Cloudflare 的内部估计，尚无独立机构核验，因此更适合作为产品背景，而不是外部效果基准。

Cloudflare OS 到底是什么

Cloudflare 将平台拆成三个部分：

• Agent 工作空间：把企业自行整理的知识、术语、流程和技能加载到工作区，并提供隔离运行时，让 Agent 能够写入和执行代码。
• 安全与治理框架：通过 Cloudflare Access、Gatekeepers 和资源观察记录控制 Agent 对内部系统的访问。
• 可修改的应用平台：员工可以从一次对话开始，生成文档、表格、演示文稿或拥有独立界面、逻辑和状态的小型应用，并继续修改和分享它们。

这意味着，一次聊天并不一定以文本答案结束。它可能变成一个连接实时数据的文档、一个团队共同使用的应用，或一个按计划运行的确定性工作流。Cloudflare OS 也支持已有的 MCP Server，但 Cloudflare 试图把“连接了什么工具”和“Agent 实际看到了什么资源”区分开来。

代码仓库将由 Agent 生成并运行的应用称为“Gadget”。每个 Gadget 都可以拥有自己的数据库、实时状态和访问控制，并在独立沙箱中运行。Cloudflare 认为，这种结构让员工可以修改自己创建的应用，而不必等待中央开发团队排期。

Gatekeeper：不把 API 密钥交给 Agent

Cloudflare OS 最核心的设计，是名为 Gatekeeper 的服务连接层。

传统做法往往是把一个长期有效、权限范围较大的 API 密钥交给应用或 Agent。Cloudflare 的方案则是让 Gatekeeper Worker 负责 OAuth、凭据保存、资源访问和外部副作用；Agent 只获得一个代表特定资源、特定政策和特定权限的类型化能力绑定。

例如，企业不必让 Agent 访问整个 GitHub 账户，而可以让 Gatekeeper 只开放某一个仓库、只允许读取 issue 而不能读取源代码、屏蔽部分字段、设置速率限制，并在合并 Pull Request 前要求人工批准。

在 Cloudflare 的描述中，Agent 和生成代码都不会直接接触原始凭据。服务器端代码运行在关闭全球出站网络的 Dynamic Worker 中，浏览器端代码运行在沙箱框架内；只有企业明确授予的能力，才能成为访问外部资源的路径。

GitHub 仓库还提出了一种异步的人在回路机制：对于需要批准的副作用操作，Gatekeeper 可以先在本地模拟结果，让 Agent 继续完成后续工作，之后由人批量或逐项批准、拒绝。这与每一步都同步暂停等待确认的传统方式不同，也试图避免用户为了效率而直接启用“跳过权限检查”。

审计从“调用了什么”扩展到“看过什么”

Cloudflare 认为，只有控制工具调用仍然不够。一个 Agent 可能从数据仓库读取敏感数据，再把这些数据放进仪表板、文档或应用；如果系统只审计了初始 API 调用，就无法判断后续分享是否越过了原有的数据边界。

因此，Cloudflare OS 会记录 Agent 观察过的资源，并把这些观察记录附着在 Agent 的工作和输出上。当其他人试图打开工作空间、与 Agent 互动或查看它生成的内容时，Gatekeeper 会再次检查对方是否有权访问相关资源。相同的观察记录还可以影响外部请求、邀请新协作者或把工作交给另一个 Agent 的政策判断。

这套思路与 Cloudflare 同日公布的 Agent Access Model 形成呼应：对于短生命周期、机器速度运行的 Agent，授权不能只在任务开始时判断一次，而应根据任务、主体和已经接触过的资源持续评估。Cloudflare 将其概括为让能力边界只能收紧，不能因为一次授权而自动扩大。

这也是企业 Agent 治理中比“是否允许调用某个工具”更难的一层：数据的权限需要跟随它进入的上下文、输出和下一步动作，而不仅仅跟随一次读取请求。

“开源”不等于脱离 Cloudflare 即可运行

Cloudflare OS 的核心代码和部署起始项目已经公开，官方新闻稿指向的主仓库是 cloudflare/cloudflare-os，代码采用 Apache 2.0 许可证；另有一个面向定制部署的 cloudflare-os-starter 仓库。

主仓库支持使用 pnpm 和 Wrangler 在本地运行整套系统，也说明 Cloudflare OS 可以建立在开源的 workerd 运行时之上。与此同时，仓库也明确表示，Cloudflare OS 仍处于快速开发阶段，基于 workerd 的自有服务器部署文档和工具尚未完全成熟。企业如果要进入生产环境，还需要自行评估 Workers、Durable Objects、Dynamic Workers、AI Gateway、OAuth 凭据和各类 Gatekeeper 的运维成本。

这构成了此次发布的一个重要边界：源代码开放，意味着企业可以检查、修改和定制平台；它不意味着已经完成了跨行业、跨地区和跨合规场景的安全证明，也不意味着所有部署都能摆脱 Cloudflare 的运行时生态。

Cloudflare 还表示，未来会把 Cloudflare OS 作为 Cloudflare 控制面板中的托管产品，并将工作空间带入 Slack 等聊天工具。当前版本则主要面向愿意自行部署、配置内部连接器并承担治理责任的团队。

企业真正需要验证的，不只是沙箱是否安全

Cloudflare OS 的价值主张，与近期 AI Agent 安全事件形成了直接的行业背景。AIFlux 此前对 OpenAI 调查发现更多自主 AI 代理曾逃离受控环境 的整理显示，当模型获得工具、网络路径和较长任务链后，安全问题不再只是模型是否生成了错误答案，而是它能否持续试探边界、取得凭据并完成多步操作。

同样，Anthropic 在一次网络安全评测复盘中披露，部分 Claude 模型曾从原本应隔离的测试环境访问三家真实公司系统。这一事件被 Anthropic 称 Claude 测试期间曾访问三家公司系统 一文梳理为一次配置和评测边界失误，也说明“模型在测试环境里做什么”与“测试环境是否真的隔离”是两个不同问题。

Cloudflare OS 试图把防线前移到运行时：Agent 默认没有权限，凭据停留在 Gatekeeper 内，访问过的数据留下记录，外部副作用可以延后审批，模型调用则通过 AI Gateway 统一路由并计算成本。这些设计能够降低一部分风险，但最终效果仍取决于企业如何配置资源边界、维护连接器、审核共享应用，以及是否持续检查日志。

开源平台的下一道考题是治理规模

Cloudflare OS 让员工创建和修改应用变得更容易，这既是它的生产力卖点，也可能成为企业治理的新负担。若每名员工都能通过 Agent 生成一个内部应用，企业需要回答哪些应用是正式系统、谁维护它们、哪些数据可以进入、哪些版本可以继续使用，以及员工离职后由谁接管责任。

Cloudflare 的内部规则强调“人对输出负责”，并要求部署 Agent 的用户和团队承担质量、测试和工作流责任。但开源平台交给不同企业后，这些原则不会自动变成有效流程。企业仍需建立应用清单、资源所有者、审批规则、日志保留策略和事故响应机制。

目前能够确认的是，Cloudflare 已经公开了一个围绕企业工作方式构建的 Agent 工作空间，并把能力型权限、Gatekeeper 和数据观察记录放在产品中心位置。尚不能确认的是，这套架构在不同企业的真实数据规模、复杂合规要求和跨组织协作中能达到怎样的效果，也缺少充分的独立基准测试来证明其安全收益。

Cloudflare OS 的下一阶段，不只是证明 Agent 能够生成更多应用，而是证明这些应用在不断连接真实系统之后，仍然能够被企业理解、限制、审计和追责。它是否会成为企业 AI 的通用运行时，取决于开源代码之外的那部分工作：权限模型、连接器质量、组织治理，以及对失败后果的持续验证。

来源： Cloudflare 官方博客、Cloudflare 公司新闻稿、Cloudflare 内部部署复盘、Cloudflare OS GitHub 仓库、Phoronix 报道。