ego-lite：一个试图终结"AI 抢你标签页"问题的 Chromium 浏览器

“

寄生 vs 共生 ——现有的 AI 浏览器自动化工具都在寄生，而 ego-lite 试图把人和 Agent 的工作空间整合进同一个 Chromium 内核。

文章来源：GitHub — citrolabs/ego-lite README　|　交叉信源：掘金技术文章（ego lite 深度解析）、掘金 browser-use 实测评测

01、CORE IDEA

核心观点

ego-lite 的出发点很清晰：现有的 AI 浏览器自动化工具都在寄生，而不是共生。Browser-use、Playwright 等框架本质上是“拿着遥控器驱动一个独立浏览器”——登录态要手动迁移、Agent 和人共用同一个浏览器实例互相干扰、每步操作都要来回问 LLM。ego-lite 的定位不是框架，而是把人和 Agent 的工作空间真正整合进同一个 Chromium 内核。

这不是范式级突破，但也不是普通的渐进优化。它处于“将既有技术组合重新封装”的阶段——核心机制（Accessibility Tree 快照、进程内 Space 隔离、heredoc 脚本一次性执行）都不是全新发明，但把它们打包进一个日常浏览器这个思路确实填补了一个明显的空缺。

02、MECHANISM

最关键的机制：三层设计缺一不可

1. Space：进程内隔离，而非另起炉灶

传统方案启动 6 个并发浏览器任务 = 6 个 Chromium 进程，内存消耗约 15GB；ego-lite 的 Space 是同一进程内的分区，6 个并发任务只新增约 0.9GB（节省约 94%）。

这个优势来自 Chromium 本身的多 Profile 架构，ego-lite 做的是内核级定制让 Space 之间共享渲染进程但隔离 cookie/storage。这比“再开一个浏览器”聪明得多，但前提是你愿意把它当成日常浏览器用——你不换浏览器，Space 就没有意义。

2. Snapshot：用 Accessibility Tree 替代 HTML，Token 压缩 99%

页面完整 HTML 通常 30,000+ token，ego-lite 的 Snapshot 基于无障碍树（Accessibility Tree）输出 200–400 token 的结构化视图，并为每个可操作元素分配 @N 编号，Agent 直接调用 click(@5) 而不是靠 CSS 选择器猜 DOM 路径。

这个机制的关键优势在于对 iframe 和 shadow DOM 的处理——原文特别提到这是竞争对手“consistently break down”的地方。交叉信源（掘金技术分析）也确认了这一点：基于 Accessibility Tree 的方案天然穿透 iframe，而基于 HTML 字符串的方案在嵌套结构里极其脆弱。

3. Code-base 而非 CLI-base：用 heredoc 脚本消灭来回轮询

传统 CLI 模式：LLM 发一条命令 → 等返回 → 再发一条 → 等返回，复杂任务需要 N 轮往返。ego-lite 模式：Agent 把整个流程写成一段 JavaScript heredoc，ego-browser 在浏览器里一次性执行完，只返回最终结果。

这是速度快 2.5× 的真实来源——不是什么魔法，就是减少了 LLM 和工具之间的 round-trip 次数。对比 browser-use 的“一步看一步”模式，ego-lite 让 Agent 做它最擅长的事：一次性把流程代码写出来。

03、HISTORY

放进历史脉络里看：它站在哪里？

browser-use 的 97% 成功率是用官方优化模型跑出的，用通用 GPT-4o 实际只有 60–70%（来源：掘金 browser-use 实测）。这说明“框架好不好”的前提是“模型够不够强”——ego-lite 的 heredoc 模式理论上对模型质量要求更高，但每次任务的 token 消耗更低，经济账上可能反而划算。

04、CROSS-CHECK

交叉验证

信源一：掘金《ego lite：让 AI Agent 操作浏览器快 3 倍的秘密》

该文章独立测试并给出了更详细的性能数字：启动速度快 4 倍（2.5s→0.6s），完成时间快 3.45 倍，内存节省 94%。数据方向与原文（2.5×）吻合，且更具体。该文章认同原文的核心架构判断，并补充了 Space 是“进程内分区而非新窗口/新 Profile”这一关键实现细节，原文 README 对此语焉不详。

信源二：掘金《2026 年最火的 AI 浏览器自动化开源项目实测》（browser-use 实测）

该文章对 browser-use 的评价揭示了一个重要的反面对照：browser-use 在复杂多步任务的真实成功率只有 60%，且遇到 Cloudflare/强反爬时几乎无解。这间接支持了 ego-lite 的“对手不成熟”的论断。但该文章也指出：browser-use 的瓶颈不在框架本身，而在页面 JS 渲染和反爬机制——ego-lite 继承 Chrome 登录态可以绕过一部分反爬（因为 Cookie 和 Session 是真实的），这是原文没有显式强调但确实存在的优势。

两个信源总体认同原文核心观点，无明显反驳，但也没有来自中立第三方的基准测试复现。

05、LIMITATIONS

边界与局限：不能无条件唱赞歌

06、INSIGHTS

个人启发

07、PROJECTION

推演：接下来会怎样

ego-lite 的架构方向是对的，但它现在面临的最大问题不是技术，而是用户迁移成本。Chrome 用户换浏览器是极高摩擦的决策，哪怕产品再好。它更可能的成功路径是：先成为“开发者机器上的第二浏览器专门用于 Agent 任务“，而不是真正的日常主浏览器。

如果“经验积累”功能真的落地，ego-lite 会形成数据飞轮：越用越快 → 开发者更愿意用 → 积累更多成功路径 → 进一步降低 token 成本。这个护城河比纯技术参数更值得关注。

08、THOUGHTS

延伸思

END