Chrome 现在已经把 Remote Debugging（远程调试）这套能力开放得比较直接了，和 Chrome DevTools MCP 这类协议配合起来也更顺手。对 Claude Code、Codex 这类 Agent 来说，重点不是“伪装成一个浏览器”，而是直接连到你正在使用的 Chrome 实例，读取页面结构、执行脚本、点击按钮、输入内容，必要时还能继续使用当前浏览器里的登录态。
这件事真正有价值的地方，不是“看起来很酷”，而是它把很多原本很绕的浏览器自动化场景变简单了。以前要先搭测试环境、补登录流程、处理一堆兼容问题；现在如果本机 Chrome 已经开着、账号也已经登录，很多操作可以直接开始。
不过也要说清楚：远程调试权限很强。你一旦开启，它就不只是“让工具看一眼页面”，而是把当前浏览器实例的控制权部分开放出去。所以这更适合本机开发、调试和排障，用完最好及时关闭。
开启 Chrome 的远程调试
-
打开你的 Chrome 浏览器，最好先更新到较新的版本。
-
在地址栏输入下面这个地址：
chrome://inspect/#remote-debugging -
进入页面后，勾选 Allow remote debugging for this browser instance。
-
勾选完成后，页面通常会显示一个本地监听地址，例如
127.0.0.1:9222。
看到这个地址，基本就说明当前浏览器实例已经接受远程调试连接了。后面的 Agent 或工具，就是通过这个入口和 Chrome 通信。
安装 chrome-cdp-skill
如果你打算让支持 MCP/工具调用的 Agent 直接操作 Chrome，可以先安装这个 skill：
npx skills add https://github.com/pasky/chrome-cdp-skill -g --all --copy
安装并连接成功后，Agent 就能直接操作浏览器。只要当前 Chrome 里已经有可用的登录状态，它通常也能沿用这份会话继续工作，不用每次都重新登录。
这对开发者有什么帮助
- 调试登录后的流程会轻松很多，比如后台系统、支付页、控制台这类必须带登录态才能复现的问题。
- 很多重复性的网页操作可以直接交给 Agent 跑，例如填表、点按钮、查页面元素、抓取结果，再把过程整理回来。
- 前端排障更直接。你可以让 Agent 读取 DOM、定位元素、验证交互流程，而不是只靠口头描述猜页面出了什么问题。
- 做联调时更省时间。接口通了没有、页面有没有拿到正确数据、按钮点击后发生了什么，Agent 都可以在浏览器里直接帮你检查。
- 对测试和验收也有帮助，尤其是那些“必须真浏览器、必须真登录、必须按真实步骤走一遍”的场景。
一个实际例子
我用 Codex 做过一个很直接的演示：让它打开 Kimi，然后帮我查询“今日江苏省油价”。
整个过程其实不复杂。Agent 会先加载对应的 skill，然后连接 Chrome，打开目标网站，查找输入框，输入问题，再定位发送按钮并提交。等页面返回结果后，它还可以继续读取回复内容。
如果你是开发者，应该很容易想到这套方式还能继续往下用：复现 bug、验证页面流程、跑登录后操作、做简单验收，甚至帮你处理一部分本来很机械的浏览器工作。它不一定能替代完整的自动化测试，但在“先把问题定位清楚”这件事上，确实很省事。