ego 解放双手:让 AI 代理真正去用浏览器,而不是让你去迁就它

最近我把博客里好几个「本来要我自己点」的活,都丢给了 AI 代理自动跑——登录后台、抓数据、填表、截图、跨站点复制粘贴。我反复被一件事教育:

AI 能不能干活,不取决于模型多强,而取决于它能不能稳定地「动浏览器」。

模型再聪明,只要浏览器这一关过不去,它就只能给你出方案,然后还是得你自己点鼠标。直到我认真用了一段时间 ego-browser,这条死循环才算真正断掉。

今天这篇,我想把 ego-browser 当作「让 AI 解放双手」的工具来介绍,而不是又一篇「AI 写代码真爽」的宏大叙事。

ego-browser 到底是什么

一句话:ego-browser 是一个给 AI 代理用的 Chromium 外壳。

它在普通 Chrome 的基础上多做了三件事:

能力	普通浏览器	ego-browser
跑在本地,登录态可继承	✅	✅
多个互相隔离的任务空间(各自一套标签页)	❌(要靠 profile 或多开浏览器)	✅
对外暴露完整 CDP + Node.js 助手脚本	❌(要自己起 puppeteer)	✅
任务中途能把浏览器交回给你操作	❌	✅(handOff / takeOver)

它的核心心智模型有三个:任务空间(task-space)、登录态继承、工具函数加载。

这三件事,决定了 AI 代理能不能「真的在用浏览器」,而不是在跑一个临时开起来、用完就关的隐身窗口。

为什么普通浏览器对 AI 不够友好

在讲 ego-browser 怎么好用之前,先看「普通浏览器 + puppeteer/playwright」为什么不够用。

我用 puppeteer 写过不少爬虫脚本,通常的姿势是:

const browser = await puppeteer.launch({ headless: true })
const page = await browser.newPage()
await page.goto('https://example.com')

这条路能跑,但踩雷极多:

登录态是空的。你要么把 cookie 导出来再塞进去(格式经常对不上、还会过期),要么手动登录一次把 storageState 存下来再用——而很多网站反爬很严,headless: false 反而更难,因为它们认为 headless 才是机器人、headful 才是真人。
任务之间互相打架。代理 A 开着某后台,代理 B 也想开,共用同一个 Chrome 实例就开始抢标签页、抢 devtools 端口、抢代理设置。
异常处理太粗糙。脚本里一个 click 没命中,你要么 catch 重试,要么整条链路中断——但浏览器其实还好好的,标签页也还在。
没有「人介入」机制。遇到验证码、扫码登录、风控弹窗,脚本只能干瞪眼,要么停在那里,要么笨重地重启。

ego-browser 干的就是把这四件事系统性地解决掉。

任务空间:一个浏览器,多个互不干扰的工作台

这是 ego-browser 最值钱的设计。

const task = await useOrCreateTaskSpace('inspect example page')

一个任务空间对应一组互不干扰的标签页 + 一个独立的 browsing context,但默认继承当前用户的登录态。

这意味着:

你在 Chrome 里登录过的网站,agent 不用再登录一次
agent A 在抓某后台,agent B 在填另一份表单,两人互不知道对方存在
你想中途让 agent 停下来自己点几下,「交还控制权」是显式 API,不是靠抢

我在用的时候最常见的姿势就是:

ego-browser nodejs <<'EOF'
const task = await useOrCreateTaskSpace('抓取本月 CSDN 阅读数据')
await openOrReuseTab('https://blog.csdn.net/xxx', { wait: true })
cliLog(await snapshotText())
EOF

useOrCreateTaskSpace 不是「开一个新浏览器」,而是「给我找个不打架的工作台」。同名任务空间可以跨多次 heredoc 复用,这才是真正能撑住长流程的能力。

登录态继承:不用导 cookie,也不用 selenium 那一套

传统自动化最恶心的一步永远是登录。

微信公众号后台、知乎创作者中心、各种 SaaS——它们要么有扫码、要么有手机验证码、要么干脆风控封杀 headless。puppeteer 时代最常见的 workaround 是「人工登录一次,导出 storageState,后续脚本加载」。这条路能走通,但每次 cookie 过期都要重做一次。

ego-browser 的做法是直接基于你正在用的 Chrome,而不是拉起一个隔离实例。换句话说:

你的 Chrome 是「登录态来源」
agent 借这套登录态干活,本身不登录
任务跑完,登录态还留在你的 Chrome 里,你下次打开照常用

这带来的副作用是:agent 的动作不会污染你的标签页——它开的是任务空间里的标签页,不是你的;反过来,你随便关你那边的标签页,也不会让 agent 那边的脚本崩。

我第一次跑通「让 agent 自己进 CSDN 后台抓数据」的时候,真的是会心一笑。

工具函数:不是 puppeteer,更接近「操作手册」

普通 puppeteer 写起来是这样的:

const el = await page.$('button.submit')
await el.click()
await page.waitForSelector('.toast')
const text = await page.$eval('.toast', el => el.innerText)

ego-browser 给你的是更接近「人话」的一层:

await click('@21', { label: '点击提交按钮' })
const text = await js(`document.querySelector('.toast').innerText`)

注意几个细节:

@N 引用:来自 snapshotText() 的可访问性树快照,直接对应「页面上能被屏幕阅读器读到的元素」,这是无头场景里最稳定的抓取对象。
label 参数:每次点击都带个 3-6 个词的意图标签,主要是为了在录屏里留痕迹,排查 agent 卡在哪一步特别好用。
js() 和 cdp():前者就是 Runtime.evaluate,后者直接发 CDP 命令。需要的精细操作,随时可以下沉到浏览器协议。

我在用 ego-browser 之前,自动化脚本最痛的一步是「定位元素」——选择器天天失效、xpath 太脆、role 在不同页面又不一致。snapshotText() 返回的可访问性树把这步变成可观察、可调试的——agent 不再需要「猜选择器」,而是基于「这个按钮是干啥的」去点击。

几种真实工作流

下面这些活是我这半个月里真丢给 ego-browser + 代理跑的,顺手记一下用得对路的姿势。

1. 抓后台数据

公众号后台、CSDN、知乎、掘金——各家后台都有反爬,但 agent 借你的 Chrome 跑就没事。

const task = await useOrCreateTaskSpace('公众号后台周报数据')
await openOrReuseTab('https://mp.weixin.qq.com/', { wait: true })
// 静观:登录态已经在
await waitForElement('text=昨日阅读数', { timeout: 10 })
cliLog(await snapshotText({ scope: 'only_within_viewport' }))

2. 填表单 / 提交申请

很多内部 OA、报销系统、表单填写,字段多但逻辑简单,这是 agent 最擅长的领域。

await fillInput('@email', '[email protected]')
await fillInput('@subject', '本月工具采购报销')
await uploadFile('input[type=file]', '/abs/path/to/invoice.pdf')
await click('@submit')

3. 跨站点搬运数据

「把 A 站的数据填到 B 站」这种无聊活,自己点三十个表单字段要半小时,agent 跑两分钟。

4. 录屏 + 排错

agent 卡住的时候,captureScreenshot() + @N 引用 + 标签文本一组合,基本能定位 90% 的卡点——这比 puppeteer 时代翻 trace 强太多。

5. 中途交还给我

这是最体现「设计感」的一处:

await handOffTaskSpace([task.id])   // 浏览器还给你
// 你自己点几下、扫个码、过人机验证
// 完成后告诉我「继续」

我让它跑某个需要扫码的内部系统时,这套机制直接救命——agent 不会傻等着,而是把控制权干净地交回给你。

它不是万能的

ego-browser 不是银弹。说几个它处理不好的场景:

没有图形界面的服务器:它本质依赖一个能跑 Chromium 的环境,纯 Linux 容器想跑起来要折腾 xvfb、headless 配置。纯云端自动化任务,Puppeteer + headless 还是更省心。
反爬特别严的站:借你 Chrome 跑能骗过大部分常规风控,但遇到 Cloudflare Turnstile、复杂的设备指纹检测,仍然要靠真人介入或者住宅代理。
复杂的 canvas / 富文本编辑器:Notion、Figma、Google Docs 这种是基于 canvas 的,DOM 选择器几乎没用,得切到「截图 + 鼠标坐标」这种笨办法。ego-browser 支持,但写起来要谨慎。
需要长稳态运行的工业级爬虫:它定位是「AI 代理的浏览器」,不是「爬虫集群」。量大了请上 Playwright Cluster,不要拿它当爬虫框架。

我的取舍

如果让我给「要不要上 ego-browser」定一条线,我现在大概这么分:

场景	推荐
让 AI 代理在「我已经登录过的网站」里点东西	✅ ego-browser
跑一次性、定时的小数据抓取	✅ ego-browser / Puppeteer 都行
写一个长期运行的工业爬虫	❌ 拿 Playwright Cluster
做端到端 UI 测试	✅ Playwright 仍更稳
需要扫码、过人机验证	✅ ego-browser(交还控制权机制)
想给博客文章自动配封面图、配正文图	✅ ego-browser 抓 Doubao/Kling 输出

最后一条听起来离谱,但「agent 调 Doubao 生成图 → 自动抓到文章目录 → 自动 commit」这条链路,我现在是真的在跑。

写在最后

我越来越确信:AI 能不能替代人干活,不是看模型能写多复杂的代码,而是看它能不能在「真实世界」里动手。

写代码是 AI 最早拿下的工作,因为代码本身是结构化的、有 git、有 test,改坏了立刻有反馈。但「在浏览器里点鼠标」这种看似更简单的活,因为之前没有合适的工具,反而是最后被攻克的。

ego-browser 这种东西,本质上是把「人 - 浏览器 - AI 代理」这条链路上所有原本别扭的环节都重新接了一遍。它不是新的浏览器引擎,也不是新的 AI 模型,它只是把「AI 怎么用浏览器」这件事,从一个每次都要自己拼的脚本工作,变成了一个有清晰心智模型的工具。

对 AI 代理来说,能动手,才有自由。而「能动手」这件事,ego-browser 这一年做得最像样。