很好信息已经足够完整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 进程内存消耗约 15GBego-lite 的 Space 是同一进程内的分区6 个并发任务只新增约 0.9GB节省约 94%。这个优势来自 Chromium 本身的多 Profile 架构ego-lite 做的是内核级定制让 Space 之间共享渲染进程但隔离 cookie/storage。这比再开一个浏览器聪明得多但前提是你愿意把它当成日常浏览器用——你不换浏览器Space 就没有意义。2. Snapshot用 Accessibility Tree 替代 HTMLToken 压缩 99%页面完整 HTML 通常 30,000 tokenego-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 heredocego-browser在浏览器里一次性执行完只返回最终结果。这是速度快 2.5× 的真实来源——不是什么魔法就是减少了 LLM 和工具之间的 round-trip 次数。对比 browser-use 的一步看一步模式ego-lite 让 Agent 做它最擅长的事一次性把流程代码写出来。放进历史脉络里看它站在哪里工具类型代表产品核心问题传统自动化框架Playwright / Puppeteer不懂 LLM需要人写硬编码脚本LLM 外挂浏览器browser-use / agent-browser登录态孤立、高内存、来回轮询慢AI 内置浏览器ChatGPT Atlas / Perplexity CometAgent 锁死用户无法带自己的 LLMego-liteego-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
