什麼是 Agentic Commerce？為什麼你的網站會攔截它

一位顧客請助手去找一個替換用的濾水芯，比較三家賣家，然後買下週末前能送到的最便宜的那一個。助手開啟瀏覽器， 逐頁瀏覽你的商品頁，把一件商品放進購物車，然後走向結帳。你為了擋住抓取程式而寫下的每一條規則，都在旁觀這次 工作階段並對它作出判斷。這個判斷很有可能是錯的。

這就是代理式商務，而今天它又多了一道障礙。Cloudflare 的新流量預設設定自 2026 年 9 月 15 日起生效，Agent 是 其中兩個在展示廣告的頁面上預設被攔截的類別之一。

代理式商務究竟指什麼

代理式商務是指由軟件替某個人完成的購物：它搜尋、在賣家之間比較、套用對方給出的條件、填滿購物車，有時更會付 款。這個人給出的是一個結果（「四十元以內，星期五之前送到」），而不是一條查詢語句，點擊的工夫交給代理。

這句話裏真正關鍵的詞是行動。過去兩年多數網站爭論不休的那一類 AI 流量，由頭到尾只做一件事，就是讀：

前兩者屬於內容權利問題和 SEO 問題，已在 Cloudflare 的爬蟲預設設定對你的網站有何影響 中討論過。代理兩者都不是。它是一位從陌生管道走進來的顧客，把它擋下損失的是訂單，而不是一次引用。

它實際送出的是什麼流量

HUMAN Security 的 2026 年基準報告以 2025 年超過一千萬億次互動為基礎，給出目前最清晰的公開圖景。AI 驅動的流 量在 2025 年 1 月至 12 月之間增長了 187%，自動化流量目前的增速約為人類流量的八倍。

更有用的部分是這些流量落在哪裏。整個 2025 年，代理式活動的分佈如下：

• 77% 落在商品頁和搜尋頁
• 8.8% 落在帳戶頁
• 5% 落在身分驗證流程
• 2.3% 落在結帳環節

到 2026 年 4 月，HUMAN 認為代理式瀏覽器，也就是由程式驅動的真實瀏覽器而非腳本化的 HTTP 客戶端，已佔全部代理 式流量的接近四分之三。

把這些數字合起來讀，畫面就很具體了。絕大部分是瀏覽，它看起來像瀏覽，是因為它確實發生在一個真實瀏覽器裏，而 只有很窄的一條抵達真正付款的頁面。你正在裁決的大多數請求並不是購買嘗試，而是有可能變成購買的資料搜集。

你現有的規則為什麼會攔住它

沒有人專門坐下來決定要把購物代理擋在門外。做出這個動作的規則是為另一個問題而寫的，而它們的推廣能力很差。

來自數據中心的來源。 代理工作階段經常跑在雲端基礎設施上而不是家用寬頻上，而那恰好是多數網站視為可疑的位 址空間。這條經驗法則是針對租伺服器的抓取程式而建立的，它分不清抓取程式和一個正在跑腿的託管助手。 辨識雲端與主機託管 IP 講的是同一個陷阱：來源只告訴你在哪裏，永 遠不會告訴你為什麼。

無頭與自動化標記。 被驅動的瀏覽器會留下痕跡，而多數系統預設把這些痕跡當作敵意。

速度。 一個要比較四家賣家的代理，讀頁面比人快，於是撞上了按人類閱讀速度設定的限制。

驗證挑戰。 互動式驗證的前提是有人在場把它解開。在代理式商務裏確實有人，只是不在鍵盤前，而這恰恰是驗證流 程處理得最差的情形。

在自動化還意味着有人抄你的商品目錄的年代，上面每一條都算合理。其後 Cloudflare 9 月 15 日的預設設定再疊加上 來，帶着一個明確的 Agent 分類，在展示廣告的頁面上預設攔截：適用於新客戶、新加入的網站，以及未更改該設定的免 費方案帳戶。一個混合了多種用途卻不加區分的爬蟲，會按其任一行為所適用的最嚴格規則處理。

司法這條路剛剛關上了

不少商戶原本以為這件事會在法庭上解決。它確實被檢驗過，而答案指向了另一邊。

亞馬遜於 2025 年 11 月就 Comet 瀏覽器入稟控告 Perplexity，指控之一是該代理送出了與 Google Chrome 相同的 User-Agent 字串，而沒有表明自己的身分。地區法院在 2026 年 3 月 9 日頒下初步禁制令。2026 年 8 月 4 日，第九巡 迴上訴法院撤銷該禁制令，認定當一個人指示助手在 Amazon.com 上完成某項任務時，存取亞馬遜電腦的是使用者而不是 Perplexity，助手在其中充當工具。法院並未就 User-Agent 字串是否被蓄意更改這一事實爭議作出裁斷。

由此可以得出兩點。面對一個由顧客主動要求去行動的代理，電腦犯罪法例是一根很弱的槓桿，因此放誰進來這個決定屬 於你，要靠技術手段和服務條款去落實。而在唯一一宗由大型零售商詳細量度過此事的案件裏，處於爭議中心的恰恰是營 運方自己的識別字串。用代理「自稱什麼」來辨識它，問題正在於此。

代理與攻擊者的分界線在哪裏

所有人最先伸手去抓的那個訊號，恰恰是客戶端唯一能自行控制的訊號。User-Agent 由傳送方書寫，所以它是一項聲稱而 不是證據，任何標頭同理。真正站得住的，是那些從客戶端如何被建構中自然流露出來、而非它決定要說什麼的屬性：

沒有任何單獨一行能定案。一個主機託管 IP 不是判決，被驅動的瀏覽器也不是，因為那既能描述購物代理，也能描述一 場撞庫。橫着把幾行連起來讀，含糊之處通常就化解了：一個來自會公佈位址範圍的營運方、落在商品頁、維持單一工作 階段的代理，和一個無從核實、反覆試探你登入表單的數據中心位址，並不是同一類事件。 完整的驗證機制因營運方而異，值得認真做對。

這正是 Agentscan 在一次呼叫裏完成的事。它傳回一個類別，human、known_bot、ai_agent 或 malicious_automation，附帶信心值和支撐判定的訊號，把 IP 來源與無頭標記、JA4 指紋以及一份經反向 DNS 核實的 放行名單融合在一起。命中快取的判定在 50 毫秒內傳回，這才使得這個決定能放進一個中介軟件環節，而不是第二天早 上的日誌覆檢。

一套經得起真實流量考驗的策略

1. 按路由決定，而不是按網站決定。 流量分佈已經說明：代理活動絕大多數落在商品頁和搜尋頁，落在結帳上的極 少。放代理去讀商品目錄，把真正的審查留給登入和付款，策略就對準了風險真正所在的位置。
2. 把四個問題分開問。 它是否自動化、它是誰的代理、背後是否有已登入的人、它正在做什麼？單一的放行或攔截 開關會把四個問題壓成一個答案，而其中三個會答錯。
3. 絕不要只憑名稱放行。 ChatGPT-User 誰都可以送出。按營運方放行，然後把來源位址與該營運方公佈的內容核 對，否則這份名單就成了任何讀過它文件的人的通行證。
4. 有意識地檢查你的 Cloudflare 設定。 如果你使用免費方案，或最近新增了網站而從未動過 AI 流量控制項，9 月 15 日的預設設定現在已經對你生效。這是否合適，取決於你是否在賣東西，而預設值並不知道這一點。
5. 即使放行也要記錄類別。 那些真正轉化了的代理工作階段，有意去找才找得到。你無法對一個從未標註過的分群 做分析，「有多少收入是透過代理進來的」會在一個季度之後變成一個無法回答的問題。

小結

代理式商務不是換了個名字的爬蟲問題。訓練爬蟲從你這裏拿走東西，搜尋爬蟲用引用換取存取，而代理是一位帶着替他 點擊的軟件出現的顧客。你現有的規則分不清它們，因為這些規則是為回答「這次工作階段是否自動化」而建的，而那已 經不再是值得問的問題。司法這條路在 8 月關上，基礎設施的預設值在今天翻轉，剩下的正是一直以來真正要緊的部分： 先把這些流量歸類，再按路由決定每一類可以做什麼，並且讓兩者都建立在客戶端無權替自己書寫的訊號之上。