我对 ego-lite 的第一判断是：它真正想替换的不是 Playwright 或 Puppeteer 的某个 API，而是“agent 该拿什么浏览器干活”这个默认假设。
普通浏览器自动化框架的默认形态是：agent 另起一个空白浏览器，自己处理登录、cookie、弹窗、SSO、iframe、截图、DOM 选择器，然后一条工具调用接一条工具调用地试。Ego Lite 的默认形态正好反过来：浏览器本身就是 agent-aware 的运行时，保存真实登录态和任务空间；agent 只是临时生成一段 JavaScript，交给浏览器里的 helper runtime 去执行。
这篇是截至 2026-07-27 的源码/产品笔记。我读的是 GitHub 仓库当前 HEAD 02ee972，再对照了官网、quick start、changelog 和 open issues。
1. 它解决的不是“怎么点击”，而是“agent 和人怎么共用一个浏览器”
官网和 README 的叙述都很一致：ego lite 是一个基于 Chromium 的浏览器，agent 在自己的 Space 里工作，人类用户的 tabs 保持不受打扰；首次启动时可以迁移 Chrome 数据，登录态、cookies、扩展、书签会被带过来，agent 因此能操作那些“只有登录后才有意义”的页面。官网还强调 ego-browser 是连接 Codex、Claude Code、Cursor 等外部 agent 的 skill/连接层，而不是只服务内置 agent 的私有入口。
这点很关键。浏览器 agent 的难点从来不只是“点按钮”：
- 登录态怎么来？
- 人类用户和 agent 会不会抢同一组标签页？
- agent 每一步看到的页面表示是否足够稳定？
- 中途需要用户接管时，控制权怎么交还？
- 多个 agent 任务并行跑时，状态怎么隔离？
Ego Lite 的答案是把这些问题放到浏览器层，而不是放到每个自动化脚本里补丁式解决。
2. 开源仓库里真正开源的是什么
这里要先划清边界：这个仓库不是完整浏览器源码。仓库里开源的是 ego-browser 的 Node helper runtime 和 agent skill 包；浏览器 app 本体是单独下载安装的免费应用。仓库里的 package/ego-browser/README.md 把关系写得很清楚：
ego-browser (Chromium) -> globalThis.ego -> Playwright-style helper facades -> agent heredoc也就是说，开源层主要做三件事：
- 提供 agent 能调用的 helper API，比如
page.snapshot()、page.locator()、browser.openOrReuseTab()、taskSpaces.useOrCreate()、cdp()。 - 把这些 API 转成浏览器 runtime 暴露的
globalThis.ego调用，底层主要是 CDP、Snapshot、Task Space 管理。 - 把这些能力打包成 skill，让 Codex/Claude Code 这类外部 agent 通过 heredoc 方式提交 JavaScript。
因此，如果要评价它的“原理”，不能只看 README 里的 benchmark，也不能只看 npm 包。正确的层次是：浏览器侧 runtime 提供真实浏览器能力，开源 helper runtime 提供 agent-facing 编程接口；完整浏览器 runtime 并没有在这个仓库里开源。
3. 数据流：agent 写代码，浏览器执行代码
传统 CLI 工具常见模式是：
agent 观察 -> 调一个命令 -> 读输出 -> 再调一个命令 -> 再读输出ego-browser 的模式更像：
agent 一次性写一段 JS -> helper 注入 page/browser/taskSpaces 等对象 -> 浏览器 runtime 执行 -> 输出结果可以画成这样：
flowchart LR
A[Agent prompt] --> B[ego-browser Skill]
B --> C[JS heredoc]
C --> D[runMain injects helpers]
D --> E[page browser taskSpaces site fetch cdp]
E --> F[globalThis.ego]
F --> G[CDP Snapshot Spaces]
G --> H[Chromium profile and tabs]
G --> I[console output]源码上，入口在 run.ts：runMain() 从 stdin 读入 heredoc 代码，execute() 用 AsyncFunction 包起来，并把 helperContext() 产出的对象作为参数注入。这个设计很 agent-friendly：agent 不需要学习一堆 shell 子命令，而是直接写它最擅长的 JavaScript。
这也是它宣称“更少 tool calls”的根源。不是因为点击本身突然便宜了，而是因为许多步骤可以合并进同一个脚本里执行：
await taskSpaces.useOrCreate('read docs')
await browser.openOrReuseTab('https://example.com', { wait: true })
const title = await page.title()
const text = await page.snapshot()
console.log({ title, text: text.slice(0, 500) })对 coding agent 来说，这比“下一步点哪里”式工具循环更自然。它把浏览器任务变成了一个小程序，而不是一串离散动作。
4. globalThis.ego 是这套系统的中轴
源码里所有真正碰浏览器的路径都会回到 browser-runtime.ts。最核心的函数很直白：
browserEgo()：检查并返回globalThis.ego。rawCdp()：把 CDP payload 序列化后交给runtime.sendCDPMessage(...)。browserCdp()：为普通 CDP 调用自动补 session，遇到 session lost 时重新 attach。ensureSession()：从ego.listTabs()找 active/preferred tab，调用Target.attachToTarget，并缓存 session。
这说明一个设计事实：Node 进程不是状态中心，浏览器才是状态中心。 每个 heredoc 进程可以很短命，但 tab、Space、登录态、Snapshot 能力都留在浏览器里。短命进程负责组合动作，长命浏览器负责承载世界。
这也是我认为 Ego Lite 有价值的地方。很多 browser automation 工具把浏览器当“被驱动对象”；Ego Lite 更像把浏览器变成一个轻量操作系统，agent 只是往里面提交 job。
5. Snapshot：开源层负责消费，浏览器层负责生产
官网强调它的语义 snapshot 做在 custom Chromium engine 里，能更好处理 iframe、shadow DOM、第三方 widget。源码也支持这个判断：observe.ts 里的 snapshotRaw() 只是调用：
browserEgo().snapshot(options)然后把返回的 refs 转成 helper 层可用的 ref map。也就是说，开源 helper 并没有自己在普通网页里用 JS 拼一个 snapshot；真正的页面语义抽取能力在浏览器 runtime 侧。
这带来一个优点和一个边界：
- 优点：如果浏览器内核层真的能拿到更完整的页面结构，那它会比纯 JS shim 更可靠，尤其是跨域 iframe、可访问性树、shadow DOM 这类麻烦场景。
- 边界：这部分不是完全可审计的开源实现。我们可以从 helper 调用路径确认接口形态，但不能仅凭仓库证明“最强 snapshot”这类产品级结论。
6. refs、locators 和 CDP 让“看见”能够落到“行动”
只给模型一段页面文本还不够。关键是 snapshot 里的 @N ref 或 loc=... 能不能稳定映射回真实元素。Ego Browser 在 element-resolver.ts 里做了这层转换：
@Nref 会先查 ref map，对应到 CDP 的backendNodeId。- 如果节点还在，就用
DOM.getBoxModel算中心点。 - 如果节点 stale，就尝试用 role/name 等信息重新定位。
- 如果传入的是
loc=...、XPath、CSS selector，则走各自的解析路径。
再往上，helpers.ts 把这些能力包装成接近 Playwright 的 facade：page.getByRole()、page.getByText()、locator.click()、locator.fill()、page.waitForResponse()、page.evaluate()。
这里的工程取舍很务实：给 agent 的表面是熟悉的 Playwright 风格；内部则保留 CDP、backend node、session、iframe session 这些底层概念。agent 写起来像高层脚本，失败时系统还能回到底层做更精确的定位。
7. Task Spaces 才是它区别于普通自动化框架的地方
我最看重的不是 click()，而是 Task Spaces。
在 skill 文档和源码里，Space 是一个有 ownership 的隔离浏览上下文。helper 层提供：
taskSpaces.list()taskSpaces.useOrCreate()taskSpaces.claim()taskSpaces.handOff()taskSpaces.takeOver()taskSpaces.complete()
这些 API 不是锦上添花，而是 agent 浏览器的安全阀。因为 agent 跑网页任务一定会遇到人类必须介入的时刻：登录、验证码、支付确认、权限选择、敏感提交。没有 ownership 和 handoff，agent 和人就是在抢鼠标；有了 Space 和控制权协议，系统至少有机会表达“现在谁在控制这个浏览上下文”。
这也解释了为什么 Ego Lite 的产品叙事一直强调“你和 agent 并行工作”。它不是把 agent 塞进你的当前 tab，而是给 agent 一个继承登录态但可隔离的工作区。
8. 我的判断：方向是对的，但风险也集中在同一个地方
我看完后的判断分三层。
第一，产品洞察是对的。 Web agent 规模化的瓶颈不是缺少 click()，而是登录态、真实浏览器环境、长任务状态、用户接管、多任务隔离这些“浏览器操作系统”问题。Ego Lite 把问题下沉到浏览器层，这是比再造一个自动化库更有杠杆的方向。
第二，编程模型是对 agent 友好的。 让 agent 写一段 JS，而不是逐条调用工具，符合 coding agent 的优势。模型可以把观察、提取、等待、点击、验证写在一个小程序里，减少往返，也减少 token 被中间输出吃掉。
第三，最大风险也来自它的核心优势。 一旦 agent 继承了真实登录态，它拿到的是很高的 ambient authority：邮箱、CRM、后台、社交账号、支付页面都可能在可达范围内。官网说数据本地保存，这是好事；但“本地”不等于“低权限”。浏览器 agent 下一步真正需要的是更细的策略层：哪些站点可读不可写，哪些按钮必须人工确认，哪些表单提交前必须截图/摘要给用户确认。
这不是我凭空担心。GitHub issues 里已经能看到 profile import、截图、实例注册以及安全类 issue 报告；这很正常，说明它正在碰真实浏览器产品才会碰到的复杂性。相关研究也在往这个方向走，比如浏览器 agent sandboxing 论文 ceLLMate 讨论的就是如何降低 prompt injection 和过大浏览器权限带来的风险。
9. 我会怎么定位 Ego Lite
如果只把它归类成“Browser Use 的替代品”，我觉得低估了它。更准确的定位是：
Ego Lite = 日常 Chromium 浏览器 + agent task spaces + semantic snapshot runtime + external-agent skill bridge它不是一个纯库，也不是一个只会聊天的 AI 浏览器。它介于两者之间：浏览器负责真实状态和隔离，外部 agent 负责推理和写代码，ego-browser 负责把两边接起来。
短期看，它适合那些“必须登录、流程重复、页面环境复杂、又不值得单独接 API”的任务，比如后台录入、数据巡检、社媒操作、CRM 信息整理、订票/预约、内部门户测试。当前另一个现实边界是平台：README 写明 ego lite 目前跑在 macOS，Windows 和 Linux 还在 roadmap 上。
长期看，它能不能成立，取决于三个问题：
- Snapshot 和 locator 在真实复杂网站上是否稳定。
- Space/ownership/handoff 是否能让用户放心地交出控制权。
- 权限、审计、确认机制是否跟得上“复用真实登录态”这件事的风险。
我的结论是：Ego Lite 抓住了 browser agent 的正确抽象层。 它最有价值的部分不是“让 agent 会浏览网页”，而是把网页浏览从一次性自动化脚本，推进到一种可共享、可隔离、可编程的运行环境。接下来真正的竞争点，不会是多几个 helper 函数，而是谁能把“真实登录态 + agent autonomy + 用户控制权”这三件互相冲突的东西平衡好。