HN Weekly 中文
← #805

Cloudflare OS：面向 agent、应用与工作的开放平台

查看原文 HN 讨论

文章摘要

Cloudflare 在 2026 年 8 月 5 日开源了 Cloudflare OS，作者是 Phillip Jones 和 Dan Carter。它的出发点是：过去两年里，agent 已经能靠「代码要么跑得起来、要么跑不起来」这个反馈回路为开发者产出可用的代码，但组织里其余所有人并没有享受到同等杠杆。要把这份杠杆带给非工程岗位，agent 必须理解公司的上下文并且能够触达员工日常使用的系统。

Cloudflare 今年五月就给全公司每个人开通了第一版 Cloudflare OS。数千名跨职能员工（很多不在工程部门）每天用它写文档和幻灯片、把可重复的任务自动化、构建可视化数据的小应用。它同时提供了一个共享的上下文与技能库——把公司的术语、流程和处理重复工作的最佳已知方式，写成 agent 能遵循的指令；一个人琢磨出更好的做法，所有人都能直接用上。

第一版暴露的问题。 第一版围绕「个人在私有工作区里与 agent 协作」展开，应用是静态的而非连接内部系统的活软件，而且即便是确定性很强的任务，也仍然要重跑一次 agent skill、再烧一遍 token。真正根本的挑战出现在协作上：能访问某个 MCP server 只告诉了我们 agent 可以调用哪些工具，却没告诉我们 agent 实际观察到了哪些底层资源。一旦人们开始共享工作区、应用和产出，就必须保证协作不会泄露某人无权看到的信息。于是他们在新地基上重建了整个系统，核心判断是：安全必须是平台的一部分，而不是每个写应用、用 agent 的人都得自己正确实现一遍的东西。

Cloudflare OS 的三个组成部分： ① 一个以公司精选的上下文与技能为基础的 agent 工作区，附带一个 agent 可以写代码并运行代码的隔离运行时；② 一套用于安全访问内部数据与服务的新安全与治理框架；③ 一个供人构建、共享、并持续修改的个人化应用平台。一段对话可以变成一份文档、一个应用，或一条持续替你干活的工作流。

工作区面向公司里的每个人，在浏览器里使用，不需要你是开发者、也不需要会用终端。它把 agent 会话、持久状态、产出与文件、资源访问权以及隔离运行时组合在一起，并预装了团队或公司积累的上下文与技能。具体能做的事包括：做研究与提问（agent 会写代码去搜索、过滤、连接、分析信息，而不是把整个数据集塞进模型的上下文窗口）；生成文档、幻灯片和表格（这些产出不必是静态文件，可以保持与实时数据的连接、随源变化而更新，也能导出到 Google Drive 等熟悉的格式与服务）；为团队构建协作式的、连接内部资源的应用；运行确定性工作流——很多任务只是一串已知步骤加上一两个需要判断的地方，工作区可以把它们变成以代码承担可预测部分、只在真正有价值处调用模型的准确定性工作流，支持按需、定时或由外部系统事件触发。

安全模型是这次的重头戏。 文章指出，员工开始在工作中尝试 AI 时最先提的要求往往是「给我公司系统的 API key」——这可以理解，但分发 API key 既危险又无法规模化：密钥往往权限过宽、生命周期过长、难以约束、难以安全共享、难以审计。MCP 提供了一条更好的路（由 MCP server 持有凭据、只暴露一组定义好的工具），但控制 agent 能调用哪些工具只是第一步：MCP 并不告诉你 agent 观察到了哪些底层资源；agent 可以跨系统组合信息、把它送到限制更少的地方，或者通过应用和产出暴露给无权查看原始资源的人。授权必须考虑数据接下来会流向哪里。

于是他们的设计是：agent 从零权限开始。Cloudflare Access 控制谁能进入 Cloudflare OS；进入之后，每个 agent 和应用对任何东西都没有访问权。agent 可以申请访问某个具体资源，由你批准或拒绝。生成的代码以带类型的 binding 形式拿到该资源（例如 env.PROJECT 就是一个代表「在特定策略下使用特定资源」的能力，凭据对 agent 和生成代码完全隔离）。服务端代码跑在关闭了全局出站网络的 Dynamic Worker 里，客户端代码跑在浏览器的沙箱 frame 里，两者除了你显式提供的能力之外都无法触达互联网。

Gatekeeper 是介于 Cloudflare OS 与外部服务之间、针对具体服务的 Worker。它理解该服务的 API、资源和可执行操作。把整个 GitHub 账号给 agent 显然太宽，而 Gatekeeper 可以只给它一个仓库、允许读 issue 但不能读源码、屏蔽特定字段、施加速率限制、并在合并 PR 前要求审批。agent 和它的应用看到的只是一小段 TypeScript API，Gatekeeper 负责 OAuth、持有凭据、执行策略、记录读取了什么、并居中处理一切有外部可见副作用的动作。

最关键的一环是策略跟随 agent 已经看到的东西：只控制首次读取是不够的。假设 agent 读了数据仓库里的敏感表并据此生成了一个实时仪表盘，那么分享这个仪表盘就不能变成把原表分享出去的途径。Cloudflare OS 记录 agent 观察到的每一个资源，这些观察记录会附着在 agent 及其产物上；当另一个人试图打开该工作区、与 agent 交互或查看其产出时，Gatekeeper 会验证此人对这些被观察资源的访问权。同一份观察日志也用于决定 agent 何时可以发起外部请求——一次对敏感数据的读取，可以阻止 agent 之后向某些目标写入数据、邀请新协作者、把工作移交给另一个 agent，或发出出站请求。

应用平台：每个「文件」都是一个应用。 大多数生产力套件给你一组固定应用（文档、表格、演示），而在 Cloudflare OS 里，每个「文件」都可以是它自己的应用，由 agent 为某一个人、某一个项目或某一个团队而写。这些不是需要导出再部署到别处的原型，而是带客户端代码、服务端代码、API 和持久状态的全栈应用，默认私有，但可以像文档一样分享。服务端按需以 Dynamic Worker 载入，并实例化为 Durable Object Facet（两者都是为这个项目新建的能力），facet 给应用自己的 SQLite 数据库，与管理它的 Cloudflare OS 运行时分开；Dynamic Workers 用轻量 V8 isolate，所以每个应用都能有自己的隔离运行时，而不需要常驻的服务器或容器。浏览器客户端通过 Cap’n Web（Cloudflare 开源的对象能力 RPC 系统）与服务端通信，服务端方法可以像普通 JavaScript 函数一样从客户端调用——而特别之处在于 agent 也能调用同一个方法：如果你能造一个工具替自己干活，那么当你不在时 agent 也能用你的工具干这活。

共享有两种方式：分享应用本身，让别人以同一份状态实时协作；分享应用的蓝图（blueprint），让别人创建自己的副本——副本包含原应用的代码，但不含它的 SQLite 数据、对话历史、凭据或已连接资源，每个新应用从独立的状态和资源开始。这意味着你把应用分享给团队后，他们可以自己用 AI 修改它，而不是给你提一个需求单。

模型与成本： Cloudflare OS 可搭配任意模型，所有推理调用都经过 Cloudflare AI Gateway，让组织有一个统一位置来决定哪些模型可用、哪个任务该用哪个模型（「你大概不想每天早上用最贵的前沿模型来总结未读邮件」）。每个请求都归因到发起的人、团队或工作区，管理员可以看到推理开销的去向、设定预算与限速、并决定触及上限时如何处理。

开源与合作伙伴： 项目已在 GitHub 上开源，可以部署到自己的 Cloudflare 账号，使用自己的 Access 策略、AI Gateway 配置、数据与集成。他们释出了两个仓库：Cloudflare OS 核心，以及一个基于内部实际用法的示例部署——部署仓库不打补丁地消费核心，专门用来放配置、定制 UI、内部集成、分析与部署流水线。Cloudflare 的战略合作伙伴 Presidio 和 Happy Cog 会帮客户围绕自身运作方式做定制与全员推广。后续路线包括把 Cloudflare OS 做成 Cloudflare 控制台里的全托管产品、为开发工作流加入容器支持，以及把工作区带进 Slack 等聊天工具。

HN 评论精华

这条帖子拿到 665 分、328 条评论。讨论几乎被两条主线占满：对「OS」这个命名的集体反感，以及 Cloudflare Workers 团队负责人 Kenton Varda 亲自下场解释这其实是 Sandstorm 的十年后重制。后者极大改变了整条讨论的走向。