WebDriver BiDi 是讓 Puppeteer 等工具自動化 Chrome 與 Firefox 的 W3C 標準。解析它對機器人偵測的影響。
多年來，「自動化 Chrome」幾乎等同於「使用 Chrome DevTools Protocol」。這個局面正在改變：WebDriver BiDi 是一套 W3C 標準協定，讓自動化工具在多個瀏覽器中取得同樣即時、事件驅動的控制能力。無論你是做自動化偵測的，還是 CI 工作階段老是被誤判的，關鍵問題都一樣：原本依附在舊通道上的那些訊號會怎樣。本文說明 BiDi 是什麼、它削弱了哪些偵測訊號，又有哪些訊號完全不受影響。
核心要點
- WebDriver BiDi 是標準化的雙向協定。 它建立在 WebSocket 之上，允許瀏覽器主動向自動化用戶端推送事件，由 W3C 瀏覽器測試與工具工作小組制定。該規範目前仍是工作草案（Working Draft）。
- 它的目標是取代「一切都用 CDP」的習慣。 CDP 與 Chrome DevTools 綁定，並非公開的共用標準，而 BiDi 把 WebDriver Classic 的跨瀏覽器標準化與 CDP 式的底層、事件驅動控制結合在一起。
- 有一類訊號會被削弱。 依賴 CDP 自身副作用的偵測，例如我們的 CDP 自動化偵測指南中談到的
Runtime.enable行為，在同一腳本改用 BiDi 驅動瀏覽器時可能什麼都觀察不到。 - 偵測體系的大部分並不在意協定。
navigator.webdriver、無頭渲染差異、行為時序與網路層指紋描述的是瀏覽器及其流量，而不是自動化用戶端使用的傳輸格式。 - 正確的因應是分層評分，而不是依賴單一破綻。防禦方應把「存在 CDP 副作用」視為一項輸入，並預期它觸發的頻率會逐漸降低。
WebDriver BiDi 是什麼
WebDriver 有兩代。WebDriver Classic 是 Selenium 起家時使用的請求—回應式協定：用戶端送出指令，瀏覽器回應，期間發生的任何事情都需要用戶端輪詢。Chrome DevTools Protocol（CDP）則是相反的取捨：快速、雙向、底層，但為 Chrome 自己的 DevTools 設計，並不是共用的公開標準。
WebDriver BiDi 規範希望兼取兩者之長。用 Chrome 團隊介紹該協定的文章的話來說，它是一種新的標準自動化協定，旨在結合 WebDriver Classic 與 CDP 的優點：雙向訊息、底層控制，並且有 W3C 標準作後盾。「雙向」意味著瀏覽器可以在主控台訊息、網路請求或頁面導覽發生的瞬間就把事件推送給用戶端，而不必等用戶端來詢問。
同一篇文章明確指出，BiDi 並不是換了名字的 CDP。CDP 中含有 Chrome 與 DevTools 特有的部分，無法照搬進跨瀏覽器規範；而且由於用戶端與瀏覽器不一定在同一台機器上，BiDi 必須盡量減少往返次數。這種設計壓力使 BiDi 的指令與事件和 CDP 不同，這對偵測很重要，因為可被觀察到的副作用也隨之不同。
目前的採用情況
採用進度以各工具自己的公告為準，所以應當引用日期，而不是臆測路線圖。Chrome 團隊關於 WebDriver BiDi 達到正式可用的文章指出，Firefox 129 與 Puppeteer 23 各自獲得了正式可用的支援：從 Puppeteer 23 起，它透過 BiDi 提供穩定的 Firefox 自動化，同時其 CDP 支援維持不變。
在此之前，Puppeteer 對 Firefox 的支援仰賴 Mozilla 在 Firefox 中實作並維護 CDP 的一個子集，文章稱這只是權宜之計，無法保證完整的 Puppeteer API。BiDi 以共用標準取代了這種安排。實際含義是：Firefox 自動化率先轉向 BiDi，而透過 Puppeteer 的 Chromium 自動化仍常使用 CDP。「取代 CDP」是一個方向，而不是已經完成的切換。在斷定某個工作階段用的是哪種協定之前，請先查看你所用框架目前的發行說明。
對偵測有哪些改變
與偵測相關的變化範圍很窄，值得說準確。那些透過 CDP 在渲染程序內部造成的效果來推斷「有 CDP 用戶端已連線」的技術，例如我們的 CDP 偵測指南所描述的旁路訊號，依賴於某個 CDP 網域被啟用。如果腳本透過 BiDi 驅動瀏覽器，這些特定效果可能根本不會出現。僅依賴這一項檢查的偵測器會看到更少的命中，並不是因為流量變得像人，而是因為控制通道變了。
有兩點需要注意，以免高估這項變化。第一，BiDi 的實作還很新，具體某個框架或瀏覽器建置如何設定工作階段屬於實作細節，可能隨版本變化；關於特定工具的說法，應對照其文件確認。第二，一個瀏覽器可以同時被多種協定驅動，一些框架在 BiDi 尚未涵蓋的功能上仍會與 BiDi 並用 CDP，所以使用了 BiDi 並不自動等於工作階段中沒有 CDP。
無論用哪種協定都仍可偵測的訊號
協定只是自動化用戶端與瀏覽器之間的傳輸通道。凡是描述瀏覽器本身及其行為的訊號，都不受影響。
| 訊號 | 為什麼協定改變不了它 |
|---|---|
navigator.webdriver | WebDriver 規範為受遠端控制的瀏覽器定義了「webdriver-active」狀態，BiDi 的工作階段處理會設定與清除它。某個工作階段是否暴露該旗標取決於瀏覽器與框架，請確認而不要假設。 |
| 無頭渲染破綻 | 軟體渲染圖形、缺少外掛與視窗尺寸預設值都源於瀏覽器的啟動方式。參見無頭瀏覽器偵測。 |
| 行為時序 | 過於規律的輸入時序與缺少的指標移動是腳本本身的屬性。參見行為機器人偵測。 |
| 網路層指紋 | TLS 與 HTTP/2 指紋來自瀏覽器的網路堆疊以及 IP 信譽，而不是控制通道。 |
這正是成熟的偵測體系把許多弱訊號合併評分的原因。失去一類訊號在意料之中；自動化檢測技術總覽展示了這一體系的其餘部分。
如果你執行自動化卻被標記
測試工程師與監控團隊往往是被偵測「誤傷」的一方：合法的 CI 任務被擋在驗證頁面前。換協定不是解決辦法，本文也不這樣建議。真正有用的做法都很樸素：只在你自己掌控或已獲授權測試的網站上執行測試套件；與網站擁有者協商，把 CI 的 IP 範圍加入白名單；如果對方提供官方認可的接入方式，就使用它。歡迎自動化流量的服務通常會提供讓用戶端表明身分的途徑，例如 API 或簽章請求，這遠比設法偽裝成真人可靠。我們關於 AI 瀏覽智能體的文章討論了「機器人」與「替人辦事的軟體」之間的界線正如何被重新劃定。
想看看你自己的瀏覽器工作階段暴露了什麼，請開啟機器人偵測工具：它會列出目前工作階段觸發了哪些自動化旗標，這與真實偵測體系所組合的檢查屬於同一類。
常見問題
WebDriver BiDi 會取代 CDP 嗎？
並非完全取代，也還沒有在所有地方取代。BiDi 是一項標準，旨在為跨瀏覽器自動化提供過去主要來自 CDP 的事件驅動控制。Firefox 129 與 Puppeteer 23 已達到正式可用的 BiDi 支援，但 Puppeteer 的 CDP 支援依然保留，Chromium 自動化往往仍在使用它。
BiDi 能讓自動化變得無法偵測嗎？
不能。它去掉的是一類訊號，即已連線 CDP 用戶端帶來的副作用，但 navigator.webdriver、無頭渲染差異、行為時序與網路指紋都與承載指令的協定無關。
在 BiDi 下 navigator.webdriver 還會出現嗎？
WebDriver 規範把該屬性與瀏覽器處於遠端控制狀態連結在一起，BiDi 工作階段同樣參與「webdriver-active」機制。具體某個瀏覽器建置或框架如何設定它可能不同，所以請查閱你所用確切版本的文件，而不要想當然。
BiDi 為什麼對防禦方重要？
因為隨著更多流量遷移到 BiDi，針對 CDP 副作用調校的偵測器會悄悄漏報。持續觀察該訊號的命中率，並更多依靠與協定無關的訊號，才能維持涵蓋率穩定。
