在日常浏览器里灵活选择标签页范围。
适合让 Agent 复用 Chrome 或 Edge 的现有登录态；用户可以授权当前标签页或全部受支持标签页，当前控制状态始终可见，也随时可以释放。
复用现有浏览器 · 基于真实边界的对比
让 AI Agent 接入你正在使用的浏览器，有哪些选择？
该选哪种方案，取决于你需要的是现有登录态、干净的隔离环境、底层调试控制，还是面向用户的标签页授权。Panerelay 面向的是这样一种场景：日常浏览器仍属于用户，Agent 只在明确、可见的边界内工作。
事实、实测数据与来源链接最后核对于 2026 年 8 月 11 日。
01 · 快速选择
四种有价值的方案，解决四类不同问题。
拥有干净、可重复的执行环境。
适合需要隔离配置文件、启动时代理、远程运行、测试可重复性或规模化执行的场景，尤其是不需要复用用户日常浏览器时。
自行管理调试配置与端点。
适合能主动暴露并保护调试端点的自定义集成。CDP 提供的是协议连接，本身并不是面向终端用户的标签页授权管理器。
把所选标签页交给 Playwright MCP。
适合已经选择 Playwright MCP，并且认可其原生“选择一个浏览器标签页、审批连接”工作流的场景。
02 · 对比矩阵
不要只比较“能否连接”，还要比较连接边界。
授权范围、连接审批、当前控制是否可见、谁拥有浏览器进程，才决定一套方案是否适合日常使用。
| 方案 | 复用已登录浏览器 | 用户可见范围 | 连接审批 | 当前控制状态 | 浏览器归属 | 适合场景 |
|---|---|---|---|---|---|---|
| Panerelay | 是，复用当前 Chrome 或 Edge 会话 | 当前标签页或全部受支持标签页 | 完成本地接入后，再明确选择浏览器与标签页范围 | 专门的受控状态与“释放控制”入口 | 不拥有、也不关闭浏览器进程 | 多种自动化引擎接入日常浏览器 |
| 托管 / 隔离浏览器 | 通常使用独立或额外提供的配置文件 | 浏览器上下文、配置文件或远程会话 | 因工具而异，并非现有标签页授权 | 取决于具体工具界面 | 拥有启动或远程运行的环境 | 干净环境、代理、可重复性与规模化 |
| Chrome 原生 CDP | 仅限被主动启动或设为可发现的浏览器 | 调试端点及其可发现目标 | 没有内建的终端用户标签页审批层 | 需要由上层集成自行提供 | 接入方负责调试配置和端点安全 | 调试与底层自定义集成 |
| Playwright Extension | 是，复用浏览器现有状态 | 首次交互时由用户选择一个标签页 | 默认审批；可配置 token 便于重复连接 | Playwright 连接 / 会话状态 | 不拥有浏览器进程 | Playwright MCP 的原生单标签页流程 |
“托管 / 隔离浏览器”是一类方案，具体行为随供应商而不同。CDP 行描述的是协议本身；基于 CDP 的上层工具可以额外加入策略和界面。
03 · 登录态 FETCH
无需借道标签页的登录态请求。
当 Agent 需要携带浏览器登录态调用 HTTP API 时，Panerelay Fetch 与 OpenCLI 存在能力交集，但采用了不同的执行链路。OpenCLI 的范围更广，还覆盖公开 HTTP、页面操作、请求拦截和桌面端工作流。
对比范围。这里比较的是 Panerelay Fetch 与 OpenCLI
由浏览器驱动、在页面上下文执行的 fetch() 路径；OpenCLI 可直接请求 HTTP 的
PUBLIC 命令不在本次对比中。
| 方案 | 请求链路 | 登录态 | 目标标签页依赖 | 浏览器界面 | 并行执行 | 适合场景 |
|---|---|---|---|---|---|---|
| Panerelay Fetch | Agent CLI → 本地 Bridge → 扩展后台 Fetch | 浏览器 Cookie；适配器需要时可声明受限数据绑定 | 无，相关页面可以关闭 | 不附加 CDP，也不显示调试横幅 | 独立的短时会话，由扩展限制并发上限 | 快速调用带当前登录态的 API、Feed 与数据接口 |
| OpenCLI 浏览器驱动路径 | CLI → daemon / 扩展 → CDP Runtime.evaluate → 页面 Fetch | 预备浏览器页面可用的凭证 | 需要一个存活且可定位的页面目标 |
使用 chrome.debugger，Chrome 可能显示调试提示
|
并行调用仍经过共享的页面与 CDP 命令链路 | 需要把请求与页面检查、操作组合起来的适配器 |
本地实测快照 · 完整 CLI 调用
在浏览器登录态请求场景中，命令链路更短。
- 串行中位数
- 129.9 ms对比 217.1 ms · 降低 40.2%
- 8 请求批次
- 227.7 ms对比 441.4 ms · 降低 48.4%
- 成功请求
- 110 / 110两种实现均无失败
2026 年 8 月 11 日在 Apple M4 Pro、Chrome 151、Panerelay 0.9.0 与 OpenCLI 1.8.6 上测得。预热 5 次后，使用合成 HttpOnly Cookie 保护的本地回环 1 KiB JSON 接口，执行 30 次串行调用和 10 × 8 次并发调用；OpenCLI 页面在计时前已准备完成。该结果是本机快照，不代表所有命令或环境。 查看方法、汇总数据与限制。
真实适配器快照 · BILIBILI ME
真实命令的差距可能更大。
OpenCLI 需要先准备并等待页面稳定，这个命令随后在页面上下文执行 3 次 API 请求；Panerelay 通过扩展后台 Fetch，并复用导航数据，无需准备目标页面，只发起 2 次 API 请求。
- Panerelay 中位数
- 633.8 ms
- OpenCLI 中位数
- 2753.0 ms
- 实测差距
- 4.34×延迟降低 77.0%
在同一设备、浏览器配置与账号登录态下，各预热 1 次后交替实测 10 轮，20 次调用全部成功。结果包含 Bilibili 实时网络、页面准备和适配器实现差异，只是一次现场快照，不能外推到其他站点或策略。 查看 p95、计时边界、源码路径与限制。
04 · PANERELAY 模型
获得授权，与获得当前控制权，是两件不同的事。
扩展可以在哪些来源上工作。
选择当前标签页或全部受支持标签页；焦点永远不会自动授予权限。
会修改页面的 Agent 必须拥有当前控制权，而且受控状态持续可见。
结束当前控制时，不会暗中改变用户已经选择的授权范围。
05 · 不适合 PANERELAY 的情况
如果“拥有浏览器进程”本身就是需求，请选择其他方案。
- 每次运行都需要隔离 BrowserContext 或一次性干净配置文件。
- 必须在启动浏览器时配置可执行文件参数、扩展或代理。
- 需要导出整个配置文件的 Cookie、关闭整个浏览器或管理远程浏览器集群。
- 只使用 Playwright MCP，并且更喜欢它原生的扩展连接审批流程。
Panerelay 不会假装扩展连接拥有浏览器进程。它负责的是本地路由与策略边界，并且只暴露用户明确授权的标签页。
06 · 参考来源
这份对比所依据的一手资料。
开源 · MIT