过去两年，AI 智能体在写代码这件事上进展飞快，原因说穿了很朴素：代码要么跑得通，要么跑不通，反馈闭环天然存在。但公司里绝大多数岗位不写代码，做的是文档、幻灯片、流程、关系和线下结果，这些工作缺少同样清晰的判定标准。
Cloudflare 给出的答案叫 Cloudflare OS。8 月 5 日，这家公司宣布把它开源，任何组织都可以自行部署、接入内部系统并按需改造。
先在自家跑了三个月
今年 5 月，Cloudflare 向全体员工开放了第一个版本。据其官方博客描述，各职能部门数千人每天使用，其中很多人并非工程师——他们用它撰写文档和幻灯片、把重复性任务自动化、搭建小型应用来可视化数据。
更关键的是共享层。Cloudflare OS 为所有人提供了一个由各团队共建的上下文与技能库，把公司的术语、流程和处理常规工作的最佳做法，沉淀成智能体可以直接遵循的指令。一个人摸索出更好的做法，其他人立刻就能复用。
第一版也暴露了问题。它以个人私有工作区为中心，生成的应用是静态的，而非连接内部系统的活体软件；即便是几乎完全确定的重复任务，也得重新跑一遍智能体技能，白白消耗模型 token（模型处理文本的计费单位）。
协作环节的问题更根本。接入 MCP 服务（模型上下文协议，用于让智能体调用外部工具）只能告诉系统智能体可以调用哪些工具，却无法说明它实际读取过哪些底层资源。一旦开始共享工作区、应用和产出，就必须确保协作不会让人看到本不该看到的信息。
于是 Cloudflare 把整套系统在新底座上重建了一遍，核心判断是：安全必须是平台自带的能力，而不是每个搭应用、用智能体的人各自去正确实现一遍。
三个组成部分
新版 Cloudflare OS 由三块拼成：一个以公司自建上下文与技能为基础的智能体工作区，内置可让智能体编写并运行代码的隔离运行时；一套面向内部数据与服务的安全治理框架；以及一个支持个人搭建、共享并持续修改应用的平台。
工作区在浏览器里使用，不需要懂终端。它能做四类事：调用公司上下文与已授权资源做研究，且智能体是通过写代码去搜索、筛选、连接和分析信息，而不是把整个数据集塞进模型的上下文窗口；把研究结果转成可继续编辑的文档、演示或表格，这些产出可以与实时数据保持连接、随数据源更新，也能导出为常见格式；在文档表格不够用时，直接构建带界面、逻辑和状态的应用，供多人协同；以及把已知步骤的重复工作转成基本确定性的流程，用代码处理可预测部分，只在真正需要判断的环节调用模型，流程可按需触发、定时执行或由连接系统的事件驱动。
安全设计：智能体的默认权限是零
员工接触 AI 后最常提的诉求，往往是索要公司系统的 API 密钥。Cloudflare 的判断很明确：把密钥直接交给人和智能体既危险也无法规模化，密钥通常权限宽泛、有效期长，难以约束、难以安全共享、难以审计。
Cloudflare OS 的做法分三层。
默认无权限。 由 Cloudflare Access 控制谁能进入系统，进来之后每个智能体和应用的初始权限是零。智能体可以申请访问某个具体资源，由人决定批准或拒绝，生成的代码以类型化绑定的形式拿到该资源，凭据始终与智能体和代码完全隔离。服务端代码运行在关闭了全局出站网络的 Dynamic Worker 中，客户端代码运行在浏览器的沙箱框架内，两者除了显式授予的能力之外都无法访问互联网。
Gatekeeper 管资源和动作。 这是一个针对特定服务的 Worker，夹在 Cloudflare OS 与外部服务之间，理解该服务的接口、资源和可执行操作。官方举的例子是：把整个 GitHub 账号交给智能体范围太大，而 Gatekeeper 可以只开放单个仓库、只允许读取议题而不能读源码、屏蔽特定字段、施加速率限制，并要求合并请求前必须经人工审批。智能体看到的只是一个小巧的 TypeScript 接口，OAuth 授权、凭据保管、策略执行、读取记录和外部副作用的中介，全部由 Gatekeeper 承担。
策略跟着智能体看过的东西走。 只管住第一次读取是不够的。官方设想了这样一种场景：智能体读取数据仓库中一张敏感表，据此生成实时看板，分享看板不能变成把这张表分享给无权访问的人。为此，Cloudflare OS 记录智能体观察到的每一项资源，这些记录始终附着在智能体及其产出上。当另一个人试图打开工作区、与智能体交互或查看产出时，Gatekeeper 会核验此人对那些被观察资源的访问权限。同一套观察日志还用于判定智能体何时可以发起外部请求——读取过敏感数据，可能就会禁止它向特定目标写入、邀请新协作者、把工作移交给另一个智能体或发起外部请求。
每一个“文件”都是一个完整应用
多数生产力套件给的是固定几件套：文档、表格、演示。Cloudflare OS 的思路不同——每个“文件”都可以是一个应用，由智能体为某个人、某个项目或某个团队专门编写。
这些不是需要导出再另行部署的原型，而是自带客户端代码、服务端代码、接口和持久状态的全栈应用，默认私有，可像文档一样共享。智能体写应用时产出两部分：渲染界面的客户端代码，以及存储状态、实现逻辑的服务端代码。服务端以 Dynamic Worker 按需加载，并实例化为 Durable Object Facet（这两项能力都是为该项目专门构建的）。Facet 给每个应用一个独立的 SQLite 数据库，与管理它的运行时相互分离；Dynamic Workers 使用轻量级 V8 隔离环境，因此每个应用都能拥有独立运行时，而不必长期占用一台服务器或容器。
浏览器客户端通过 Cap’n Web 与服务端通信，这是 Cloudflare 开源的对象能力式远程过程调用系统。服务端方法可以像普通 JavaScript 函数一样从客户端调用——特别之处在于，智能体也能调用同一个方法。用官方博客的说法，只要一个人能造出工具来完成某项工作，那么在这个人不在的时候，智能体也能用同一件工具把活干完。
共享方式有两种：共享应用本身，其他人可基于同一份状态实时协作；共享应用的“蓝图”，其他人可创建属于自己的副本。从蓝图创建的应用包含原应用的代码，但不包含其 SQLite 数据、对话历史、凭据和已连接资源，每个新应用都从独立的状态和资源开始。这意味着团队成员可以自己用 AI 修改应用，而不必提工单等着原作者排期。
模型可换，花销可控
Cloudflare OS 支持任意模型，所有推理调用都经由 Cloudflare AI Gateway，组织可在同一处决定哪些模型可用、哪项工作交给哪个模型。官方给出的理由很实际：不是每项任务都需要最贵的模型——每天早上总结未读邮件，未必值得动用最昂贵的前沿模型。
每一次请求都会归属到发起它的人、团队或工作区。管理员可以看到推理支出流向，设定预算与速率限制，并决定触及上限后如何处理。
开源之后
代码已在 GitHub 的 cloudflare-os 仓库放出，可部署到自有 Cloudflare 账号，配合自家的 Access 策略、AI Gateway 配置、数据与集成。Cloudflare 一共发布两个仓库：Cloudflare OS 核心，以及一个基于其内部运行方式的示例部署；部署仓库不修改核心即可使用，用于承载配置、自定义界面、内部集成、分析和部署流水线。
值得一提的是，该项目在 GitHub 上把自己类比为一套真正的操作系统：workshop-backend 相当于内核，各类 Gatekeeper 相当于设备驱动，workshop-frontend 相当于 shell，Gadget 相当于进程，蓝图相当于可执行文件。而传统操作系统尚未管理的那一类对象，正是 AI 智能体——Cloudflare 的观点是，智能体不能简单当成用户对待，它必须对某个人类用户负责，同时拥有自己受限的权限，这种场景下更合适的安全模型是基于能力的安全，而非访问控制列表。
由于 Cloudflare Workers 的运行时 workerd 本身也是开源的，Cloudflare OS 并不局限于只能跑在 Cloudflare 上，完全可以架在自有服务器的 workerd 之上。
代码只是起点。Cloudflare 表示，其战略伙伴 Presidio 和 Happy Cog 会协助企业按自身运作方式定制并推广。后续规划包括：把 Cloudflare OS 做成 Cloudflare 控制台中的全托管产品、为开发流程增加容器支持，以及把工作区接入 Slack 等聊天工具。
来源：The Cloudflare Blog
