ego-lite：一个试图终结“AI 抢你标签页“问题的 Chromium 浏览器
很好，信息已经足够完整，
ego-lite：一个试图终结"AI 抢你标签页"问题的 Chromium 浏览器
文章来源：GitHub — citrolabs/ego-lite README
交叉信源：掘金技术文章（ego lite 深度解析）、掘金 browser-use 实测评测
核心观点
ego-lite 的出发点很清晰：现有的 AI 浏览器自动化工具都在寄生，而不是共生。Browser-use、Playwright 等框架本质上是"拿着遥控器驱动一个独立浏览器"——登录态要手动迁移、Agent 和人共用同一个浏览器实例互相干扰、每步操作都要来回问 LLM。ego-lite 的定位不是框架，而是把人和 Agent 的工作空间真正整合进同一个 Chromium 内核。
这不是范式级突破，但也不是普通的渐进优化。它处于"将既有技术组合重新封装"的阶段——核心机制（Accessibility Tree 快照、进程内 Space 隔离、heredoc 脚本一次性执行）都不是全新发明，但把它们打包进一个日常浏览器这个思路确实填补了一个明显的空缺。
最关键的机制：三层设计缺一不可
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 做它最擅长的事：一次性把流程代码写出来。
放进历史脉络里看：它站在哪里？
| 工具类型 | 代表产品 | 核心问题 |
|---|---|---|
| 传统自动化框架 | Playwright / Puppeteer | 不懂 LLM，需要人写硬编码脚本 |
| LLM + 外挂浏览器 | browser-use / agent-browser | 登录态孤立、高内存、来回轮询慢 |
| AI 内置浏览器 | ChatGPT Atlas / Perplexity Comet | Agent 锁死，用户无法带自己的 LLM |
| ego-lite | ego-lite | 同一浏览器，用户+任意 Agent 共存 |
browser-use 的 97% 成功率是用官方优化模型跑出的，用通用 GPT-4o 实际只有 60–70%（来源：掘金 browser-use 实测）。这说明"框架好不好"的前提是"模型够不够强"——ego-lite 的 heredoc 模式理论上对模型质量要求更高，但每次任务的 token 消耗更低，经济账上可能反而划算。
交叉验证
信源一：掘金《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 是真实的），这是原文没有显式强调但确实存在的优势。
两个信源总体认同原文核心观点，无明显反驳，但也没有来自中立第三方的基准测试复现。
边界与局限：不能无条件唱赞歌
仅支持 macOS。Windows/Linux 在路线图上但没有时间表，这对大多数服务器端、CI 场景直接排除在外。
基准测试是自己做的。README 里"快 2.5×"的数据是 ego-lite 对比 Vercel agent-browser 的内部测试，没有中立第三方复现。这不代表数据造假，但读者应保持保留态度。
需要把它当主力浏览器。Space 机制的前提是你实际在用 ego-lite 浏览网页，否则登录态继承和 Space 隔离都没有意义。这是用户迁移成本——"再下载一个浏览器"和"换掉 Chrome 作为日常浏览器"是两件完全不同量级的事。
"经验积累让 Agent 越来越快"功能标注为 coming soon，目前不可用。这是最有差异化想象空间的特性，但现在只是一个承诺。
heredoc 脚本模式对 LLM 代码能力要求更高。如果 Agent 一次写错了整个脚本，整个任务失败而不是停在某一步等待修正。这是"一次执行完"的反面——容错性比 CLI 模式低。
个人启发
对 Agent 开发者：如果你正在用 Claude Code / Cursor 做需要浏览器操作的工作流，ego-lite 值得立刻试用，理由不是性能数字，而是"不用再管登录态"这个实际工程痛点——在 browser-use 里每次都要重新注入 cookie 是真实的摩擦成本。
对工具选型决策者：ego-lite 和 browser-use 不是替代关系。browser-use 是 Python 生态的库，适合嵌入 Agent 服务端流水线；ego-lite 是桌面应用，适合开发者本地工作流的增强。混用是合理的。
对普通用户：现在还不是时候。功能还在密集迭代，macOS 限制明显，且"让 AI 拿着你的真实 Cookie 在浏览器里操作"这件事需要对工具有一定信任基础。观望到 Windows 版本发布是务实的选择。
推演：接下来会怎样
ego-lite 的架构方向是对的，但它现在面临的最大问题不是技术，而是用户迁移成本。Chrome 用户换浏览器是极高摩擦的决策，哪怕产品再好。它更可能的成功路径是：先成为"开发者机器上的第二浏览器专门用于 Agent 任务"，而不是真正的日常主浏览器。
如果"经验积累"功能真的落地，ego-lite 会形成数据飞轮：越用越快 → 开发者更愿意用 → 积累更多成功路径 → 进一步降低 token 成本。这个护城河比纯技术参数更值得关注。
延伸思考
heredoc 一次性执行 vs 步步确认：Agent 执行浏览器任务时，"一次写完脚本执行"和"逐步执行允许人工介入"哪种模式在真实工作流里更安全？ego-lite 选了前者以换速度，但对于涉及支付、删除等不可逆操作的场景，这个取舍是否合理？
Accessibility Tree 的天花板：Snapshot 依赖无障碍树，但大量商业 SaaS 产品（如 Salesforce、内部 CRM）的 a11y 实现质量极差，无障碍树几乎是空的。ego-lite 宣传的"强 Snapshot"在这类场景是否还能成立？
"继承你的真实 Cookie"是双刃剑：登录态继承是最大卖点，但这也意味着 Agent 可以以你的身份在任何你已登录的网站上执行操作。在 Agent 被 prompt injection 攻击的场景下（恶意网页操控 Agent 行为），这个权限边界应该如何设计？
📚 参考来源
- GitHub - citrolabs/ego-lite: The best browser for both you and your AI agents work in parallel. · GitHub