Cloudflare 開源了 Cloudflare OS，但真正值錢的不是那些 Worker
2026年8月7日 · Waiting7777 · 8 分鐘閱讀
Cloudflare開源兩年前，我花最多時間的不是 agent
先講一段我自己的經驗，你才會知道我看這篇 Cloudflare 公告的角度是什麼。
前一份工作我在一家 AI 新創，做的事情用一句話講完：讓 Claude agent 幫業務和營運跑跨系統的流程。銷售資料在 HubSpot，營運資料在 Odoo，中間全靠人工轉派、複製貼上、群組通知。做完之後人工交接的工作量降了大約七成，資料同步從幾小時變成近即時。
聽起來很像一個 LLM 專案，對吧？
但實際上，寫 agent 本身大概只佔我三成的時間。剩下的七成全花在一堆聽起來很不性感的事情上：
- 這個 agent 該拿到哪些權限？給它整個 HubSpot 的 API key，等於給它刪除所有客戶資料的能力。
- 它到底讀過什麼？出事的時候我要能回答「它是不是看過那筆不該看的薪資欄位」。
- 哪些動作可以自動做完，哪些一定要人按下確認？
- 這些規則寫在哪裡？寫在 prompt 裡的話，模型心情不好就會忽略它。
我最後是自己刻的。權限映射表、操作白名單、每一步的稽核紀錄、需要人拍板的節點——全部土法煉鋼。當時心裡想的是：這些東西怎麼會沒有現成的？每一家想導入 agent 的公司不是都要再刻一次嗎？
然後 Cloudflare 上禮拜把它做成產品，還開源了。
Cloudflare OS 是什麼：三十秒版
Cloudflare 開源了一套叫 Cloudflare OS 的內部平台，他們自己已經用了好幾個月。今年五月開始給全公司用，官方說法是「數千人跨每個職能在用，其中很多人不是工程師」。
它由三塊組成：
- Agent workspace — 用官方的話說，是「結合 agent sessions、持久狀態、產出與檔案、資源存取，以及一個 agent 可以寫程式並執行的隔離 runtime」。
- 安全治理框架 — 也就是本文的主角，等一下講。
- 個人應用平台 — 每個員工都可以自己建、改、分享內部小工具。
技術棧全是 Cloudflare 自家的：Dynamic Workers 跑程式、Durable Object Facets 存狀態、每個 app 配一個 SQLite、前後端用 Cap'n Web 這套 RPC 溝通、外部工具靠 MCP 串、模型呼叫走 AI Gateway 管成本。
看到這裡，大部分技術媒體的報導就結束了——「Cloudflare 開源內部 AI 平台，技術棧包含 XXX」。
但如果你真的做過企業 agent 導入，你的目光應該會停在完全不同的地方。
判讀一：主角是 Gatekeeper，不是那些 Worker
整篇公告裡，我認為最重要的是這兩句：
"Inside, every agent and app starts with access to nothing. An agent can ask for access to a specific resource, which you can grant or deny."
"A Gatekeeper is a service-specific Worker that sits between Cloudflare OS and an external service. The Gatekeeper handles OAuth, holds the credential, enforces policy, records what was read, and mediates anything with an externally visible side effect."
翻成人話：每個 agent 出生時什麼權限都沒有，要什麼就得申請，而且它永遠拿不到憑證本身——憑證握在 Gatekeeper 手上，agent 只能透過它去碰外面的世界。順便，Gatekeeper 會記錄 agent 讀過什麼，還能依據這份觀察紀錄去限制它後續能對外送出什麼。
這正是我當年手刻的那七成工作，被抽象成基礎建設了。
而且我要指出一個更有意思的連結。我上個月做技術分享講 Loop Engineering 的時候，講過一句話：
迴圈的自主權不是「信任程度」，是寫死在設定檔裡的邊界。「我覺得它應該不會亂改」不是安全機制。
Cloudflare 這套 Gatekeeper 就是那句話的產品化版本。差別在於，我當時講的是一個工程師該有的心態，他們做的是讓這件事變成「你不照做就跑不起來」的架構約束。心態會鬆懈，架構不會。
這也是我看這篇公告最大的收穫：AI agent 進企業的難點正在從「模型夠不夠聰明」轉移到「權限與稽核的形狀」，而且已經有人開始賣鏟子了。
判讀二：「每個員工都能建 app」是甜蜜陷阱
公告裡另一個賣點是：非工程師也能自己做內部工具，thousands of people across every function。
這件事我的態度比較保留，理由跟技術無關。
當產出變便宜，瓶頸會整個移到驗證。 這是我這一年跑自主 agent pipeline 最痛的體會——agent 一個晚上開十個 PR 不是問題，問題是隔天早上誰有能力判斷這十個該不該進。同樣的邏輯放到組織規模上會被放大：一千個員工各自建了三個小工具，跑了半年之後，沒有任何一個人知道公司內部到底有多少個在跑的自動化、它們各自碰了哪些資料。
這就是「理解債」（comprehension debt）在組織層級的樣子。它沒有症狀，帳單也看不出來，直到某天有人問「這份客戶名單為什麼會出現在這個 Slack 頻道」，才發現追不出來。
公平地說，Cloudflare 的設計是有意識在處理這件事的——Gatekeeper 的觀察紀錄本身就是稽核工具。但工具能給你資料，給不了你「有人真的定期去看」這個習慣。買平台可以外包架構，外包不了治理。
所以如果你是要導入這種平台的決策者，我的建議是：先想清楚「誰負責每個月看一次這些 app 在幹嘛」，再想要不要開放全員自建。這個角色沒有指定，平台上得再漂亮都會長成技術債溫床。
判讀三：開源這一步，是發行策略
來講商業面。這篇公告值得問一個問題：Cloudflare 為什麼要把內部平台開源？
不是做慈善。你看一下技術棧就知道了——Dynamic Workers、Durable Objects、AI Gateway、Access，整套東西是長在 Cloudflare 上的。官方也講得很直白：
"You can deploy it into your own Cloudflare account and use your own Access policies, AI Gateway configuration, data, and integrations."
Your own Cloudflare account. 開源的是「你怎麼組裝」，不是「你可以搬到別的地方跑」。
這是很標準也很聰明的一步棋：把一個大家都缺、但又懶得自己刻的東西免費送出去，讓它變成企業導入 AI 的預設起點，而每一次部署都會長出更多 Workers 用量、更多 Durable Objects、更多 AI Gateway 的流量。開源在這裡是發行通路，不是商業模式。
我不覺得這有什麼問題——說實話，如果兩年前就有這套東西，我大概會直接用，省下的三個月比綁定的代價值錢多了。但你在評估的時候要知道自己在買什麼：你買的不是一個中立的框架，是一張進入 Cloudflare 生態的門票。
那台灣的公司現在該做什麼？
大部分台灣中小企業不會因為這篇公告就把基礎建設整包搬到 Cloudflare，這很合理。但概念可以現在就抄，而且不用付錢。
我認為有三件事，是任何規模的公司導入 AI agent 時都該照做的，Cloudflare 只是幫你證明了它們重要到值得做成產品：
一、從零權限開始，而不是從方便開始。 不要把整把 API key 塞給 agent。先讓它什麼都不能碰，需要什麼再一項一項開。這件事在一個 Python script 裡也做得到，差別只在你有沒有把它當成必要條件。
二、憑證跟 agent 分家。 中間放一層代理，憑證握在那一層，agent 只能呼叫被定義好的動作。這就是 Gatekeeper 的精神，而它本質上只是一個你自己寫的薄薄 wrapper——真正難的是決定「哪些動作可以被呼叫」，那是業務判斷，不是技術問題。
三、留下觀察紀錄，而且要有人看。 每一次 agent 讀了什麼、做了什麼，都要留痕。這件事在出事之前看起來像浪費時間，出事之後它是你唯一的救命繩。
這三件事沒有一件需要換掉你的雲。缺的通常不是工具，是有人拍板「我們的 agent 邊界長什麼樣子」。
結論：meta shift 還是版本 patch？
我的判定是：Cloudflare OS 這個產品是 patch，但它指向的方向是 meta shift。
產品本身是 patch——它高度綁定 Cloudflare 生態，適用對象是本來就重度使用 Workers 的公司，多數企業不會因為它而搬家。
但它揭露的趨勢是真的：企業導入 AI 的競爭場地，正在從「用哪個模型」移到「權限、稽核與治理的形狀」。 模型會繼續變強變便宜，那不再是差異化來源；能不能安全地讓 agent 碰到公司真正的系統，才是決定它有沒有用的關鍵。
換句話說，AI 導入正在從一個 ML 問題，變成一個權限工程問題。而權限工程這件事，二十年前的 SRE 和資安團隊早就知道怎麼做——只是這一次，被授權的對象不是人，是一個會自己決定下一步要做什麼的東西。
這也是為什麼我對這個領域樂觀：值錢的技能不是「會用 AI」，是知道什麼時候不該讓它動手。那個判斷不會因為模型變強而貶值。
延伸閱讀
Waiting7777
WoW Arena 冠軍轉前端，用電競 meta 思維拆解技術趨勢。
相關文章
AIMistral+3Mistral AI 怎麼跟 OpenAI 搶生意 — 開源模型的商業邏輯
Mistral 的策略很聰明：用開源打知名度、用企業版收錢。這個打法跟 MongoDB、Elastic 當年很像，值得好好拆解它怎麼跟 OpenAI 錯位競爭。
2026年7月7日 · Waiting7777 · 6 分鐘閱讀
繼續閱讀 →
SpaceXAI+3SpaceX 又簽 AI 算力協議 — Musk 的 AI 版圖到底在佈什麼局？
SpaceX 買了 Cursor，又跟開源 AI lab 簽算力協議，Musk 的 AI 版圖佈局到底是什麼策略？從 xAI 到 SpaceX 的計算資源，梳理這盤棋的走向。
2026年6月24日 · Waiting7777 · 6 分鐘閱讀
繼續閱讀 →
Claude開源+3Claude Code 的記憶問題有解了？Recall 這個開源工具值得試試
從實際 Claude Code 使用者的角度評估這個工具解決的痛點是否真實，以及 local memory 對 AI coding 工作流的實際影響，順帶拆解它的技術架構。
2026年6月23日 · Waiting7777 · 8 分鐘閱讀
繼續閱讀 →這篇文章對你有幫助嗎？
每週一篇 — 技術趨勢背後的商業邏輯
AI 產業在變什麼、工程師該注意什麼——拆清楚寄到你的信箱。