Clive Notes
Cloudflare · Company OS · Open Source

Cloudflare OS

不是又一个聊天框。它是 Cloudflare 给自家全员用的 AI 生产力环境: 公司上下文 + 隔离运行时 + Gatekeeper 治理,开源后让你做成「Your Company OS」。

1. 它是什么:Company OS,不是桌面 OS

Cloudflare 说得很直白:目标不是让全世界都用「Cloudflare OS」, 而是让你 fork 之后变成 Your Company OS——接自家 Access、AI Gateway、数据与集成。

「操作系统」有两层含义:

公司上下文在转 INTERACTIVE
术语 流程 Skills 系统 政策
Sales IT Eng
Company OS 人 + Agent
共享公司上下文

模型可以换;难的是把「公司怎么运作」变成 Agent 可执行的上下文与技能。

2. 为什么出现:销售要一打 API Key

CIO Sam Rhea 写过内部故事:销售同学想用 AI 做「SuperApp」改造 GTM, 张口就要十来个生产系统的 API Key + 部署流水线管理员权限。

2025 他们偏谨慎;年末模型与 harness 跃迁后,全公司技术/非技术同事都开始「动手」。 义务变成两件事:赋能,同时保住系统、内部数据与客户数据

五条原则(摘要) 为客户省时间、人人该有超能力、人对产出负责、组织上下文比模型重要、 用 AI 时权限绝不能比原系统更大——共享出去的 Agent 也必须按对方的权限生效。

3. 三块积木:Workspace / Gatekeeper / Gadget

开源版把平台收成三件事(点下面可逐步点亮):

平台分层 点击播放
Layer 1
Agent Workspace
浏览器里的会话:公司 skills / 上下文、持久状态、文件产物、隔离运行时(可写代码查数,不必把整表塞进上下文)。
Layer 2
Gatekeepers · 治理框架
服务专用 Worker:握凭证、缩权到单一资源、记审计、副作用可审批;对 Agent 只暴露窄 TypeScript API。
Layer 3
Gadgets · 可改的个人应用
对话可变成 doc / 幻灯片 / 全栈小应用;私有默享,可共享实例或 Blueprint(代码模板)。

对话只是入口;终点可以是持续连着活数据的文档、定时工作流,或团队共用的小工具。

4. 安全模型:默认零权限,策略跟着「看过什么」走

Access 管「谁能进门」。门内每个 Agent / App 从零权限开始。 需要资源时显式申请;通过后变成 typed binding,凭证永不进 Agent 或生成代码。

默认拒绝 · 点击授予能力 TRY ME
env.PROJECT
denied · click to grant
env.CRM
denied · click to grant
env.WAREHOUSE
denied · click to grant
global fetch
denied · 平台禁用
// Agent 生成的服务端代码只能碰你授予的 binding
// 当前:没有任何能力

服务端跑在禁用全局出网的 Dynamic Worker;浏览器端在沙箱 iframe。互联网只能经你显式提供的能力出去。

Gatekeeper:比 MCP 多一档

MCP 解决「工具目录 + 凭证托管」;但调了哪些工具 ≠ 看过哪些底层资源。 协作分享工作区 / 应用 / 产出时,必须防止「借仪表盘偷看无权的表」。

Gatekeeper 记观察日志;别人打开你的产出时,要核对对方对那些资源是否有权。 敏感读还可以禁止写到某些出口、禁止邀请协作者、禁止外呼。

异步审批:Agent 不用干等咖啡 PLAY
1
Agent 请求副作用(如 merge PR)
传统 HITL:此处卡住,等人点批准。
2
Gatekeeper 本地模拟结果
告诉 Agent「已完成」,并在读回时给模拟数据。
3
Agent 继续往下排后续动作
你去倒咖啡;队列在攒,而不是卡在第一步。
4
你回来批量批准 / 拒绝
方便时处理;避免「烦了就 --dangerously-skip-permissions」。

5. Gadget:每人一份私有应用实例

传统办公套件是固定文件类型。Cloudflare OS 里每个「文件」可以是 为自己写的全栈应用:客户端 UI + 服务端逻辑 + 独立 SQLite(Durable Object Facet)。

SaaS 共享进程 vs Gadget 私有实例 TOGGLE

多租户同一份应用

所有用户连同一套服务;功能靠厂商排期。

VS

每人一个隔离实例

沙箱控访问;缺功能可让 Agent 改自己的那份。

经典模式:一份代码服务所有人——扩展靠提需求。

6. 从 Magic Email 到 v2 的演进

内部不是一步到位的。按 CIO 文梳理的关键拐点:

内部路径 AUTO
原则
CTO + CIO 先写规则,再铺工具
人人超能力 · 人负责产出 · 上下文 > 模型 · 权限不膨胀
工程侧
Engineering Codex + MR / 设计 / 事故审查 Agent
四个月拦下约 16,000 次合并、近 600 份设计问题
非工程
Magic Email:把不想干的活寄给「魔法邮箱」
人工 + AI 接单 → 沉淀 jobs-to-be-done / skills / 数据连接
OS v1
浏览器 harness + Zero Trust + MCP Portal + AI Gateway
开箱即用;但每次 skill 仍烧一轮推理
OS v2 · 开源
自然语言 → Agent 写代码 → 确定性工作流 / Gadget
晨报类任务可零 token 加载;分享时按对方权限过 Gatekeeper
0
销售侧约节省工时 / 月(自评)
0
30 天内创建的 apps / tools
0
仓库:core + 示例部署(不改 core)

7. Workers 底座:DO · Dynamic Workers · Facets

由 Workers 团队自己做:每个 workspace 是 Durable Object;每个 Gadget 是 Dynamic Worker Facet; Gatekeeper 也往 workspace 装 facet。Dynamic Workers / Facets 等能力,相当一部分就是为这个项目推出来的。

传统 OS Cloudflare OS
kernelworkshop-backend
device driversgatekeeper-*
shellworkshop-frontend
processesgadgets
executablesblueprints
(缺失位)agents —— 能力安全,而不是简单当「另一个用户」

也可跑在开源运行时 workerd 上自托管;本地 pnpm run-locallocalhost:8787。 模型经 AI Gateway:控路由、预算、归因到人 / 团队 / workspace。

8. 对照 Stripe Kai / Minions

相似

同一类问题

  • 编程 Agent 浪潮把非工程甩在后面
  • 要公司上下文,不是裸模型
  • 不能把生产 Key 塞给人/Agent
  • 技能 / 上下文要联邦沉淀
差异

形态选择

  • Kai:知识工作 Agent 平台(skills + 产物)
  • Minions:无人值守写代码 → PR
  • CF OS:办公套件隐喻 + 每人可改的 Gadget OS
  • CF 更强调开源「复制成自家 OS」

延伸阅读站内: Stripe Kai · Minions Part 2

9. 可带走的结论

若你要抄结构

  • 先原则与权限模型,再上聊天 UI
  • 用「不想干的活」挖 jobs-to-be-done(比鼓励 vibe coding 更准)
  • MCP / 工具只是第一层;观察日志 + 分享边界才是协作安全
  • 能确定性的流程,别每次都烧大模型
  • 核心与部署配置分仓,方便做成 Your Company OS

一句话

Cloudflare OS 把「全员 AI」从发 Key、发终端,改成: 零权限工作区 + 能力型 Gatekeeper + 可分享的私有应用实例。 难的不是接入又一个模型,而是让公司真实的工作方式可运行、可审计、可改。