别让智能体 Agent 卡在登录页！接管“已登录 Chrome浏览器”的 6 种实战方案

用 Claude Code、Cursor、Codex 或 Gemini CLI 干活时，经常会遇到，就是代码已经改好了，Agent 却卡在登录页，连业务界面都进不去。

企业单点登录（SSO）、手机二次验证、扫码、验证码，任何一个环节，都可能让自动化停下来。你明明已经在自己的 Chrome 里登录了十几个系统，Agent 打开的浏览器却像刚出厂一样，还要从头再来。

问题就出在这里。许多浏览器工具默认使用独立的用户目录，与你日常 Chrome 的登录态互不相通。

解决这个断点，可以让 Agent 直接连接你正在使用的浏览器。账号已经登录，页面已经打开，甚至 Bug 都复现到一半了，它接着往下做就行。

Browser Use 团队围绕这类需求整理了多种接入方式。本文沿着六种方案展开，说明各自的配置方法、控制范围，以及接通浏览器后值得用起来的工程场景。

过去常见的做法，是把 Cookie 和 LocalStorage 导出成状态文件，再通过 Playwright 的 storageState 或相关工具的 --storage-state 配置载入。

这套方法在不少测试场景中仍然有效。但遇到设备绑定、复杂 SSO 和额外风控时，单纯搬运 Cookie 就容易掉链子。

障碍	具体发生了什么	对自动化的影响
设备绑定会话 DBSC	会话续期需要浏览器证明持有设备上的私钥	复制 Cookie 无法一并复制续期能力
重新登录与自动化风控	新 Profile 没有原来的会话，部分登录系统会检查浏览器环境	需要重新验证，甚至被拒绝登录
Chrome 默认目录调试限制	Chrome 136 起，默认数据目录不再接受旧式远程调试参数	不能再靠一个启动参数直接接管日常 Profile

DBSC，全称 Device Bound Session Credentials，会将会话续期与设备持有的密钥关联起来。浏览器生成密钥对，并在可用时借助 TPM 等硬件支持的存储保护私钥。

网站仍然可以使用普通 Cookie，但短效 Cookie 到期后，浏览器需要证明自己持有对应私钥，才能刷新会话。只把 Cookie 导出到另一个浏览器，并不能带走这套续期能力。 Chrome DBSC 机制说明

2. 新 Profile，意味着登录流程再走一遍

独立浏览器没有你的企业 SSO、扫码记录和已验证设备状态。十几个内部系统，可能就要重新登录十几次。

部分身份系统还会对自动化环境触发额外检查。于是，原本想节省的时间，又花在了验证码、手机确认和登录失败排查上。

3. Chrome 136 收紧了默认目录的远程调试

从 Chrome 136 开始，--remote-debugging-port 和 --remote-debugging-pipe 不再对默认用户数据目录生效。使用这些参数时，需要通过 --user-data-dir 指向非默认目录。

这项调整主要针对利用远程调试窃取浏览器数据的攻击，也改变了过去直接附着日常 Chrome 的方式。Chrome 官方说明

因此，如果目标是继续使用自己的登录会话，更直接的路径是扩展桥接，或者 Chrome 144+ 提供的原生远程调试授权入口。由用户明确批准，让工具连接正在运行的浏览器。

二、接管已登录 Chrome 的 6 种实战方案

方案 1，Claude in Chrome，官方直连最省事

如果主要使用 Claude Code，又有 Anthropic 官方订阅，Claude in Chrome 是最直接的选择。

适用工具

Claude Code CLI，以及支持该集成的 VS Code 扩展。

配置方法

安装 Claude in Chrome 扩展，使用 /login 登录官方账号，然后启动：

bash 复制代码

claude --chrome

也可以在会话中输入：

bash 复制代码

/chrome

检查连接状态，或设置后续默认启用。

Claude 会在已登录浏览器中打开自己的标签页组，复用当前 Profile 的会话。整个过程在可见浏览器里进行，方便随时接手。

主要限制

这条官方通道要求使用支持的 Anthropic 直接订阅。API Key、claude setup-token 生成的长效 Token，以及 Bedrock 等第三方服务的认证方式，都不能直接用于扩展连接。遇到需要人工登录或验证的环节，仍由用户接手。Claude Code 官方文档

方案 2，Playwright MCP 扩展模式，标签页"指哪打哪"

Playwright MCP 默认使用自己的浏览器环境。加上 --extension，就可以通过 Playwright 扩展连接现有 Chrome、Edge 或 Chromium 浏览器。

适用工具

Claude Code、Codex、Gemini CLI、Cursor 等支持 MCP 的客户端。

配置方法

先安装 Playwright Extension，再添加 MCP 配置：

bash 复制代码

{
  "mcpServers": {
    "playwright-extension": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--extension"]
    }
  }
}

首次调用时，扩展会让你选择要连接的标签页。

它最实用的地方，是每个客户端拥有自己的标签页组，只能看到组内标签页。你可以把标签页拖进或拖出分组，调整 Agent 能操作的范围。多个客户端也可以分别连接，一个标签页同一时间归属一个客户端。

默认每次连接需要批准。若需要免去重复的连接确认，可以把扩展显示的 PLAYWRIGHT_MCP_EXTENSION_TOKEN 配置到 MCP 服务端环境变量中。

多 Profile 用户还可以通过以下参数指定目录：

bash 复制代码

--profile-dir-name "Profile 2"

目录名可以在 chrome://version 的 Profile Path 中找到。Playwright 扩展文档

方案 3，Chrome DevTools MCP，前端调试的重装备

想让 Agent 查看 Console、分析网络请求、录制性能轨迹，Chrome DevTools MCP 更对路。

它通过 --autoConnect 连接正在运行的 Chrome，让调试直接发生在你已经打开的页面上。

适用工具

支持 MCP 的编程工具。

配置方法

在 Chrome 144 或更高版本中打开：

bash 复制代码

chrome://inspect/#remote-debugging

启用远程调试，再配置 MCP：

bash 复制代码

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--autoConnect",
        "--no-usage-statistics"
      ]
    }
  }
}

连接时，在 Chrome 弹窗中批准调试请求。

其中 --no-usage-statistics 用于关闭该 MCP 服务的使用统计。

与 Playwright 扩展的标签页分组不同，这种连接可以访问所连接 Profile 的打开窗口，控制范围更广 。适合需要同时检查页面、请求和运行状态的调试任务。Chrome DevTools MCP 项目、连接方式对比

方案 4，Gemini CLI 内置 Browser Agent，改成 existing 即可复用

Gemini CLI 内置的 Browser Agent 已经集成 Chrome DevTools MCP，无需再单独安装一套浏览器服务。

它默认使用 persistent 模式，保留独立目录中的登录状态。要连接日常 Chrome，需要切换到 existing。

配置方法

先在 Chrome 144+ 中打开远程调试入口，再修改 Gemini CLI 的 settings.json：

bash 复制代码

{
  "agents": {
    "overrides": {
      "browser_agent": {
        "enabled": true
      }
    },
    "browser": {
      "sessionMode": "existing"
    }
  }
}

这样就会连接现有 Chrome，不再启动新的浏览器进程。

它还提供几个实用控制项：

allowedDomains 限制可访问的域名。
maxActionsPerTask 默认是 100，限制单项任务的工具调用次数。
fill、fill_form 等表单填写操作需要用户确认。

如果主要工作都在 Gemini CLI 里，这条路线比较省配置。Gemini CLI Browser Agent 文档

方案 5，ChatGPT 桌面端浏览器扩展，用 @ 直接叫来 Chrome

OpenAI 的浏览器扩展可以让 ChatGPT 桌面端中的聊天与 Codex 工作连接日常浏览器。

配置方法

打开桌面端：

bash 复制代码

Settings → Computer Use

在对应浏览器旁安装扩展，完成连接后，在输入框里通过 @Chrome 等方式选择浏览器。

支持的浏览器包括 Chrome、Edge、Brave、Opera 和 Vivaldi。使用多个 Profile 时，需要把扩展安装并启用在实际使用的那个 Profile 中。

扩展按站点管理访问许可，可以选择仅允许一次、允许当前站点，或者允许所有站点。

这条路线适合习惯桌面端交互的用户。Codex CLI 要连接 Chrome，则使用 MCP 等命令行接入方式。 OpenAI 浏览器扩展文档

方案 6，Browser Harness，能边干活边补工具的瑞士军刀

Browser Harness 是 Browser Use 团队开源的浏览器连接器，采用 MIT 协议，通过 CDP 连接正在运行的 Chrome。

它支持 Claude Code、Codex、Cursor，以及能够执行命令或连接 MCP 的其他 Agent。

它比较特别的地方，是 Agent 可以在工作过程中补写辅助脚本。遇到现成工具不好处理的日期选择器或上传流程，可以编写对应的 Helper，再继续执行任务。

配置方法

把官方 README 中的安装提示交给 Agent，让它使用 uv 安装最新稳定版、注册 Skill，并按安装文档完成连接。

首次连接仍需要用户在 Chrome 中启用：

bash 复制代码

chrome://inspect/#remote-debugging

然后批准连接请求。

Browser Harness 会给操作中的标签页标题加上 🐴 标记，支持在后台标签页工作，减少对当前浏览页面的干扰。

对于使用 MCP 的客户端，可以运行 browser-harness-mcp，具体配置见下一节。

涉及遥测设置，可以使用以下命令关闭：

bash 复制代码

browser-harness telemetry disable

本地录屏是另一项独立设置，按实际需要开启即可。Browser Harness 项目、安装说明

三、六种方案怎么选？附主流 Agent 接入命令

先看控制范围，再看接入方式

方案	适用客户端	主要控制范围	最适合的需求
Claude in Chrome	Claude Code	自建标签页组，配合站点权限	官方订阅用户直接上手
Playwright MCP 扩展模式	MCP 客户端	授权给客户端的标签页组	只让 Agent 接触指定业务页面
Chrome DevTools MCP	MCP 客户端	所连接 Chrome Profile 的窗口	Console、网络、性能调试
Gemini CLI Browser Agent	Gemini CLI	existing 模式连接的 Chrome	使用内置工具，减少额外配置
ChatGPT 浏览器扩展	ChatGPT 桌面端	所连接 Profile，按站点授权	桌面端直接选择浏览器工作
Browser Harness	命令行 Agent、MCP 客户端	连接的 Chrome 会话	自定义脚本、跨工具复用

连接器免费开源，也仍需使用对应的模型服务。选择时可以先问自己一件事，只需要操作几张标签页，还是需要深入调试整个浏览器会话？

前者优先看 Playwright 扩展，后者优先看 Chrome DevTools MCP。已经在某家桌面端或 CLI 中工作，则可以先用原生入口。

1. Claude Code

bash 复制代码

# 官方 Chrome 集成
claude --chrome

# Playwright MCP 扩展模式
claude mcp add playwright-extension -- npx @playwright/mcp@latest --extension

# Chrome DevTools MCP
claude mcp add chrome-devtools --scope user -- npx chrome-devtools-mcp@latest --autoConnect --no-usage-statistics

2. Codex CLI

bash 复制代码

# Playwright MCP 扩展模式
codex mcp add playwright-extension -- npx @playwright/mcp@latest --extension

# Chrome DevTools MCP
codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --autoConnect --no-usage-statistics

3. Gemini CLI

使用内置 Browser Agent 时，采用前面的 existing 配置即可。

如果希望改用 Browser Harness MCP：

bash 复制代码

gemini mcp add browser-harness uvx -- --from "browser-harness[mcp]" browser-harness-mcp

4. Cursor

在项目的 .cursor/mcp.json，或全局的 ~/.cursor/mcp.json 中加入：

bash 复制代码

{
  "mcpServers": {
    "browser-harness": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "--from",
        "browser-harness[mcp]",
        "browser-harness-mcp"
      ]
    }
  }
}

Cursor 内置 Browser 使用自己的工作区 Profile。需要复用日常 Chrome 的登录状态时，再连接上述扩展或 CDP 方案。

这些命令负责注册连接器；扩展安装、Chrome 调试开关和首次授权，需要按对应方案完成。

四、接通已登录 Chrome，能解锁哪些高价值场景？

编程 Agent 一旦同时拿到本地代码库、真实业务页面和浏览器调试信息，就能把过去需要开发者来回搬运的信息接起来。

你不必反复截图、复制报错、粘贴接口响应。它可以自己看现场，再回到代码里处理问题。

下面五类任务，尤其适合这种工作方式。

场景 1，带企业 SSO 的全栈调试

传统痛点

很多 ToB 系统即使跑在 localhost 或预发环境，也要经过 Okta、企业微信扫码或公司统一鉴权。

Agent 能启动项目，却看不到登录后的页面。代码修改只能靠推测，验证又得交回给人。

接管后的做法

你先在 Chrome 中完成登录，再让连接了 Chrome DevTools MCP 的 Agent 接手。

修改 React 或 Vue 代码后，它可以刷新业务页面，读取 Console 报错、检查失败的 REST 或 GraphQL 请求，再回到代码中继续修复。

bash 复制代码

读取业务页面
    ↓
检查 Console 与网络请求
    ↓
定位前后端代码
    ↓
修改并运行测试
    ↓
回到原页面验证

登录这道坎由你处理一次，后面的排错可以连续推进。

场景 2，不再逐个平台接 API，直接跨系统分诊

传统痛点

想完成"读 Sentry 报错、查 Confluence 文档、定位本地代码"，往往要先配置多个平台的 API 凭证。

有些系统没有合适的接口，有些工具接入流程又很长。真正的排错还没开始，集成工作先堆了一桌。

接管后的做法

把已经登录的 Sentry、Confluence 等标签页交给 Agent。例如使用 Playwright 扩展，将需要的页面放进同一个授权标签页组，然后下达任务：

查看 Sentry 页面中出现次数最多的空指针异常，结合 Confluence 的接口文档，在本地分支定位并修复问题，完成后运行相关测试。

这样可以先通过现有网页完成查询，不必为一次排错给每个平台单独开发连接器。

场景 3，人工复现到一半，AI 原地接手

传统痛点

有些前端 Bug 很会藏。要连续点击十几步、展开多层弹窗、选中特定日期，才会触发。

让 Agent 从首页重新走一遍，既耗时，也容易在某个细节上跑偏。

接管后的做法

你先手动把页面操作到出问题的状态，再让 Agent 连接当前标签页：

接手当前订单页面。筛选后表格出现卡顿，请保留当前筛选条件，录制一段性能轨迹，定位耗时最多的调用，并检查对应代码。

它可以从现有页面状态继续调查，省去重建整个复现过程的时间。

这类"接力式 Debug"，往往比让 Agent 从零包办更顺手。

场景 4，老旧后台和 SaaS 控制台里的重复配置

传统痛点

日常工作里，总有一些"只能点网页"的事情。老 ERP 没开放 API，第三方后台要逐条配置 Webhook，账单要按月份下载，几十项设置只能挨个核对。

这些操作不难，却很磨人。

接管后的做法

让 Browser Harness 或其他浏览器工具读取明确的配置清单，在已登录后台逐项填写、核对，再按任务授权提交。

例如：

根据这份测试环境 Webhook 清单，检查后台现有配置。先列出缺失项和差异，再补齐我确认的项目，最后导出结果。

后台标签页负责重复操作，你可以继续处理其他工作。任务依据也来自明确的清单，方便最后对账。

场景 5，保留设备绑定会话，做报表核对与页面巡检

传统痛点

某些站点启用了设备绑定会话。把 Cookie 搬到独立浏览器或 CI 容器后，即使最初能访问，也可能在续期时失效。

接管后的做法

让 Agent 留在已经建立会话的原浏览器中操作，由浏览器继续完成正常的会话维护。这样可以减少凭证搬运带来的问题，用于读取已授权报表、核对业务数据，或检查登录后的页面流程。

这里最实用的变化，是保留原会话与现场状态。网站要求重新验证时，用户接手验证，再继续任务。

编程 Agent 写得出代码，却看不到真实页面，很多工作就只能完成一半。

接通已登录 Chrome 后，报错、请求、页面状态和本地代码终于能放到同一次任务里。

别让智能体 Agent 卡在登录页！接管“已登录 Chrome浏览器”的 6 种实战方案

一、为什么"复制 Cookie 到新浏览器"越来越不省心？

1. Cookie 能复制，设备私钥搬不走

2. 新 Profile，意味着登录流程再走一遍

3. Chrome 136 收紧了默认目录的远程调试

二、接管已登录 Chrome 的 6 种实战方案

方案 1，Claude in Chrome，官方直连最省事

方案 2，Playwright MCP 扩展模式，标签页"指哪打哪"

方案 3，Chrome DevTools MCP，前端调试的重装备

方案 4，Gemini CLI 内置 Browser Agent，改成 existing 即可复用

方案 5，ChatGPT 桌面端浏览器扩展，用 @ 直接叫来 Chrome

方案 6，Browser Harness，能边干活边补工具的瑞士军刀

三、六种方案怎么选？附主流 Agent 接入命令

先看控制范围，再看接入方式

1. Claude Code

2. Codex CLI

3. Gemini CLI

4. Cursor

四、接通已登录 Chrome，能解锁哪些高价值场景？

场景 1，带企业 SSO 的全栈调试

场景 2，不再逐个平台接 API，直接跨系统分诊

场景 3，人工复现到一半，AI 原地接手

场景 4，老旧后台和 SaaS 控制台里的重复配置

场景 5，保留设备绑定会话，做报表核对与页面巡检