Chrome 136 起，一个常见的浏览器自动化方案发生了变化：如果仍然使用 Chrome 默认数据目录，命令行传入的 --remote-debugging-port 和 --remote-debugging-pipe 不再生效。Chrome 官方建议调试时改用自定义 user-data-dir ，或者使用 Chrome for Testing 。
官方说明：
https://developer.chrome.com/blog/remote-debugging-port
问题在于，自定义 Profile 很适合测试和隔离，却不等于用户正在使用的浏览器：日常登录态、已打开标签页和现有扩展往往仍在默认 Profile 中。
现在大致有几条路线：
1. 需要可复现测试、独立 Profile 或进程控制：使用 Chrome for Testing 、专用 user-data-dir 或托管浏览器。
2. 接受浏览器级调试权限：较新的 Chrome 可以在 chrome://inspect/#remote-debugging 中由用户为当前实例开启远程调试，适合直接使用 CDP 的工具。
3. 使用 Playwright MCP：官方 Chrome Extension 可以从用户选择的现有标签页建立连接，复用登录态和浏览器扩展。
4. 希望 agent-browser 、Browser Use 、Playwright CLI 共用同一套当前标签页/全部受支持网页授权：可以使用 Panerelay ，把标签页授权与活动控制分开，控制状态可见并可随时 Release 。
这里的关键不是简单判断 CDP 或 Extension 谁更好，而是先确定需要哪种边界：
- 浏览器级权限，还是标签页级授权？
- Agent 是否需要拥有浏览器进程？
- 是否需要干净 Profile 、代理或远程并发？
- 是否要继续使用当前打开的页面和浏览器扩展？
方案与适用边界对比：
https://f-loat.github.io/panerelay/zh-CN/compare/
如果你正在做浏览器 Agent ，实际更常遇到的是“默认 Profile 无法远程调试”，还是“工具连上了但没有正确拿到目标标签页”？
官方说明：
https://developer.chrome.com/blog/remote-debugging-port
问题在于，自定义 Profile 很适合测试和隔离，却不等于用户正在使用的浏览器：日常登录态、已打开标签页和现有扩展往往仍在默认 Profile 中。
现在大致有几条路线：
1. 需要可复现测试、独立 Profile 或进程控制：使用 Chrome for Testing 、专用 user-data-dir 或托管浏览器。
2. 接受浏览器级调试权限：较新的 Chrome 可以在 chrome://inspect/#remote-debugging 中由用户为当前实例开启远程调试，适合直接使用 CDP 的工具。
3. 使用 Playwright MCP：官方 Chrome Extension 可以从用户选择的现有标签页建立连接，复用登录态和浏览器扩展。
4. 希望 agent-browser 、Browser Use 、Playwright CLI 共用同一套当前标签页/全部受支持网页授权：可以使用 Panerelay ，把标签页授权与活动控制分开，控制状态可见并可随时 Release 。
这里的关键不是简单判断 CDP 或 Extension 谁更好，而是先确定需要哪种边界：
- 浏览器级权限，还是标签页级授权？
- Agent 是否需要拥有浏览器进程？
- 是否需要干净 Profile 、代理或远程并发？
- 是否要继续使用当前打开的页面和浏览器扩展？
方案与适用边界对比：
https://f-loat.github.io/panerelay/zh-CN/compare/
如果你正在做浏览器 Agent ，实际更常遇到的是“默认 Profile 无法远程调试”，还是“工具连上了但没有正确拿到目标标签页”？
1
Select Language