刊 DailyNews 科技 / AI 每日文摘2026 年 10 月 30 日

每日文摘

深挖 · ego-lite：给 agent 用的浏览器，能不能替掉你的 Chrome CDP

题图

ego-lite 是 citrolabs 出品的 macOS「AI agent 专用浏览器」，14.7k star，口号是「The fastest browser for AI agents」。它想解决的问题很具体：人和 agent 共用一个浏览器——agent 拿着你的登录态干活，但待在隔离的 Space 里，不抢你的鼠标、不开一堆新窗口。本文按四个实际问题展开：它和 agent 操作 Chrome CDP 有什么本质差异；Mac 上已经装了 app，agent 要怎么稳定接入；一个用 Playwright-over-CDP 的采集管线能不能换成它；以及到底值不值得换。

一、是什么：三层架构与 Space 机制

先纠正一个容易误解的点：这个 GitHub 仓库不是浏览器源码。AGENTS.md 写得很清楚——“The repo contains the harness and skill package — not the browser”（AGENTS.md）。真正的结构是三层：

核心机制是 Space：官方文档明确定义「one isolated BrowserContext per task, with its own cookies and storage」——同一个浏览器进程内，每个任务一个隔离的原生 BrowserContext，每个 Space 有自己的一组 tab（openOrReuseTab/switchTab/closeTab）。官方给过一组示意数字：6 路并发打开空白页，「独立实例 + profile 拷贝」约 15GB 内存 / 84 进程，ego Space 约 0.9GB / 6 进程（官方注明是资源模型示意、非严格 benchmark，出处：官方文档 Space）。这正是「一个实例开 tab 而不是开关新窗口」的原生答案。

另一个卖点是 snapshot：由浏览器内核侧（而非脚本库）从 accessibility tree 压缩出的结构化文本，每个交互元素带 @N 编号（来自 CDP backendNodeId，跨快照稳定），官方量级说法是完整 DOM 数万 token（典型页面约 30k）压缩到数百 token（官方文档 Snapshot）。

二、agent 操作它，和操作 Chrome CDP 差在哪

官方有一篇架构文章把「agent 用浏览器」的路数分成四条 route，ego 的自我定位是「Mechanically it is route 3, productized」——底层就是 CDP，但把端口暴露、profile 锁、窗口冲突在产品内消化掉了（How AI Agents Can Use Your Existing Browser）。差异具体在五处：

维度Chrome + CDP（Playwright 等）ego-lite
谁做决策你的脚本（确定性）或 agentagent（写整段 JS）
输入给模型什么DOM/HTML/截图内核级压缩 snapshot（数百 token）
登录态专用 profile，人工登录一次继承日常 Chrome 登录态（onboarding 迁移）
外部工具直连CDP 端口，任意客户端可连无端口暴露，仅 heredoc 内 helpers
token 成本逐命令往返一次 heredoc 整段跑（官方示例 1.1k vs 13.6k）

操作范式叫「Code base, not CLI base」：agent 用 Bash 跑 ego-browser nodejs <<'EOF' ... EOF，在一段 Node 脚本里调预注入的 helpers（snapshotText/click/fillInput/waitForElement/cdp 等 60 多个），一次跑完导航、观察、滚动、提取、过滤、输出——而不是「调两条命令、看结果、再调两条」的循环（README）。

两个容易忽略的技术细节：其一，ego-lite 不暴露任何外部可连的 CDP 端口——全库 grep remote-debugging/9222/connectOverCDP 零命中，CDP 报文走 globalThis.ego.sendCDPMessage 宿主注入绑定，所以外部 Playwright/CDP 工具无法直连它；官方也明言 ego-browser “not a replacement for Playwright or Puppeteer”（ego-browser 文档）。其二，兼容是反方向的：它把 Playwright 语义（strict/auto-wait 的 locator、getByRole、page.evaluate）搬进了 heredoc 内的 facade，还配了 playwright-* 系列真浏览器回归测试（helpers.ts）——让你在 agent 脚本里写出 Playwright 风格的代码，而不是让 Playwright 连它。

顺带一说工程质量：测试与源码约 1:1（8.3k 行测试）、自研变异测试、25+ 真浏览器 e2e（包括「大麦抢票」这种对抗场景）、JSDoc 即文档的 help() 体系。对一个连接层项目，这明显高于平均水准；短板是内核闭源，核心卖点（快照质量、Space 隔离、benchmark 成绩）都无法独立复现。

三、Mac 上已经装了，agent 怎么稳定接入

我已在 Mac（arm64）上装了 /Applications/ego lite.app（0.4.6.14），CLI 在 ~/.local/bin/ego-browser。答案是要装 skill——app 和 CLI 只是执行层，skill 是 agent 的「使用说明书」，官方接入链是五件套（出处：references/install.md、Codex 接入指南）：

  1. app onboarding（一次）：首启只问一件事「是否迁移 Chrome 数据」（可能要 macOS 密码），同意后 agent 继承登录/cookie/扩展/书签；
  2. CLI 注册 PATH：onboarding 把 ego-browser 注册到 ~/.local/bin（实体在 app bundle 内）；
  3. skill 注入 agent 目录：onboarding 自动扫描本机 agent——Claude Code 写 ~/.claude/skills/，Codex/Cursor/OpenCode 写 ~/.agents/skills/；也可以 npx skills add citrolabs/ego-lite 手动只装 skill；
  4. agent 放开沙箱权限：各 agent 都要求 Bypass permissions / Full access / Run Everything 这一档，否则 CLI 拉不起本地 app；
  5. 重启 agent 进程刷新 skill 列表。

本机实测（2026-09-03）：我直接跑了最小探针——useOrCreateTaskSpace → openOrReuseTab('https://example.com') → snapshotText() → completeTaskSpace，全链跑通，snapshot 输出确实是压缩语义树。但发现一个坑：CLI 的 --help 尾注指向 ~/.agents/skills/ego-browser/SKILL.md，这个文件在本机不存在——官方 agent 名单（Claude Code/Codex/Cursor/OpenCode/WorkBuddy/Hermes）不含 ZCode，说明 onboarding 没覆盖到这个目录，需要手动补装 skill（npx skills add citrolabs/ego-lite 或重跑 onboarding 勾选）。另外 0.4.6.14（08-14 发布）已落后最新 0.4.7.4（08-31），且 0.4.6.12→0.4.6.14 恰好是一次内存暴涨回归的修复链，建议先 ego-browser upgrade（Changelog）。

四、数据说话

先看官方成绩单，注意全部是厂商自测、无第三方复现：

社区侧很薄弱：HN 两个 Show HN 帖合计 13 分 9 评论（有真话——「agent gets its own independent space but still holds my credentials… exactly what I’ve wanted」，但团队零回帖）；Reddit 高赞的 6-agent 横评帖根本没测它；Reddit 讨论帖里还嵌着 ego 官方的付费投放广告。采信度也要打折：citrolabs 是新加坡的匿名组织（GitHub 无公开成员、主站 coming-soon、无融资披露），14.7k stars 对 106 个 org followers，营销驱动明显。

对迁移决策最要命的三个 issue（均 open）：#303——从 agent 的 Task Space 调 cdp("Network.clearBrowserCookies") 会把用户主 Space 的登录态一并清掉，Space 隔离模型被 raw CDP 逃逸；#213——CDP 传输是全局单通道，并发多 Space 会竞态报错；#314——导航操作会被误判为「用户接管」而硬停任务，有用户的机票任务连停 3 次（#303、#213、#314）。

五、值不值得把 Chrome CDP 换成它

先回答「能不能换」：不能直接换。ego-lite 没有外部 CDP 端口，管线里的 chromium.connectOverCDP("http://127.0.0.1:9222") 无法指向它；替换意味着把采集脚本整体改写为 heredoc JS 形态。再回答「该不该换」：生产线不该换，交互层值得引入。

不该换的理由有四。第一，需求错位：我的头条采集是确定性脚本——每天定时跑、选择器写死、要可回归，ego-lite 的 snapshot+agent 模式是为「委托给 agent 的探索性任务」设计的，官方自己的定位就是「Playwright for tests you commit, ego lite for tasks you delegate」（官方对比页）。第二，「省资源」的预期有个前提错位：现在的 chrome.sh 本来就是常驻单实例 + newPage() 开 tab，并不存在开关新窗口的问题——ego 的 0.9GB vs 15GB 对比是打「多实例拷 profile」的做法，不是打单实例 CDP。第三，成熟度：#303 隔离失效、#314 误停这类 bug 对生产管线是致命的，而 Playwright-over-CDP 是被验证过几年的路径。第四，平台锁定：仅 macOS、无 headless、闭源不可审计，官方自己都说 headless CI 场景请留在 profile 拷贝方案。

值得引入的地方也很明确：作为 agent 的交互式浏览操作层。登录态继承是真实优势——深挖作业里撞上渲染墙的登录态站点，再也不用先人工去专用 profile 登录一次；Space 隔离让 agent 干活不影响人正在用的窗口；压缩 snapshot 让 agent 每步看页面的 token 成本降一个量级。具体的落地动作是两件：给 ZCode 补装 ego-browser skill（解决本机 skill 缺失），在深挖作业的兜底工具箱里加一条 ego-lite 路径，与 crwl 并列。采集管线一行不动。

一句话总结：ego-lite 是「agent 委托任务」赛道目前完成度很高的浏览器，它把 CDP 产品化的思路（无端口、宿主注入、Space 隔离）值得学；但它解决的问题（agent 逐步决策的交互任务）和 DailyNews 管线的问题（确定性采集）不是同一个——两条线并行，而不是替换。

参考阅读