Cloudflare OS 是什麼？Agent 進公司的權限層
Cloudflare OS 在 8/5 開源：不是桌面系統，是公司內部 agent 的權限層。這篇拆 v2 為什麼不再天天燒 token、Gatekeeper 怎麼讓權限跟著資料走，以及獨立開發者該抄的三件事。
目錄+
業務做了一套 SuperApp，向 CIO 要約一打系統的 production API key，外加部署管線的 admin 權限——這是 Cloudflare CIO Sam Rhea 自己寫下的場景。缺的不是 agent，是一層讓它能做事、又不把整間公司交出去的權限。這篇拆 8 月 5 日開源的 Cloudflare OS：該抄 Gatekeeper，不該明天整包當公司 OS。
Cloudflare OS 是什麼
Cloudflare 在 2026-08-05 同步發布了主文、CIO 文與產品頁，核心程式碼在 GitHub（Apache-2.0，2026-08-14 抓取：8.1k stars、878 forks、666 commits），另附一份 starter。官方名稱裡有 OS，但它不是傳統意義的作業系統——README 明講這不是用來跑你既有電腦的 OS。
按官方定義，Cloudflare OS 由三塊組成：一個 agent 工作的 workspace、一個可個人改寫的全端 app（gadget），以及一層權限與稽核的安全層（Gatekeeper）。這是 Cloudflare 給內部員工跑 agent 的產物，官方自述從 2026 年 5 月起全員可用第一版，且「thousands」同事跨職能每天都在用——這些數字都是官方說法，不是第三方稽核。
改了什麼：v1 燒 token，v2 把流程寫成 app
Cloudflare OS 的 v1 是「workspace + skill」：每個流程都再跑一次 agent。CIO 文寫的問題是，每次執行 skill 都重新燒 token。他自己的 IT helpdesk 早報，v1 每天燒掉 thousands of tokens；v2 把這份報表寫成連到資料集的 app 後，官方說載入初始報告是 0 token。這是單一內部例子，不是「所有 v2 工作都零推論」。
這就是 gadget 的定位：每個 gadget 可以是一個獨立的全端 app（client + server + SQLite），跑在 Dynamic Worker 與 Durable Object Facet 上。確定性流程一旦寫成程式，就不必每次仰賴模型重新推論。官方自述過去一個月銷售省下 more than 10,000 hours、員工建立了 over 4,000 個 apps 與 tools——v2 的核心不是「更強的 agent」，是「把重複的事從推論移到程式」。
Gatekeeper 才是這篇的重點
Cloudflare OS 真正值得拆解的是 Gatekeeper，這是夾在 agent 與公司資源之間的一個 Worker。它的設計原則是：agent 與 gadget 預設都是零權限，任何資源都要「介紹」進去才看得見；伺服器預設關掉 outbound，client 跑在 sandboxed iframe。
關鍵在「權限跟著觀察走」。Gatekeeper 握著憑證、收窄資源、記錄 agent 看了什麼。它讓你能先讓 agent 模擬出結果、繼續向下做，使用者稍後再批次核准——而不是像同步 approve 或 --dangerously-skip-permissions 那樣，在「每一次都停下來問」與「完全不設限」之間二選一。觀察紀錄會跟著 workspace 與產物走：官方舉的例子是，agent 讀過資料倉裡的敏感表再做出即時儀表板，分享儀表板時 Gatekeeper 會再查對方能不能看那些原始資源。
至於 MCP，Cloudflare OS 支援既有 MCP server，透過 MCP Server Portals 匯入。換句話說不是「MCP 不夠好所以另外做了一套」，而是 MCP 解決的是工具介面、Gatekeeper 解決的是權限與稽核，兩者疊在不同的層。值得帶走的只有這一句：
權限要跟著資料走，不能只守在 API key。
你給 agent 一整包 key，等於把「它能看到誰、能改什麼」一次放開；只介紹單一資源、由 Gatekeeper 握憑證，才還留得住資料層的控制權。
這不是明天就能上的公司 OS
骨架很完整，但幾個前提必須講清楚。其一，README 標的是 early access，且版本迭代非常快——v2 被描述為一次完整重寫。其二，自架 workerd 的文件標的是 COMING SOON，手動部署的路徑還沒走完，官方也在 README 表明暫不尋求大型外部 PR。其三，上面引用的用量與時數多數是 Cloudflare 自述，不是第三方稽核，引用時要照樣標「官方說」。其四，Cloudflare OS 的形狀深度綁在 Workers、Access、AI Gateway 這套自家生態上，離開這個環境的通用性還待驗證。
把工作負載全押進這個生態不是沒有成本面——別再拼三家雲、全丟 Cloudflare 的成本算法就討論過早期便宜的代價是遷移時一次爆發；而若你想在 Workers 之外自架執行層，用 Rust 自架 Workers 執行層的 OpenWorkers 是另一條路。如果你把「OS」當成一套今天就能選型的公司基礎設施，很容易高估成熟度。它更接近一個權限作業系統的原型：方向清楚，但離可當正式產品選型還有一段路。
獨立開發者該偷哪三件
就算不用部署整套，這裡有三件可以直接抄進自己的工作流。
一、別給整包 API key。 能收窄就收窄：只開這次任務需要的資源，把長效金鑰換成短命、指向單一資源的准入。做法不一定得搬 Gatekeeper，但「預設零權限、用時才介紹」這個心態是免費的。
二、重複工作寫成程式，不要每天重跑 skill。 這是 Cloudflare 的 v1→v2 總結。如果你的 agent 每天都在重複同一套確定性動作，考慮把它固化成一支小 app 或指令稿，省下的是每次跑都要重算的 token 與時間。
三、本地 harness 看得到整台筆電；雲端 workspace 只看你放進去的東西。 本地跑 agent 的危險在於 agent 擁有的是你整台作業系統的權限——它能翻你全部的家目錄、env、憑證。雲端 workspace 的好處是，agent 只看得到你刻意放進去的那一小塊，預設看不見其他東西；Tencent 開源的 CubeSandbox agent 沙箱 走的是同一條「把 agent 關進可控容器」的路線。整理桌面配件是另一回事，真正的風險是 agent 的權限範圍；利益揭露：以下為聯盟連結，桌面 4 件套能讓桌面整齊，但控制不了 agent 能看到什麼。改寫執行環境，讓 agent 預設只看得到它該看的。
常見問題
Cloudflare OS 是作業系統嗎？ 不是傳統桌面或伺服器 OS，而是由 workspace、gadget、Gatekeeper 組成的權限層與執行環境，管理的是「agent 能做什麼」，不是跑既有機器。
跟 MCP / Claude Code 差在哪？ MCP 定義 agent 能呼叫哪些工具，Claude Code 是一支 agent 工具；Cloudflare OS 的 Gatekeeper 在更外層做憑證、資源收窄與稽核，兩者在不同層協作。
一個人團隊要不要現在部署？ 缺的是權限意識而不是整套 OS；官方是 early access、自架文件未完成，先抄它的零權限與介紹資源思維，不必明天整包上線。
資料會不會全部送給模型商？ 官方說推論走 AI Gateway，可選模型、記帳、設預算；這不是自動把敏感表從模型商面前藏起來。能進模型的內容，仍取決於你介紹了哪些資源、以及 Gateway／DLP 怎麼設。
「OS」這個名字是行銷，權限模型才是產品。Cloudflare OS 真正的貢獻，是把「agent 要有權限，但不能擁有你全部的權限」做成一套可執行的參考。你現在給 agent 的，是一把 key，還是一張會過期的介紹信？
本文根據 Cloudflare 官方部落格、CIO 部落格與 README 整理，引用數字皆標「官方說／README 寫」，非獨立第三方稽核；GitHub 統計為撰文當下抓取值，查核日期 2026-08-14。