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 副作用调校的检测器会悄悄漏报。持续观察该信号的命中率，并更多依靠与协议无关的信号，才能保持覆盖稳定。
