Cloudflare 開源「Cloudflare OS」：把全公司變成 AI Agent 的工作場
Cloudflare 8 月 5 日宣布，內部使用超過三個月的 AI Agent 平台「Cloudflare OS」正式開源，任何組織都能下載部署、把公司內部系統、術語、流程灌進 AI 工作區，讓每個員工都擁有理解公司脈絡的 Agent。
從工程團隊內部工具到全公司作業系統
oudflare 在 6 月 11 日的 Analyst/Investor Day 上，已經展示過 Cloudflare OS 雛形。當時重點是「雲端 Agent 跑在 Cloudflare 全球網路上」。這次開源版本，則補齊了從內部實驗到企業級平台之間最重要的兩塊拼圖：安全治理框架，以及一般員工也能自己寫 App 的個人化工具鏈。
Cloudflare 內部從 5 月開始使用第一版，公司 CIO Sam Rhea 在另一篇部落格文章中詳述了這段旅程。內部版本的重點是「個人工作區 + Agent」，但很快就浮現三個問題：
- 第一，App 大多是靜態的，沒有跟內部系統即時連接
- 第二，需要 Agent 重複跑的「重複性工作」每次都得消耗新一次的模型 token
- 第三，協作時，MCP 伺服器只告訴我們 Agent 能呼叫哪些工具，卻沒告訴我們 Agent 看過哪些底層資料
於是 Cloudflare 決定打掉重練。新版本把安全做進平台本身，讓任何寫 App 或用 Agent 的人都不用自己煩惱權限。
為什麼這件事重要
這套產品不是在做另一個 ChatGPT 介面，而是在搶「企業級 AI Agent 作業系統」這塊長期被忽略的領地。過去一年，企業 AI 落地最大的痛點從「模型不夠聰明」變成「內部資料接不出來、權限管不住」。當 Anthropic、Google、OpenAI 都在拚模型本身的 benchmark，Cloudflare 選擇從平台層切入，把 Agent 需要的 Context、權限、執行環境、應用生命週期全部打包。
Cloudflare 早在 Q1 2026 法說會就公開承認，AI 工具讓公司內部 1100 個職位變得多餘（Quartz 5 月報導）。這次開源 Cloudflare OS 幾乎是把自家「如何用 AI 改造公司」的內部流程攤開來當產品賣。這不是純技術展示，而是帶有商業訊號的策略動作：Cloudflare 想成為企業 AI 轉型的「基礎設施提供者」。
三大架構核心
版的 Cloudflare OS 由三個部分組成：
- Agent 工作區：以公司內已整理好的 Context 與技能為基礎，搭配隔離執行環境，讓 Agent 能寫程式並執行
- 安全與治理框架：透過 Gatekeeper 機制守住內部資料與服務的存取
- 個人化 App 平台：讓員工寫出可分享、可修改、具狀態的全端應用
Agent 工作區：給非工程師也能用的 Agent
工作區的核心設計是「在瀏覽器裡對話」，所以不需要會寫程式、懂終端機也能用。每個工作區包含 Agent session、持久狀態、產出檔案、資源存取權限，以及一個隔離的執行程式碼環境。
最具體的差異化是「Context 與技能庫」——公司團隊或整個組織可以把術語、流程、最佳實踐整理成 Agent 可讀的指令。當某個人找到更好的做事方法，整個團隊都能立刻套用，不必再從頭教模型「我們公司怎麼運作」。
實作上能做四件事：
- 研究與提問：Agent 能寫程式搜尋、過濾、串接、分析，不會把整個資料集塞進 Context window
- 製作文件、簡報、試算表：產出不是死的檔案，可與原始資料保持連線，來源更新時會跟著更新
- 打造團隊協作 App：Agent 可寫出有介面、有邏輯、有狀態的 App，支援多人協作
- 執行確定性工作流：把已知步驟編成程式碼，只在需要判斷的地方用模型，可依需求、排程或事件觸發
Gatekeeper：守住資源的代理人
MCP（Model Context Protocol）讓 Agent 透過伺服器存取外部系統，不用直接拿 API 金鑰。但 Cloudflare 指出這還不夠：MCP 只告訴我們 Agent 能呼叫哪些工具，無法約束 Agent 看過哪些底層資料。如果 Agent 讀了某張機密表、再把結論寫成 dashboard 分享出去，機密等於變相洩漏。
Cloudflare OS 的解法是「Gatekeeper」：
- 代理層 Worker 介於 Cloudflare OS 與外部服務之間，負責處理 OAuth、保管憑證、執行政策、記錄讀取行為、仲裁有外部副作用的動作
- 每個 Agent 與 App 預設對所有資源「零存取」，Agent 必須先「請求」特定資源，由人或政策決定是否授權
- 通過授權後，程式碼收到的是「型別化綁定」（如
env.PROJECT.listIssues()），憑證本身對 Agent 與程式碼完全隔離 - 伺服器端程式碼跑在 Dynamic Worker（關閉全域外網），瀏覽器端程式碼跑在沙箱 iframe，兩者除了你明確給的 Capability 之外都連不上網
政策：跟著「Agent 看到了什麼」走
Cloudflare OS 會記錄 Agent 觀察過的所有資源，這些觀察記錄會持續綁定在 Agent 與它的產出上。當其他人打開工作區、跟 Agent 互動、或檢視它的產出時，Gatekeeper 會驗證該人員對原始資源的存取權。
同一份觀察紀錄也用來決定 Agent 能否執行外部請求：例如讀取敏感資料後，Agent 會被禁止寫入某些來源、邀請新協作者、把工作交接給其他 Agent、或發出外連請求。
換句話說，安全不是「Agent 能不能讀」，而是「Agent 讀了之後資料能流向哪裡」。這是企業 AI 落地最頭痛的問題，Cloudflare 用「觀察紀錄 + 政策依賴圖」直接解掉。
數據解讀：實際使用情境與限制
Cloudflare 公開的數字停在「Cloudflare 內部上千名員工跨部門每天使用」這個層級，沒有更細的 ROI 數字（例如每天省下多少工時、Token 成本下降幅度）。這是自我行銷常見的盲點。
兩個值得觀察的技術限制：
- Container 支援還沒到位：官方文章明確說「Cloudflare 正在把 Container 帶進開發工作流程」，但目前 Dynamic Worker 只能用 V8 isolate 跑輕量隔離，無法跑需要完整 Linux 環境的傳統工作負載
- Slack 整合還在路上：「Cloudflare 正在把工作區帶進 Slack 與其他聊天工具」，目前主要還是網頁介面
值得注意的功能差異：Cloudflare OS 開源版強調「Workforce Transformation」這個面向（給上班族一個會用 Agent 的工作環境），跟 Anthropic 的 Claude Code（給工程師用的 CLI 工具導向）走的是不同路線。
為什麼 AI Native 企業都該關注
Cloudflare 把 Cloudflare OS 開源，背後有三層戰略意涵：
第一層是 生態系綁定。當企業用 Cloudflare OS 部署 Agent，所有 AI 推論都會走 Cloudflare AI Gateway，每個請求都歸屬到個人、團隊或工作區。對 Cloudflare 來說，這意味著可觀察的 AI 推論營收，而不只是 Workers 算力費用。
第二層是 企業安全標準制定。Gatekeeper 與觀察紀錄機制如果成為業界標準，等於把所有 MCP 伺服器廠商都拉到 Cloudflare 的治理框架裡。Anthropic、OpenAI、Google 的模型不論用誰家的，企業要嘛走 Cloudflare OS 的標準、要嘛自己想一套同樣嚴謹的安全模型。
第三層是 平台鎖定。Cloudflare 把 App 寫成 Worker + Durable Object Facet，每個 App 都有自己的 SQLite 資料庫。一旦企業在上面寫了幾十個 App，切換到其他平台的轉移成本會非常高。
質疑與不足
雖然 Cloudflare OS 開源版解決了企業 AI 落地的關鍵痛點，但仍有幾個明顯限制：
- 沒有實證的 ROI 數據：Cloudflare 沒有公開任何內部用量、節省時間、Token 成本下降的具體數字，只有「上千名員工每天使用」這類行銷詞
- 學習曲線陡峭：Gatekeeper、Cap’n Web、Durable Object Facet 等概念對一般企業 IT 部門並不友善，部署門檻不低
- 生態系剛起步：Open Source 社群剛開始，使用案例、第三方整合、學習資源都還很少
- 沒有官方 Container 方案：對需要跑完整 Linux 環境的傳統工作負載，目前只能用 Dynamic Worker 處理簡單任務
怎麼開始
Cloudflare OS 已開源在 GitHub（cloudflare/agents 倉庫），可以下載源碼、試用 demo，或用官方 starter repo 幾分鐘內部署到自己的 Cloudflare 帳號。
編按：本文綜合整理自 Cloudflare Blog 官方公告〈Cloudflare OS: an open platform for agents, apps, and work〉、Cloudflare 官方新聞稿、Phoronix、BusinessWire 報導，並加入 Siami 編輯部觀點與分析。
網友熱門留言 (5)