**摘要：**Cloudflare 在 2026 年 11 月 4 日由 Marina Elmore 與 Nicole Justus 發表的新功能，讓網站主人第一次能清楚看到哪些個人代理（personal agents）在代替人類訪問自己的網站，並針對個別代理設定不同的存取政策。對正在做代理產品或經營網站的 builder 來說，這等於多了一層預設的通行檢查站，值得提前理解它的運作方式。
從「不明自動化流量」變成「可以行動的情報」
問題的起點很實際：客戶請個人代理比價、找支援文章、完成購買，這三件事對網站主人來說全部長得一樣——就是自動化流量。Cloudflare 在公告中直指兩難：全部封鎖感覺最安全，但可能因此失去客戶；放行又不知道對方在做什麼。
這次的第一個改動是把 Cloudflare 自稱全球最大的 verified bot 目錄帶進流量分析。Security Analytics 裡的 Bot Analysis 圖表新增了 Personal Assistants 分類，與 Verified Bot、Likely Human、Likely Automated、Automated 並列。Top statistics 也多了一個 Personal Assistants widget，列出哪些代理在訪問、各發出多少請求。選定某個代理後，其他 widget 會跟著過濾，顯示它請求的路徑、收到的狀態碼、來自哪些網路——一眼就能看出它是登入中、讀商品頁、走到結帳，還是卡在它無法使用的頁面上。
把代理綁回使用者帳戶
只在流量層看代理還不夠，Cloudflare 另一條線是 Account Abuse Protection（目前為 early access）。對有保護使用者帳戶的網站，站長和詐欺團隊可以看到每個代理代表哪位使用者：population overview 顯示哪些個人代理活躍於你的使用者之間、多少帳戶在用它們；每次登入與註冊事件都會標記是否由個人代理發起、是哪一個。
對 Fraud 團隊最實用的細節是帳戶層的判斷：調查異常登入時，可以分辨這是客戶用了好幾週的代理，還是今天第一次出現、需要多看一眼的新代理。如果確認有攻擊者透過代理操作某帳戶，分析師可以直接用 WAF rule 針對該帳戶的 Hashed User ID 做處置，而不必封鎖其他人都依賴的同一個代理。
政策從整批轉向逐 Agent 設定
控制面的改動是這樣的：Cloudflare 今夏推出的 AI bot policies（讓站長分別設定 Search、Training、Agent 行為的存取）現在擴充 Agents policy，改名為 AI Crawler and Agent access policies。在 Security Settings 裡，你可以先設一個整體 Agents policy，再對每個支援的個人代理個別選擇：Allow（不封鎖）、Block on pages with ads、或 Block。既有的 Search 與 Training 政策不受影響。
新增 zone 時也能一併設定，onboarding 會先問你是否以廣告變現頁面，再依回答調整建議政策。公告刻意舉了兩種都是合理選擇的情境：一家出版社全站放行某代理方便讀者找文章，另一家在同一個代理上封鎖有廣告的頁面——正確政策取決於商業模式，不是技術對錯。
代理身分只是故事的一半
公告末段坦白交代了還沒解決的部分，這點值得肯定。網站認得出代理，但拿不到原本對使用者的了解：對方是不是既有客戶、授權了代理做什麼、有沒有訂閱、該套用哪些保護。Cloudflare 列出三個待解課題：以注重隱私的方式把使用者 context 傳過代理、讓網站評估代理的信譽、以及出事時的問責機制，並表示會隨著與代理營運方合作再公布更多。來源沒有提供任何採用數據，也沒列出「supported personal agents」具體是哪些。
Builder 接下來該做什麼
如果你經營網站，先到 Security Analytics 看看個人代理流量實際佔比，再到 Security Settings → AI Crawler and Agent access policies 決定政策，而不是沿用整批封鎖。如果你在做代理產品，要假設自己的流量會被識別、分類、個別設限——就像代理在終端機裡也需要明確的權限邊界一樣（可參考本站先前對 Claude Code 組織預設與 MCP 邊界補強的討論）。特別留意使用者 context 傳遞的後續設計：等到 Cloudflare 公布那套機制，代理能不能帶著使用者授權通過檢查站，很可能就決定你的產品被歡迎還是被封鎖。