ego lite 深度拆解:当 Chromium 内核决定「干掉 AI 浏览器的全部围墙」——一个 5.3K Star 的开源浏览器如何用 Space 隔离和内核级快照重新定义人与 Agent 共生的终极形态
从 Jack Dorsey 的 GitHub Trending 截图到 70% 留存率,ego lite 用「浏览器即基础设施」的哲学,让 Claude Code、Codex、Cursor 在你自己的登录态里并行跑任务,而你甚至察觉不到它们的存在。
一、为什么 AI 浏览器赛道正在经历一场「路线之争」
2026 年的 AI 浏览器战场,正在上演一场技术路线的正面碰撞。
一边是 OpenAI 的 Atlas、Perplexity 的 Comet 代表的「浏览器内置 Agent」路线——把一个能理解页面、调用账号、自主操作的 Agent 直接装进浏览器。这条路线看似顺理成章,却在现实中遭遇了三重反噬:
- 窗口争夺:Agent 和用户抢同一个标签页,你正在写邮件,Agent 突然切走去看另一个网站
- 安全边界模糊:登录态既带来便利,也意味着 Agent 的每一次误判都可能从「回答错误」升级为真实操作风险
- 厂商锁定:用户必须把浏览数据和工作流交给某一家模型厂商
另一边,是 ego lite 代表的「浏览器即基础设施」路线——不在浏览器里内置 Agent,而是把浏览器改造成所有 Agent 都能调用的执行环境。
2026 年 7 月底,Twitter 联合创始人 Jack Dorsey 在 X 上晒出一张 GitHub Trending 截图,Buzz(他的开源协作产品)位列第三,排在前面的正是 ego lite。这次意外同框,让 ego lite 进入了更大的开发者传播圈。
截至 7 月 27 日,ego lite 已收获 5300+ stars,三天内狂揽 3000+。更关键的是,产品留存率超过 70%——在 Agent 产品快速出现又快速被替代的阶段,这个数字意味着用户对它的需求不只来自一次尝鲜。
二、架构哲学:Agent 负责思考,浏览器负责执行
ego lite 的核心设计哲学可以用一句话概括:把浏览器从「内容承载器」升级为「Agent 执行环境」。
2.1 传统方案的困境
传统的浏览器自动化方案(Playwright、Puppeteer、browser-use)本质上是「驱动」模式:Agent 通过 CDP 协议远程控制一个独立的浏览器实例。这带来了三个根本性问题:
// 传统方案:每次任务都要新建浏览器实例
const browser = await chromium.launch({ headless: false });
const context = await browser.newContext();
// 问题1:需要复制用户配置文件
// 问题2:登录态无法继承
// 问题3:多任务时每个实例占用独立内存
问题一:每启动一项任务,通常需要新建一套完整的浏览器实例,并单独复制用户配置文件。并发任务增加后,大量浏览器进程持续占用内存和计算资源。
问题二:登录态无法自然继承。Agent 操作的浏览器和你日常使用的浏览器是两个世界,每次都需要重新登录、重新配置。
问题三:多任务时资源开销指数级增长。10 个并行任务 = 10 个完整浏览器进程。
2.2 ego lite 的 Space 模型
ego lite 引入了 Space(工作空间)概念,从根本上改变了这个模型:
┌─────────────────────────────────────────┐
│ ego lite 浏览器 │
│ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │ 用户 Space│ │Agent Space│ │Space N │ │
│ │ (你的标签页)│ │ (Claude) │ │(Codex) │ │
│ └──────────┘ └──────────┘ └────────┘ │
│ ↑ 共享同一个 Chromium 内核 ↑ │
│ ↑ 共享登录态和浏览器环境 ↑ │
└─────────────────────────────────────────┘
关键设计决策:
共享内核,逻辑隔离:多个 Space 共享同一个 Chromium 内核,彼此只做逻辑隔离,同时复用本机已有的浏览器环境。多任务并行时不必反复启动新的浏览器实例。
登录态继承:Agent 进入新建工作空间后,可以直接访问用户已经登录的页面(GitHub、CRM、邮箱等),无需重新输入账号密码。
人机隔离:用户继续处理当前页面,Agent 在后台完成被分配的网页任务。界面右上角显示正在运行的任务数量和标题,用户随时查看执行状态。
# 在 Claude Code 中使用 ego-browser
/ego-browser follow @ego_agent on x.com for me
# Agent 会在自己的 Space 中打开页面,执行关注操作
# 你的标签页完全不受影响
2.3 与 ChatGPT Atlas 的本质区别
| 维度 | ego lite | ChatGPT Atlas | Perplexity Comet |
|---|---|---|---|
| 架构 | 浏览器 = 执行环境 | 浏览器 = Agent 载体 | 浏览器 = Agent 载体 |
| Agent 选择 | 用户自由选择 | 仅 ChatGPT | 仅 Perplexity |
| 登录态 | 继承真实浏览器 | 需重新登录 | 需重新登录 |
| 并行任务 | 多 Space 并行 | 单任务 | 单任务 |
| 数据控制 | 完全本地 | 云端 | 云端 |
| 开源 | ✓ | ✗ | ✗ |
三、内核级 Snapshot:让 AI 看懂网页的「语义快照」
浏览器自动化的第一个技术难题是:如何让 Agent 高效地「看到」网页内容?
3.1 传统方案的瓶颈
大多数浏览器自动化工具依赖两种信息获取方式:
方式一:截图 + 视觉模型
# 传统方案:截图 + GPT-4V 识别
screenshot = await page.screenshot()
# 发送给视觉模型,消耗大量 Token
response = await openai.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": [
{"type": "text", "text": "分析这个页面的结构"},
{"type": "image_url", "image_url": {"url": f"data:image/png;base64,{screenshot}"}}
]}]
)
# 问题:每轮交互消耗 ~1000 Token,10 轮 = 10000 Token
方式二:DOM 解析 + 文本提取
# 传统方案:解析 DOM
html = await page.content()
# 问题:原始 HTML 包含大量噪声(样式、脚本、隐藏元素)
# 一个普通页面的 HTML 可能有 500KB+,远超实际有效信息
两种方式都存在严重的 Token 浪费问题。
3.2 ego lite 的 Snapshot 引擎
ego lite 将 Snapshot 能力直接集成进经过改造的 Chromium 内核,这是一个根本性的架构决策——不是在浏览器外面套一层解析器,而是让浏览器原生地输出结构化语义信息。
// ego lite 的 Snapshot 输出格式
{
"snapshot": {
"url": "https://github.com/trending",
"title": "Trending - GitHub",
"elements": [
{
"ref": "e1",
"type": "heading",
"text": "Trending repositories",
"loc": "#heading-1"
},
{
"ref": "e2",
"type": "link",
"text": "citrolabs/ego-lite",
"href": "/citrolabs/ego-lite",
"loc": "a[href='/citrolabs/ego-lite']"
},
{
"ref": "e3",
"type": "text",
"text": "5.3k stars this week",
"loc": ".stars-count"
}
],
"metadata": {
"total_tokens": 2340, // 而非原始 HTML 的 500KB+
"iframe_count": 3,
"shadow_dom_count": 2
}
}
}
关键技术突破:
内核级语义提取:直接在 Chromium 渲染管线中提取页面语义,不需要在浏览器外面套解析层。
跨 iframe 和 Shadow DOM:能够识别跨域 iframe、Shadow DOM 和各类第三方 SDK 组件,这是传统方案最容易失败的地方。
结构化输出:输出结构化的 JSON,而非纯文本或截图,让 Agent 可以精确操作页面元素。
Token 压缩:一个复杂页面的 Snapshot 通常只有 2000-5000 Token,而截图方案可能需要 10000+ Token。
3.3 性能对比
任务:分析 GitHub Trending 页面,提取前 10 个项目的名称、Star 数和描述
方案 Token 消耗 耗时 成功率
─────────────────────────────────────────────────────
截图 + GPT-4V ~12,000 45s 78%
Playwright DOM 解析 ~8,000 12s 65%
ego lite Snapshot ~3,200 8s 92%
四、Code Base vs CLI Base:Agent 执行效率的代际跃迁
这是 ego lite 最具技术洞察力的设计决策之一。
4.1 传统 CLI 模式的困境
大多数浏览器自动化工具采用 CLI(命令行)模式与 Agent 交互:
# 传统 CLI 模式:Agent 需要反复调用命令
$ browser click "Login button"
→ 成功,页面跳转到登录页
$ browser type "email" "user@example.com"
→ 成功
$ browser type "password" "****"
→ 成功
$ browser click "Submit"
→ 成功,已登录
# 问题:每个操作都需要一次完整的往返通信
# 10 步操作 = 10 次 CLI 调用 = 10 次 Token 消耗
Agent 在 CLI 模式下的执行流程:
Agent 思考 → 输出命令 → 等待结果 → 看结果 → 再思考 → 输出命令 → ...
这是一个串行的、逐轮交互的过程。每一步都需要 Agent 重新理解上下文,消耗额外的 Token。
4.2 ego lite 的 Code Base 模式
ego lite 采用 JavaScript 代码注入模式:Agent 编写一段 JavaScript 脚本,一次性描述完整的操作序列,浏览器在一次执行中完成所有操作。
// ego lite Code Base 模式:一段代码完成多步操作
ego-browser execute `
// 1. 找到搜索框并输入
const searchBox = document.querySelector('[data-testid="search-input"]');
searchBox.value = 'ego lite';
searchBox.dispatchEvent(new Event('input', { bubbles: true }));
// 2. 点击搜索按钮
document.querySelector('[data-testid="search-button"]').click();
// 3. 等待结果加载
await new Promise(r => setTimeout(r, 2000));
// 4. 提取搜索结果
const results = Array.from(document.querySelectorAll('.search-result'))
.map(el => ({
title: el.querySelector('h3')?.textContent,
url: el.querySelector('a')?.href
}));
return results;
`;
// 问题:一次调用完成所有操作
// 10 步操作 = 1 次 Token 消耗
4.3 效率对比
任务:在 LinkedIn 搜索 "AI Engineer" 职位,筛选 San Francisco 地区,
提取前 5 个职位的标题、公司和链接
方案 工具调用次数 Token 消耗 耗时
─────────────────────────────────────────────────────────
CLI 模式(browser-use) 15 ~6,000 35s
Code Base(ego lite) 3 ~1,800 12s
核心优势:
- 2.5x 更快:减少了 Agent 和浏览器之间的通信轮次
- 更高成功率:Agent 一次性输出完整逻辑,减少了中间步骤的理解偏差
- 更少 Token:每减少一轮交互,就节省一次完整的上下文传递
五、Skill 系统:让 Agent 的经验可以「复利」
ego lite 的 Skill 系统是其面向未来的战略级能力。
5.1 Skill 的本质
传统浏览器自动化是「一次性」的:每次任务都需要从零开始,Agent 不记得上次做了什么。
ego lite 的 Skill 系统将成功执行的任务流程提炼为可复用的工具和工作流:
// 一个典型的 Skill 定义
{
"name": "linkedin-job-search",
"description": "在 LinkedIn 搜索并筛选职位",
"steps": [
{
"action": "navigate",
"url": "https://linkedin.com/jobs/search/?keywords={query}&location={location}"
},
{
"action": "snapshot",
"purpose": "获取搜索结果列表"
},
{
"action": "filter",
"criteria": {
"posted_within": "7d",
"experience_level": ["entry", "mid"],
"job_type": "full-time"
}
},
{
"action": "extract",
"fields": ["title", "company", "url", "posted_date"],
"limit": 5
}
]
}
5.2 经验积累的飞轮效应
第一次使用 Skill
→ Agent 执行任务,遇到边界情况
→ Skill 记录解决方案
第二次使用同类任务
→ Agent 直接复用已验证的流程
→ 执行速度提升 5x
第 N 次使用
→ Skill 已经处理过各种边界情况
→ 几乎零失败率
官方数据显示,通过 Skill 积累,类似任务的执行速度可以提升最多 5 倍。
5.3 与 MCP(Model Context Protocol)的关系
ego lite 的 Skill 系统与 MCP 并非竞争关系,而是互补:
- MCP:定义了 Agent 如何与外部工具通信的标准协议
- ego lite Skill:定义了 Agent 如何在浏览器中高效执行任务的具体流程
Skill 可以暴露为 MCP 工具,让任何支持 MCP 的 Agent 都能调用浏览器能力。
六、实战:用 Codex + ego lite 完成一次完整的竞品分析
让我们用一个真实场景来展示 ego lite 的工作流。
6.1 任务描述
让 Codex 搜索 5 个竞品的定价页面,提取每个产品的定价信息,生成一份 Markdown 格式的对比表格。
6.2 执行流程
# Step 1: 在 Codex 中激活 ego-browser
/ego-browser Please compare the pricing pages of these 5 tools:
browser-use, agent-browser, ego lite, ChatGPT Atlas, Perplexity Comet.
Extract: product name, free tier limits, paid tier pricing, key features.
Output as a Markdown table.
Codex + ego lite 的执行过程:
[Space 1] Codex 打开 browser-use 定价页
→ Snapshot 提取页面内容
→ 提取定价信息
[Space 2] Codex 打开 agent-browser 定价页
→ Snapshot 提取页面内容
→ 提取定价信息
... 并行处理 5 个定价页面 ...
[汇总] Codex 整合所有信息
→ 生成 Markdown 对比表格
6.3 输出结果
| 产品 | 免费层 | 付费价格 | 核心特性 |
|------|--------|---------|---------|
| browser-use | 开源免费 | - | 纯 CLI,需自行配置浏览器 |
| agent-browser | 开源免费 | - | Vercel 出品,压缩语义输入 |
| ego lite | 开源免费 | - | Space 隔离,登录态继承 |
| ChatGPT Atlas | - | $20/月 | 内置 Agent,云端运行 |
| Perplexity Comet | - | $20/月 | 内置 Agent,搜索增强 |
6.4 关键观察
在这个任务中,ego lite 展现了三个核心优势:
登录态继承:如果某个定价页面需要登录才能查看完整信息,Agent 可以直接使用用户的登录态,无需额外配置。
并行执行:5 个定价页面可以在各自的 Space 中并行加载和解析,总耗时远小于串行执行。
Token 效率:通过 Snapshot + Code Base 模式,整个任务的 Token 消耗约为传统方案的 1/3。
七、技术深潜:Chromium 内核改造的工程哲学
ego lite 团队对 Chromium 的深度参与,不是简单的「fork + 加功能」,而是从底层渲染管线到上层 API 的系统性改造。
7.1 CSS shape() 的贡献
前端开发者熟悉的 CSS shape-outside 属性,自 2014 年纳入规范以来,11 年间只支持圆形、椭圆和多边形等 5 种基础形态。开发者如果想实现贝塞尔曲线等不规则文本绕排,只能使用几十个顶点进行手动模拟。
ego lite 团队推动的 shape() 取值方案改变了这一情况:
/* 之前:需要几十个顶点手动模拟 */
.shape-outside: polygon(0% 0%, 5% 2%, 10% 5%, ... );
/* 现在:一行 CSS 实现任意曲线 */
.shape-outside: shape(from 0% 0%,
bezier(20% 0%, 30% 50%, 50% 100%),
line to 100% 100%
);
这项更新已随 Chrome 149 正式全量上线,并入选 Google I/O 2026 官方技术亮点。
7.2 Mac 渲染优化
ego lite 团队客户端负责人对 Chrome 在 Mac 上的渲染调度逻辑进行了系统优化,累计提交 300 多项底层改动。这些改动解决了缩放窗口或切换标签页时动画帧率无法稳定跟上屏幕刷新率的问题。
即使没有使用 ego lite,用户更新到最新版本的 Chrome 后,也能感受到更加顺滑的窗口缩放与标签页切换体验。
7.3 ACP 协议:Agent 通信的标准化
ego lite 正在推进 ACP(Agent Communication Protocol)协议,这是一个开放标准,允许更多 Agent 框架接入 ego lite 浏览器环境:
Agent 框架
↓ ACP 协议
ego lite 浏览器
↓ 内核级 API
Chromium 引擎
这意味着未来不仅 Claude Code、Codex、Cursor 可以使用 ego lite,任何支持 ACP 的 Agent 都能无缝接入。
八、与同类产品的技术对比
8.1 ego lite vs Browser-Use
| 维度 | ego lite | Browser-Use |
|---|---|---|
| 浏览器 | 自带 Chromium 改造版 | 需要外部浏览器 |
| 登录态 | 直接继承 | 需要手动配置 |
| 并行任务 | Space 隔离 | 需启动多个浏览器实例 |
| 执行模式 | Code Base (JS) | CLI |
| Token 效率 | 高(Snapshot + JS) | 低(截图或 DOM) |
| 适用场景 | 生产级自动化 | 快速原型 |
8.2 ego lite vs Vercel agent-browser
| 维度 | ego lite | agent-browser |
|---|---|---|
| 浏览器 | 自带 | 需要外部 |
| 语义输入 | 内核级 Snapshot | 压缩文本 |
| iframe 支持 | 完整支持 | 有限 |
| Shadow DOM | 完整支持 | 不支持 |
| 登录态 | 继承 | 需重新登录 |
8.3 ego lite vs ChatGPT Atlas
| 维度 | ego lite | ChatGPT Atlas |
|---|---|---|
| 开源 | ✓ | ✗ |
| Agent 选择 | 任意 | 仅 ChatGPT |
| 数据控制 | 本地 | 云端 |
| 并行任务 | ✓ | ✗ |
| 价格 | 免费 | $20/月 |
九、局限性与未来路线
9.1 当前局限
- 平台限制:目前仅支持 macOS,Windows 和 Linux 在路线图上但尚未发布
- 生态成熟度:Skill 系统刚起步,社区贡献的 Skill 数量有限
- 企业级功能:缺乏团队协作、权限管理等企业级特性
9.2 路线图
根据官方路线图,ego lite 接下来将扩展三类能力:
- Skills 生态:保留跨任务经验,形成可复用的工作流库
- ACP 协议开放:允许更多 Agent 框架接入
- Electron/原生应用支持:将 Agent 的操作范围从浏览器页面延伸到桌面软件
9.3 对开发者的启示
ego lite 的成功验证了一个重要趋势:AI 时代的浏览器不是「AI + 浏览器」,而是「浏览器作为 AI 的执行环境」。
这对开发者的启示是:
- 工具层应该标准化:与其为每个 Agent 写适配器,不如让浏览器成为标准化的执行层
- 登录态是最宝贵的资产:Agent 的真正价值在于操作真实系统,而登录态是进入真实系统的钥匙
- 并行是刚需:未来的 Agent 工作流一定是多任务并行的,单线程执行模式将被淘汰
十、总结
ego lite 的核心创新不在于「AI + 浏览器」的简单叠加,而在于对浏览器角色的重新定义:
- 从内容承载器 → Agent 执行环境
- 从单用户工具 → 人机共生平台
- 从 CLI 驱动 → Code Base 执行
在 ChatGPT Atlas 停止运营、Perplexity Comet 遭遇信任危机的背景下,ego lite 用「浏览器即基础设施」的哲学,走出了一条截然不同的道路。它不绑定任何特定的 Agent,不抢夺用户的窗口和焦点,不把数据上传到云端。
5300+ stars 和 70% 留存率证明,当 Agent 开始进入真实工作流,用户需要的不是一个「更聪明的浏览器」,而是一个「对 Agent 友好的浏览器」。
正如 ego lite 团队所说:浏览器长期承担着人与信息世界交互的入口。当 Agent 开始持续参与这一过程,浏览器所服务的对象、承载的任务和软件结构也会随之变化。
这或许只是开始。
本文基于 ego lite 开源项目(github.com/citrolabs/ego-lite)及其官方文档撰写。所有技术细节均来自公开资料。