Cloudflare 推出 Monetization Gateway：用 x402 協定讓邊緣節點直接收費
Cloudflare Blog · 2026-07-01
背景
Cloudflare 於 2026 年 7 月 1 日發布 Monetization Gateway，讓客戶可以針對網頁、資料集、API 或 MCP 工具設定付費存取門檻，而不需要自己架設金流系統。促成這個產品的直接原因是 AI 爬蟲對內容站台的流量結構已經失衡：Cloudflare 觀察到，AI 爬蟲每替一個網站帶來一次真人訪客，會先發出「數百次到數萬次」的抓取請求，傳統的廣告或訂閱模式完全無法對這類流量收費。過去網站要嘛完全開放、要嘛用 robots.txt 或防火牆整台擋掉，中間缺乏一個「單次請求計價」的機制。
核心改動
Monetization Gateway 的底層是 x402 協定，這是一個重新啟用 HTTP 402 Payment Required 狀態碼的付款交換流程，由 x402 基金會（掛在 Linux Foundation 底下，Cloudflare 是 25 個以上發起成員之一）維護規格，原始程式碼放在 coinbase/x402。流程是：客戶端對受保護資源發出請求，伺服器回傳 402 並附上價格與可接受的資產類型；客戶端完成付款後帶著付款證明重送請求；一個稱為 facilitator 的角色負責驗證這筆付款，驗證通過才把資源交還給客戶端。結算走區塊鏈上的點對點交易，鎖定穩定幣（stablecoin）作為計價與支付單位，目標是達到次秒等級的結算速度。
x402 的關鍵設計哲學是「付款本身就是憑證」，買方完全不需要在賣方那裡預先開帳號、走 KYC 或簽長期合約，這與現行 API 金鑰、訂閱制的商業模式明顯不同。在 Cloudflare 的實作裡，站台可以用類似既有防火牆規則的表達式語法，決定哪些流量要被攔下要求付款；也支援針對不同 REST 動詞分開計價、依請求複雜度浮動定價，甚至把既有的 401 Unauthorized 回應攔截後改寫成 402。
影響範圍
由於 Cloudflare 的邊緣網路涵蓋 330 個以上城市，付款驗證與門檻判斷可以直接在離使用者最近的節點完成，不需要每筆請求都回源站確認，這對於本來就用 Cloudflare 做 CDN/WAF 的網站來說等於是免加裝就能開通的計費層。目前產品仍在等候名單階段，Cloudflare 尚未公布正式的按量收費費率或上線時程；但把 402 這個沉寂多年的 HTTP 狀態碼重新標準化，等於是替「AI 代理人自動幫使用者付費瀏覽/呼叫 API」這件事鋪好了通用的協定層。
原始來源：Cloudflare Blog：Announcing the Monetization Gateway、x402.org 協定總覽、coinbase/x402 GitHub
Meta 重寫 AI 儲存架構：拿掉 dataplane proxy，把 metadata 攤平成單層 schema
Meta Engineering · 2026-07-01
原本的問題
Meta 工程團隊在 2026 年 7 月 1 日發表的文章中，回顧了支撐「數十萬顆 GPU」同時訓練、橫跨「數百個 exabyte 等級儲存叢集」的 AI 儲存系統演進過程。核心痛點有兩個：一是儲存效能追不上運算成長，GPU 常常因為等資料而閒置；二是研究人員在訓練工作真正開始前，得先花好幾個小時把資料集在不同地區之間搬運、灌入。舊架構是多層 metadata 系統疊加 dataplane proxy 轉發資料，每一層都會疊加延遲。
採用的方法
新架構把 metadata 從多層結構攤平成單一 flat schema，統一交給 ZippyDB 這個 metadata store 管理，支援 O(1) 的查找。資料層則建立在 Tectonic（區域型、多租戶的底層區塊儲存，支援 erasure coding 與媒介分層）之上，再疊一層叫 BLOB-storage 的全域無限擴展儲存介面。
最關鍵的改動是拿掉 dataplane proxy，改用內嵌在客戶端 SDK 裡的「胖客戶端（fat client）」直接對儲存節點串流讀寫，省掉一層轉發。同時架構從「預設全域」改成「預設區域部署」，資料盡量留在計算發生的區域，減少跨區搬移；再搭配 Owl 這個分散式內容快取子系統，在客戶端 SDK 內建多層快取：主機記憶體（L1）、本機 flash（L2）、區域 flash（L3）、全域 HDD（最後一層）。
實際效果
文章提到分散式資料快取（Owl）平均命中率達到 80%，大幅降低對底層儲存叢集的直接讀取壓力；透過 readplan cache，metadata 存取延遲壓到 1 至 2 毫秒。文中的 Figure 5 也顯示改版後資料集的 ingestion 時間有明顯縮短，但原文未附上具體改善倍數的數字。這套架構同時對應了 Meta 過去發表的 ZippyDB（2021 年 8 月技術文章）與 Owl 子系統（2022 年 7 月文章），可視為兩者在 AI 訓練規模下的整合升級版本。
Google 發布 ADK Go 2.0：以圖形化工作流引擎統一單一 Agent 與多 Agent 執行模型
Google Developers Blog · 2026-06-30
背景
Google 於 2026 年 6 月 30 日在 Google Developers Blog 發布 ADK Go 2.0。ADK（Agent Development Kit）是 Google 提供的多語言框架，讓開發者用各自熟悉語言的慣用寫法（idiomatic patterns）建構正式環境等級的 AI Agent 應用，Go 版本強調強型別與事件串流，方便嵌入既有的 Go 後端服務。過去用一般程式邏輯手動串接多個 Agent 的協作順序，遇到「執行順序要等模型講完話才知道」這種動態情境時，程式碼會變得又長又難維護。
核心改動
ADK Go 2.0 最主要的新增功能是圖形化工作流引擎（graph-based workflow engine），把應用程式表示成一組互相連接的節點（node），而不是寫死的呼叫順序，藉此讓複雜的 Agent 行為可以用宣告式的方式組裝與除錯。官方釋出的最小範例如下：
upper := workflow.NewFunctionNode("upper", upperFn, cfg)
suffix := workflow.NewFunctionNode("suffix", suffixFn, cfg)
edges := workflow.Chain(workflow.Start, upper, suffix)
wf, _ := workflowagent.New(workflowagent.Config{
Name: "simple_sequence_workflow",
Edges: edges,
})這個版本同時內建人機協作（human-in-the-loop）作為一級原語：任何節點都能暫停執行、等待人類輸入，靠 durable state 管理讓工作流在中斷或服務重啟後仍可從原點恢復，不必整條流程重跑。另外新增 Chat、Task、SingleTurn 三種 LLM Agent 模式，讓協調者（coordinator）Agent 一邊跟使用者聊天，一邊指派子 Agent 安靜地完成任務或做單輪推論，並依角色自動掛載對應的工具集。
影響範圍
ADK Go 2.0 引入統一節點執行模型（unified node runtime），讓單一 Agent 與完整的工作流圖跑在同一套執行機制上，共用一致的 telemetry 與 agent.Context 型別，開發者不必為「單體 Agent」和「多 Agent 圖」維護兩套邏輯。ADK Go 延續與 Python、Java 版本一致的設計原則，並支援 Agent2Agent（A2A） 協定，讓不同語言寫成的 Agent 可以互相協作。程式碼與版本紀錄公開在 google/adk-go 的 v2.0.0 release，並附有從 1.0 遷移的說明文件。
原始來源：Google Developers Blog：Build reliable multi-agent applications with ADK Go 2.0、google/adk-go v2.0.0 Release