8 月 5 日，Cloudflare 在 Agents Week 期间正式开源了 Cloudflare OS，一个已在内部运行数月、被数千名员工（含大量非工程岗位）日常使用的 Agent 平台。Apache 2.0 许可、完整的 Gadget 沙箱架构、基于能力安全的 Gatekeeper 机制——这些技术标签背后，是一个比「又一个带 connector 的 chatbot」大得多的问题：当 AI 让每个人都能修改软件时，过去 25 年的 SaaS 多租户架构还成立吗？
这不是又一个 chatbot——这是 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 通信，除非你显式引入资源。
这意味着两件事：第一，Gadget 自身不可能有安全漏洞泄露数据——即使攻击者获得了另一个 Gadget 的访问权限，也无法跨越沙箱；第二，用户可以用 AI 自由修改自己 Gadget 的代码，无需向任何人提交 feature request。这在集中的 SaaS 多租户模型中是不可能的——你不拥有软件的副本，就无法修改它。
GitHub README 中有一张技术映射表解释了「OS」这个命名的技术依据：workshop-backend 是 kernel，Gatekeeper 是 device driver，Gadget 是 process，Blueprint 是 executable。Varda 特别指出传统 OS 缺少对 AI agent 的原生支持——agent 既不是普通用户（权限太大），也不是纯粹的程序（需要受限执行），能力安全模型可能才是正确答案。
Gatekeeper：异步模拟执行替代危险的 skip-permissions
企业内部部署 Agent 的第一个障碍不是模型能力，而是权限。「给 agent API 密钥」这个请求几乎会在任何组织中触发安全团队的红色警报。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 记录所有操作，对副作用操作要求人工审批。
异步审批。 这是 Gatekeeper 最巧妙的创新。传统 human-in-the-loop 要求 agent 在每次需要审批时停下来等用户——结果是用户走开喝杯咖啡回来，发现 agent 第一步就卡住了。Gatekeeper 的解决方案是：当 agent 请求副作用操作时，本地模拟执行结果，让 agent 继续推进并排队后续操作；用户可以在方便时批量审批。这消除了「为了效率关闭安全检查」的激励——而这正是大多数 agent 框架 --dangerously-skip-permissions 模式的来源。
内部验证：从魔法邮件到 4000 个自建应用
CIO Sam Rhea 推广 Cloudflare OS 的过程本身就是一个值得记录的组织实验。最初团队给非工程人员提供与工程师相同的 AI 工具——结果是一堆「vibe coded apps looking for a problem to solve」。
转折点是一个反直觉的举措：Cloudflare 告诉所有员工可以把不想做的工作发给一个「魔法 AI 邮件机器人」。背后其实是一个小团队手动操作 AI 工具。人们不太愿意把一时兴起的想法发给自动化系统，但非常愿意把讨厌的重复工作丢过去。通过数千次手动 session，团队识别出了各职能的常见任务模式，积累了上下文文件和技能，然后才把这些能力交还给用户自助完成。
截至目前的数据（来自 Cloudflare 自身，未经第三方审计）：每日活跃用户每工作日持续增长，从未下降。过去一个月，销售团队节省了超过 10,000 小时——主要用于区域规划和提案创建。用户创建了超过 4,000 个应用和工具。工程团队通过 Codex agent review 所有 MR，在过去 4 个月标记了近 25 万潜在问题，阻止了 1.6 万次合并，在设计阶段捕获了约 600 个架构问题。
竞争逻辑：基础设施公司为何在定义 Agent 平台
Cloudflare OS 与 OpenAI Operator、Anthropic Computer Use 的差异不是功能多少，而是根本的架构哲学分歧。
Operator 和 Computer Use 本质上是「让 AI 替你操作现有软件」——打开浏览器、点击按钮、填写表单。它们依赖 AI Lab 的模型能力突破，运行在 AI 公司的云基础设施上。Operator 已整合进 ChatGPT Pro，面向消费者完成网上任务；Computer Use 仍是开发者 API，能控制完整桌面但跨应用工作流成功率约 50%。
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 创建和修改软件，是最关键的未验证假设。
这些都不否定核心论题——AI 时代的软件架构可能需要根本性重思——但它们会影响愿景落地的速度和范围。Varda 等了 10 年才等来 Sandstorm 的时机；Cloudflare OS 能否说服足够多的组织押注这种新架构，2026 年还不会有答案。