Cloudflare 給 agent 發了張能刷的卡
整理版優先睇
Cloudflare 同 Stripe 推出新協議，讓 agent 安全成為客戶，將失控風險鎖喺可計算範圍內
呢篇文係一個技術觀察者分析 Cloudflare 同 Stripe 合作推出嘅 stripe projects 協議。作者拆解咗點解俾 agent 直接註冊域名、刷信用卡、部署服務，睇落好似放權，但實際上係將控制點從 agent 嘅執行邊緣搬到協議層。文中詳細解釋咗三道安全關卡：OAuth 同意、$100/月預算上限、同憑證隔離，令 agent 失控嘅最壞情況變成可計算、可承受嘅事故。
作者認為呢步唔止係產品發佈，而係產品定位嘅判斷——Cloudflare 賭 agent 係一類全新客戶類型，需要專門嘅 onboarding、計費同 TOS 路徑。傳統 SaaS funnel 唔適用於 agent，所以佢哋設計咗一條新通道：用 catalog 代替 landing page、自動 provisioning 加 OAuth、token-based payment 加預算 cap、協議層 telemetry。如果呢套標準跑通，agent 經濟就會從「agent 調 API」升級做「agent 係 buyer」，呢個係質嘅分別。
短期睇 Cloudflare 搶咗先機，長期嚟講任何賣 infra 嘅公司都要做類似嘅事，否則會被 agent 直接跳過。作者總結咗幾條啟示：provider 要為 agent 留入口、OAuth scope 同預算 cap 係新安全邊界，仲有 agent-as-customer 係新商業類別，S…
- Cloudflare 同 Stripe 推出 stripe projects 協議，令 agent 可以直接成為客戶，控制點從執行層搬到協議層。
- 三道安全關卡（OAuth scope、預算 cap、憑證隔離）將 agent 失控嘅最壞情況鎖死喺可計算範圍內。
- 傳統 SaaS funnel 唔適合 agent；新通道用 catalog、自動 provisioning、token payment 同協議層監控。
- OAuth scope 同預算 cap 係 agent 時代嘅新安全邊界，provider 要重新審視設計。
- Agent-as-customer 係新商業類別，SaaS 產品應該盡快提供 agent-friendly 嘅註冊同計費協議，否則會被跳過。
Agent 而家做到啲咩？
Cloudflare 同 Stripe 合作推出咗一個新協議叫 stripe projects。原文話：「Starting today, agents can now be Cloudflare customers. They can create a Cloudflare account, start a paid subscription, register a domain, and get back an API token to deploy code right away.」具體動作就係三條命令。
stripe projects init
stripe projects catalog
stripe projects add cloudflare/registrar:domain第一行初始化項目，第二行查可用嘅 provider 同服務，第三行令 agent 透過 Cloudflare 嘅 registrar 註冊域名。流程大致係：用戶先登 Stripe → 執行 stripe projects add → Stripe 作為 identity provider 驗身份 → Cloudflare 自動開賬號（如果未有），或者走標準 OAuth（已有賬號）→ Cloudflare 將 API token 發返 CLI，存喺系統 keychain 度 → agent 拎住呢個 token 直接調 Cloudflare API 部署。呢個係 stripe projects 協議層嘅封裝，唔止 Cloudflare，理論上任何 provider 都可以註冊成 catalog 項，agent 透過同一個 CLI 跨 provider 自由組合。
韁繩點樣藏喺協議入面？
好多人第一反應係：「俾 agent 信用卡？咪玩啦！」但 Cloudflare 冇真係俾信用卡，佢將三道關卡挪咗入協議層。
- 1 第一道：OAuth 同意。用戶必須明確接受 Cloudflare TOS、批准 OAuth scope，agent 冇得繞過。授權嘅顆粒度由 OAuth scope 決定，唔係俾 agent 全權。
- 2 第二道：預算 cap。Stripe 俾每個 provider 默認 $100/月上限，超咗就停。用戶可以調高，但默認係收緊嘅，將「agent 失控燒錢」嘅恐懼收窄到最多 100 蚊。
- 3 第三道：憑證隔離。原文：「Raw payment details like credit card numbers aren't ever shared with the agent.」agent 拎到嘅係 opaque payment token，唔係真卡號。token 可以即時回收，唔影響用戶嘅卡。
三道關合埋，agent 拎到嘅唔係信用卡，而係「用戶授權、範圍限定、有月度上限、用完即棄嘅代付能力」。控制點從執行邊緣搬到協議邊緣——agent 可以調邊啲 API（OAuth scope）、最多使幾錢、用咩憑證，全部喺協議層定死。
Agent 升呢做 first-class 客戶
Cloudflare 呢步表面係產品發佈，本質係 product positioning 嘅判斷——佢賭 agent 係一類新客戶類型，需要專門嘅 onboarding、計費同 TOS 路徑。傳統 SaaS 客戶畫像係人類，從 marketing → trial → 轉化 → 付費 → 增購，每一步都要做用戶研究。但呢套 funnel 唔適用於 agent。Agent 唔需要 marketing，佢就係一段 code，見到合適嘅 API 就調；Agent 亦唔會做 trial，佢要就係要、唔要就係唔要。
所以 Cloudflare 為 agent 設計咗一條全新通道：入口係 stripe projects catalog（代替 marketing landing page），註冊係自動 provisioning 加 OAuth（代替 sign-up form），計費係預算 cap 加 token-based payment（代替信用卡加月度賬單），監控係協議層 telemetry（代替 dashboard 加客服）。呢套設計嘅目標用戶特徵好具體：高頻、小額、自動化、可監控、可即時叫停。每一筆交易可能只係 $1，但一個 agent 一日可能跑幾百次，月度 GMV 加埋唔少。
SaaS 行業過去 10 年冇認真做過呢種用戶。Stripe 加 Cloudflare 而家做嘅嘢，係將 micro-payment、scoped auth、自動 provisioning 呢三塊原本分散嘅能力封裝成標準協議。如果跑通，agent 經濟會從「agent 調 API」升級做「agent 係 buyer」——呢個係質嘅分別。
幾條值得重新評估嘅判斷
- Provider 必須俾 agent 留入口。如果你做 SaaS 或 API 產品，「有冇 agent-friendly 嘅註冊同計費協議」喺未來 12 個月會變成評估標準。手動 dashboard 加複製粘貼 token 對 agent 唔友好，等於自我邊緣化。stripe projects 呢類協議一旦擴散，冇接嘅 provider 會被 agent 直接跳過。
- OAuth scope 係 agent 時代被低估嘅設計。多數 OAuth 用法停留在「授權一個 app」，但 agent 時代要細化到「授權呢個 agent 喺呢個 scope 內嘅具體操作」。Scope 設計直接決定 agent 安全嘅上限。而家應該重新審視你產品嘅 OAuth scope——佢係為 app 寫嘅，定係為 agent 寫嘅？
- 預算 cap 係新嘅安全邊界。傳統安全邊界係「可以做啲咩」，agent 時代多咗一條「可以使幾多」。$100/月呢個默認值唔係數字遊戲——佢將「agent 失控嘅最壞情況」變成可承受、可保險、可量化嘅事故。任何令 agent 動錢嘅產品，預算 cap 都應該係默認機制，唔係高級選項。
- Agent-as-customer 係新嘅商業類別。呢類用戶特徵係高頻小額、自動化、可監控、可即時叫停。SaaS 定價模式過去十年都係為人類設計嘅——月度訂閲、年度合約、tiered pricing。為 agent 用戶重新設計的話，可能要按調用計價、按預算 cap 劃檔、按 scope 分級。等到大家都做嘅時候，先發嘅 Cloudflare 已經定咗標準。
呢個禮拜 Cloudflare 俾 agent 直接嚟註冊網域、碌卡、部署服務。
聽落好似俾人控制權咁 - 俾 agent 信用卡同 API token，咁咪即係等於令佢失控？
但拆開睇其實唔係。Cloudflare 將控制點從 agent 嘅執行邊緣搬咗去協議層。呢個係一個完全唔同嘅 agent 安全哲學，亦係 Cloudflare 賭 agent 係一類新嘅客戶類型。值得仔細睇下。
agent 而家可以做啲乜
Cloudflare 同 Stripe 合作出咗個新協議，叫 stripe projects。原文係：Starting today, agents can now be Cloudflare customers. They can create a Cloudflare account, start a paid subscription, register a domain, and get back an API token to deploy code right away.
具體動作就係三個命令：
stripe projects init
stripe projects catalog
stripe projects add cloudflare/registrar:domain第一行初始化項目，第二行查可用嘅 provider 同服務，第三行俾 agent 經 Cloudflare 嘅 registrar 服務註冊一個網域。
flow 大致係：用戶先登入 Stripe → 跑 stripe projects add ... → Stripe 作為 identity provider 驗證身份 → Cloudflare 自動開賬號（如果仲未有），或者行標準 OAuth（已經有賬號）→ Cloudflare 將 API token 發返去 CLI，擺喺系統 keychain 入面 → agent 拎呢個 token 直接 call Cloudflare API 部署。
呢個係一個 stripe projects 協議層嘅封裝，唔止係 Cloudflare 自己。理論上任何 provider 都可以註冊成 stripe projects 嘅 catalog 項目，agent 經同一個 CLI 就可以跨 provider 自由組合。Cloudflare 係首發合作方，但意思係要做一個標準。
韁繩收埋喺協議入面，唔喺執行層
最容易引起嘅反應係：「俾 agent 信用卡？呢個唔係癲咩？」
但 Cloudflare 冇真係俾信用卡。佢將三道關卡搬咗去協議層。
第一道係 OAuth 同意。用戶必須明確接受 Cloudflare TOS、批准 OAuth scope，agent 唔可以繞過。呢個同傳統 OAuth 一樣，但意義唔同 - 喺傳統場景下 OAuth 係「用戶授權一個 app」，呢度係「用戶授權一個 agent 代表用戶行使賬號能力」。授權嘅顆粒度（網域註冊、賬單訂閲、API token 範圍）由 OAuth scope 決定，而唔係俾 agent 全權。
第二道係預算上限。Stripe 俾每個 provider 預設 $100/月上限，agent 用超就停。用戶可以調高，但預設係收緊嘅。呢個將「agent 失控會點樣」呢個最大恐懼從「無限燒錢」收窄到「最多 100 蚊」。
第三道係憑證隔離。原文：「Raw payment details like credit card numbers aren't ever shared with the agent.」agent 拎到嘅係 opaque payment token，唔係真正嘅卡號。token 失效或被濫用，可以即時回收，唔影響用戶嘅卡。
三道關卡加埋，agent 拎到嘅唔係「信用卡」，而係「用戶授權嘅、範圍限定、有月度上限、用完即棄嘅代付能力」。控制點從執行邊緣搬咗去協議邊緣 - agent 可以 call 邊啲經過 OAuth scope 嘅 API、最多使幾多錢、用咩憑證，全部喺協議層就規定死咗。
呢套思路最大嘅好處係 agent 失控嘅最壞情況係「可計算嘅」。$100 燒曬就停，token 用濫就回收，OAuth scope 以外嘅操作根本 call 唔通。將「萬一 agent 出事」從一個開放風險變成一個有邊界、可以買保險嘅事故。
將 agent 升級做 first-class 客戶類別
Cloudflare 呢步表面上係產品發佈，本質係 product positioning 嘅判斷 - 佢賭 agent 係一類新嘅客戶類型，需要專門嘅 onboarding、計費、TOS 路徑。
傳統 SaaS 客戶嘅畫像：人類，從 marketing → trial → 轉化 → 付費 → 增購，每一步都要做用戶研究、轉化率優化。呢套 funnel 唔適用於 agent。Agent 唔需要 marketing，佢就係一段 code、見到合適嘅 API 就 call。Agent 亦唔會做 trial - 佢一係需要呢個服務、一係唔需要。
所以 Cloudflare 為 agent 設計嘅係一條全新通道：
入口是 stripe projects catalog（取代 marketing landing page）註冊係自動 provisioning 加 OAuth（取代 sign-up form） 計費係預算 cap 加 token-based payment（取代信用卡加月度賬單） 監控係協議層 telemetry（取代 dashboard 加客服）
呢套設計嘅目標用戶特徵非常具體：高頻、小額、自動化、可監控、可即時叫停。每一筆交易可能就 1 蚊，但一個 agent 一日可能行幾百次。月度 GMV 加埋唔細，但每一筆都係 micro。
SaaS 行業過去 10 年冇認真做過呢種用戶。Stripe 加 Cloudflare 而家做嘅嘢，係將 micro-payment、scoped auth、自動 provisioning 呢三塊原本分散嘅能力封裝成一個標準協議。如果呢件事行得通，agent 經濟呢條線會從「agent call API」升級成「agent 係 buyer」。呢個係質嘅不同。
短期睇，呢個係 Cloudflare 搶先一步為 agent 經濟整咗個入口。長期睇，任何賣 infra 嘅公司遲早要做類似嘅嘢 - 唔係就被 agent 直接跳過。呢個係個先發優勢嘅賭注。
幾條應該重新評估嘅判斷
Provider 一定要為 agent 留入口。 如果你做 SaaS 或 API 產品，「係咪有 agent-friendly 嘅註冊同計費協議」喺未來 12 個月會變成評估標準。手動 dashboard 加複製貼上 token 呢條路對 agent 唔友好，等於自我邊緣化。stripe projects 呢類協議一旦擴散，冇接嘅 provider 會被 agent 直接跳過。
OAuth scope 係 agent 時代被低估嘅設計。 多數 OAuth 用法停留喺「授權一個 app」，但 agent 時代要細化到「授權呢個 agent 喺呢個 scope 內嘅具體操作」。Scope 設計直接決定 agent 安全嘅上限。而家重新審視一下你產品嘅 OAuth scope - 佢係為 app 寫嘅定係為 agent 寫嘅？
預算 cap 係新嘅安全邊界。 傳統安全邊界係「可以做啲乜」，agent 時代多咗一條「可以用幾多」。$100/月呢個預設值唔係數字遊戲 - 佢將「agent 失控嘅最壞情況」變成一個可承受、可保險、可量化嘅事故。任何令 agent 鬱錢嘅產品，預算 cap 都應該係默認機制，而唔係高級選項。
Agent-as-customer 係新嘅商業類別。 呢一類用戶嘅特徵係高頻小額、自動化、可監控、可即時叫停。SaaS 定價模式過去十年都係為人類設計嘅 - 月度訂閲、年度合約、tiered pricing。為 agent 用戶重新設計嘅話，可能會係按調用計價、按預算 cap 劃檔、按 scope 分級。等到大家都做緊呢件事嘅時候，先發嘅 Cloudflare 已經將標準定咗。
這周 Cloudflare 讓 agent 直接來註冊域名、刷信用卡、部署服務了。
聽起來像把控制權交了出去 - 給 agent 信用卡和 API token，那不就等於讓它失控嗎？
但拆開看其實不是。Cloudflare 把控制點從 agent 的執行邊緣挪到了協議層。這是個完全不一樣的 agent 安全哲學，也是 Cloudflare 在賭 agent 是一類新的客戶類型。值得仔細看一下。
agent 現在能幹什麼
Cloudflare 跟 Stripe 合作發了個新協議，叫 stripe projects。原話是：Starting today, agents can now be Cloudflare customers. They can create a Cloudflare account, start a paid subscription, register a domain, and get back an API token to deploy code right away.
具體動作就是三條命令：
stripe projects init
stripe projects catalog
stripe projects add cloudflare/registrar:domain第一行初始化項目，第二行查可用的 provider 和服務，第三行讓 agent 通過 Cloudflare 的 registrar 服務註冊一個域名。
flow 大致是：用戶先登 Stripe → 跑 stripe projects add ... → Stripe 作為 identity provider 驗身份 → Cloudflare 自動開賬號（如果還沒有），或者走標準 OAuth（已有賬號）→ Cloudflare 把 API token 發回 CLI，存在系統 keychain 裏 → agent 拿這個 token 直接調 Cloudflare API 部署。
這是一個 stripe projects 協議層的封裝，不僅是 Cloudflare 自己。理論上任何 provider 都能註冊成 stripe projects 的 catalog 項，agent 通過同一個 CLI 就能跨 provider 自由組合。Cloudflare 是首發合作方，但意思是要做一個標準。
繮繩藏在協議裏不在執行層
最容易引發的反應是："給 agent 信用卡？這不瘋了嗎？"
但 Cloudflare 沒真給信用卡。它把三道關挪進了協議層。
第一道是 OAuth 同意。用戶必須明確接受 Cloudflare TOS、批准 OAuth scope，agent 不能繞過。這跟傳統 OAuth 一樣，但意義不同 - 在傳統場景下 OAuth 是 "用戶授權一個 app"，這裏是 "用戶授權一個 agent 代表用戶行使賬號能力"。授權的顆粒度（域名註冊、賬單訂閲、API token 範圍）由 OAuth scope 決定，而不是給 agent 全權。
第二道是預算 cap。Stripe 給每個 provider 默認 $100/月上限，agent 花超就停。用戶可以調高，但默認是收緊的。這把 "agent 失控會怎樣" 這個最大恐懼從 "無限燒錢" 收口到 "最多 100 塊"。
第三道是憑證隔離。原話："Raw payment details like credit card numbers aren't ever shared with the agent." agent 拿到的是 opaque payment token，不是真正的卡號。token 失效或被濫用，可以即時回收，不影響用戶的卡。
三道關合起來，agent 拿到的不是 "信用卡"，是 "用戶授權的、範圍限定、有月度上限、用完就丟的代付能力"。控制點從執行邊緣挪到了協議邊緣 - agent 能調哪些經過 OAuth scope 的 API、最多花多少錢、用什麼憑證，全在協議層就規定死了。
這套思路最大的好處是 agent 失控的最壞情況是 "可計算的"。$100 燒光了就停，token 用濫了就回收，OAuth scope 之外的操作根本調不通。把 "萬一 agent 出事" 從一個開放風險變成一個有邊界的、能買保險的事故。
把 agent 升級為 first-class 客戶類別
Cloudflare 這步表面上是產品發佈，本質是 product positioning 的判斷 - 它在賭 agent 是一類新的客戶類型，需要專門的 onboarding、計費、TOS 路徑。
傳統 SaaS 客戶的畫像：人類，從 marketing → trial → 轉化 → 付費 → 增購，每一步都要做用戶研究、轉化率優化。這套 funnel 不適用於 agent。Agent 不需要 marketing，它就是一段代碼、看到合適的 API 就調。Agent 也不會做 trial - 它要麼需要這個服務、要麼不需要。
所以 Cloudflare 給 agent 設計的是一條全新通道：
入口是 stripe projects catalog（替代 marketing landing page）註冊是自動 provisioning 加 OAuth（替代 sign-up form） 計費是預算 cap 加 token-based payment（替代信用卡加月度賬單） 監控是協議層 telemetry（替代 dashboard 加客服）
這套設計的目標用戶特徵非常具體：高頻、小額、自動化、可監控、可即時叫停。每一筆交易可能就 1，但一個 agent 一天可能跑幾百次。月度 GMV 加起來不小，但每一筆都是 micro。
SaaS 行業過去 10 年沒認真做過這種用戶。Stripe 加 Cloudflare 現在做的事，是把 micro-payment、scoped auth、自動 provisioning 這三塊原本分散的能力封裝成一個標準協議。如果這件事跑通，agent 經濟這條線會從 "agent 調 API" 升級成 "agent 是 buyer"。這是質的不同。
短期看，這是 Cloudflare 搶先一步給 agent 經濟造了一個入口。長期看，任何賣 infra 的公司遲早要做類似的事 - 不然就被 agent 直接跳過去。這是個先發優勢的賭注。
幾條該重新評估的判斷
Provider 必須給 agent 留入口。 如果你做 SaaS 或 API 產品，"是否有 agent-friendly 的註冊和計費協議" 在未來 12 個月會變成評估標準。手動 dashboard 加複製粘貼 token 這條路對 agent 不友好，等於自我邊緣化。stripe projects 這種協議一旦擴散，沒接的 provider 會被 agent 直接跳過。
OAuth scope 是 agent 時代被低估的設計。 多數 OAuth 用法停留在 "授權一個 app"，但 agent 時代要細化到 "授權這個 agent 在這個 scope 內的具體操作"。Scope 設計直接決定 agent 安全的上限。現在重新審視一下你產品的 OAuth scope - 它是為 app 寫的還是為 agent 寫的？
預算 cap 是新的安全邊界。 傳統安全邊界是 "能做什麼"，agent 時代多了一條 "能花多少"。$100/月這個默認值不是數字遊戲 - 它把 "agent 失控的最壞情況" 變成了一個可承受的、可保險的、可量化的事故。任何讓 agent 動錢的產品，預算 cap 都該是默認機制不是高級選項。
Agent-as-customer 是新的商業類別。 這一類用戶的特徵是高頻小額、自動化、可監控、可即時叫停。SaaS 定價模式過去十年都是為人類設計的 - 月度訂閲、年度合約、tiered pricing。給 agent 用戶重新設計的話，可能是按調用計價、按預算 cap 劃檔、按 scope 分級。等到大家都在做這件事的時候，先發的 Cloudflare 已經把標準定了。