给 AI Agent 一个专属浏览器：ego-lite 如何把浏览器自动化从遥控机器人变成共享工作台
一个场景
你让 Claude Code 去帮你关注 Twitter 上 10 个账号。传统做法是：agent 启动一个 headless 浏览器，登录你的 Twitter 账号——然后卡住。因为 Twitter 检测到异常登录，要验证码。agent 不知道验证码是什么，你也不在旁边。
或者更糟的情况：agent 登录成功了，开始操作。你这时候打开自己的浏览器想查个资料，发现 Twitter 账号被挤下线了——因为 agent 在另一个 session 里登录了同一个账号。
这是 2025 年所有浏览器自动化框架的共同痛点。browser-use、agent-browser 这些工具本质都是"遥控机器人开浏览器"——agent 在外面操控一个不属于它的浏览器。登录态、cookie、扩展插件，全是两套。
2026 年 8 月，citrolabs 发布了 ego-lite。一个为 AI agent 和人类共享使用而设计的浏览器。单日涨星 153，数字不大，但概念是新的：不是给 agent 一个浏览器，是让 agent 和你共享一个浏览器。
核心创新：Space
ego-lite 的核心概念是 Space（空间）。每个 Space 是一个完全隔离的浏览器工作区。你浏览时用你的 Space，agent 工作时在它自己的 Space。同一个浏览器，不同的工作区。
这意味着：
- 你的标签页不会被 agent 抢走
- agent 的操作不会干扰你的浏览
- 你可以同时开 10 个 Space，让 Claude Code 在 5 个里做数据抓取，Codex 在另外 5 个里做表单填写
- 鼠标始终在你手里
"Code base, not CLI base"
这是 ego-lite 最技术性的创新，也是它比传统方案快 2.5 倍的根因。
传统浏览器自动化是 CLI 模式：agent 调一个命令（比如 click("button")），等浏览器执行，看结果，再调下一个命令。每个命令都是一次往返：agent → 浏览器 → agent → 浏览器。复杂任务需要几十次往返，每次都有网络延迟和 token 消耗。
ego-lite 把浏览器能力暴露成 JavaScript 函数：snapshot、fill、click、wait、navigate、capture。agent 不是调 CLI 命令，而是写一段 JavaScript 代码，把多步操作组合成一个输出，ego-browser 在页面里一次性执行。
// 传统 CLI 模式（伪代码）
result1 = click("login")
result2 = wait_for("#dashboard")
result3 = fill("#search", "keyword")
result4 = click("#submit")
// 4 次往返，4 次 token 消耗
// ego-lite 代码模式（伪代码）
execute(`
click("login");
wait_for("#dashboard");
fill("#search", "keyword");
click("#submit");
`)
// 1 次往返，1 次 token 消耗
这个设计的深层逻辑是：让 agent 做它最擅长的事——写代码。LLM 写代码的能力远强于它逐步调试 CLI 命令的能力。把浏览器操作从"命令序列"升级为"代码片段"，是把任务形态对齐到 agent 的强项。
页面 Snapshot：agent 的"眼睛"
浏览器自动化的另一个瓶颈是页面感知。agent 需要把网页转换成文本模型能理解的格式（snapshot），然后基于 snapshot 决策。snapshot 质量直接决定 agent 的成功率。
ego-lite 在这个点上做了内核级定制。它声称能处理"深度嵌套 iframe"这种其他方案搞不定的情况。iframe 嵌套是网页自动化里的经典难题——一个页面里套三层 iframe，每层都有自己的 DOM 树，传统方案在第二层就迷路了。
内核级定制意味着 ego-lite 不是在浏览器外面套一层 wrapper，而是真的改了浏览器内核来优化 snapshot 生成。这是它和 browser-use 这类"外挂框架"的本质区别——它从浏览器内部重新设计了对 agent 友好的接口。
一个对比表
| 能力 | ego-lite | browser-use | agent-browser (Vercel) | ChatGPT Atlas | Perplexity Comet |
|---|---|---|---|---|---|
| 并行多任务 | ✓ | — | — | — | — |
| 可复用 skills | ✓ | — | — | — | — |
| 继承 Chrome 数据 | ✓ | — | — | ✓ | ✓ |
| 同浏览器独立工作区 | ✓ | — | — | — | — |
| 压缩语义输入 | ✓ | — | ✓ | — | — |
| 外部 agent 可控 | ✓ | ✓ | ✓ | — | — |
| 数据本地存储 | ✓ | ✓ | ✓ | — | — |
| 日常使用浏览器 | ✓ | — | — | ✓ | ✓ |
| 免费 | ✓ | ✓ | ✓ | — | — |
从"工具"到"基础设施"
ego-lite 的定位不是"另一个浏览器自动化框架"，而是"agent 时代的基础设施"。
传统浏览器是给人用的——一个人一个浏览器，标签页是人的工作单元。ego-lite 提出的模型是：一个浏览器，多个 Space，人和 agent 共享。这像操作系统从单用户到多用户的转变——不是给每个人发一台电脑，是让一台电脑支持多个用户。
这个类比的推论是：未来的浏览器可能原生支持 agent。就像手机原生支持多 app 一样。ego-lite 是这个方向的早期产品，它把"agent 是浏览器的一等公民"这个假设变成了可测试的产品。
什么时候该用，什么时候别用
该用：
- 需要登录态的浏览器自动化（Twitter、LinkedIn、内部系统）
- 多 agent 并行任务（同时跑多个 agent 在不同 Space）
- 你需要边用浏览器边让 agent 工作（不能让 agent 独占浏览器）
- 你用 Claude Code、Codex 等外部 agent（不是 ChatGPT 内置的）
- 公开页面抓取（不需要登录态，browser-use 够用）
- 单次简单任务（开个浏览器点两下就完事）
- 你只用 ChatGPT 内置 agent（Atlas 已经集成）
一个更深的观察
ego-lite 的存在说明了一件事：agent 时代的浏览器不是"更快的浏览器"，而是"为两种用户设计的浏览器"。
人类用户需要：视觉反馈、鼠标交互、标签页管理、隐私隔离。 Agent 用户需要：结构化 snapshot、代码可调用、并行工作区、登录态共享。
这两套需求在传统浏览器里是冲突的——agent 需要的 headless 模式和人类需要的 GUI 模式互斥。ego-lite 的解法是 Space——不是"一个浏览器两种模式"，是"一个浏览器多个工作区"，每个工作区可以独立配置。
这和操作系统的进程隔离是同构的。操作系统不让进程互相干扰，靠的是进程地址空间隔离。ego-lite 让 agent 和人类不互相干扰，靠的是 Space 隔离。浏览器正在变成 agent 的操作系统。
当浏览器从"人的工具"变成"人和 agent 的共享平台"，它的架构必须重新设计。ego-lite 是这个重新设计的早期尝试。153 颗星不多，但概念方向可能是对的。
---
项目地址：citrolabs/ego-lite