8 月 5 日，Cloudflare 在 Agents Week 期间正式开源了 Cloudflare OS，一个已在内部运行数月、被数千名员工（含大量非工程岗位）日常使用的 Agent 平台。平台采用 Apache 2.0 许可，通过 Gadget 沙箱运行应用，由 Gatekeeper 管理外部资源权限。它尝试让用户用 AI 修改自己的应用实例，探索集中式 SaaS 之外的一种软件使用方式。
延续 Sandstorm 的独立应用实例设计，用 AI 降低修改门槛
要理解 Cloudflare OS 为什么不同，需要追溯到 2014 年的 Sandstorm.io。那是 Kenton Varda（Protocol Buffers 和 Cap'n Proto 的作者）创办的一家创业公司，核心主张是：每个用户应该运行自己应用的独立实例，平台负责隔离和权限，而不是让应用开发者自己实现安全。
Sandstorm 未能实现预期的商业规模，当时能够自行修改软件的用户仍然有限。Varda 后来加入 Cloudflare，花了 9 年时间领导 Workers 团队，构建了一个全球分布的 serverless 运行时。现在他带着 Workers 重新实现了 Sandstorm 的核心理念。他在 X 上写道：「这是我秘密十年计划的顶点。这是一个完整的个人应用 vibe coding 平台，沙箱安全到你几乎可以任意发挥——AI 不可能引入重大安全漏洞。」
Cloudflare OS 的核心抽象是 Gadget——每个文档、应用、工作流都是一个独立的沙箱实例。如果你创建一个幻灯片，系统不会调用某个中心的 SaaS 服务；它会在 Dynamic Worker 中启动一个只属于你的幻灯片应用实例。这个实例完全隔离，无法访问互联网，不能与其他 Gadget 通信，除非你显式引入资源。
这样的隔离旨在减少一个应用出错后影响其他应用或资源的机会，实际安全仍依赖沙箱实现与授权配置。用户也可以用 AI 修改自己 Gadget 的代码，无需等待统一产品加入某项功能。相比共用同一套应用代码的 SaaS，这给个人或团队留下了更多定制空间。
GitHub README 中有一张技术映射表解释了「OS」这个命名的技术依据：workshop-backend 对应内核，Gatekeeper 对应设备驱动，Gadget 对应进程，Blueprint 对应可执行程序。Varda 特别指出传统 OS 缺少对 AI agent 的原生支持——agent 既不是普通用户（权限太大），也不是纯粹的程序（需要受限执行），能力安全模型可能才是正确答案。
Gatekeeper 隔离凭据、限定资源，并控制外部操作与分享
企业部署 Agent 时，需要同时解决模型能力和资源权限问题。直接交出 API 密钥，可能让 Agent 获得过宽且难以审计的访问权。MCP 协议通过让 server 持有凭证、暴露受限工具集缓解了第一步，但 Cloudflare CIO Sam Rhea 发现了一个更深层的问题：MCP 告诉你 agent 能调用哪些工具，但不知道它观察了哪些具体资源。Agent 可以跨系统组合信息、写入权限较弱的目标、或通过共享输出将敏感数据暴露给无权查看的人。
Cloudflare OS 的 Gatekeeper 机制从三个层面应对：
默认零权限。 每个 agent 和 Gadget 启动时无法访问任何外部资源。需要资源时必须请求引入，用户授予或拒绝。授予后，生成的代码以类型化 binding 形式获取资源引用——env.PROJECT.listIssues()——凭据本身对 agent 完全不可见。Server 端代码运行在禁用全网访问的 Dynamic Worker 中，Client 端代码运行在沙箱 iframe 中，受 Content-Security-Policy 和 iframe sandbox 双重限制。
窄化访问。 Gatekeeper 不暴露整个 API，只暴露被授权访问的特定资源。GitHub 的 Gatekeeper 可以限制到单个 repo 的特定 issue，Google 的 Gatekeeper 可以限制到单个文档。Gatekeeper 记录所有操作，对副作用操作要求人工审批。
追踪读取与分享。 平台还记录 Agent 读过的资源，并据此检查后续分享和外部操作。例如，一个 Agent 读取了敏感数据后生成仪表盘，其他人查看仪表盘时仍需拥有原始资源的访问权。这使审批和访问检查延伸到输出结果，减少信息经新应用或共享文件转到权限较低位置的机会。
先人工整理重复任务，再推广员工自助创建应用
CIO Sam Rhea 推广 Cloudflare OS 的过程本身就是一个值得记录的组织实验。最初团队给非工程人员提供与工程师相同的 AI 工具——结果是产生了不少「先做出应用，再寻找用途」的项目。
随后，团队换了一种收集需求的方式：Cloudflare 告诉所有员工可以把不想做的工作发给一个「魔法 AI 邮件机器人」。背后其实是一个小团队手动操作 AI 工具。人们不太愿意把一时兴起的想法发给自动化系统，但非常愿意把讨厌的重复工作丢过去。通过数千次人工协助的任务会话，团队识别出了各职能的常见任务模式，积累了上下文文件和技能，然后才把这些能力交还给用户自助完成。
截至目前的数据（来自 Cloudflare 自身，未经第三方审计）：每日活跃用户每工作日持续增长，从未下降。过去一个月，销售团队节省了超过 10,000 小时——主要用于区域规划和提案创建。用户创建了超过 4,000 个应用和工具。工程团队使用 Codex Agent 审查所有合并请求（MR），在过去 4 个月标记了近 25 万潜在问题，阻止了 1.6 万次合并，在设计阶段捕获了约 600 个架构问题。
Cloudflare 将应用创建与资源治理接到现有云基础设施
Cloudflare OS 更强调创建和修改应用，可以与操作现有软件的 Agent 形成对照。
Operator 和 Computer Use 本质上是「让 AI 替你操作现有软件」——打开浏览器、点击按钮、填写表单。它们依赖模型对屏幕和操作步骤的判断，具体运行环境由产品或开发者配置。Operator 已整合进 ChatGPT 的 Agent 功能，面向消费者完成网上任务；Computer Use 向开发者提供桌面操作能力，复杂跨应用流程的可靠性仍需按具体任务测试。
Cloudflare OS 走的是相反方向：「让 AI 为你创建和修改软件本身」。用户不是让 agent 去操作 Google Docs，而是在自己的沙箱中获得替代品——agent 可以随时修改代码、增加功能，平台负责提供隔离和权限控制。用户既可以共享同一个应用协作，也可以分发 Blueprint（代码模板），让接收者创建拥有独立状态和资源的副本。
这两种路线指向一个更深的问题：Agent 时代，软件的「主人」是谁？是 SaaS 厂商、AI Lab 还是最终用户？过去 25 年，SaaS 用规模经济说服所有人接受「你只是租用软件」；AI 正在改写这个公式，因为生成和修改应用代码的门槛正在降低。Cloudflare 作为基础设施公司切入这个市场的逻辑也由此成立：它不需要做出最好的模型，而是提供 Agent 运行所需的基础设施层——计算隔离、网络控制、身份认证、数据治理。这些恰好是 Cloudflare 现有产品矩阵（Workers、Durable Objects、Access、AI Gateway、Zero Trust）的有机延伸。
平台仍在早期，企业需要补齐服务接入和组织配置
Cloudflare OS 目前是明确的「early access」状态。GitHub README 坦率写道 v2 仍有不少功能和体验需要完善。项目当前不接受外部代码贡献——AI 让写代码变得简单，但代码审查、质量维护和产品一致性反而是瓶颈。
几个实质性的不确定因素：平台深度绑定 Cloudflare Workers 生态，虽然 workerd 开源理论上允许自托管，但官方工具链尚未准备好。Gatekeeper 需要为每个外部服务单独开发，目前覆盖约 10 个，企业内部通常需要连接数十上百个系统。另一项待验证的问题是：Cloudflare 内部的使用数据来自技术员工比例极高的公司；在更传统的组织中，非技术人员能否真正用 AI 创建和修改软件，是最关键的未验证假设。
这些约束会影响平台进入不同组织的速度。距离 Sandstorm 提出类似理念已十多年，AI 让修改软件更容易了，但应用维护、资源授权和员工培训仍需有人负责。Cloudflare OS 能否扩大采用范围，要看这些整合成本和日常收益是否匹配。
