ego-lite
citrolabs/ego-lite加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一个周一早晨。你正在浏览器里回客户邮件、查订单号、盯着一个后台报表。与此同时，你让 Claude Code 去把上周散落在 15 个竞品网站上的价格整理成一张表。
传统做法会卡在两个地方：第一，自动化脚本启动的是一个全新的浏览器实例，你的登录态、Cookie、两步验证全都得重来一遍；第二，等脚本一跑起来，它就接管了你的鼠标和焦点，你不得不在另一个窗口里干活。
ego lite（仓库 citrolabs/ego-lite）就是冲着这两个痛点来的。它的做法有点反直觉：不再给你一个「给 AI 用的浏览器」，而是把你每天用的这个浏览器，改造成你和 AI Agent 能同时住的房子。
截至目前，这个项目在 GitHub 上已收获 18,603 星、1,021 次 fork，采用 MIT 协议，主语言是 JavaScript/TypeScript。它不是一篇论文，也不是一个演示 Demo，而是一个已经能下载安装、每天在用的桌面应用 + 一套开源的 Agent 接入层。
这一点必须先说清楚，否则后面所有理解都会错位。
ego lite 浏览器本体是闭源免费下载的，是一个基于 Chromium 内核、深度定制过的桌面应用。仓库里开源的是另一部分：ego-browser，一个用 TypeScript 写的 Node.js CDP（Chrome DevTools Protocol）自动化 harness，加上配套的 Agent Skill 包。
项目作者在 AGENTS.md 里写得很直白："This repo contains the open-source harness and the agent skill package — not the browser itself."
这个开源/闭源的切分，直接决定了两件事：
如果把整个项目类比成一套工具链：闭源的浏览器就像一支重新设计的「笔」，开源的 ego-browser harness 则是让 AI 学会如何把这支笔用起来的「握笔姿势教学」。
这是整个项目最核心的设计。
Space 是 ego lite 在同一个浏览器进程内部划出的隔离工作区，语义上接近 Chromium 的独立 BrowserContext：每个 Space 有自己独立的页面、Cookie 和 Storage，但共享底层浏览器基础设施。
它不是「另开一个浏览器」，不是「云端浏览器会话」，也不是「一套新的 Chrome 用户资料」——这几种常见误解在社区文章里被反复澄清过。
Space 还带一个「所有权模型」（agent / user）。你可以随时查看哪个 Space 里有 Agent 在跑，也可以接管（take over）或直接停掉它。官方给的典型场景是：Claude Code 在 10 个平行 Space 里同时 enrich 10 条销售线索，Codex 在另外 5 个 Space 里爬 5 个竞品站点，而你的鼠标还在原来那个标签页上。
纯文本模型没有眼睛，所谓的「看见网页」，靠的就是把 DOM 序列化成一棵结构化的、带元素引用的文本树。
ego lite 官方把这个能力称为「市场上最强的页面 Snapshot」，底气来自它在浏览器引擎内部做了定制，而不是外挂一层解析。据称它能稳定处理深层嵌套的跨域 iframe、Shadow DOM 这类别的方案经常翻车的地方。
v2 版本引入了 Page ref 机制，元素引用从 v1 的 @e21 变成了 @21 这类由 SDK 分配的 ID，绑定到具体的 frame/document/backend node，跨轮次保持有效；导航或 DOM 变化后需要重新 snapshot。
这是我认为最值得学的一点。
传统浏览器自动化暴露给 Agent 的是一串命令：navigate、click、fill、snapshot。Agent 的执行模式于是变成「发一条命令 → 看结果 → 再发一条 → 再看结果」，多步任务里这种往返会疯狂吃掉 token 和时间。
ego lite 换了个思路：把浏览器能力包装成页内 JavaScript 函数，Agent 直接写一段代码，一次性把多步流程组合好，在页面里一次跑完。README 里给出的对比很直接：复杂工作流完成得更快、成功率更高、工具调用次数大幅减少、单任务成本显著下降。
src/learning/ 这一层做的事情很有意思：从 skills/ego-browser/learnings/<site>/manifest.json 发现站点专属的技能包，经过校验后由 Agent 直接调用。
项目的出发点很务实——Agent 的大部分时间其实花在试错上。每成功一次，就把它沉淀成一个可复用的工具或流程，下次类似任务能快得多（官方宣称最高可到 5 倍）。而且它对站点技能有硬性约束：稳定 URL、耐用的选择器、禁止使用像素坐标、禁止包含密钥。
安装路径有三条，难度递增：
npx skills add citrolabs/ego-lite，只装 ego-browser skill，之后 Agent 首次跑浏览器任务时会引导你装应用。skills/ego-browser/references/install.md 交给你的 Agent 照做。真正使用时的交互形态是 CLI：在 Agent 终端里输入 /ego-browser，然后用自然语言描述任务，例如 ego-browser follow @ego_agent on x.com for me。
对开发者来说，本地开发路径是 npm ci && npm run build，产物在 package/ego-browser/dist/out/index.js，然后通过 ego-browser nodejs --sdk-path <绝对路径> 挂到已安装的 Ego Lite CLI 上跑。注意这里有个硬约束：必须安装 Ego Lite 应用本体，纯仓库代码无法独立驱动真实浏览器。
从 Web UI 的角度看，ego lite 应用本身就是一个浏览器界面，能看到各个 Space 的运行状态、实时预览并手动接管。也就是说，它的「Web UI」不是传统的服务端后台管理台，而是一个真实的桌面浏览器。
翻遍 package/ego-browser/src/，情况如下：
| 维度 | 数据 |
|---|---|
| 源码文件数 | 82 个（TypeScript / .mjs） |
| 测试文件数 | 36 个 .test.mjs，与代码同目录放置 |
| 源码体量 | 约 1.2 MB |
| 唯一运行时依赖 | acorn（其余全是 devDependencies） |
| 引擎要求 | Node.js >= 22，ESM only |
CI 配置（.github/workflows/ci.yml）链路完整：checkout → setup-node 22（带 npm 缓存）→ npm ci → prettier 风格检查 → npm audit --audit-level=moderate → npm test（构建 + 技能翻译一致性检查 + tsc 类型检查 + node --test）→ plugin 风格检查 → plugin 单测 → 站点技能校验 → tag 触发时打包 release payload 并发布。
几个能看出作者水平的设计细节：
public-api-schema.ts 是 v2 API 的唯一真相来源，新增 API 要同步 runtime 校验、help() 输出、架构文档和 skill-body/SKILL.md 四处；help() 在运行时用 acorn 解析打包产物里的 JSDoc，也就是说导出函数上的 JSDoc 注释就是面向用户的正式文档；transient（可重试）或 permanent（永久失败），等待循环依赖这个分类；loc= 定位符；FakeEgo 替身和 __testing.setOverrides 注入，而不是去 mock 整个 CDP；npm run e2e 的真实浏览器端到端套件，自带本地 fixture server、创建唯一命名的临时 Task Space 并自动清理。
不回避问题，这个项目有几个相当硬的限制：
1. 浏览器本体闭源。 你无法审计浏览器做了什么，也无法自建。开源的只有 harness 层。闭源部分还意味着「零配置」实际上是有前置条件的：必须下载安装、必须完成引导、必须允许 Agent 启动沙箱外应用。
2. Linux 完全不可用。 对以 Linux 为主力环境的团队（包括大量 CI 场景）来说，这基本等于不可用。而且它无法容器化，也就无法进 CI 流水线。
3. 天然的安全风险面。 它的核心卖点是「Agent 继承你的真实登录态」——这既是最大价值，也是最大风险。社区实践指南里给出的建议是：只在确实需要启动本机浏览器时开启 Full access；涉及支付、发布、删除、转账的操作要求 Agent 暂停；测试任务用低风险账号；任务结束后检查 Space 里访问过的网页。
4. 平台独占带来的生态限制。 它是「给外部 Agent 用的浏览器」（Claude Code、Codex、Cursor、Hermes 等），而不是自带固定 Agent 的 AI 浏览器（ChatGPT 内置浏览器、Atlas、Comet 那类）。这既是它的差异化优势，也意味着它不能替代后者的开箱即用体验。
5. 「经验累积」功能官方标注为 coming soon。 那个宣称「越用越快、最高 5 倍」的特性目前还不是完全体，落地效果需要观察。
6. 隐私承诺需要自行验证。 官方称浏览数据、Cookie 都留在本机，数据收集刻意收窄（例如「是否把 ego lite 设为默认浏览器」这类产品信号）。但闭源应用的实际行为，第三方只能从外部观察，无法完全证实。
把 ego lite 放到行业演进里看，它代表了一个方向性的转变。
2023 到 2024 年，浏览器 Agent 的主流形态是「库 + 远程控制」：browser-use、agent-browser 这类工具，本质是一个自动化库，需要外挂一个浏览器去驱动。它们的痛点被 ego lite 的 README 一句话点破："They need a separate one to drive, your browser data rarely carries over intact, the connection is unstable, and you and the agent end up fighting over control of the browser."
2025 年之后，另一条路线出现了：ChatGPT、Claude 各自在产品内建浏览器能力，但代价是只能服务于自家 Agent。
ego lite 走的是第三条路：同一只浏览器，人机分区，任意你已经在用的 Agent 都能接。这个定位从 GitHub topic 标签就能看出来——agent-skills、claude-code、codex、hermes-agent、skills-sh，它明确瞄准的是「Agent Skills」这个正在成型的分发形态。
更有意思的是它把接口设计成「代码驱动」而非「CLI 驱动」。当模型具备了写代码的能力，把 Agent 与外部世界的交互从「一串命令」升级为「一段程序」，是一个自然而然、且目前还很少有人做透的升级方向。这背后是大模型工具调用范式的一次迁移：从 function calling 的离散参数，转向代码执行的组合能力。
项目从 2026 年 4 月 16 日创建至今约半年，stars 从社区文章记录的 7,924 一路涨到 18,603，半年翻了一倍多，这个增速在工具类项目里相当突出。open issues 已有 238 个，热度带来的社区压力也可预见。
对于国内团队，它的意义还在于：它把「让 Agent 真正能用的浏览器」这件事的关键——继承登录态、并行隔离、不抢焦点——一次性解掉了，而这套方案对 Claude Code、Codex、Cursor 以及 Hermes 这类主流 CLI Agent 都是开放可接的。
适合： 已经在用 CLI Agent（Claude Code / Codex / Cursor / OpenCode / Hermes）的开发者；重度依赖网页操作的工作流（竞品监控、线索整理、后台数据搬运）；以及希望本地化、不想把登录态上传云端的团队。
不适合： Linux 团队、需要 CI 里跑浏览器自动化的场景、要求完全可审计或可自托管的场景，以及不愿在本机开启 Agent 沙箱外应用权限的组织。
一句话总结：ego lite 不是又一个浏览器自动化框架，它是一次浏览器交互范式的重新设计——把浏览器从「Agent 要遥控的对象」变成「你和 Agent 共用的工作环境」。 而它把这一切的开源部分，交到了一个可以被任何人读、被任何人改的 harness 里。