很多人第一次接触 Chrome DevTools MCP 时，最先想到的是“让 AI 帮我点页面、跑自动化流程”。这当然有用，但真到了日常开发里，更常见的痛点其实不是自动化，而是调试现场没法无缝交接。
比如你已经在浏览器里登录了后台系统，问题只会在登录态出现；或者你已经在 DevTools 的 Network 面板里定位到一个失败请求，下一步想让 AI 继续深挖，但又不想从头再描述一遍。Chrome 官方在 2025 年底发布的这次更新，解决的就是这个断层。
这次 Chrome DevTools MCP 的增强版，允许 coding agent 直接接入你当前正在使用的 Chrome 会话，甚至可以接手你已经打开的 DevTools 调试上下文。这一点，才是它真正从“浏览器自动化工具”迈向“协作式调试工具”的关键。
这次更新到底解决了什么问题？
官方给出的能力点其实很明确，我把它翻译成更接近开发现场的话，就是下面两件事：
1. 复用当前浏览器会话
以前很多基于浏览器的 agent 工具，都会自己拉起一个新的浏览器实例。这样做的好处是隔离明确，但坏处也很明显：
- 你已经登录的网站，它还得重新登录一次
- 某些系统有验证码、双因子认证或者企业 SSO，重新登录非常麻烦
- 有些问题只会在你当前的用户状态、Cookie 或本地存储环境里复现
现在 Chrome DevTools MCP 可以直接连接你已经打开的 Chrome 会话。换句话说，agent 不再需要重新“扮演一个新用户”，而是可以直接站在你当前的浏览器上下文里工作。
这对排查登录态问题尤其重要。
2. 接管当前正在进行的 DevTools 调试
这次更新更有意思的地方，是它不只是“连上浏览器”，而是可以衔接你正在进行的 DevTools 调试动作。
举个很真实的场景：
- 你在 Network 面板里发现一个请求报错
- 或者你在 Elements 面板里已经选中了一个有问题的 DOM 节点
- 这时候你直接对 coding agent 说：帮我分析这个请求为什么失败，或者帮我看看这个元素为什么样式不对
以前这一步通常要靠你手动复制信息、截图说明，或者让 agent 再从页面头开始摸索。现在这类上下文可以直接被 agent 继承。
这意味着“人类手动定位问题”与“AI 接力深入分析”之间，第一次有了比较顺滑的衔接。
它是怎么实现的？
这次能力依赖的是 Chrome M144 中新增的一条远程调试连接流程。它并不是绕过 Chrome 原有安全模型，而是在现有 remote debugging 能力之上，加了一层用户明确授权的交互。
核心逻辑大致是这样：
- 你先在 Chrome 里手动开启 remote debugging 功能。
- 启用了
--autoConnect的 Chrome DevTools MCP server 尝试连接当前运行中的 Chrome。 - Chrome 会弹出权限确认框，询问你是否允许这次调试连接。
- 如果你点击允许，MCP server 就能接入当前浏览器实例。
- 调试期间，Chrome 顶部会显示“Chrome is being controlled by automated test software” 这类提示横幅。
这套流程的重点在于：默认仍然是关闭的，用户必须先开启并明确授权。
这点我认为很重要。因为一旦 agent 可以接入你正在浏览的真实会话，安全边界就不能靠“默认开放”。Chrome 这次的设计思路很保守，但也因此更适合进真实开发环境。
怎么开始用？
第一步：在 Chrome 里启用远程调试
前提条件是 Chrome 版本至少在 144 以上。官方在文章发布时说明 M144 还处于 Beta，所以那时需要配合 beta channel 使用。
你需要先在浏览器里打开：
chrome://inspect/#remote-debugging
然后按照页面提示，显式开启远程调试连接能力。
这一层不能跳过，因为 Chrome 默认不会接受这类连接请求。
第二步：给 Chrome DevTools MCP server 加上 --autoConnect
如果你用的是 gemini-cli，官方示例配置大概是这样：
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": [
"chrome-devtools-mcp@latest",
"--autoConnect",
"--channel=beta"
]
}
}
}
这里有两个关键参数：
--autoConnect启用自动连接到当前运行中 Chrome 实例的能力--channel=beta在 Chrome M144 尚未进入 stable 时，明确连接 Beta 通道
如果你之后使用的是稳定版 Chrome，并且对应版本已经进入 stable，这个参数是否还需要保留，就要看当时官方 README 的最新说明。
第三步：测试是否生效
官方给的演示 prompt 很简单：
Check the performance of https://developers.chrome.com
运行后，MCP server 会尝试连接你当前打开的 Chrome，浏览器会弹出授权框。你点击允许之后，agent 就可以在当前会话里打开页面并抓取性能追踪数据。
这个过程里最值得注意的一点是：Chrome 必须由用户自己先启动。
它不是那种“偷偷后台拉起一个实例”的模式，而是以你已打开的浏览器为基础建立协作。
为什么这项能力很有实际意义？
很多新功能看起来很酷，但未必真能进入日常工作流。这个更新我觉得不一样，因为它恰好命中了前端调试里最麻烦的几个时刻。
登录态问题终于更容易交给 AI
很多 bug 根本不是公开页面问题，而是：
- 需要管理员权限才会触发
- 需要特定账户数据
- 需要用户本地存储状态
- 需要复杂登录流程
以前你让 agent 复现这些问题，常常会卡在登录这一步。现在它直接复用当前浏览器会话，这个门槛一下就降下来了。
手动调试和 AI 调试开始衔接起来
开发者并不是每次都希望 agent 从零开始摸索。
很多时候我们自己先做了一半：
- 在 Elements 面板里已经锁定了问题元素
- 在 Console 里已经看到了错误栈
- 在 Network 面板里已经找到异常请求
接下来最理想的状态，不是重新解释，而是把这个现场直接交给 AI。Chrome DevTools MCP 现在提供的就是这种接力能力。
AI 更像一个“跟你并肩调试的搭档”
过去很多浏览器自动化工具更像远程控制器，能帮你操作页面，但并不了解你当前在看什么。
而这次更新之后，agent 开始更像一个真正意义上的调试协作者：
- 你先观察
- 你先定位
- 然后它接手分析
这个工作流比“全自动从头跑一遍”更符合资深开发者的习惯。
它和旧的 Chrome DevTools MCP 使用方式有什么区别？
这次更新不是替代原有模式，而是在原有连接方式上新增了一种更贴近日常调试的工作流。
原来你仍然可以：
- 用 MCP server 自己拉起专用浏览器 profile
- 连接到一个已经开启 remote debug port 的 Chrome 实例
- 使用临时 profile 跑隔离的多实例自动化
新的 --autoConnect 更像是第四种模式，它的重点不是隔离，而是上下文延续。
所以简单理解：
- 如果你要做稳定的自动化回归测试，隔离 profile 依然合适
- 如果你要排查一个真实用户态页面里的 bug，
--autoConnect会更自然
这两个方向并不冲突，只是适合的场景不同。
我觉得它还不够的地方
虽然这次更新很实用，但官方自己也说了，这只是第一步。
目前更像是把“连接真实浏览器会话”这件事打开了，后面真正决定体验上限的，还是 DevTools 面板数据能向 agent 暴露多少。
现在已经能做的方向包括：
- 选中 Elements 面板中的元素再交给 agent
- 选中 Network 请求再交给 agent
但如果未来能继续扩展到更多面板数据，比如：
- Performance 的具体事件细节
- Application 面板中的 storage / cookie / service worker 信息
- Sources 面板里的断点与调用栈上下文
那它就不只是“浏览器控制 + 少量调试上下文”，而会真正变成一套面向 coding agent 的浏览器调试接口层。
这也是我觉得这篇官方文章真正值得看的地方：它不是在发布一个花哨的新命令，而是在慢慢定义“AI 如何进入开发者真实调试现场”这件事。
总结
如果你已经在用 Chrome DevTools MCP，那这次更新最值得记住的不是某个参数本身，而是工作流变了。
你不再必须在“自己调试”和“让 AI 接管”之间二选一。
现在更自然的方式是：
- 先在 DevTools 里自己看
- 找到问题现场
- 然后让 agent 在这个现场上继续深挖
而 --autoConnect 正是把这个切换过程变顺的关键。
对需要处理登录态、复杂前端状态或者真实页面上下文问题的开发者来说，这个能力的实用价值，可能比单纯的浏览器自动化大得多。
参考资料
- Chrome 官方博客：Let your Coding Agent debug your browser session with Chrome DevTools MCP
- GitHub README：Chrome DevTools MCP
关于
关注我获取更多资讯
