什么是 WebDriver BiDi？

Scrapeless Agent Browser 通过为浏览器自动化客户端提供有文档的连接接口来提供托管浏览器会话。

WebDriver BiDi 是一种用于远程控制浏览器并接收浏览器事件的双向协议。“BiDi”指的是双向通信：自动化客户端发送命令，当已订阅的活动发生时，浏览器可以发送事件消息。这种事件驱动模型支持那些如果仅通过反复的请求－响应查询来表达会显得笨拙的观测操作。

WebDriver BiDi 是一种协议，而不是浏览器、测试运行器或托管服务。W3C 规范仍在编写中，且不同实现对模块和命令的支持程度各不相同。因此，评估时需要考虑任务所需的实际浏览器、客户端绑定、协议能力和操作，而不是笼统地声称某个技术栈“支持 BiDi”。

双向通信带来了什么

双向通信使浏览器能够在无需等待客户端逐一请求每个单独事件的情况下报告相关活动。 WebDriver BiDi 协议 为浏览器控制和监测定义了命令、响应、事件、传输和模块。

对于许多操作而言，传统的请求-响应交互已经足够。客户端发出导航请求并接收结果。当浏览器可以在这些命令之间产生活动时（例如文档更改上下文或脚本生成日志条目），基于事件的观察就变得有用。

重要的改进在于观察模型本身，而不是承诺每个浏览器任务都会变得更快。如果某个任务只需要最终的页面标题，那么事件流可能贡献不大。如果某个任务必须将控制台活动与特定的导航关联起来，那么通过订阅获得的信息可能比定期请求快照更加相关。

事件也会产生责任。客户端必须决定要订阅什么、如何关联消息、哪些事件与完成相关，以及何时释放订阅。无限量的观测集合可能会从有用的诊断信息变成存储和解释问题。

命令、响应和事件具有不同的角色

命令请求执行某个操作，响应报告其结果，而事件描述已订阅的浏览器活动。这些消息类型应根据其角色来处理，而不是被视为一个按顺序完成操作的单一列表。

命令响应可以确认某个受支持的协议操作已完成。事件可能因为页面发起的浏览器活动或其他操作而到达。客户端需要足够的上下文，将这一观察与相关的文档、任务和导航关联起来。

不要将事件的存在视为应用程序已达成其业务目标的证据。导航事件只说明了导航相关的信息。任务可能仍然需要结果区域出现、表单变为可用，或某个特定项目被选中。

为该任务定义一个精简的观测契约。识别启动工作的命令、提供有用证据的事件、确立成功的页面条件，以及结束观测的清理步骤。这样就能使事件驱动的工作流在不必永久保留每一条原始消息的前提下仍然可审查。

事件驱动自动化中的上下文身份至关重要

上下文标识决定了某个事件涉及的是哪个页面或嵌入文档。一个浏览器可以包含多个顶级页面和子文档，因此一个连接并不意味着只关注单一文档。

该 HTML 浏览上下文模型 提供了浏览器文档及其相互关系之间的根本区别。弹出窗口、嵌套框架和导航都可能影响应该观察或控制的是哪个文档。

一个实际示例是，一个应用程序在单独的页面中打开收据。发起点击发生在原始页面，但收据的就绪条件属于新的上下文。一个持续读取原始文档的任务可能会得出“收据不存在”的结论，即使浏览器已经成功将其打开。

框架身份需要同样仔细的处理。来自嵌入式小部件的日志消息不应自动归因于父应用程序。在诊断记录中保留上下文身份，以便可以将观察结果关联到生成它们的文档。

订阅需要作用域和生命周期

订阅应涵盖任务所需的事件和上下文，并且只在任务需要它们的时间内保持有效。这样可以同时减少诊断噪声以及保留无关页面信息的可能性。

在需要证据的活动之前先建立观察。如果页面在某个操作之后能立刻产生相关事件，那么在此之后再附加观察者可能会留下空档。检查实际客户端绑定的生命周期行为，而不是假设顺序会被自动处理。

在收集之后选择要存储的内容。对于工作摘要而言，一个包含事件类型、上下文标识符和相关结果的简洁记录可能就足够了。完整的日志消息或网络细节可能包含敏感的应用数据，因此保留的记录应与故障排除需求相匹配。

在其所有者完成时关闭订阅。一个控制多个任务的长生命周期客户端不应该意外地将先前任务的观察者附加到后续任务上。显式的所有权使得更容易解释缺失的观察以及出现在错误作业中的观察。

WebDriver BiDi、经典 WebDriver 和 CDP

WebDriver BiDi、经典 WebDriver 和 Chrome DevTools Protocol 是不同的控制接口。共同使用浏览器自动化或 WebSocket 传输并不会让它们可以互换。

该 经典 WebDriver 命令模型 通过其标准化接口定义远程浏览器操作。BiDi 增加了一个双向协议模型。CDP 具有其与 Chromium 工具相关联的独立命令与事件界面。请围绕您的应用实际需要的浏览器覆盖范围和操作进行选择。

迁移不必一次性替换每一个操作。先识别需要 BiDi 的观测，再检查所选客户端如何将其与现有浏览器控制结合。当需求只是一个狭窄的诊断能力时，避免对整个协议进行重写。

必须按操作评估浏览器支持

对 WebDriver BiDi 的浏览器支持，应按操作和环境分别评估。成功的连接建立的是传输通道，而受支持的订阅或命令则建立起更窄的能力范围。

该 Selenium BiDi 客户端界面 为使用 Selenium 的应用程序提供实现背景。这并不能免除检查实际语言绑定与浏览器组合的必要性。在一种语言中展示的功能，在另一种语言中可能拥有不同的接口或支持状态。

创建一个与工作任务绑定的能力清单。对每个所需操作，指定浏览器环境、客户端方法、预期的协议行为，以及将证明其有效的条件。将不受支持的能力显式记录下来，这样缺失的事件就不会被误判为空的应用结果。

避免在不检查当前文档的情况下照搬旧的实验标志或连接示例。协议工作在不断演进，以前用于启用预览功能的配置，可能已不再描述受支持的路径。本术语表特意不提供未执行的连接代码或通用支持表格。

一个有用的 BiDi 验收场景

一个有用的验收场景会将事件与可见的页面结果关联起来。在可控的测试应用上，安排一个页面动作去打开已知文档，并发出可识别的诊断消息。

在启动动作之前，先订阅所需的事件类别和作用域。执行该动作，识别新的文档上下文，并检查目标页面状态。只有当预期的观测归属于预期的上下文，且应用结果正确时，测试才算通过。

同时也要演练清理过程。结束观测，执行无关工作，并确认旧任务不会继续累积证据。这是在检查订阅的所有权，而这往往是“顺利路径”示例所忽略的。

在最终报告中，将协议结果与业务结果区分开来。订阅失败、上下文关闭和页面记录缺失需要不同的解释。此区分在远程执行中尤为重要，因为多层基础设施和应用可以独立发生故障。

在 Scrapeless 中使用 BiDi 概念

BiDi 概念有助于解释事件驱动自动化，但 Scrapeless 端点必须通过其已文档化的协议来使用。 Agent Browser CDP surface 记录的是 CDP 操作；它并不能证明存在 WebDriver BiDi 端点。

该 Agent Browser platform 提供托管的浏览器执行与观测功能。对 浏览器控制台和会话诊断 的讨论提供了相关的操作背景，而 Scrapeless pricing 则支持工作负载规划。在将协议概念转化为产品集成之前，请验证所需接口。

结论

WebDriver BiDi 让浏览器事件成为控制对话的一部分。当基于事件的观测可以解决明确定义的需求时再使用它，并将上下文标识、订阅范围、完成条件和清理过程一并设计。兼容性取决于您真实的浏览器与客户端能执行的操作，而不是仅凭协议名称。