這則新聞在講什麼： 2026 年 8 月 Cloudflare 的 Agents Week 發布了 agent 錢包等一系列功能，但真正結構性的改動，是 8 月 7 日發布的信任評分機制轉型——從「一次性驗證通過就放行」改成「每次請求都根據累積行為重新評分」。這跟一般認知裡「身份驗證 = agent 有沒有簽章、有沒有通過檢查」的靜態理解不同：新機制底下，通過檢查只是起點，agent 之後的每一次行為都在持續被納入評分考量，信任狀態本身是動態、會隨時變動的。
這跟表面上看起來的東西不同：多數報導把焦點放在「agent 終於有錢包了」，但錢包只是這波更新裡相對次要的部分，真正影響長期營運風險的是信任評分邏輯的轉型，這一點在多數報導裡幾乎沒有被展開。
為什麼 Cloudflare 要在這個時間點做這個改動： 直接的驅動因素是 Matthew Prince 公布的數據——自動化系統產生的 HTML 請求已佔 57.5%，比預期提早了約 18 個月出現。當自動化流量已經逼近甚至超越人類流量的規模，「在門口驗一次身份就放行」這種靜態模式的防禦效率會快速下降：一個惡意行為者只要通過一次驗證，之後就能長期利用這張通行證從事任何行為，防禦方完全沒有機會根據後續行為重新評估。
這也解釋了為什麼 Cloudflare 選擇在同一週把「錢」（Wallets）跟「持續信任評分」一起推出——當 agent 開始真正持有並移動資金，靜態驗證的風險就從「多幾筆垃圾流量」升級成「多幾筆真實的財務損失」，這個風險層級的變化，才是逼著整個防禦邏輯必須從一次性驗證轉向持續監控的根本原因。
具體機制怎麼運作： 這套持續信任評分機制底下，實際上疊了兩層技術。第一層是 Web Bot Auth 提供的身份層——用 RFC 9421 規範的 HTTP 訊息簽章，讓每個 agent 用專屬的 Ed25519 金鑰替每一次請求簽章，搭配 Signature-Agent 標頭跟公開金鑰目錄，讓伺服器端能確認「這個請求真的來自牠聲稱的那個 agent」。這一層在 2025 年就已經是生產環境的基礎設施，2026 年 8 月並沒有改變。
第二層才是這次真正的改動——〈Unveiling good and bad behaviors〉裡描述的持續行為評估。即使 agent 通過了第一層的簽章驗證（證明「牠是誰」），系統仍會持續觀察牠「做了什麼」：請求頻率、存取模式、有沒有觸碰不該碰的資源，這些行為資料會持續餵進信任評分模型。兩層機制合起來運作的結果是：身份是靜態的（金鑰簽了就是簽了），但信任是動態的（今天的良好行為不保證明天的信任分數）——這也是為什麼一個簽章完全正確、身份完全清白的 agent，還是可能因為行為模式改變而被重新分類。
對讀者的實際影響： 如果你在開發或維運任何會存取外部網站、API 的 agent 或自動化系統，這則新聞的實際意義是：你不能再把「身份驗證做對了」當成一勞永逸的安全清單項目，而要把它變成一個需要持續追蹤的營運風險。具體行動包括：對照本文提供的四項稽核清單（域名 SPF/DKIM/DMARC 是否對齊、網站內容是否不需 JavaScript 就能被讀取、定價/整合/安全頁面是否用文字而非圖片或 PDF 陳述、任何自動化爬蟲或瀏覽行為是否有簽章）逐一檢查一次；如果你的資料蒐集或爬蟲工作外包給第三方供應商，主動要求對方書面確認簽章狀態，而不是預設「供應商應該處理好了」。
更長期的意義是：這套機制目前還建立在一份尚未定案的草案標準之上，Cloudflare 跟 IETF 草案之間甚至存在實作衝突（字典格式 vs 結構化字串格式），意味著近期內你的 agent 有一定機率會因為規格本身的變動而觸發非預期的驗證失敗——這不是你的程式碼有問題，而是整個生態系還在快速變動中，值得預先設好監控跟告警，而不是等到流量無故下滑才回頭排查。
2026 年 8 月 3 日到 7 日這一週，Cloudflare 辦了一場「Agents Week」，密集發布了一系列跟 agent 身份與資金相關的新功能——Cloudflare Wallets（可程式化 agent 錢包）、cloudflare.pay（agent 的商戶端識別代號）、Agent Access Model（存取權限框架）。但這週真正該被記住的一天，其實是 8 月 7 日發布的〈Unveiling good and bad behaviors on the Agentic Internet〉——這篇文章把 Cloudflare 的機器人防禦邏輯，從「一次性風險評分」徹底改成「持續信任評分」，這個改動比錢包本身影響更深遠，卻在多數媒體報導裡被輕輕帶過。
過去的機器人防禦邏輯，本質上是「訪客在門口出示一次憑證，驗證通過就放行」——這正是 最小權限原則 在傳統存取控制裡的典型體現：一次授權，之後就照著授權範圍執行。Cloudflare 這次的改動，把整個邏輯換成了「訪客的每一次請求都會被重新評估」，評估依據是牠一路以來的行為模式，而不是牠當初出示的那張憑證。這代表一個過去兩年爬蟲行為一直很乾淨的資料供應商，可能在下個月因為行為模式的變化被重新分類，而且不會有任何事先警告，也不會有人主動通知你。任何你的團隊在跑的瀏覽器自動化也適用同樣邏輯——通過第一關檢查，不再等於拿到終點線的門票；系統評估的對象，變成了一整串持續發生的行為，而不是一次性的憑證。
多數報導把 8 月的公告當成「agent 身份驗證」剛剛起步，但實際時間線完全不是這樣。Cloudflare 早在 2025 年 5 月就提出了 Web Bot Auth，讓自動化用戶端能用 RFC 9421 規範的 HTTP 訊息簽章，搭配每個 agent 一組 Ed25519 金鑰、Signature-Agent 標頭，以及一份公開金鑰目錄，對每一次 HTTP 請求進行簽章。2025 年 8 月，Cloudflare 就已經公布第一批簽章 agent 合作夥伴，包括 Block 的 Goose、Browserbase、Anchor Browser。緊接著 AWS WAF Bot Control 在 2025 年 11 月跟進支援，Vercel、Akamai、Stytch、Shopify 也陸續加入，連 Google 都為自己的 agent 流量做了實驗性實作。
更少被提及的是，2025 年 10 月 14 日，Cloudflare 就已經跟主要支付網路合作，基於 Web Bot Auth 建構 agentic commerce 的驗證層——Visa 把它整合進 Trusted Agent Protocol 與 Visa Intelligent Commerce，Mastercard 整合進 Agent Pay，American Express 也承諾在自家 agentic commerce 計畫中採用。換句話說，「這個 agent 能不能證明自己的身份」這個問題，早在 2026 年 8 月的錢包功能上線之前，就已經是產線上運作中的基礎設施——8 月真正新增的，只是「錢」這個部分。
2026 年 6 月 3 日，Cloudflare CEO Matthew Prince 公布 Radar 數據，指出全球自動化系統產生的 HTML 內容 HTTP 請求已佔 57.5%，人類只佔 42.5%——他曾在 3 月的 SXSW 上預測這個交叉點會在 2027 年底左右出現，結果提早了大約 18 個月。但這個數字有個容易被忽略的限定條件：這個測量範圍僅限於 Cloudflare 網路上的 HTML 頁面請求，不是所有網路流量。同一段時間，Cloudflare 的全流量機器人指標大約落在 35.2%——HTML 請求會排除圖片、腳本、API 呼叫、影音、遊戲，而這些正是人類產生流量佔比明顯更高的類別。任何人跟你說「機器人佔了網路流量的 57%」，等於是拿掉了分母、把數字誇大了大約 1.6 倍。
Web Bot Auth 目前還稱不上是一個正式標準——IETF 在 2026 年初才為它成立工作組，截至 2026 年 8 月 12 日，這個工作組還沒有正式採納任何一份文件，目前所有進行中的內容都還只是個人提交的草案。與此同時，Cloudflare、AWS、Akamai、HUMAN、Vercel 每天都在正式環境中驗證這些簽章，決定哪些 agent 能存取哪些網站。2026 年 8 月 6 日修訂的架構草案，已經把工作內容轉移到 Standards Track，並要求簽章方必須用字典格式（dictionary form）傳送 Signature-Agent 標頭；但 Cloudflare 目前公開的驗證規則，仍然要求實作者使用結構化字串（structured string）格式，並把字典格式視為請求失敗的理由。這代表如果你照著最新草案實作，Cloudflare 會拒絕你的請求；如果你照著 Cloudflare 現行文件實作，你等於是在對一份已經過時的規格寫程式碼——不管選哪一邊，都得有人花時間去踩這個坑，這正是「先於標準上線」在實務上要付出的代價。
如果你的 agent 需要爬取網頁、呼叫第三方 API，或是代表使用者跟商戶端互動，持續信任評分機制改變的是一個關鍵前提：過去「通過一次驗證就能持續運作」的假設不再成立。你的 agent 現在暴露在三個層面：發送端的身份基礎設施（域名、金鑰、簽章是否齊全）、自動化資料蒐集（你依賴的任何第三方爬蟲或資料供應商是否簽章、以誰的身份簽章）、以及與平台互動的自動化行為模式本身（持續被評估，而非驗證一次就結束）。一個團隊可能發送端的簽章跟驗證都做得無懈可擊，卻因為使用了一個從未被稽核過的第三方資料供應商，而在完全不知情的情況下被判定為不受信任的流量來源。
如果你的 agent 或自動化系統需要長期穩定地存取外部網站、API 或平台，持續信任評分帶來的風險是「今天正常運作的東西，明天可能無預警地被降級或封鎖」，而你可能要等到出現異常症狀（例如某個資料來源品質突然變差、某個工具突然開始被拒絕存取）才會發現問題已經發生一段時間。實際能做的事：確認你的 agent 或自動化流程是否有做 Web Bot Auth 簽章（如果答案是「外部供應商在處理」，務必要求對方明確書面確認，而不是預設對方已經處理好）；如果你的 agent 依賴任何資料蒐集服務，主動詢問對方是否簽章、用誰的身份簽章——誠實的供應商會直接給答案，含糊其辭的回答本身就是一個警訊；把「持續信任評分」當成一個長期要追蹤的風險項目，而不是一次性檢查完就能放著不管的事。