TopsTip
Cloudflare 最近公开了一套内部使用的 AI 工作环境。
根据 Cloudflare OS 官方仓库，这套系统已经被 Cloudflare 从工程、销售到其他部门的大量员工日常使用。它可以查找企业资料、制作文档、运行代理，也能根据员工的要求直接生成应用。
如果只看这些功能，Cloudflare OS 很像一个加入编程能力的企业 AI 助手。但它真正提出的问题更激进：
当 AI 已经能够写软件，公司是否还需要让所有员工使用同一套固定的软件？
员工不再等待功能更新，而是让软件按需长出来
Cloudflare OS 把 AI 生成的小应用称为 Gadget。
员工可以要求代理制作客户会议简报、协作白板或者 GitHub 问题看板。生成完成后，每个 Gadget 都在独立环境中运行，默认只有创建者能够访问；需要协作时，再像分享在线文档一样授权给其他人。
这与传统 SaaS 的产品逻辑并不相同。
传统软件由厂商统一设计功能。用户发现缺少某项能力，只能寻找插件、提交需求，或者等待下一个版本。Cloudflare OS 的设想是：员工先让 AI 做出一个满足当前需要的小应用，使用过程中再继续修改。
软件因此不再只是公司采购回来的一套固定工具，也可能变成围绕具体任务临时生成、持续演化的工作成果。
它可能成功的原因也在这里。
企业内部存在大量规模不大、差异很强的需求。它们不足以进入 SaaS 厂商的产品路线图，也不值得公司安排完整的开发团队，却可能每天消耗员工数小时。如果生成和修改应用的成本足够低，这些长期被忽略的需求就有机会被软件覆盖。
真正的难题不是生成应用，而是管住应用的权限
让 AI 写出一个看板并不困难。让这个看板安全地读取 GitHub、调用 Slack，甚至修改企业数据，才是 Cloudflare OS 必须解决的问题。
Cloudflare 给出的答案是 Gatekeepers。
根据官方说明，每个代理和应用初始时都没有访问权限。Gatekeeper 负责保存凭据、处理 OAuth 授权，把访问范围限制在用户指定的资源内，并记录代理读取了什么、执行了什么。涉及写入或其他有副作用的操作时，系统可以要求用户批准。
Cloudflare 还设计了一种延迟审批机制。
当代理准备执行需要批准的操作时，Gatekeeper 可以先在本地模拟结果，让代理继续规划后续步骤。任务结束后，用户再集中批准或拒绝这些操作。这样既不需要给代理完全自动执行的权限，也不必让任务每走一步都停下来等待人工确认。
不过，模拟结果并不等于真实操作已经发生。模拟环境与真实系统之间是否会出现差异，审批数量增加后用户是否仍会认真检查，都是这套设计需要在真实企业中证明的问题。
从产品角度看，Gatekeepers 可能比 AI 生成应用本身更重要。
模型的编程能力会迅速普及，但权限、审计、身份和审批不会因为模型升级而自动解决。企业真正愿意长期使用的，往往不是最会生成内容的模型，而是能够在正确边界内完成工作的系统。
Cloudflare 为什么把它叫作“操作系统”
Cloudflare OS 并不是传统意义上的电脑操作系统。它管理的是企业里的代理、应用、数据入口和权限。
每个工作区由 Durable Objects 保存状态，每个 Gadget 运行在隔离的 Dynamic Worker 环境中，Gatekeepers 则控制代理如何连接外部服务。员工看到的是一个工作台，下面运行的却是一整套由 Cloudflare Workers、权限系统和 AI 基础设施组成的执行环境。
这解释了 Cloudflare 的战略位置。
Cloudflare 过去主要向企业提供网络、安全和计算基础设施。Cloudflare OS 向上走了一层：它不再只提供运行应用的服务器，而是试图成为企业生成、运行和管理 AI 应用的工作环境。
官方主页鼓励企业把 Cloudflare OS 部署到自己的账户，连接内部系统，再根据公司的术语、政策和工作流程进行修改。
从商业上看，开源并不意味着 Cloudflare 放弃了产品价值。相反，它可能是一种基础设施分发方式：企业越多地使用 Cloudflare OS，越多代理、应用、权限和模型调用就会运行在 Cloudflare 的平台上。
模型可以更换，真正沉淀下来的资产是企业自己的资料、技能、Blueprint、Gatekeeper 和审批规则。这些内容也可能成为 Cloudflare OS 最重要的转换成本。
它挑战 SaaS，但暂时替代不了 SaaS
Cloudflare 认为，当员工能够让 AI 添加自己需要的功能时，过去二十多年以统一应用服务所有用户的模式会受到挑战。
这个判断有吸引力，但只说对了一半。
传统 SaaS 的价值不只是提供功能，还包括统一升级、数据结构、质量控制和责任边界。如果每位员工都生成自己的应用，公司可能迅速得到数百个缺少维护者、数据口径不同、代码质量不一的 Gadget。
因此，Cloudflare OS 是否成功，不只取决于 AI 能否写出应用，还取决于企业能否低成本地治理这些应用：
- 谁负责检查和维护 AI 生成的代码；
- 员工离职后，个人 Gadget 由谁接管；
- 应用依赖的数据或接口发生变化时，系统能否及时发现；
- 多个员工生成相似应用后，公司是否能够合并和复用；
- 安全团队能否看清代理实际获得了哪些权限。
如果这些问题得到解决，Cloudflare OS 可能成为 SaaS 之外的一层“长尾软件系统”。如果解决不了，它也可能制造一种规模更大的影子 IT。
已经开源，但仍不是可以直接采购的成熟产品
Cloudflare 在官方仓库中明确把 2026 年 8 月发布的 v2 称为 early access。这个版本是根据第一版经验完成的一次重写，目前仍存在不少粗糙之处。
本地运行方式主要用于了解和测试产品，并不适合直接投入生产。部分 Gatekeeper 的独立部署模式仍在设计中，项目当前也没有大规模接收外部代码贡献。
这意味着 Cloudflare OS 现在更像一套可以研究和试验的产品方向，而不是已经成熟的企业办公套件。
接下来值得观察三个信号：
- 非技术员工能否在没有工程团队帮助的情况下长期维护 Gadget；
- Gatekeeper 的模拟审批能否在真实工作流中保持准确；
- 企业能否治理大量个人应用，而不把效率提升变成新的安全与维护成本。
Cloudflare OS 最值得关注的地方，并不是它证明了 AI 可以写应用。现在能够演示这一点的产品已经很多。
它真正把一个更重要的问题摆到了企业面前：
当软件可以随时生成，下一轮竞争的核心还是谁能写出更多功能，还是谁能管理这些软件使用的身份、数据、运行环境和权力？
Cloudflare 显然押注了后者。
