# 一个真实 Chrome,几个 agent,还有你自己:怎么不互相点乱

chrome-use 的卖点是让 agent 用你这一个真实浏览器。但这个卖点自带一个麻烦:开新浏览器的工具,每个任务一个独立浏览器,天生井水不犯河水;chrome-use 反过来,可能有好几个 agent、加上你本人,同时在同一个 Chrome 里动手。谁点了谁的标签页、谁把谁的页面导航走了,这问题它必须解决,不然"用你的浏览器"就成了灾难。

问题比想象的具体

假设你正开着 Chrome 看文档,后台挂着两个 agent:一个帮你翻 Slack 消息,一个在抓某个后台的数据。三方都在这一个浏览器里。

要是它们不加区分地操作"当前标签页",立刻乱套:agent A 打开的登录页,被 agent B 当成自己的目标点了下去;你正在读的那个标签,被某个 agent 导航去了别处。开新浏览器的方案没有这个问题,因为它们各有各的进程。chrome-use 想在"共用一个真浏览器"的前提下拿到同样的互不干扰,得靠别的机制。

它的解法:按"谁开的"来隔离

chrome-use 不给每个 agent 发一个浏览器,而是在同一个 Chrome 里按归属切分。每个 --session <名字> 会拿到三样东西:一个彩色标签组(你在 Chrome 里一眼能看出哪组是哪个 agent 的)、一个专属的后台 daemon,以及一条铁规矩,它只操作自己创建的标签页。

于是三方各玩各的:agent A 的页在 A 的标签组里,agent B 的在 B 的组里,你自己的标签谁都不碰。你甚至不用给每个 agent 起名字,不设的话它会按 agent 自动派生一个稳定的 session 名。标签在一个 session 内有稳定的 id(t1、t2…,用过不复用),所以"切回我刚才那个标签"这种事是确定的,不会串号。用完 chrome-use close(或 close --all)把这个 session 的标签清掉,不碰你其它的。

一个不写出来会栽的取舍

这里有个关键细节,官方文档点了一句、但很容易被略过:这套按 session 隔离,只在"扩展连接"这条路上成立;你要是用原始的 --cdp <端口> 直连,它不隔离。

原因是隔离靠浏览器扩展去管标签组和归属;裸的 CDP 端口连接没有这一层,几个连接看到的是同一堆标签,谁都能点谁的。这一点正好接上我之前写 Electron 那篇的另一面:Electron 应用只能走 --remote-debugging-port(装不了扩展),所以在 Electron 上你拿不到这套多 agent 隔离,那条路本来就没有扩展兜底。

这也顺便解释了 chrome-use 为什么在浏览器场景坚持走扩展加 native messaging、而不是图省事直连调试端口:不弹"是否允许远程调试"只是表面好处,更实的是,扩展这条路才撑得起"一个真实浏览器上多个 agent 各自为政"。

顺带一层:页面内也隔离

隔离不止在标签级。chrome-use 注入页面的那些操作,跑在一个隔离世界(isolated world)里:能读页面的 DOM,但碰不到页面自己的 JS 全局变量。好处是双向的:你的自动化逻辑不会意外踩到页面脚本的全局,页面脚本也探测不到你注入了什么。这跟"不被反爬识别"是一条线上的事,痕迹越少越好。

什么时候你才用得上

单个 agent、单个任务,其实不用想这些,默认那个自动 session 名就够了。真正需要在意的,是你开始并行跑多个 agent、而且它们共用你这一个登录好的浏览器的时候:比如一个常驻助理在收发消息,你又临时让另一个 agent 去查点东西。这时给它们各分一个 --session,三方(两个 agent 加你)在同一个 Chrome 里同时干活也不打架。

说到底,开新浏览器的工具是用"多开几个浏览器"换来的隔离;chrome-use 是在坚持"就用你这一个真浏览器"的同时,用归属和标签组把隔离做进去。前者省事,后者换来的是:你那一整套登录态,几个 agent 谁都能直接用,不用各自重登一遍。