只要心还在跳，就要努力学习。——张海迪

https://github.com/citrolabs/ego-lite

当浏览器开始“分身”：ego-lite 想把 AI 代理的网页自动化，变成一件更顺手的事

有些工具擅长“自动化浏览器”，有些工具擅长“连接 AI 代理”，但真正让人头疼的，往往不是“能不能跑”，而是“跑起来以后是不是顺手”。

ego-lite 给人的第一感觉，就很直接：它不是在强调一套抽象框架，也不是把浏览器当成一个遥远的被控对象来处理。它更像是在认真回答一个很现实的问题——当人和 AI 代理都需要浏览器时，能不能不要互相打架？

项目地址：https://github.com/citrolabs/ego-lite

它想解决的，不只是“浏览器自动化”

从 README 的描述来看，ego-lite 把自己定义成一个让你和 AI 代理并行工作的浏览器。

它的核心表达非常鲜明：你的代理会在它们自己的 Spaces 里执行多个浏览器任务，而你的标签页依然归你自己。也就是说，人在前台继续正常使用浏览器，代理在自己的工作空间里推进任务，彼此不抢焦点、不争控制权。这种设计，天然就带着一种很强的“共处感”——不是替你把浏览器夺走，而是把代理安顿到它该待的位置上。

README 还特别点出了它与一些现有工具的区别：有些浏览器自动化工具本质上是框架，需要额外的浏览器来驱动；登录状态也不容易自然继承；最后常常演变成用户和代理在同一个浏览器上下文里互相干扰。ego-lite 显然不想走这条路，它想把浏览器体验从“被脚本遥控”改成“可并行协作”。

这个项目最醒目的气质：快，而且尽量少折腾

仓库 description 里有一句很有辨识度的话：The fastest browser for AI agents to run web automation。后面紧接着给出的定位也很集中：它是为“把你已经登录过的浏览器状态分享给 AI 代理”而构建的，而且强调不打扰你，同时还给出了三个很有态度的词：Zero cost, zero config。

这种表达很像是在传递一种产品立场：别让用户先研究一堆环境变量、适配层和账户同步流程，再谈自动化。先让它跑起来，再让它自然融入你的工作流。

README 里的 Quick Start 也延续了这种思路。它没有故意把上手过程包装得神秘，而是提供了几种明显不同的入口：你可以直接下载 macOS 应用，可以通过 npx 只安装 ego-browser skill，也可以干脆把安装步骤交给代理自己去完成。这个设计很有意思，因为它不是强迫所有人按同一种方式接入，而是在承认每个人“开始使用一个工具”的习惯不一样。

它今天运行在 macOS，上手路径也很直接

README 写得很明确：ego-lite 目前运行在 macOS，Windows 和 Linux 处于 roadmap 中。

安装方式有三类。

第一类是下载 macOS 应用。README 说明，安装之后，ego-lite 会把 ego-browser skill 添加到机器上每个代理的 skills 目录中。

第二类是通过 npx 添加 skill：

1
npx skills add citrolabs/ego-lite

README 还提到，第一次让代理执行浏览器任务时，它会引导你安装 ego-lite 应用。这种方式很像“先把连接点埋好，真正需要时再完成浏览器侧安装”，节奏更柔和。

第三类更有“代理协作”的味道：直接把一段指令粘贴给代理，让代理替你完成 setup。

1
2
3
Set up ego lite for me: https://github.com/citrolabs/ego-lite

Read `skills/ego-browser/references/install.md` and follow the steps to install ego lite.

这段设计很妙。它没有把“安装”当成一个必须由人手工逐步完成的动作，而是把 setup 过程本身也纳入了 AI 代理可以处理的范围里。

它最诱人的一笔，是把你已有的浏览器状态接了过来

README 提到，第一次启动时，ego-lite 会询问一个问题：是否迁移 Chrome 数据。

如果选择 yes，代理就会继承你现有的 logins、cookies、extensions 和 bookmarks。这其实非常关键。很多浏览器自动化工具真正的阻力，并不在“会不会点按钮”，而在“登录是不是得重来一遍”“会话是不是断开的”“常用环境是不是完全割裂的”。

ego-lite 在这里给出的答案很直接：尽可能让代理进入一个你已经熟悉、已经完成登录、已经积累过使用痕迹的浏览器环境。这样一来，它想处理的就不再只是页面动作本身，而是整个“使用上下文”的继承。

README 还明确写到：你的浏览数据保留在你的设备上，ego-lite 只记录你是否选择在安装时迁移 Chrome。这个表述也很清楚，它把“本地保存数据”当成了产品叙事中的重要组成部分。

真正使用时，它看上去更像一条会被代理理解的能力入口

README 里给出的第一次任务示例很短：

1
ego-browser follow @ego_agent on x.com for me

按照 README 的描述，当你在 agent CLI 里输入 /ego-browser 加上自然语言任务后，代理会接手 ego-browser skill，在它自己的 Space 中打开页面，读取 Snapshot，在页面上执行动作，然后向你回报结果。而在这一切发生的同时，你自己的标签页不会被碰到。

这段体验描述之所以有吸引力，不在于命令多复杂，而在于它把“浏览器自动化”重新组织成了一种更自然的交互结构：

  • 你用自然语言发起任务
  • 代理通过 ego-browser skill 接管浏览器能力
  • 浏览器在代理自己的 Space 内完成执行
  • 人类用户的前台浏览不被打断

这种关系安排得很克制，也很有边界感。

README 里最值得细看的部分，是它如何概括自己的亮点

在 “Highlight of ego lite” 一节里，README 用表格概括了几个核心特性。这些点合在一起，基本就勾勒出了 ego-lite 的骨架。

1. 它强调“Code base, not CLI base”

README 的说法是：ego-lite 暴露给代理的能力，被封装成可直接调用的 JavaScript 函数，而不是让代理不停地在 CLI 文本界面里兜圈子。

这句话很重要。它说明 ego-lite 想减少复杂任务中额外的 token 消耗，也想让代理在执行层面更直接。与其让代理反复组织命令行文本、解析输出、再决定下一步，不如把能力包装成明确的函数入口。这是一种更偏“能力接口化”的思路。

2. 每个代理都有一个专属 Space

README 反复强调 Space。这是它最具辨识度的概念之一。

它给每个代理一个完全隔离的工作空间。你在前面浏览，代理在后面工作，彼此不会干扰。这样的结构让“同一个浏览器里同时存在多个任务”成为了一个自然的状态，而不是一种危险的抢占行为。

3. 代理可以在多个 Spaces 中并行处理任务

README 直接写到：每个 Space 都可以分配给一个 AI 代理，或者一个单独任务，而且这些任务可以同时运行。

这意味着 ego-lite 想表达的不只是“有隔离”，还有“有并行”。浏览器不再只是一个单线程的动作执行器，而更像一个能够容纳多路任务的操作场。

4. 它很看重 Snapshot 的质量

README 把自己称作拥有 “The strongest page Snapshot on the market”，并把这一点归因于 kernel-level customization。按照 README 的说法，这让 ego-lite 能生成更高质量的页面 Snapshot，而文本模型正是依赖这种视图来“看见”网页并执行动作。

这是一种很有意思的产品判断：很多人直觉上会把浏览器自动化理解成点击、输入、跳转，但 ego-lite 显然把“代理如何感知页面”放在了非常靠前的位置。

5. 任何代理都可以通过 ego-browser 驱动它

README 里提到，ego-browser 是 agent CLI 和 ego-lite 之间的连接层，适用于 Claude Code、Codex、Cursor，或者自定义代理。

这一点让项目的姿态很开放。它并不要求你必须迁移到某一种专门的代理环境，而是尝试成为一个可接入的浏览器能力层。

6. 它提到了“Experience accumulation”

README 里把这个特性标注为 coming soon。描述的方向是：浏览器任务里，代理大量时间花在 trial and error 上，而 ego-lite 的官方 Skill 会蒸馏经验，让代理越用越快。

这个点虽然还在未来计划中，但它透露了一种非常明确的思路：浏览器自动化不只是执行动作，更可能是一种可积累、可复用的经验系统。

它甚至把“对比”这件事写得很明白

README 专门列了一个 “ego lite vs existing products” 表格，把 ego-lite 和 Browser-Use、Vercel 的 agent-browser、ChatGPT Atlas、Perplexity Comet 放在一起比较。

表格中列出的能力包括：

  • 并行多任务
  • 可复用技能
  • 继承 Chrome 数据
  • 同一浏览器内的独立工作空间
  • 压缩语义输入
  • 可被外部代理控制
  • 数据本地存储
  • 无登录摩擦
  • 作为日常浏览器使用
  • 免费

按照 README 中这张表，ego-lite 在这些列项上都给出了明确位置。更重要的是，README 也给了两类竞品的解释方式：

一类是浏览器自动化框架，它们是代理调用的库，但不自带浏览器，因此登录状态、共享会话和并行工作方式会成为问题。

另一类是面向普通用户的 AI 浏览器，它们虽然能处理一些类似问题，但并不强调由外部代理控制。

这段对比的价值，不在于“谁赢谁输”，而在于它帮助读者快速理解 ego-lite 把自己放在哪个坐标系里：它不是单纯的自动化框架，也不是只服务单一产品闭环的 AI 浏览器，而是试图成为 AI 代理可调用、又保留日常浏览器属性的那一类工具。

它还给出了 benchmark，而且结论相当直接

README 中的 Benchmarks 写得很干脆：他们把 ego-lite 与 Vercel 的 agent-browser 在四个复杂的浏览器自动化任务上进行了基准测试，结果是 ego-lite 最快可达到 2.5× 的完成速度，并且使用的 token 明显更少。README 还补了一句：任务越难，差距越明显。

这类表述传达出的不是抽象口号，而是一种非常产品化的自信：如果你的任务本身就复杂，那么速度和 token 使用量不是边缘指标，而是会直接影响实际可用性的核心指标。

如果继续往下看，会发现它不只是“一个 README 里的想法”

仓库里还有 package/ego-browser/README.md，这部分信息能让人更具体地看见它的技术结构。

这个 README 把 ego-browser 描述为运行在 ego-browser Chromium 浏览器内部的 Node.js helper layer。浏览器暴露一个 ego runtime，包含 tabs、CDP、snapshots、task spaces 等能力，而这个包则负责把这些浏览器能力，打包成面向代理的 helper。

它甚至用一行结构图把关系串了起来：

1
ego-browser (Chromium) -> globalThis.ego -> Playwright-style helper facades -> agent heredoc

光看这行，就能感受到它的工程取向：浏览器提供底层运行时，helper 负责暴露代理友好的操作界面，而最上层的交互则可以通过 heredoc 形式送入执行流中。

ego-browser 的运行方式，也很值得玩味

package/ego-browser/README.md 给出了构建和运行命令：

1
2
3
npm ci
npm run build
npm test

其中 npm run build 会把内容打包到 dist/out/index.js，而浏览器会把 ego-browser nodejs <<'EOF' ... EOF 这样的 heredoc 分发给这个 bundle。

README 还给了一个示例：

1
2
3
4
5
ego-browser nodejs <<'EOF'
await taskSpaces.useOrCreate('demo')
await browser.openOrReuseTab('https://example.com', { wait: true })
console.log(await page.snapshot())
EOF

这个示例很有代表性。它同时展示了几个关键词：

  • taskSpaces.useOrCreate
  • browser.openOrReuseTab
  • page.snapshot

也就是说，在 ego-browser 这层里，浏览器能力已经被整理成了一组清晰的、偏 Playwright 风格的 helper facade。代理不需要自己硬拧底层浏览器协议，而是通过更顺手的抽象去完成任务。

如果只是本地调试 helper bundle，本 README 还给了另一种调用方式：

1
2
3
node dist/out/index.js <<'JS'
console.log(await page.info())
JS

同时，它也列出了可用 flags：-h、--help、--doctor、--reload、--debug-clicks。

它把“技能工作区”也单独抽了出来

在 package/ego-browser/README.md 里，runtime 默认会从相邻的 skill 包中加载 agent helpers 和 site learnings，对应路径是：

1
../../skills/ego-browser

如果要覆盖默认路径，可以通过环境变量 EGO_BROWSER_AGENT_WORKSPACE：

1
2
3
EGO_BROWSER_AGENT_WORKSPACE=/path/to/skill ego-browser nodejs <<'EOF'
console.log(await site.skills())
EOF

README 还提到，位于 agentWorkspace()/learnings/<site>/ 下的 site learnings 会始终启用，并且会在每次 helper 调用时读取。验证方式如下：

1
npm run validate:site-skills

这一点其实很能体现 ego-lite 的方向感。它不是只想提供一组静态 API，而是把“站点经验”“技能工作区”“可复用学习内容”一并纳入体系里。这样一来，浏览器自动化的执行过程就不只是临场决策，也可能带着某种逐渐成型的经验层。

从源码结构描述里，也能读出它的重点

package/ego-browser/README.md 给出了 source layout。虽然不需要逐个展开，但单看命名就很能说明问题：

  • run.ts 负责 CLI entry、读取 stdin、注入 helpers、执行
  • helpers.ts 是公开的 Playwright-style facade 和内部 glue
  • browser-runtime.ts 负责桥接 globalThis.ego
  • element-resolver.ts 负责解析 @eN、CSS、XPath、ARIA 目标
  • driver/ 下包含 pointer、observe、keyboard、locator、nav、load、waits、files、downloads
  • http.ts、cdp-eval.ts
  • learning/ 负责 site-learnings discovery 和 manifest validation

这份结构表并没有花哨地包装自己，但恰恰因为足够直接，反而让项目的气质更清晰：它在认真搭建一整套“代理可用的浏览器能力层”。

README 还写了几条 design constraints，其中包括：

  • 浏览器 runtime 负责 tabs、task spaces、CDP transport、snapshots、event delivery
  • 这个 package 只保留 agent-facing ergonomics
  • Snapshot helpers 依赖浏览器 runtime contract
  • 面向代理的公共 helpers 采用 object-style facades
  • site-specific reusable experience 应放在 skills/ego-browser/learnings/ 下，而不是这个 package 里

这几条约束说明，它并不是随意把各种能力堆在一起，而是在非常刻意地划分边界：底层归浏览器 runtime，代理友好性归 helper 层，可复用站点经验归 learning 体系。这样的切分，通常意味着这个项目从一开始就不是“先跑起来再说”，而是有意识地控制职责分布。

连测试夹具都带着很强的“真实场景感”

仓库里还有一份 package/ego-browser/scripts/real-browser-e2e/damai-rush/README.md，标题叫 Concert Ticket Rush Fixture。

这份 README 说明它是现有 real-browser E2E 环境的一部分，并复用了 shared runner 所拥有的 server、random port、task space、lifecycle、assertion reporting 和 cleanup。

更有意思的是，它模拟的内容非常具体：

  • performance 选择
  • price-tier 选择
  • attendee 选择
  • waiting room
  • queueing
  • electronic ticket confirmation
  • idempotent replay
  • 20 个 virtual users 竞争 5 张票

同时 README 也明确写出，它不会接触真实的第三方网络。

运行方式如下：

1
npm run e2e

如果只跑这个 ticket journey：

1
EGO_BROWSER_REAL_E2E_ONLY="concert ticket rush" npm run e2e

这一小段信息很能说明问题：ego-lite 在构造测试场景时，并不是只拿一个静态页面点几下按钮就完事，而是在尝试搭建更接近复杂浏览器任务的流程化环境。排队、竞争、确认、重放，这些词放在一起，就让“浏览器自动化”突然有了更真实的阻力和节奏。

README 还列出了 shared fixture routes，包括页面入口、事件元数据接口、订单预留接口、重置接口，以及 competition 接口。仅从这些信息就能看出，它对 E2E 场景并不是浅尝辄止，而是愿意把复杂行为模拟得更完整。

读完整个仓库信息后，会发现它最打动人的地方不是“能做什么”，而是“怎么安排人与代理的关系”

很多项目介绍浏览器自动化时，会让人第一时间想到脚本、页面操作、元素定位、等待状态、执行结果。这些当然重要，ego-lite 也显然具备这些层面的能力组织。但它真正让人记住的，是另一件事：

它试图让 AI 代理进入浏览器世界时，不必把用户赶出去。

你继续保留自己的标签页、自己的使用节奏、自己的登录状态；代理则进入自己的 Space，拿到属于它的 Snapshot、任务空间和操作能力。浏览器不再只是一个“被谁抢到控制权谁就赢了”的工具，而更像一个可以共存、分工、并行推进的环境。

这也是为什么 ego-lite 的描述里，会反复出现这些词：parallel、Spaces、inherit Chrome data、same browser separate workspace、external agents、stored locally。它们看似分散，实际上都在围绕同一个命题打转——如何让浏览器真正成为 AI 代理可工作的场所，同时又不破坏人类本来的使用体验。

最后看一眼它的整体轮廓

如果只依据 README 和 description 去概括，citrolabs/ego-lite 至少呈现出这样一幅相当完整的画面：

它是一个面向 AI 代理网页自动化的浏览器，当前运行在 macOS；它希望把用户已有的登录状态、Cookie、扩展和书签自然延续给代理；它通过 ego-browser 作为连接层，让不同 agent CLI 都能驱动浏览器能力；它为每个代理提供独立 Space，让多任务并行成为默认能力；它强调高质量 Snapshot、较少 token 消耗和更快任务完成；同时，它还在 helper runtime、技能工作区、site learnings 和 real-browser E2E 夹具上展现出一套相当清晰的工程组织方式。

如果说很多工具只是把浏览器变成“AI 可操作的界面”，那 ego-lite 更像是在尝试把浏览器变成“人和 AI 代理可以各自安稳工作、又彼此协同”的场域。

这件事，听上去不吵不闹，却很有野心。