编程 ego-lite 深度拆解：一个人类和 AI 并行操控的浏览器，如何重新定义 Agent 的网页自动化

2026-07-27 10:46:16 +0800 CST views 8

ego-lite 深度拆解：一个人类和 AI 并行操控的浏览器，如何重新定义 Agent 的网页自动化

2026 年 7 月，一个叫 ego-lite 的项目在 GitHub Trending 上日增 880 Stars，暴涨 3.5 倍。它不是又一个 AI 编程助手，不是又一个浏览器自动化框架——它是一个从零设计、专门解决「人类和 AI 能不能共享同一个浏览器」这个问题的 Chromium 分支。

一、问题：为什么现有的浏览器自动化框架总是「差一口气」

在 ego-lite 出现之前，开发者想让 AI 代理操控浏览器做 Web 自动化，通常走两条老路：

1.1 Playwright / Puppeteer：程序员的浏览器控制台

这是最常见的选择。Playwright 和 Puppeteer 本质上是 headless/headful Chromium 控制工具：你用 JavaScript/TypeScript/Python 写脚本，通过 CDP（Chrome DevTools Protocol）驱动浏览器。

优势明显：API 成熟、社区庞大、生态丰富。但痛点同样明显：

痛点一：登录状态是个大麻烦。 你的浏览器里登录了 GitHub、LinkedIn、Jira、CRM 系统，但 Playwright 启动的是一个全新的 headless 实例，Cookie/LocalStorage 全是空的。你要么手动传入 --user-data-dir，要么从已有浏览器导出 Cookie，要么在自动化脚本里跑一遍登录流程。每一种方案都繁琐且脆弱。

痛点二：profile 锁问题。 Chrome 的 --user-data-dir 只能被一个进程独占锁住。如果你在本地跑着 Chrome 浏览器，同时想用 Playwright 操控同一个 profile，就会遇到 user data directory is already locked 错误。解决方案是每次复制一份临时 profile，但复制速度慢、占空间大，多个并发任务更是噩梦。

痛点三：人机冲突。 即使用户愿意接受以上妥协，还有一个更根本的问题：AI 操控浏览器时，页面焦点、鼠标、甚至标签页都在 AI 的控制下。你没法一边让 AI 在 CRM 里跑数据，一边自己写代码。两者只能二选一。

1.2 browser-use、Agent Browser 等 AI 自动化框架

2024-2025 年，一批 AI 原生的浏览器自动化框架兴起，试图解决「把 DOM 塞给 LLM」的问题。它们本质上还是在 Playwright/Puppeteer 之上封装了一层：截图 + DOM 提取 → 扔给 LLM → LLM 输出 action → 框架执行。

问题几乎完全继承了 Playwright 的：

登录状态无法复用
需要单独起浏览器实例
资源开销巨大（每个任务都要一个独立 Chromium 进程）
人机无法并行

这背后的根本矛盾是：现有方案都是在已有浏览器生态上打补丁，而没有人重新思考「如果浏览器天然支持人类和 AI 并行使用，应该长什么样」。

ego-lite 就是这个问题的直接回答。

二、ego-lite 是什么：重新设计一个「人机并行」的浏览器

2.1 核心定位

ego-lite 是一个基于 Chromium 的浏览器，但它的设计目标从第一天起就只有一件事：让人类用户和 AI 代理在同一个浏览器进程里并行工作，互不干扰。

官方描述原文是：

"ego (lite) is a browser where you and your AI agents work in parallel. Your agents run multiple browser tasks in their own Spaces while your tabs stay yours, and tasks complete faster on fewer tokens."

翻译一下：一个浏览器，你和你的 AI 代理并行工作。代理在各自的 Space 里跑任务，你的标签页始终属于你，任务完成更快，Token 消耗更少。

2.2 与 Chromium 原版的根本区别

ego-lite 不是 Chromium 的皮肤，不是主题，不是插件。它在 Chromium 的多进程架构基础上做了一层关键改动：BrowserContext 隔离层。

标准 Chromium 的架构中：

一个 browser 进程管理窗口和标签页生命周期
每个标签页对应一个 renderer 进程
Cookie/LocalStorage/Profile 数据与特定 --user-data-dir 绑定，且被该目录独占锁

ego-lite 的改动在于：

保持单 browser 进程，所有 Spaces 共享这个进程
每个 Space 拥有独立的 BrowserContext，拥有独立 Cookie/Storage，但共享底层渲染基础设施
不需要 profile 复制：从主浏览器一键迁移登录状态（Cookies、Extensions、Profile），迁移后 AI 直接可用

这就是 Space 机制的核心——我们下一节重点拆解。

三、Space 机制：并发安全的隔离空间

3.1 什么是 Space

Space 是 ego-lite 的核心概念。一个 Space = 一个 AI 代理任务的独立工作区，包含：

独立的 BrowserContext（有自己的 Cookie、LocalStorage、SessionStorage）
独立的标签页集合
独立的网络请求上下文

Space 不是：

新窗口（共享同一个 browser 进程而非新建进程）
Chrome Profile（轻量级 BrowserContext 而非磁盘级 profile）
云端浏览器实例（所有数据留在本地）

3.2 性能对比：数字最有说服力

官方给出的基准测试——6 个并发任务、每个仅打开 about:blank：

方案	新增内存	新增进程	并发启动耗时
独立浏览器实例 + profile 复制	~15 GB	~84	~2.5s
ego-lite Space	~0.9 GB	~6	~0.6s

这个数字的对比是惊人的：独立实例方案需要约 15GB 额外内存和 84 个进程，而 ego-lite 只增加不到 1GB 内存和 6 个进程。

背后的原因很清晰：

进程复用：传统方案每个任务起一个完整的 Chromium 渲染进程树（GPU 进程、Network 进程、Utility 进程等），ego-lite 所有 Space 共享一套渲染基础设施
BrowserContext 而非 profile 复制：BrowserContext 是 Chromium 内部的轻量隔离单元，创建成本远低于复制整个 user-data-dir
内存共享：共享代码段、共享字体、共享 WebGL 上下文等基础资源

3.3 代码层面看 Space 的生命周期

ego-lite 提供了一套 Node.js 风格的 API 来操作 Space。以下是完整的任务生命周期：

```javascript
// ego-browser nodejs <<'EOF'
// 1. 创建或复用 Space（推荐用自然语言描述而非占位符）
const task = await useOrCreateTaskSpace('招聘网站批量投递简历')

// 2. 打开目标页面
await openOrReuseTab('https://www.linkedin.com/jobs/', { wait: true, timeout: 20 })

// 3. 读取页面快照（语义化 DOM 树）
cliLog(await snapshotText())

// 4. 执行操作
await click('@15', { label: '点击搜索按钮' })
await fillInput('@3', 'Senior Go Engineer')

// 5. 任务完成，保留标签页供人工审核
// （注意：是 completeTaskSpace 而非 closeTaskSpace）
await completeTaskSpace(task.name)
```

对比传统 Playwright 方案：

```javascript
// Playwright：每个任务需要启动独立浏览器实例
const browser = await chromium.launch({
headless: true,
userDataDir: '/tmp/profile-' + uuid() // 每次都要复制或新建
})
const context = await browser.newContext()
const page = await context.newPage()
// ... 操作 ...
await browser.close() // 关闭后无法回溯操作历史
```

两者的关键差异：

ego-lite 在创建 Space 时共享浏览器进程，启动时间从秒级降到毫秒级
任务完成后 Space 保留标签页，可以人工审查 AI 做了哪些操作
同一个 Space 可以被多个 step 复用，不需要每次都重新初始化

3.4 多任务并发

ego-lite 支持在一个 Space 内运行多个并行任务，每个任务有自己独立的标签页和 Cookie：

```javascript
// ego-browser nodejs <<'EOF'
// 同时处理两个求职任务
const task1 = await useOrCreateTaskSpace('LinkedIn 职位搜索')
const task2 = await useOrCreateTaskSpace('Boss 直聘投递')

await openOrReuseTab('https://www.linkedin.com/jobs/search', { wait: true }, task1.name)
await openOrReuseTab('https://www.zhipin.com', { wait: true }, task2.name)

// 每个任务在自己的 Cookie 上下文中独立运行
// 不会相互干扰
```

四、登录状态共享：从「每次重新登录」到「一键继承」

4.1 传统方案的登录困境

这是大多数 AI 浏览器自动化场景中最痛苦的环节。

以 GitHub 为例：你想让 AI 自动帮你：

在 GitHub 上创建一个 issue
PR 里跑 CI 检查
整理某个组织的成员列表

你的真实 Chrome 浏览器里已经登录了 GitHub，但 Playwright 启动的是一个干净实例。解决方案通常是：

方案 A：导出 Cookie → 导入 Playwright

# 用 browser-use 或类似框架
cookies = json.load(open('github_cookies.json'))
await context.add_cookies(cookies)

问题：Cookie 有过期时间，过期了就得重新导；httponly 的 Cookie 导不出来（无法导出基于 SMS/邮件验证码登录的会话）。

方案 B：--user-data-dir 复用

browser = await chromium.launch(
    headless=False,  # 必须非 headless 才能复用
    userDataDir='/Users/me/Library/Application Support/Google/Chrome/Default'
)

问题：Chrome 必须关闭（独占锁），你在本地跑 AI 时没法用浏览器了。

方案 C：在脚本里跑 OAuth 登录流程

# 打开 GitHub 登录页 → LLM 判断输入框 → 输入账号密码 → 处理 2FA

问题：2FA 无法自动化；整个登录流程慢且脆弱；每次都要跑一遍。

4.2 ego-lite 的解法：浏览器数据迁移

ego-lite 在首次启动时提供了一步到位的数据迁移：

"On first launch, ego (lite) scans your machine for installed agents and writes the ego-browser skill into their skill directories. It'll also ask whether you want to migrate your browser data — pick the right browser and confirm, and your login state, cookies, extensions, and Profile all come along, ready for your agent to reuse directly."

实际效果是什么？

你平时用 Chrome 浏览器，登录了 GitHub、LinkedIn、Notion、Salesforce、Slack……迁移之后，这些登录状态直接在 ego-lite 中可用，AI 代理通过 Space 访问这些站点时，不需要任何重新认证。

4.3 人机协同时的登录处理

即使有了迁移机制，有些登录场景仍然需要人类介入。ego-lite 的设计哲学是：关键时刻停下来等人类确认。

需要人类介入的场景（Space 会自动暂停）：

SMS 或邮件验证码
二维码登录（微信、飞书等）
硬件安全密钥（YubiKey 等）
支付/下单/转账类操作
发布、删除、归档等不可逆操作

示例：AI 想帮你自动投简历，但在提交前会停在支付页面等你确认：

Agent: 已填完简历表单，正在提交申请...
[SPACE PAUSED] 需要你确认：发送申请至 hr@company.com 吗？
→ 点击 [继续] 提交  |  点击 [停止] 取消

你也可以在任务开始前设定边界：

"帮我找 LinkedIn 上的 Go 工程师职位，只读，不投"
"帮我更新 CRM 里的客户联系人，但不要删除任何记录"

五、Token 消耗降低：从「全量 DOM 传输」到「语义快照」

5.1 AI 浏览器自动化的 Token 困境

现有 AI 浏览器自动化框架的核心瓶颈之一，是 将整个 DOM 传给 LLM 的成本。

一个中等复杂度的 SaaS 页面（CRM 列表页、Dashboard、表格页）的 DOM 节点数量往往在 500-5000 个之间。即使只提取 innerText，Token 消耗也相当可观：

一个典型的 Jira Issue 详情页：约 8000 Tokens
一个 LinkedIn 个人主页：约 12000 Tokens
一个 Salesforce Dashboard：约 20000+ Tokens

如果 AI 每次操作都要读取全量 DOM，一个 10 步的自动化任务就可能消耗 100K+ 输入 Tokens，成本极高。

5.2 ego-browser 的语义快照机制

ego-lite 的 ego-browser 提供了一种 语义化快照（Semantic Snapshot） 机制：

// 读取语义化快照（而非原始 DOM）
const snapshot = await snapshotText()
// 返回示例：
// [ref=1, loc=header.nav, url=https://example.com]
//   [ref=2, loc=header.nav.search-form] 搜索...
//   [ref=3, loc=header.nav.user-menu] 个人头像
// [ref=10, loc=main.content.job-list]
//   [ref=11, loc=main.content.job-list[0]] 高级 Go 工程师 | 字节跳动 | 北京
//   [ref=12, loc=main.content.job-list[1]] 后端架构师 | 美团 | 上海

这个快照做了几件事：

去噪声：过滤掉 <style>、<script>、隐藏元素等对理解页面内容无用的节点
结构化：保留 HTML 语义层级（header/main/aside/nav），用 [ref=N, loc=...] 格式提供可引用的坐标
按需粒度：可以限定范围（scope: 'only_within_viewport'），只读视口内可见内容

实际效果：一个 LinkedIn 个人主页的原始 DOM 可能 12000 Tokens，但语义快照可能只有 2000-3000 Tokens，降低 70-80%。

5.3 可视化参考定位

每个 ref 都可以做可视化高亮，帮助 AI 确认自己在操作正确的元素：

await click('@21', { label: '点击登录按钮' })
// AI 操作时会先在页面上高亮标注 ref=21 的元素（蓝色边框闪烁）
// 人类在旁边可以看到 AI 的操作意图

六、实战：构建一个「社交媒体运营助手」

6.1 场景描述

让我们用一个真实场景来完整展示 ego-lite 的使用流程：自动监控竞品公司的 LinkedIn 动态，定期汇总并推送到飞书群。

涉及站点：LinkedIn（需要登录）、飞书（需要登录）。

6.2 完整代码

// ego-browser nodejs <<'EOF'
const COMPETITORS = [
  'stripe', 'github', 'vercel', 'supabase', 'planetscale'
]

// 1. 创建专属 Space
const space = await useOrCreateTaskSpace('竞品 LinkedIn 动态监控')

// 2. 打开 LinkedIn 主页（登录状态已从浏览器迁移复用）
await openOrReuseTab('https://www.linkedin.com/company/stripe/posts', { wait: true, timeout: 30 })

// 3. 读取公司帖子列表
const snapshot = await snapshotText()

// 4. 提取最新帖子（限制在最近 7 天）
const posts = await js(String.raw`
  (() => {
    const cards = document.querySelectorAll('.occludable-update')
    return [...cards].slice(0, 5).map(card => {
      const text = card.querySelector('.feed-shared-update-v2__description')?.innerText || ''
      const time = card.querySelector('.feed-shared-actor__sub-description span')?.innerText || ''
      const reactions = card.querySelector('.social-details-social-counts__reactions-count')?.innerText || '0'
      return { text: text.slice(0, 200), time, reactions }
    }).filter(p => p.text.length > 10)
  })()
`)

// 5. 滚动加载更多（如果不够 5 条）
if (posts.length < 3) {
  await scrollToBottomUntil(
    async () => (await js(String.raw`document.querySelectorAll('.occludable-update').length`)) >= 5,
    { step: 500, wait: 1, maxSteps: 10 }
  )
}

// 6. 输出结构化数据
const report = {
  timestamp: new Date().toISOString().split('T')[0],
  company: 'Stripe',
  posts: posts
}
cliLog(JSON.stringify(report, null, 2))

6.3 资源占用实测

对比同样任务的 Playwright 实现（理论估算）：

指标	Playwright	ego-lite
启动耗时	~3-5s（浏览器冷启动）	~200ms（已有进程）
登录处理	需要额外处理 Cookie	直接复用已有登录态
峰值内存	~500MB/任务	~50MB/任务
操作历史留存	无（关闭后丢失）	有（Space 保留标签页）
人机并行	不支持	支持（Space 不抢占主标签）

七、架构深度解析：Space 机制的技术实现

7.1 Chromium BrowserContext 的隔离模型

在 Chromium 的进程架构中，BrowserContext 是 Cookie 存储、代理设置、证书存储等网络状态的容器单位。与 Profile（磁盘级）不同，BrowserContext 是内存中的轻量对象，创建和销毁成本极低。

传统 Chromium 多标签页架构：
BrowserProcess
  ├── BrowserContext A (Profile: Default)
  │     ├── Tab 1 (github.com - 登录态 A)
  │     └── Tab 2 (linkedin.com - 登录态 B)
  └── BrowserContext B (临时/隔离)
        └── Tab 3 (google.com - 无登录)

ego-lite Space 架构：
BrowserProcess (单一进程)
  ├── Space: main (你的主标签页 - 用户独占)
  │     └── BrowserContext: main
  ├── Space: agent-task-1 (AI 任务 1)
  │     └── BrowserContext: task-1 (继承自 main 的登录态)
  │           ├── Tab A (github.com - 直接登录，无需重新认证)
  │           └── Tab B (linkedin.com - 直接登录，无需重新认证)
  └── Space: agent-task-2 (AI 任务 2)
        └── BrowserContext: task-2
              └── Tab C (salesforce.com - 直接登录)

关键点：每个 Space 的 BrowserContext 在创建时可以指定是否继承主浏览器的登录态。这使得 AI 代理在打开任何需要认证的页面时，直接获得人类用户在主浏览器中的会话。

7.2 CDP 与 ego-browser 的交互模型

ego-browser 的本质是一个 CDP 桥接层：它将 Node.js 风格的脚本通过 CDP 协议发送到 ego-lite 内部的 Chromium 实例执行，并将结果通过 cliLog 通道返回给 LLM。

LLM Agent (Claude Code / Codex)
    │
    │  ego-browser nodejs <<'EOF'
    │  const space = await useOrCreateTaskSpace(...)
    │  await openOrReuseTab(...)
    │  cliLog(await snapshotText())
    │  EOF
    ▼
ego-browser CLI
    │  (解析 heredoc，注入 helper 函数)
    ▼
CDP WebSocket (localhost:9222 + ego-lite specific endpoint)
    │
    ▼
ego-lite Chromium Process
    │
    ├── Space Manager
    │     └── Space: task-1 (BrowserContext + Tab Tree)
    │
    ├── Snapshot Renderer (语义化 DOM 提取)
    │
    └── CDP Handler (Page.navigate / Runtime.evaluate / ...)

这个架构的精妙之处在于：ego-browser 不需要导入任何 npm 包。所有 helper 函数（openOrReuseTab、snapshotText、click、fillInput 等）在 ego-lite 启动时自动注入到脚本执行上下文中，LLM 写完脚本直接投喂给 CLI 执行。

7.3 与 Playwright/Puppeteer 的架构差异

Playwright 架构：
Browser (独立进程)
  └── Chromium
        └── context (隔离)
              └── page (DOM + JS runtime)

Agent → Playwright SDK → Chromium (独立进程)

问题：Agent 和用户在不同的 Chromium 实例中，登录态不共享

---

ego-lite 架构：
Browser Process (单一进程)
  ├── Main BrowserContext (你的标签页)
  │     └── Tab (你的当前页面)
  │
  └── Space: task-1 (独立 BrowserContext)
        └── Tab (AI 操作的页面，与主 Context 共享登录态)

Agent → ego-browser CLI → CDP → 同一 Browser Process 内
        → Space task-1 BrowserContext (共享登录态)

八、适用场景与局限性

8.1 最佳使用场景

场景 1：需要登录态的批量 Web 操作

CRM 数据批量更新（Jira、Salesforce、HubSpot）
招聘平台自动投递（LinkedIn、Boss 直聘、猎聘）
社交媒体运营（发帖、监控、回复）
电商后台管理（Shopify、亚马逊卖家中心）

场景 2：需要人工监督的自动化流程

AI 帮你填表格，你在旁边实时确认
AI 帮你整理数据，你审核后提交
自动化测试 + 人工验收混合流程

场景 3：多任务并发

同时在多个平台搜索同一信息（价格对比、职位搜索）
同时管理多个账号（多品牌社交媒体矩阵）
同时抓取多个站点的数据进行汇总分析

8.2 当前局限性

局限性 1：macOS 独占
截至 2026 年 7 月，ego-lite 仅支持 macOS。Windows 和 Linux 版本在 Roadmap 上。这意味着：

如果你在 Linux CI 环境中跑自动化，不适用
如果你的团队用 Windows，短期内无法部署
但如果你在 macOS 本地开发，迁移成本为零

局限性 2：登录态迁移的边界
不是所有登录态都能迁移。硬件安全密钥（U2F）、SMS 验证码、二维码认证等强认证机制无法自动迁移。但这些场景本来就需要人类介入，所以影响有限。

局限性 3：复杂交互的支持
对于需要鼠标拖拽（拖放排序、地图缩放）、Canvas 绑定的游戏类页面、复杂 WebGL 场景，CDP 的基础操作可能不够。ego-lite 提供了 click([x, y]) 像素坐标和 captureScreenshot + click 的兜底方案，但精度和稳定性不如 Playwright 的自定义绑定。

九、竞争格局：谁是对手

9.1 直接竞品

browser-use / agent-browser：Python/JS 框架，在 Playwright 之上封装 DOM→LLM 管道。优势是语言无关、框架无关；劣势是继承了 Playwright 的所有问题（登录态、profile 锁、内存开销）。

Anthropic 的 Computer Use：Anthropic 官方出的浏览器自动化工具，基于 Claude 的视觉能力（Vision）。优势是视觉理解强；劣势是需要云端截图上传（隐私风险 + 延迟 + 成本）。

OpenAI 的 Operator：基于 GPT-4o 的浏览器自动化。优势是 OpenAI 品牌效应；劣势是云端执行、数据不上本机。

9.2 ego-lite 的差异化优势

browser-use/agent-browser:  "我们把 Playwright 包装了一下"
Anthropic Computer Use:      "我们用视觉模型理解屏幕"
OpenAI Operator:            "我们做了一个云端浏览器"
ego-lite:                   "我们重新设计了浏览器"

ego-lite 的差异化在于 平台级思考：它不是解决「怎么用 AI 操控浏览器」的问题，而是重新定义「浏览器应该长什么样，才能让 AI 和人类都能用」。

十、展望：从工具到平台

10.1 ego-lite 的野心

从项目的目录结构可以读出更大的野心：

citrolabs/ego-lite/
├── package/ego-browser/        # AI 代理用的浏览器自动化 runtime
├── skills/ego-browser/          # MCP 风格的 agent skill 包
├── .claude-plugin/              # Claude Code 插件
├── .codex-plugin/               # Codex 插件
├── spec/                        # Space 协议规范
└── docs/                        # 完整的开发者文档

这不是一个工具，这是一个 AI 浏览器协议和生态：

ego-browser 是 runtime
.claude-plugin / .codex-plugin 让所有主流 AI 代理直接可用
skills/ego-browser 是 MCP 风格的 skill 规范
spec/ 可能是未来开放 Space 协议的标准草案

10.2 Windows/Linux 版本的战略意义

当 ego-lite 推出 Windows 和 Linux 版本后，它的真正价值才会完全释放：

GitHub Actions CI 中的自动化测试：Windows/Linux CI runner 上跑 ego-lite，执行需要登录态的端到端测试
服务器端 Web 自动化：不需要 headless 浏览器，不需要 Xvfb，在真实 Chromium 中跑自动化
跨平台团队协作：设计师用 macOS、工程师用 Linux、PM 用 Windows，都能接入同一个 ego-lite 工作流

10.3 AI 原生浏览器的未来

ego-lite 让我们看到了一个更大的图景：浏览器作为 AI Agent 的操作系统（OS for AI Agent）。

传统操作系统（Windows/macOS/Linux）是给人类用的：图形界面、窗口管理、文件系统……这些范式在 1980s 设计时完全面向人类感知器官（视觉、触觉）。

当 AI 代理成为另一个重要的「用户」时，浏览器的模型需要根本性重构：

Space = 进程隔离
语义快照 = AI 可读的 DOM 抽象
登录态共享 = 跨代理的会话继承
人机并行 = 同一 UI 的双重操作权限

这是一个还没人完全定义清楚的领域。ego-lite 是目前走得最远的探索者。

结语：重新定义「用浏览器工作」

我第一次读到 ego-lite 的 README 时，印象最深的一句话是：

"No extra setup, and the agent can always reach your real logins and tabs through ego-browser."

这句话轻描淡写，但背后是一个困扰了 AI 浏览器自动化领域三年的核心问题——登录态。

ego-lite 没有发明新技术。它用 Chromium 的 BrowserContext 隔离机制、用 CDP、用 Node.js heredoc 脚本——全部是已有的东西。但它把这些东西组合在一起的方式是全新的：不是「给程序员提供一个控制浏览器的库」，而是「重新设计浏览器，让它天然支持 AI 代理」。

这才是好产品的逻辑：不是用新技术解决问题，而是用新视角重组旧技术。

如果你正在用 Claude Code、Codex 或其他 AI 编程代理，并且你的工作流中有任何需要浏览器操作的环节（社交媒体管理、招聘平台、CRM 操作、数据采集、竞品监控……），花 5 分钟装一下 ego-lite，你会感受到那种「终于有人解决这个痛点了」的快感。

本文相关链接：

GitHub：https://github.com/citrolabs/ego-lite
官网：https://lite.ego.app
文档：https://lite.ego.app/document/
Discord 社区：https://discord.gg/5eGZVvHbTq

复制全文生成海报 AI编程浏览器自动化 ego-lite Chromium Agent Web自动化 CDP