ego lite：为AI代理打造的专用浏览器，人与Agent并行工作

核心判断：AI代理需要自己的浏览器

AI代理操控浏览器这件事，已经走了三轮弯路。

第一轮，用Selenium/Puppeteer远程驱动Chrome——代理获得了操控能力，但浏览器实例笨重、脆弱，每个标签页都是孤岛。第二轮，Browser-Use、agent-browser这类框架把驱动层包成了SDK——好了一些，但本质上还是在"外部遥控"一个不为代理设计的浏览器。第三轮，ChatGPT Atlas、Perplexity Comet走了另一条路——把AI塞进自带浏览器，但代理被锁死在厂商生态里，无法选择自己的模型和工作流。

ego lite给出了第四种答案：一个从底层就为AI代理设计的浏览器，但同时让人类照常使用。 不是遥控，不是内置，而是共享同一个浏览器实例，各自拥有独立的工作空间。

这个判断的核心洞察是：AI代理和人类使用浏览器的方式根本不同。人类需要一个标签页、一个鼠标、一条注意力线。AI代理需要的是十个并发上下文、稳定的DOM接口、和可编程的操作原语。把两者强行塞进传统浏览器的标签页模型里，必然互相干扰。

系统地图：一个浏览器，多个Space

ego lite的整体架构可以用一句话概括：一个共享的浏览器实例，N个隔离的Space。

┌─────────────────────────────────────────┐
│              ego lite 浏览器              │
│                                         │
│  ┌──────────┐  ┌──────────┐            │
│  │ 人类窗口  │  │ 人类窗口  │  ...       │
│  │ (正常浏览) │  │ (正常浏览) │            │
│  └──────────┘  └──────────┘            │
│                                         │
│  ┌──────────┐  ┌──────────┐            │
│  │ Space 1  │  │ Space 2  │  ... Space N│
│  │Claude Code│  │  Codex   │            │
│  │  并行任务  │  │  竞品爬取  │            │
│  └──────────┘  └──────────┘            │
│                                         │
│  共享层：登录态 / Cookie / 扩展 / 书签    │
└─────────────────────────────────────────┘

人类在浏览器的正常窗口里工作，完全感知不到Space的存在。与此同时，Claude Code可能在10个Space里并行处理邮件归档、文档整理、数据提取等任务，Codex可能在另外5个Space里爬取竞品页面。每个Space拥有独立的页面上下文，但共享底层的浏览器数据——特别是登录态。

这个设计解决了三个传统方案的痛点：

痛点一：登录态继承。 传统方案里，给AI代理一个干净的浏览器意味着要重新登录所有服务。ego lite在首次启动时提供Chrome数据迁移选项，一键继承已登录的cookie、扩展程序和书签。AI代理开箱即获得和你一样的访问权限。

痛点二：并行冲突。 传统方案要么串行执行（慢），要么开多个浏览器实例（重）。Space是轻量级隔离，同一个浏览器进程内可以跑十几个代理任务，互不干扰。

痛点三：人类被打断。 AI代理在浏览器里执行操作时，会抢占鼠标焦点、切换标签页、干扰人类正在做的事。Space完全在后台运行，人类的浏览体验不受影响。

Space机制：隔离的设计

Space是ego lite最核心的抽象概念。理解Space的关键在于它隔离什么、共享什么。

隔离的： 页面上下文（DOM状态、JavaScript执行环境、导航历史）。每个Space是一个独立的浏览上下文，代理在其中导航、点击、填表，不会影响其他Space或人类窗口。

共享的： 浏览器底层数据——登录态、cookie、扩展、书签、密码。这意味着代理在Space里访问你的GitHub、飞书、Notion时，不需要重新认证。

这个设计有一个隐含的安全边界：Space继承了你的全部登录权限，所以ego lite的数据完全存储在本地，不上传任何信息到云端。唯一的远程记录是"用户是否同意Chrome迁移"这一个布尔值。MIT开源许可证意味着整个代码可以审计。

Space的生命周期与AI代理任务绑定。任务完成，Space可以销毁；任务需要长期运行，Space持续存在。代理可以自由创建和销毁Space，不需要人类的干预。

ego-browser技能层：代理的操作系统

如果说Space提供了执行环境，那么ego-browser技能层提供了代理与页面交互的语言。这是ego lite暴露给AI代理的核心API：

这套API的设计哲学是最小且完备。六个函数覆盖了代理在网页上需要做的绝大多数操作：看（snapshot/capture）、输入（fill）、交互（click）、移动（navigate）、同步（wait）。

值得特别关注的是snapshot。ego lite声称其页面快照质量是同类方案中最高的，能够可靠处理深层嵌套的iframe。这对于实际场景至关重要——很多企业应用（如飞书后台、Salesforce、各种SaaS管理台）大量使用iframe，传统方案在提取这些页面的DOM时经常丢失上下文。高质量的snapshot意味着代理收到的页面描述更准确，决策更可靠，token浪费更少。

另一个值得关注的路线图功能是经验积累（coming soon）。核心思路是：当代理成功完成一组操作序列后，这个序列可以被提炼为可复用的工具。类似于人类的"宏录制"，但由代理自主学习和积累。如果这个功能落地，它将使ego lite从一个执行平台进化为一个代理技能的自学习系统。

与现有方案的对比

理解ego lite的定位，最快的方式是看它不替代什么。

浏览器自动化框架（Browser-Use、agent-browser）： 这类工具是库或框架，需要你写代码来驱动一个外部浏览器实例。它们解决的是"怎么操控浏览器"的问题。ego lite解决的是"代理和人类怎么共享浏览器"的问题——它本身就是一个浏览器。两者的关系更接近互补：理论上你可以在ego lite的Space里运行自动化框架的代码，但ego lite自带的技能层已经覆盖了大部分日常需求。

内置AI的浏览器（ChatGPT Atlas、Perplexity Comet）： 这类产品把AI能力内置到浏览器中，用户只能使用厂商提供的AI模型和工作流。ego lite反过来——它不绑定任何AI模型，Claude Code、Codex或任何能调用JavaScript的代理都可以接入。这给了用户选择模型的自由，也意味着代理的能力上限由模型决定，不由浏览器决定。

ego lite的独特之处在于：它既是浏览器（不是一个附加库），又不锁定AI模型（不是封闭生态），同时提供了原生的并行隔离和登录态继承。这个三角定位目前在市场上没有直接竞品。

基准测试解读：2.5倍意味着什么

ego lite官方公布的基准测试显示，它比Vercel的agent-browser快2.5倍，且使用的token更少。

对这类基准测试需要理性看待。2.5倍的速度优势很可能来自几个因素：作为原生浏览器而非远程驱动，减少了IPC开销；Space的轻量级隔离比开多个浏览器实例更高效；高质量的snapshot减少了代理的往返次数。token更少则直接印证了snapshot质量的说法——同样的页面，ego lite生成的结构化描述更精简，代理不需要在一堆噪音中找信号。

但更重要的细节是：任务越复杂，差距越大。 这说明ego lite的优势不是常数级的优化，而是随复杂度放大的。原因不难推测——复杂任务意味着更多页面交互、更深的DOM嵌套、更多的iframe层级，而正是这些场景让传统方案的overhead急剧膨胀。

缺乏第三方独立基准测试是目前的一个限制。官方数据提供了方向性参考，但具体的性能差异需要在实际工作负载中验证。

适用边界与采用建议

适合采用 ego lite 的场景

你的工作流重度依赖网页操作。 如果你每天在多个SaaS平台之间切换——飞书、Notion、GitHub、各种管理后台——ego lite让AI代理代替你完成这些网页上的重复操作，而你继续用自己的浏览器做其他事。

你使用Claude Code、Codex等支持工具调用的AI代理。 ego lite的技能层暴露的是标准JavaScript函数，任何能执行JavaScript的代理都可以接入。如果你的代理已经通过MCP或function calling调用工具，接入ego lite的改造成本很低。

你需要并行处理多个独立任务。 如果你的工作流涉及批量操作——比如同时检查10个竞品的定价页面，或者在多个项目管理工具中同步任务状态——Space的并行模型比串行的浏览器自动化高效得多。

你重视数据隐私。 ego lite的数据完全本地存储，不上传任何浏览数据。相比云端方案，这对隐私敏感的场景更友好。

需要注意的限制

仅支持macOS。 Windows和Linux在路线图中，但目前如果你不在macOS上工作，无法使用。

Space继承你的全部登录权限。 这是一个特性，也是一个风险。AI代理在Space里拥有和你一样的权限——能访问你的GitHub私有仓库、能操作你的银行页面（如果cookie有效）。需要确保你信任正在运行的代理，并理解它将要执行的操作。

经验积累功能尚未落地。 目前snapshot/fill/click等原语是通用的，代理需要每次"重新理解"一个页面的结构。如果经验积累功能上线，代理可以记住"在飞书后台某页面，点击这个按钮可以达到某个效果"，大幅减少重复探索的token开销。

生态尚在早期。 7977个Star说明社区有关注度，但相比Browser-Use等已有一年多积累的方案，ego lite的技能生态、社区插件和最佳实践还在形成中。

安装方式

两种方式，按你的技术背景选择：

• 下载 .dmg 安装包：适合大多数用户，从 lite.ego.app 下载后拖入 Applications 即可
• 通过 npx 安装技能：npx skills add citrolabs/ego-lite，适合已经在使用Claude Code等代理工具的开发者

首次启动时，ego lite会询问是否从Chrome迁移数据（登录态、cookie、扩展、书签）。同意后，AI代理即可立即以你的身份访问已登录的服务。

结论

ego lite识别到了一个被忽略的问题：AI代理和人类需要共享浏览器，但传统浏览器的架构不是为了这种共享而设计的。Space机制、技能层API和Chrome数据继承这三件事组合在一起，创造了一个真正可用的"代理-人类浏览器"范式。

它的价值不在某一个单项指标上——不是最快的浏览器自动化（虽然基准测试声称2.5倍加速），不是最全的代理工具链（虽然六个函数设计精炼），而是它在系统层面解决了一个结构性矛盾：让AI代理获得浏览器的全部能力，同时让人类完全不受干扰。

如果你正在为AI代理寻找一个不抢占你浏览器的执行环境，ego lite是目前最值得尝试的方案。