2. V2EX
  3. Chrome 136 后 --remote-debugging-port 对默认 Profile 失效， AI Agent 怎么接现有登录态？

Chrome 136 后 --remote-debugging-port 对默认 Profile 失效， AI Agent 怎么接现有登录态？

chaimaoyuan 2026-08-06 10:21 1
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 无法远程调试”，还是“工具连上了但没有正确拿到目标标签页”？
最新回复 (3)
  • minimaluminium 08-06 10:48
    1楼
    https://github.com/Tencent/BrowserSkill 出乎意料的好用，cli 对接浏览器装的插件
  • VYSE 08-06 11:10
    2楼
    使用 EDGE 最后一个版本 149.0.4022.98 ， 叠加 https://github.com/Vikindor/disable-edge-updates 禁止更新
  • chaimaoyuan 楼主 08-06 12:16
    3楼
    @minimaluminium 这个补充很有价值。我看了下 BrowserSkill 的公开设计：它默认把任务放到独立、可见的 Agent Window ，只有明确需要时才 borrow 已有标签页，完成后再 return ；对“不打断日常浏览器窗口”这个问题处理得很直接。

    和帖子里 Panerelay 这条路径的主要区别，看起来是 BrowserSkill 把 bsk CLI 、daemon 、扩展和自动化命令面一起提供； Panerelay 则让 agent-browser 、Browser Use 、Playwright CLI 保留各自的命令与语义，主要提供连接、当前页/全部受支持网页授权和独立的 control lease 。前者更一体化，后者更适合已经选定 automation engine 、希望它们共用一套标签页授权边界的场景。

    这个对比确实值得补进方案表里，感谢推荐。
* 帖子来源V2EX
附近帖子
返回
飞读
随机推荐