让编程 Agent 接管已登录的 Chrome

让 AI 去查后台工单，第一步却卡在登录页，往往是因为它启动了一个全新的浏览器，拿不到你日常 Chrome 里的登录状态。chrome-use 想解决的就是这个断点：通过扩展和本地通信，让 Claude Code、Codex、Cursor 或脚本操作你已经登录的 Chrome。

它的价值在于复用现有会话、允许人工接管，也不用打开远程调试端口。但接上浏览器、选对账号、确认任务真的完成，是三件不同的事。原文把连接方案讲得比较清楚，对反检测效果则需要保留判断。

不开调试端口，怎么操作现有 Chrome

普通自动化经常创建新的浏览器上下文（browser context）。可以把它理解为一套独立的浏览器身份，没有原来的 Cookie，自然要重新登录，甚至触发验证码和新设备提醒。

Playwright、Puppeteer 也支持持久化配置和连接现有浏览器，限制在于连接方式。按原文说明，从 Chrome 136 开始，默认配置目录会忽略 --remote-debugging-port；使用独立配置目录可以继续自动化，但通常还得重新登录。

Chrome 144 又提供了 chrome://inspect 里的远程调试开关，Chrome DevTools MCP 可以通过 --autoConnect 接入。原文指出，这条路线需要批准对话框，而且开启后，该配置下的所有窗口都处于工具可访问的范围。

chrome-use 走另一条路径：CLI 通过 Chrome 原生消息通信（native messaging）连接扩展，再由扩展调用 chrome.debugger 操作目标标签页。这个通道是本地进程通信，没有网络监听端口，不需要连接令牌或远程服务器。项目采用 Apache-2.0 许可证。

这里要分清：不用远程调试端口，不等于没有调试权限。

扩展仍然使用调试 API，附着期间，Chrome 会在代理标签页显示调试提示条。chrome-use extension connect --silent 可以通过一次带有 --silent-debugger-extension-api 的 Chrome 重启隐藏提示条；原文称标签页和登录状态会恢复。

每个 --session 会获得独立的彩色标签组，方便多个代理共用 Chrome。遇到登录、双因素认证或无法处理的验证码，用户可以在同一窗口接手。标签组有助于分开任务，但不能据此推断它提供了账号或权限隔离。

安装成功以后，还要让代理选对工具和账号

安装包含三个部分：CLI、扩展、本地通信桥。安装脚本从最新 GitHub Release 下载预编译二进制，不依赖 npm；Windows 安装到 %LOCALAPPDATA%\Programs\chrome-use，不需要管理员权限，并检查下载文件的 sha256。

Chrome Web Store 扩展 ID 是 knfcmbamhjmaonkfnjhldjedeobeafmk。装好后，用 chrome-use extension install 注册通信桥，再运行 chrome-use doctor 检查环境、Chrome、守护进程和配置。

macOS 有个容易忽略的选择：安装程序可以提供配置描述文件，把扩展强制安装到每个配置中，但会让 Chrome 进入「由组织管理」状态，并锁定安全 DNS 等设置。不需要这套策略时，可以使用 chrome-use extension install --no-profile，再逐个配置安装扩展。

doctor 通过，只说明连接环境正常。网页里究竟登录了哪个账号，仍然要进页面确认。

安装器还会为 Claude Code、Codex、Cursor 和 ~/.agents/skills 放置发现用的 skill。使用 skills.sh 的环境可以运行 npx skills add leeguooooo/chrome-use -g，这条路线需要 Node。Claude Code 的插件安装命令则是 /plugin marketplace add leeguooooo/plugins 和 /plugin install chrome-use@leeguooooo-plugins。

skill 会引导代理加载 chrome-use skills get core。用法由本机二进制提供，目的是让说明与安装版本匹配。只支持 MCP 的客户端也能把 chrome-use mcp 配置为 stdio 服务。

Codex 还有工具路由问题。项目文档报告，在安装很多 skill 的机器上，描述被裁剪后，即使提示里点名 chrome-use，Codex 仍可能选择自带浏览器插件。他们采用的办法是在项目 AGENTS.md 中明确指定入口：

Use the `chrome-use` CLI from the shell for every browser task; start with `chrome-use skills get core`.
Do not use the built-in Chrome plugin for browser work here.

注意第一行的 every browser task：它会影响项目中的全部浏览器任务，适合已经决定统一使用 chrome-use 的项目。原文没有给出这个路由问题的发生比例，不能把个别环境中的经验当成所有 Codex 安装的固定行为。

怎样确认代理真的完成了页面操作

原文建议先做只读任务：在项目 GitHub issues 中搜索 is:issue daemon，使用专用会话 first-task，读取三个匹配标题和链接，不创建或修改 issue。

这个示例的重点，是建立一套可检查的操作循环。下面三条原始命令展示了进入页面、读取可交互元素和获取标题的过程：

chrome-use --session demo open https://github.com/leeguooooo/chrome-use
chrome-use --session demo snapshot -i     # interactive elements with @eN refs
chrome-use --session demo get title

注意第二行的 snapshot -i。它从可访问性树提取可交互元素，并给出 @e12 这样的短引用；代理再执行 click @e12 或 fill @e7 "text"，随后重新读取快照确认页面变化。

搜索示例还要求提交时使用 --observe，并检查结果 URL 是否包含 q=is%3Aissue+daemon。命令返回成功，只能说明命令执行了，搜索条件有没有生效，要看页面和 URL。

操作结果应该由页面状态证明。

只读流程跑通后，再换成确实需要登录的自有后台，并先确认可见账号。这个顺序对日常 AI 编程很实用：先验证连接和交互，再验证业务身份，最后才考虑有副作用的操作。

我的判断

我认可它对登录状态的处理。对于需要查询内部后台、复用 SSO、偶尔人工完成二次认证的任务，操作现有 Chrome 能减少重新搭建登录环境的麻烦。原文称安装后每次调用不再弹确认框，这也让连续操作更顺畅，同时要求使用者认真选择接入的浏览器配置。

但它没有证明自己是所有浏览器任务的最佳入口。原文按截至 2026-10-27 查阅的项目文档给出建议：前端调试和性能分析优先看 Chrome DevTools MCP；已经使用 Playwright MCP 的团队可以先看它的扩展模式；只用 Claude 且有付费计划的用户，可以考虑 Claude in Chrome。chrome-use 更贴近跨代理复用登录态和多个会话并行的需求。

反检测部分尤其要看清证据边界。项目称连接真实 Chrome 时不注入 JavaScript 补丁，默认不启用 Runtime.enable，只有捕获控制台或错误时才开启；定位元素使用节点句柄，不向 DOM 写临时属性。--humanize 提供曲线鼠标轨迹、落点抖动和可变输入节奏，并称在 Akamai、PerimeterX、DataDome 防护页面自动使用完整拟人动作。

这些是设计说明。项目自测还报告：CreepJS 为 0% stealth · 0% headless，bot.incolumitas 全部检查通过，bot.sannysoft 全绿，BrowserScan 的 Webdriver、User-Agent、CDP 检查干净，并通过 scrapingcourse.com 的 Cloudflare managed challenge。

原文没有解释 CreepJS 这两个百分比的评分含义，也没有给出足够的对照数据。它还转述独立测试称，有界面模式下普通 Playwright 也能通过这些指纹页面。因此，这些结果只能算特定环境的自测，支撑不了「稳定绕过风控」的结论。

普通 Yidun 拼图可尝试 solve-slider，可读图标挑战可借助截图点击；失败后交给用户。登录和第二因素同样需要交接。保留人工入口，比承诺永远不会遇到 CAPTCHA 更可信。

能拿来做什么

• 如果 AI 经常卡在已登录的内部后台，可以先用独立 --session 做只读查询，并在页面里确认账号，再评估是否接入写操作。
• 如果项目明确采用 chrome-use，可以在 AGENTS.md 固定入口，并要求先加载 chrome-use skills get core，减少代理误选工具的情况。
• 给代理布置搜索或表单任务时，应同时写出验收条件，例如查询参数、结果标题或提交后的页面状态，让它提供实际页面证据。
• 如果关注反检测，可以用 chrome-use stealth status 查看当前状态，并在自己的目标页面验证；性能分析、现有 Playwright 流程等需求，则先比较原文列出的对应工具。