什么是 WebDriver BiDi？

Scrapeless Agent Browser 公开了一个 CDP 连接，用于托管浏览器自动化和动态页面交互。

WebDriver BiDi 是一种浏览器自动化协议，通过双向连接支持来自客户端的命令和来自浏览器的事件。名称 BiDi 意为双向。该协议使控制软件能够在浏览器活动发生时进行观察，而不必将每一次观察都表达为对浏览器当前状态的单独请求。

WebDriver BiDi 是一项正在制定中的 W3C 规范，其实现支持在不同浏览器、客户端库和功能之间存在差异。应将该协议视为一个已定义的自动化接口，然后再验证你的项目所需要的具体操作。使用 WebSocket 的浏览器连接并不足以证明该连接使用的是 BiDi 协议。

为什么浏览器自动化需要事件

浏览器事件使自动化能够观察不是由下一个客户端命令发起的活动。页面可以在客户端执行其他工作时写入控制台消息、打开另一个浏览上下文，或发起网络请求。

在命令与响应的交互中，客户端请求一个操作或状态并接收结果。该模型在导航和元素交互方面仍然很有用。当客户端需要由浏览器独立生成的一系列观测流时，这种方式就不那么直接了。

该 WebDriver BiDi 规范 定义了双向机制及其命令和事件。该事件模型有助于表达诸如在整个工作流中收集相关日志之类的任务，而不是仅在某个操作完成后再进行检查。

事件并不能消除对完成规则的需求。控制台消息可能是有用的诊断证据，但不足以证明应用程序已就绪。请确定哪个事件或页面条件对应于任务所期望的状态。

命令、结果和事件具有不同的角色

BiDi 命令用于请求浏览器操作，命令响应用于报告其结果，而事件用于描述传递给已订阅客户端的浏览器活动。保持这些角色的区分可以防止对消息顺序做出错误假设。

客户端可能会在其他浏览器活动已经进行时发送一个操作。根据浏览器当前正在执行的任务，连接可以在命令响应之前或之后传输事件。请将命令响应与其请求进行关联，并通过相关的上下文和订阅来解释事件。

不要将任何消息的到达视为执行操作的许可。与导航相关的事件、脚本结果和日志条目回答的是不同的问题。你的客户端需要将观察结果与其所涉及的页面和动作关联起来。

对于诊断工作流，请定义观察窗口。在要监控的活动开始之前订阅，保留解释该活动所需的信息，并在作业不再需要时释放订阅。否则，一个长时间运行的客户端可能会累积来自无关工作的观测信息。

浏览上下文为事件提供位置

浏览上下文标识浏览器活动发生的位置，例如顶级页面或嵌入的框架。当多个页面可能触发相似事件时，上下文身份就变得很重要。

弹出窗口可能属于与打开它的页面不同的顶级上下文。iframe 可以在父页面中独立导航。如果你的客户端假定每个事件都属于最初打开的文档，它可能会将错误的证据附加到某个抽取或测试上。

跟踪任务所需的上下文，而不是仅依赖可见标题。标题和 URL 可能会变化，并且不同的上下文可能会临时显示相同的地址。上下文标识符提供协议层面的引用，而 URL 和标题则提供有用的、便于人类理解的上下文。

导航也会影响脚本环境。从一个文档中获得的值不应被假定为描述同一标签页中后续的文档。请围绕上下文及其当前文档的生命周期来构建工作流。

经典 WebDriver、BiDi 和 CDP 是不同的接口

经典 WebDriver、WebDriver BiDi 和 Chrome DevTools 协议提供了不同的浏览器控制接口。一个库可以支持多种接口，但必须针对特定浏览器和操作建立相应的支持。

The WebDriver 远程接口 仍然是理解经典会话和命令的基础。BiDi 添加的是一个标准化的双向协议，而不是让每一个现有的命令名称或传输方式都可以互换。

WebSocket 是一种传输方式，而不是兼容性保证。CDP 端点和 BiDi 端点都可以使用持久连接，同时接受不同的消息。将一种协议的命令发送给另一种协议并不是迁移策略。

订阅范围如何改变可观测性

订阅决定在协议的事件规则下，客户端会接收到哪些浏览器事件。一个有用的订阅应当包含工作流所需的观测数据，并排除不必要的活动。

考虑这样一个测试：它打开一个已授权的应用页面并检查某条必需记录。浏览器日志可以帮助诊断为何该记录没有出现。在操作前后收集这些日志，可以保留相关的事件序列，而无需保留共享会话的完整浏览历史。

网络观测数据可能包含敏感信息，包括 URL 或与账号相关的元数据。将采集范围限制在任务范围内，从保留下来的工件中删去机密，并选择与诊断需求相匹配的保留策略。

订阅清理是客户端正确性的一部分。如果重用的会话在任务完成后仍继续投递事件，后续任务可能会误解这些事件。维护对订阅和上下文映射的显式归属，而不是依赖没有作业边界的全局事件收集器。

实现支持必须按功能逐项核查

BiDi 支持是一个“按功能”的兼容性问题，而不是对整个自动化栈给出一个简单的是或否标签。浏览器版本、远程环境和语言绑定都可能影响可用的操作。

The Selenium bidirectional automation model 展示了客户端生态系统如何暴露这些能力。请核查你所使用语言和版本的 API，而不是凭猜测从另一种绑定中翻译示例。

为该工作流创建一份简短的兼容性清单。包括所需的事件族、脚本操作、上下文处理以及任何网络功能。标记哪些是关键必需，哪些是可选的诊断辅助，然后在实际环境中测试这份清单。

某个浏览器宣称支持 BiDi 连接，并不意味着特定模块是完整的，或远程提供方已将其暴露。有效的测试是在具有代表性的条件下执行所需操作，并观察是否出现预期的响应或事件。

将协议支持与数据正确性区分开来。一个有效的事件流可能会与错误的抽取规则并存。在采用某个工作流之前，既要验证自动化接口，也要验证页面层面的结果。

在不重写一切的前提下规划 BiDi 采纳

BiDi 的采纳可以从现有自动化旁边的、范围受限的观测需求开始。选择一个收益明确、行为可独立测试的功能。

例如，一个团队可能需要在失败的应用流程中收集浏览器日志。定义相关上下文，在操作之前订阅，并确认预期的诊断条目与正确的页面关联。在评估新的观测路径时，保留既有的导航和抽取检查。

避免把协议迁移当作性能或可靠性必然提升的证据。这些结果取决于客户端实现和工作负载。如果速度或资源使用是决策的一部分，请对具有代表性的作业进行测量。

记录连接创建、事件订阅和会话终止的归属。当前应用只有一个清晰负责生命周期决策的地方时，协议特性更易维护。

Scrapeless Agent Browser 在协议决策中的定位

Scrapeless Agent Browser 记录了一种基于 CDP 的浏览器连接以及 自定义 CDP 功能. 一个有文档说明的 CDP 接口并不能证明其支持 WebDriver BiDi。

如果 BiDi 对你的应用是硬性要求，请在选择浏览器托管路径之前明确验证该要求。如果所需工作流已经使用了有文档的 CDP 客户端，请基于其自身的特性进行评估。合适的选择应当遵循该作业实际需要的协议能力。

The Selenium automation discussion 为浏览器驱动的工作流提供了相关背景。只有在连接与能力需求已经明确之后，才回过头审视 Scrapeless plans .

结论

WebDriver BiDi 将命令与浏览器生成的事件引入到一个双向自动化协议中。其价值取决于正确的上下文跟踪、范围受控的订阅以及经过验证的功能支持。围绕具体操作来选择接口，并始终将协议兼容性与浏览器产出数据的正确性区分开。