企业官网建设流程全解析

让编程智能体用上你已登录的 Chrome：六种方案怎么选

原文：Browser Use Blog - 《How to Let Your Coding Agent Use Your Logged-In Chrome (2026)》（https://browser-use.com/posts/coding-agent-logged-in-chrome）

一、先排除那个看起来最省事的做法

几乎每个想让 Agent 进浏览器的人，第一反应都是把 cookie 导出来，灌进一个新起的自动化浏览器。Browser Use 的 CTO Gregor Zunic 在 10 月 25 日的这篇文章里，开头就把这条路堵死了，理由只有一句：新的自动化浏览器是另一台设备。

具体会卡在三处：

第一处是设备绑定。Chrome 有个 Device Bound Session Credentials 机制，会把私钥放在 TPM 这类安全硬件里；当站点的短生命周期会话 cookie 过期时，Chrome 只能靠证明自己持有那把私钥来续期。在用了这套机制的站点上，你拷过去的 cookie 一过期就再也续不上，换台机器更不行。

第二处是重新登录。全新 profile 是一张白纸，所有站点都是登出状态，你得在自动化环境里把每个登录和二次验证重做一遍。而 Chrome DevTools MCP 的文档明确提到，某些账号在浏览器被 WebDriver 控制时会直接禁止登录。

第三处是旧捷径已经关了。从 Chrome 136 起，远程调试端口和远程调试管道这两个启动参数，对默认数据目录一律忽略，必须另外指定一个数据目录才生效。Google 这么改的原因很直接：攻击者在用远程调试把 cookie 从 Chrome 里掏出来。

所以现在的正确姿势统一成了一句话：让 Agent 进你的真实浏览器。登录态、设备校验、二次验证全都留在原地，不用搬运。

二、六种方案，各自的边界在哪

原文按"能配哪个 Agent、能不能用你真实的已登录 Chrome、怎么装、有什么限制"四栏，逐条列了六种。我把关键边界整理成表，后面再补几条表里放不下的细节。

几条表里塞不下的关键限制：

Claude in Chrome 只认直连套餐。用 API key、用 claude setup-token 生成的 token、走 Bedrock 或 Google Cloud 或 Microsoft Foundry、以及在 WSL 里，这个功能都是关掉的。它还会在登录页和验证码处停下来等你处理。扩展需要 1.0.36 以上版本，装完先 /login，再跑 claude --chrome，用 /chrome 可以查连接状态或设为默认开启。

Playwright MCP 的扩展模式默认每次连接都要你批准，把扩展里的连接令牌拷到服务端的环境变量里可以免掉这一步。它只支持 Chrome 和 Edge。如果你装了多个 Chrome profile，它会连你最后用的那个，可以用参数指定具体 profile。多个客户端能同时连，各拿一个标签组，互相只看得到自己组里的页面——这一点对"想限制 Agent 视野"的场景很合适。

Chrome DevTools MCP 默认是另起一个 Chrome 用独立 profile，要用自动连接参数才附加到你正在跑的那个，且要求 Chrome 144 以上。连接时 Chrome 会弹窗让你允许，之后一直显示"受自动化测试软件控制"的横幅。多个 profile 同时开着时，它连默认那个，能看到该 profile 的全部窗口。另外它默认收集使用统计，可以用参数关掉。

Gemini CLI 的浏览器 Agent 默认是关的，且默认会话模式是 persistent——在用户目录下自建一个 profile，不是你日常那个。要接你的 Chrome，得把会话模式改成 existing，再在设置里打开 Agent 开关。它对表单填写一律要求确认，支持域名白名单，单任务默认 100 次工具调用后停手。

桌面版 Codex 走的是浏览器扩展，覆盖 Chrome、Edge、Brave、Opera、Vivaldi。原文只描述了桌面应用，没提 Codex CLI——CLI 要用浏览器，得靠 Browser Harness 或那两个 MCP 服务。它默认在每个新站点前问你，允许范围可选一次、该站、或所有站，其中"所有站"被 OpenAI 标为 Elevated Risk。

Browser Harness 是 Browser Use 自己的开源工具，通过 CDP 附加到你已开的 Chrome。在 Claude Code 和 Codex 里它以命令行工具加 skill 的形式工作，缺什么辅助函数由 Agent 当场写；Cursor、Gemini CLI 这类客户端走它的 MCP 版本，拿到的是一组固定的浏览器工具。它能控制整个浏览器，被它接管的标签页标题前会加一个马的表情，且它在后台工作，你当前看的标签不会被抢走。它的命令行版本默认上报遥测，内容包括 Agent 管道给它的代码和代码的输出，一条命令可以关掉。

三、按你手上的 Agent 反查方案

原文给了一张映射，比按功能对比更实用，因为大部分人不是"选工具"，而是"我只有这个 Agent，能用哪个"。

• 用 Claude Code 且订阅了 Pro、Max、Team、Enterprise：直接用 Claude in Chrome，这是最短路径。用 API key 或走云厂商的，改 Browser Harness、Playwright MCP 扩展模式或 Chrome DevTools MCP。
• 用 Codex：桌面端用 OpenAI 的浏览器扩展；CLI 用 Browser Harness 或那两个 MCP 服务。
• 用 Gemini CLI：内置浏览器 Agent 加 existing 会话模式，装都不用装；或者任选一个 MCP 方案。
• 用 Cursor：它自带的 Browser 是按工作区各存一份 cookie，不是你的 Chrome 登录态。要用真实 Chrome，往它的 MCP 配置里加 Browser Harness、Playwright MCP 或 Chrome DevTools MCP。
• 任意 MCP 客户端：想限定标签页，用 Playwright MCP 扩展模式；想给整个浏览器，用 Chrome DevTools MCP 自动连接或 Browser Harness。

作者本人的取舍口径可以概括成三句话：只想省事且只用 Claude Code，选 Claude in Chrome；想把 Agent 关在指定标签里，选 Playwright MCP；想要一个跨 Agent、跨套餐都能用的统一工具，选 Browser Harness。

四、安全边界不是附录，是选型的一部分

原文把安全单列了一节，我认为这是全文最该被截下来贴在显示器上的部分，因为它决定了"接整个浏览器"和"接一个标签页"之间的差距到底有多大。

核心事实只有一句：登录态浏览器里的 Agent，能做你能做的一切。厂商们自己也这么说。

主要风险是提示注入。缓解手段里最有效的是隔离——尽量给它一个独立的 Chrome profile；Anthropic 的建议也是用不接敏感账户的浏览器 profile。

其次是看清工具能摸到多大范围。Chrome DevTools MCP 和 Browser Harness 这类附加整个浏览器的工具，能看到那个 Chrome 里开着的一切。所以正确的做法是把敏感账户（邮箱、银行、公司后台）放在一个你不附加给 Agent 的 Chrome 里。

再就是那个老的手动方式：自己启动 Chrome 带远程调试端口，本机任何程序都能连上这个端口控制浏览器——这是 Chrome DevTools MCP 文档自己写的警告。不管走哪种方式，用完记得把远程调试关掉。

最后是审批粒度。凡是会发送、付款、删除的操作，别关掉确认。原文列出的默认行为是：Claude in Chrome 在动金融类站点前会问，ChatGPT 扩展在每个新站点前会问，Gemini CLI 每次填表单都会问。

五、动手前的体检脚本

在配 MCP 之前，先用三十行确认两件事：Chrome 版本够不够（多数方案要 144 以上），以及那个被反复警告的远程调试端口是不是开着。下面这段是我自拟的示意脚本，不是官方提供，只做本地只读检查。

# chrome_ready.py —— 附加浏览器之前的本地体检，只读，不改任何配置importsocketimportwinreg MIN_CHROME=144DEBUG_HOST,DEBUG_PORT="127.0.0.1",9222defchrome_version():"""从注册表读 Chrome 版本号；读不到返回 None，调用方不能假设它有值。"""forhivein(winreg.HKEY_CURRENT_USER,winreg.HKEY_LOCAL_MACHINE):try:withwinreg.OpenKey(hive,r"SOFTWARE\Google\Chrome\BLBeacon")askey:returnwinreg.QueryValueEx(key,"version")[0]exceptOSError:continuereturnNonedefport_open(host,port,timeout=0.3):"""connect_ex 返回 0 表示连上了，也就是有程序在监听这个端口。"""withsocket.socket()assock:sock.settimeout(timeout)returnsock.connect_ex((host,port))==0defreport():ver=chrome_version()major=int(ver.split(".")[0])ifverelse0print(f"Chrome 版本:{veror'未读到'}（远程调试开关需要{MIN_CHROME}+）")print(f"版本满足要求:{major>=MIN_CHROME}")listening=port_open(DEBUG_HOST,DEBUG_PORT)print(f"{DEBUG_PORT}端口:{'有程序在监听'iflisteningelse'空闲'}")iflistening:print(" 注意：该端口开着时，本机任何程序都能连上来控制浏览器，用完请关掉远程调试")if__name__=="__main__":report()

参数与返回值：chrome_version 不接收参数，返回形如 144.0.7559.0 的版本字符串；它遍历两个注册表根，任一命中即返回，都读不到返回 None，因此调用方必须先判空再取主版本号，这也是 report 里那个 if ver 的作用。

port_open 收主机、端口和一个很短的超时，返回布尔值。用 connect_ex 而不是 connect，是因为前者把"连不上"当返回值而不是异常，不需要 try 包一层。

report 不返回任何东西，只打印，因为它的用途是给人看的体检结论，不是给程序判断。

调用链是：跑 report → 看版本是否达标 → 若端口已开，先判断是不是自己开的、要不要关 → 再决定走"扩展/自动连接"路线还是"独立 profile"路线。整个脚本不读任何凭据、不改任何设置，属于可以随手跑的那一类。

收尾

这篇文章真正解决的问题不是"怎么连"，而是"别用错办法连"。cookie 搬运那条路被设备绑定和 Chrome 136 的改动彻底堵死之后，剩下的六种方案分歧其实只有三个维度：Agent 兼容性、能看到多大范围、谁能控制审批。

选型顺序我建议按这个来：先定范围（只要一个标签，还是要整个浏览器），再定 Agent（你手上只有哪一个），最后才看安装成本。范围这一项排在最前面，是因为它同时决定了便利性和风险敞口，而这两者在这件事上没法兼得。

文中方案细节与限制来自 Browser Use 10 月 25 日的这篇文章，其自述"其他工具的说明均取自各自文档与 README，核对日期为 2026 年 10 月 25 日"。各工具版本迭代很快，参数名与版本要求请以官方文档为准。