ego lite 深度拆解：让浏览器成为 AI Agent 的「操作系统」——Space 隔离架构、语义快照与 ACP 协议全解

一、背景：AI 浏览器为什么做一款「死」一款

2026 年，AI 浏览器赛道迎来了一轮剧烈的洗牌。

OpenAI 上线 Atlas 不到一年便宣布停止运营，将能力拆分至 ChatGPT 桌面端和 Chrome 扩展。Perplexity Comet 凭借"再也不用回 Chrome"的体验收获大量好评，却因模型可靠性、隐私和权限边界问题持续遭到质疑。用户很快发现，当 AI Agent 开始真正操作浏览器——点击按钮、填写表单、访问登录态页面——很多在 Demo 演示中顺滑无比的场景，在真实工作流里处处碰壁。

问题的根源并不在于模型能力不够强，而在于浏览器这个载体本身的设计假设被彻底颠覆了。

传统浏览器有三个核心假设：页面是内容、窗口属于用户、操作需要人类意图。当 AI Agent 开始进入浏览器，这三条假设全部被打破：

• 页面既是内容，也是指令。恶意页面可能被 AI 误识别为可操作的界面；
• 登录态既是便利，也是风险。Agent 持有用户账号权限后，一次误操作可能比钓鱼攻击更具破坏力；
• 窗口既服务用户，也承载 Agent。两者的标签页、焦点和操作流天然冲突。

主流厂商的解法是"把 Agent 塞进浏览器"——在 Chrome 里内置一个 AI 助手，让它和用户共享同一个窗口。结果可想而知：用户的工作流和 Agent 的操作流相互干扰，用户体验不升反降。

ego lite 选择了完全不同的路线：不是把 Agent 装进浏览器，而是把浏览器改造成所有 Agent 都能调用的基础设施。

这一思路在 GitHub Trending 上得到了验证：ego lite 上线三天狂揽 3000+ Stars，截至 2026 年 7 月底已突破 5300+，登顶 GitHub Trending 周榜。用户留存率超过 70%——在 AI 产品快速出现又快速消失的 2026 年，这个数字说明用户对它的需求不只是尝鲜。

本文将从 Chromium 底层定制讲起，深度拆解 ego lite 的 Space 隔离架构、语义快照（Snapshot）技术、JavaScript 批量执行模型、ACP 开放协议，以及它与 OpenAI Atlas、Perplexity Comet、Vercel agent-browser 等竞品的本质差异。

二、根植 Chromium：从内核改起，而不是在表面套壳

2.1 为什么说"基于 Chromium 定制"不是一句空话

很多浏览器自动化工具都声称"基于 Chromium"，但实际上只是在 Chrome 外面包了一层 Puppeteer 或 Playwright 脚本。本质上是一个自动化框架，并不修改浏览器本身。登录态管理、进程隔离、页面信息提取，每一个环节都要自己从零搭。

ego lite 走得远得多。根据公开资料，ego lite 团队长期深度参与 Chromium 开源社区建设，累计有近 500 个补丁被合并进入 Chromium 主线，很多技术已经随 Chrome 正式发布惠及所有用户。

CSS shape() 取值方案是一个标志性案例。

shape-outside 是 CSS 中用于实现文字环绕的规范，自 2014 年纳入以来，11 年间只支持圆形、椭圆和多边形等 5 种基础形态。开发者想实现贝塞尔曲线等不规则文字绕排，只能用几十个顶点手动模拟，开发成本极高，效果也不自然。

ego lite 团队推动的 shape() 取值方案，将 CSS 文字环绕从固定几何形态中解放出来。现在开发者只需一行 CSS，即可沿任意曲线完成文本环绕：

/* 传统方案：手动模拟不规则形状，需要几十个顶点 */
.element {
  clip-path: polygon(
    0% 0%, 15% 5%, 30% 2%, 45% 8%, 60% 3%,
    75% 6%, 90% 1%, 100% 4%, 100% 100%, 0% 100%
  );
}

/* ego lite 团队推动的 shape() 方案：一条曲线搞定 */
.element {
  shape-outside: shape(curve: nonzero, path: "M0,0 C30,5 60,3 100,4 L100,100 L0,100 Z");
  float: left;
}

该方案已随 Chrome 149 正式全量上线，并入选 Google I/O 2026 官方技术亮点。

Mac 窗口动画优化是另一个例子。

Mac 用户长期面临一个细微但持续感知的体验问题：缩放窗口或切换标签页时，动画帧率无法稳定跟上屏幕刷新率，操作过程中会产生不易描述但能持续感知的"滞涩"。ego lite 团队客户端负责人对 Chrome 的渲染调度逻辑进行了系统性优化，累计提交 300 多项底层改动，这些优化最终都进入了 Chrome 主线——即使你没有使用 ego lite，更新到最新版本的 Chrome 也能感受到更顺滑的窗口缩放与标签页切换体验。

这种"上游共建"的开发模式意味着 ego lite 不是在 Chromium 外面打补丁，而是从内部重塑浏览器的架构，为 Agent 工作流从底层扫清障碍。

2.2 与传统自动化框架的本质差异

传统方案中，每启动一个自动化任务都需要新建完整的浏览器实例，并复制用户配置文件。10 个并发任务意味着 10 个浏览器进程同时运行——内存和 CPU 占用急剧飙升，设备很容易卡顿。ego lite 的多 Space 共享同一个 Chromium 内核，只做逻辑隔离，整体资源开销被压低到接近单实例水平。

三、Space 隔离架构：人与 Agent 的「平行宇宙」

3.1 核心设计哲学

ego lite 最核心的设计理念可以用一句话概括：让人和 Agent 共享同一个浏览器，但各自在独立的空间里工作，互不干扰。

用户打开 ego lite 后，浏览器主界面与 Chrome 高度一致，用户的标签页、书签、浏览历史完全保留。Agent 则在后台独立的 Space 中运行网页任务。

┌─────────────────────────────────────────────────────────┐
│                    ego lite 浏览器                       │
│  ┌─────────────────────────┐  ┌──────────────────────┐ │
│  │   用户主空间 (User Space) │  │  Agent Space #1      │ │
│  │   标签页、浏览历史        │  │  GitHub Trending     │ │
│  │   Cookie/登录态          │  │  Cookie/登录态        │ │
│  ② 正在访问: GitHub         │  │  执行: 数据采集       │ │
│  ① 正在访问: Twitter        │  │                      │ │
│  └─────────────────────────┘  │  Agent Space #2      │ │
│                                 │  X 博主粉丝分析       │ │
│  ┌─ Agent 任务状态 ────────┐ │  Cookie/登录态        │ │
│  │  Space #1: 运行中        │ │  执行: 页面遍历       │ │
│  │  Space #2: 运行中        │ └──────────────────────┘ │
│  └─────────────────────────┘                           │
└─────────────────────────────────────────────────────────┘

两套空间完全并行，用户感知不到 Agent 的存在，Agent 也感知不到用户在做什么。这种"平行宇宙"式的设计是 ego lite 与所有"把 Agent 塞进用户窗口"方案的根本区别。

3.2 Space 的实现机制

每个 Space 在逻辑上是一个完整的浏览器上下文，包含：

• 独立的页面状态：加载的 URL、DOM 树、JavaScript 执行上下文
• 独立的数据存储：LocalStorage、SessionStorage、IndexedDB 分区
• 独立的 Cookie/Permission 域：不同 Space 可以使用不同的登录态
• 独立的焦点管理：Agent 在 Space #1 中操作的页面不会抢走用户当前窗口的焦点

底层实现上，多个 Space 共享同一个 Chromium 渲染进程，但通过 Chromium 的 Site Isolation 机制做安全隔离：

// ego-browser skill 的 Space 分配逻辑（概念代码）
class EgoSpace {
  constructor(config) {
    // 每个 Space 对应一个 BrowserContext
    // Chromium BrowserContext 是进程内隔离单元
    this.context = browser.newContext({
      // 独立存储分区，不同 Space 之间数据不互通
      storageState: config.storageState || 'default',
      // 权限隔离：Space #1 的地理位置权限不会泄露给 Space #2
      permissions: config.permissions || [],
      // 独立视口配置
      viewport: config.viewport || { width: 1280, height: 800 },
    });
  }
  
  // Space 之间的通信只能通过 ego lite 的 IPC 桥接
  async sendToAgent(message) {
    return await this.ipcBridge.send('agent:message', message);
  }
}

Space 之间的数据隔离由 Chromium 的 Partitioned Cookie 和 Storage Partitioning 机制保证——这是浏览器为对抗跨站追踪而设计的安全特性，ego lite 将其"征用"为多任务隔离的基础设施。

3.3 Profile 迁移：零摩擦的起点

首次启动 ego lite 时，系统会自动引导用户迁移 Chrome 的以下数据：

• 书签：完整导入
• 扩展程序：可选择迁移哪些扩展
• 浏览偏好：主题、字体、语言等设置
• 登录态（Cookie）：各网站的会话信息直接复用

这意味着 Agent 进入新建的 Space 后，可以直接访问用户已经登录的 GitHub、X（Twitter）、小红书等网站，无需重新输入账号密码或完成二次验证。

// 登录态迁移的核心逻辑（概念代码）
async function migrateLoginState() {
  // 读取 Chrome 的 Cookie 数据库（SQLite）
  const chromeCookiesPath = path.join(
    process.env.HOME, 
    'Library/Application Support/Google/Chrome/Default/Cookies'
  );
  
  // ego lite 读取 Cookie 并注入到每个新 Space 的 BrowserContext
  const cookies = await readChromeCookies(chromeCookiesPath);
  
  for (const space of spaces) {
    await space.context.addCookies(cookies);
  }
}

当然，能使用用户登录态也意味着权限较高。ego lite 官方建议初次使用时先用独立 Profile 测试，涉及付款、删除、发布等敏感操作，保留人工确认步骤。

四、Snapshot 语义快照：浏览器内核级别的 Token 压缩

4.1 传统方案的 Token 黑洞

这是当前 AI 浏览器自动化中最容易被忽视、但消耗最大的问题。

大多数 AI 浏览器工具采用两种方式向 Agent 提供页面信息：

方案 A：完整 HTML 传输

// Puppeteer/Playwright 的默认做法
const html = await page.content();
// html 可能是 200KB~2MB 的原始 HTML
// 对于复杂页面（如电商后台），轻松超过 100 万字符
// 转换为 Token 后：约 15 万 ~ 75 万 Token
// 按 GPT-4o $5/1M Token 计算：每次页面提取 $0.75~$3.75

方案 B：截图 + OCR/VLM

// 截图方式
const screenshot = await page.screenshot({ type: 'png' });
// 1080p 截图约 500KB~2MB
// VLM 识别后又需要大量 Token 描述页面
// 元素定位还不准确，经常"点错位置"

两种方案都存在根本性问题：HTML 信息密度极低（大量 CSS 类名、内联样式、空白符），而 Agent 真正需要的是"页面结构"——哪里是可交互按钮、哪里是输入框、哪些链接可以点击。

4.2 Snapshot 的实现原理

ego lite 的 Snapshot 机制从 Chromium 内核层面直接提取页面的语义结构信息，不依赖完整 HTML，不依赖截图。

实现路径是在 Chromium 的 Accessibility Tree 基础上构建了一层语义抽象：

// Snapshot 的核心提取逻辑（概念代码）
class SemanticSnapshot {
  async extract(page) {
    // Chromium Accessibility Tree：浏览器的无障碍辅助树
    // 每个 DOM 节点都有 role、name、value、state 等语义属性
    const axTree = await page.accessibility.snapshot();
    
    // 第一步：构建可交互元素的语义图
    const interactiveElements = this.buildInteractiveGraph(axTree);
    // {
    //   "btn-submit": { role: "button", name: "提交订单", 
    //                   bounds: [120, 340, 200, 380], 
    //                   state: { enabled: true, visible: true } },
    //   "input-search": { role: "textbox", name: "搜索商品",
    //                     bounds: [50, 80, 350, 120],
    //                     state: { editable: true, focused: false } },
    //   "nav-home": { role: "link", name: "首页",
    //                  bounds: [20, 10, 80, 40],
    //                  href: "/home" },
    //   ...
    // }
    
    // 第二步：识别复杂组件（虚拟列表、Shadow DOM、跨域 iframe）
    const complexComponents = this.detectComplexComponents(axTree);
    
    // 第三步：生成结构化文本描述
    return this.generateStructuredDescription(interactiveElements, complexComponents);
  }
  
  // 虚拟列表处理：小红书帖子列表等动态加载场景
  detectVirtualList(node) {
    if (node.role === 'list' && node.children.length < node['aria-itemcount']) {
      // 检测到虚拟列表：实际渲染数量 < 声明总数
      return {
        type: 'virtual-list',
        totalItems: node['aria-itemcount'],
        renderedItems: node.children.length,
        strategy: 'scroll-and-accumulate'
      };
    }
  }
}

Snapshot 的输出不是 HTML 片段，而是一份结构化的语义说明：

{
  "page_title": "GitHub Trending",
  "interactions": [
    { "type": "button", "label": "Language: All", "id": "lang-filter", "action": "click" },
    { "type": "link", "label": "facebook/react", "href": "/facebook/react", "action": "navigate" },
    { "type": "input", "label": "Search GitHub", "placeholder": "Type / to search", "action": "type" }
  ],
  "complex_components": [
    { "type": "infinite-scroll", "strategy": "load-more", "detected": true }
  ],
  "token_estimate": "~800 tokens"  // vs 完整 HTML 可能 50,000+ tokens
}

4.3 深度覆盖能力：解决传统方案的"抓瞎"问题

Snapshot 对传统自动化方案头疼的场景有天然优势：

Shadow DOM 穿透：Web Components 的 Shadow DOM 传统方案很难直接抓到里面的内容，Snapshot 可以深入访问 shadowRoot 内的 Accessibility Tree。

跨域 iframe：嵌套的第三方 SDK（如嵌入的 YouTube 视频、支付组件）通常在独立域的 iframe 中，Playwright/Puppeteer 需要额外处理 cross-origin 边界。Snapshot 借助 Chromium 内核权限，可以跨域提取语义信息。

虚拟列表：小红书的帖子列表是典型的虚拟滚动——往下翻页时，上面的内容从 DOM 中移除。Snapshot 内置了"滚动+累积"策略：识别到虚拟列表后，自动执行分批滚动，将所有数据收集齐全：

// 虚拟列表的 Snapshot 采集逻辑
async function collectVirtualList(page, listSelector) {
  let allItems = [];
  let previousCount = 0;
  
  while (true) {
    const snapshot = await page.semanticSnapshot(listSelector);
    const currentItems = snapshot.items;
    
    allItems = [...allItems, ...currentItems];
    
    if (allItems.length === previousCount) {
      // 列表已加载完毕，不再有新内容
      break;
    }
    
    previousCount = allItems.length;
    // 触发下一批加载
    await page.evaluate(() => {
      const list = document.querySelector('[data-virtual-list]');
      list.scrollTop = list.scrollHeight;
    });
    
    await page.waitForTimeout(500); // 等待异步渲染
  }
  
  return allItems; // 最终收集了小红书全部 251 篇帖子
}

五、JavaScript 批量执行：告别"一问一答"式的 Token 消耗

5.1 传统方案的交互效率问题

大多数 AI 浏览器工具的工作模式是：

Agent → "点击登录按钮" → 等待结果 → "输入用户名" → 等待结果 → 
"输入密码" → 等待结果 → "点击提交" → 等待结果 → "验证是否成功"

每一步都是一个完整的 HTTP 请求/响应周期，加上 Agent 的推理时间，多步骤任务的 Token 消耗和延迟成线性叠加。复杂任务轻松超过 1520 轮交互，每次往返 515 秒，累计延迟可能超过 5 分钟。

5.2 ego-browser 的 JavaScript 批处理模型

ego lite 支持 Agent 通过一段 JavaScript 脚本，统一编排连续的网页操作，多项交互动作一次下发执行：

// ego-browser skill 的 JavaScript 批量执行（概念代码）
async function executeAgentScript(script, spaceContext) {
  // Agent 生成一段 JavaScript 脚本，描述完整任务流程
  // ego lite 在 Space 内的 Chromium 上下文中执行这段脚本
  const result = await spaceContext.evaluate(script);
  return result;
}

// Agent 生成的脚本示例：批量采集 GitHub Trending
const script = `
(async () => {
  const results = [];
  
  // 1. 导航到 Trending 页面
  await navigateTo('https://github.com/trending');
  
  // 2. 滚动加载完整列表
  await scrollToBottom();
  
  // 3. 采集所有项目卡片
  const repos = await scrapeList('article.Box-row', {
    name: '.h3 a',
    description: '.col-9',
    stars: '.Link--muted',
    language: '[itemprop="programmingLanguage"]',
  });
  
  // 4. 逐个进入详情页采集更多信息
  for (const repo of repos.slice(0, 10)) {
    await openInNewTab(repo.url);
    await waitForLoad();
    
    repo.issues = await scrapeValue('.State--open');
    repo.lastCommit = await scrapeValue('time');
    repo.contributors = await scrapeValue('[href*="contributors"]');
    
    await closeCurrentTab();
  }
  
  // 5. 生成结构化报告
  return generateReport(repos);
})();
`;

这种方式的效果：在一次 evaluate() 调用中完成导航→滚动→采集→翻页→汇总的全部流程，不需要 10~15 轮往返，Agent 与浏览器之间的交互轮次从线性叠加变为常数级别。

实测数据：与 Vercel agent-browser 对比，复杂任务的端到端速度提升 2.6 倍；与 Claude Code 的 Claude-in-Chrome 对比，ego-browser 快 27 秒；与 Codex 的 Control-Chrome 对比，快 2.4 倍。

5.3 与 MCP 工具的本质对比

MCP（Model Context Protocol）是 2026 年 AI Agent 工具调用的事实标准。很多浏览器自动化 MCP（Playwright、Puppeteer）本质上还是"每步一问一答"的模式。

ego-browser 的 JavaScript 批量执行相当于在 MCP 之上增加了一个脚本执行层：Agent 不是调用单个"click"工具，而是生成一段完整的任务脚本，浏览器一次性执行。这种设计对于需要步骤依赖的任务特别有效——第 3 步依赖第 1 步的结果，第 5 步依赖第 3 步的结果，脚本内顺序执行天然保证了依赖关系，无需 Agent 反复推理下一步该做什么。

六、ACP 开放协议：不做 Agent 的"看门人"

6.1 为什么开放协议至关重要

大多数 AI 浏览器工具采用"绑定 Agent"策略：要么是某家公司的专属 Chrome 扩展，要么只能在某个特定的 Agent 框架里使用。这种策略的问题在于：

• 用户被锁定：一旦选择了一个 Agent 浏览器，就只能用它的生态里支持的 Agent
• 数据主权缺失：浏览记录、工作流、登录态全部掌握在浏览器厂商手中
• 生态封闭：新出现的 Agent 框架无法接入，用户只能等待官方适配

ego lite 的应对是 ACP（Agent Communication Protocol）开放协议：任何遵循 ACP 的 Agent 框架都可以接入 ego lite，无需 ego lite 官方逐个适配。

6.2 ACP 协议的设计要点

ACP 协议的核心是定义一套标准化的 Agent ↔ Browser 通信接口：

// ACP 协议的核心接口定义（简化概念）
interface ACPSpace {
  // Space 生命周期管理
  create(config: SpaceConfig): SpaceHandle;
  destroy(handle: SpaceHandle): void;
  
  // 页面操作
  navigate(url: string): Promise<NavigationResult>;
  snapshot(): Promise<SemanticSnapshot>;
  execute(script: string): Promise<ScriptResult>;
  
  // 元素操作
  click(selector: string): Promise<void>;
  type(selector: string, text: string): Promise<void>;
  waitForSelector(selector: string, timeout?: number): Promise<void>;
  
  // 文件/下载管理
  uploadFile(input: FileInput, target: string): Promise<void>;
  downloadFile(url: string, path: string): Promise<void>;
  
  // 状态事件
  on(event: 'download-started' | 'auth-required', handler: EventHandler): void;
}

// SpaceConfig 定义
interface SpaceConfig {
  storageState?: 'inherit' | 'fresh' | string; // 继承/新建/指定 Profile
  permissions?: string[];  // ['geolocation', 'notifications']
  viewport?: { width: number; height: number };
  userAgent?: string;
}

任何 Agent 框架只要实现了这套接口，就能接入 ego lite。目前已支持零配置自动发现：安装完 ego lite 后，系统会自动扫描本机环境，将 /ego-browser 能力注入已安装的代码智能体。

Claude Code、Codex、Workbuddy 和 Cursor 等主流工具开箱即用，不需要任何额外配置。

6.3 可复用 Skills：跨任务的记忆

ego lite 的路线图还包括"可复用 Skills"机制——让 Agent 积累跨任务的执行经验，而不只是每次从零开始。

当 Agent 在 Space 中完成一个任务后，关键的操作步骤、页面选择策略、数据提取模式可以被抽象为可复用的 Skill：

// Skills 的抽象机制（概念代码）
class EgoSkill {
  constructor(name, trigger, steps) {
    this.name = name;           // "github-trending-collector"
    this.trigger = trigger;     // { domain: 'github.com', path: '/trending' }
    this.steps = steps;         // 抽象的操作步骤模板
  }
  
  // 当 Agent 访问 github.com/trending 时，自动触发此 Skill
  async match(context) {
    return this.trigger.domain === context.domain && 
           this.pathPattern.test(context.path);
  }
  
  // Skill 执行时，Agent 只需填充变量（日期范围、语言筛选等）
  async execute(params) {
    return this.steps.fill(params).run();
  }
}

这与 OpenClaw 的 Skills 机制高度一致——Skills 是 Agent 能力的原子化模块，ego lite 的可复用 Skills 则让浏览器操作经验得以跨 Agent 复用。

七、实战案例：从批量采集到跨境电商

7.1 案例一：GitHub Trending 自动化日报

需求：每天自动采集 GitHub Trending，按语言分类，生成 Markdown 格式的开发者日报。

// GitHub Trending 日报采集脚本
async function generateGitHubDailyReport() {
  const report = { date: new Date().toISOString().split('T')[0], projects: {} };
  const languages = ['All', 'Python', 'JavaScript', 'Rust', 'Go', 'TypeScript'];
  
  for (const lang of languages) {
    // 构建带语言筛选的 URL
    const url = lang === 'All' 
      ? 'https://github.com/trending'
      : `https://github.com/trending?since=weekly&l=${lang.toLowerCase()}`;
    
    // ego-browser 在 Space 中执行导航
    await navigateTo(url);
    
    // 采集项目列表
    const projects = await scrapeList('article.Box-row', {
      rank: { selector: '.rank', transform: (el) => parseInt(el.textContent) },
      name: { selector: 'h2 a', transform: (el) => el.textContent.trim() },
      description: { selector: '.col-9', transform: (el) => el.textContent.trim() },
      stars: { selector: '[href*="/stargazers"]', transform: (el) => parseStars(el.textContent) },
      todayStars: { selector: '.float-sm-right', transform: (el) => parseStars(el.textContent) },
      language: { selector: '[itemprop="programmingLanguage"]', transform: (el) => el.textContent },
    });
    
    report.projects[lang] = projects;
  }
  
  return markdownReport(report);
}

实际执行结果：任务从下发指令到生成完整 Markdown 报告，全程无需人工介入。ego-browser 自动处理了多语言切换、页面加载等待、数据提取和格式化。

7.2 案例二：X（Twitter）博主粉丝批量分析

需求：获取 X 上关注的博主列表，采集每个人的粉丝数和关注数，生成 CSV 报告。

// X 博主数据采集
async function analyzeXFollowing() {
  await navigateTo('https://x.com/following');
  
  // X Following 页面是虚拟列表，需要持续滚动加载
  let lastCount = 0;
  let following = [];
  
  while (true) {
    const users = await scrapeList('[data-testid="UserCell"]', {
      name: '[data-testid="UserName"]',
      handle: '[data-testid="UserHandle"]',
      // 粉丝数需要进入个人页面采集
    });
    
    if (users.length === lastCount) break;
    lastCount = users.length;
    
    // 触发虚拟列表下一批加载
    await scrollToBottom();
    await waitForTimeout(1000);
  }
  
  // 对每个用户进入详情页采集粉丝数
  const enrichedData = [];
  for (const user of following.slice(0, 50)) {
    await navigateTo(`https://x.com/${user.handle}`);
    await waitForSelector('[data-testid="追随者"]');
    
    const followers = await scrapeText('[data-testid="追随者"]');
    enrichedData.push({ ...user, followers });
  }
  
  return generateCSV(enrichedData);
}

采集完成后验证准确率：Sam Altman（565 万粉丝）、Elon Musk（2.41 亿粉丝）、Anphic（155 万粉丝）——与 X 官网数据完全吻合。

7.3 案例三：小红书种草内容批量采集

小红书是出了名的"Agent 地狱"：不登录看不到搜索结果、页面大量动态加载、内容结构复杂。很多传统自动化方案一到小红书就"趴窝"。

ego lite 的处理方式：

// 小红书复杂页面采集
async function collectXiaohongshu(topic) {
  // 1. 导航到搜索页（Cookie 迁移后已登录，跳过登录流程）
  await navigateTo(`https://www.xiaohongshu.com/search_result?keyword=${topic}`);
  
  // 2. 处理登录弹窗（实际上是已登录状态，关掉弹窗即可）
  await dismissIfVisible('.login-modal');
  
  // 3. 虚拟列表滚动采集（采集完整帖子列表）
  const posts = await collectVirtualList('.note-item', {
    title: '.title',
    likes: '.like-wrapper',
    collects: '.collect-wrapper',
    comments: '.comment-wrapper',
  });
  
  // 4. 逐个进入帖子详情采集完整数据
  for (const post of posts.slice(0, 10)) {
    await click(post.link);
    await waitForSelector('.detail-content');
    
    post.content = await scrapeText('.detail-content');
    post.authorFollowers = await scrapeText('.author-followers');
    post.publishTime = await scrapeText('.publish-time');
  }
  
  return posts;
}

实测采集到完整列表共 251 篇帖子，对每篇帖子的点赞、收藏、评论数据进行了逐一采集。数据准确性经过手动抽查验证，无明显偏差。

小红书的反爬机制（验证码、多层验证）对 ego lite 几乎无效——因为它使用的是真实的浏览器操作，而不是爬虫请求。

八、性能对比与工程量化

8.1 Token 消耗对比

Snapshot 将页面信息提取的 Token 消耗压缩了 15~60 倍，这是 AI 浏览器自动化进入生产级别的关键——当单次任务成本从几美元降到几美分，大规模自动化才真正可行。

8.2 端到端速度对比

JavaScript 批量执行减少交互轮次是关键加速因素：从 1015 轮 Agent ↔ Browser 往返，压缩到 23 轮。

8.3 资源占用对比（10 并发任务）

共享内核设计将资源开销降低到原来的 1/4，这是 ego lite 能在普通 MacBook 上稳定运行 10+ 并发 Agent 任务的工程基础。

九、能力边界与局限性

9.1 当前局限

平台覆盖：目前仅支持 macOS，Windows 和 Linux 版本在规划中。这对于以 Linux 服务器为主要工作环境的开发者群体是一个显著限制。

早期阶段：截至 2026 年 7 月底，ego lite 仍处于非常早期的阶段。虽然 Core 功能已经可用，但在错误处理、超时恢复、复杂页面适配等方面仍有大量优化空间。

权限风险：登录态自动迁移是一把双刃剑——它让 Agent 可以直接操作用户账号，也让权限边界变得模糊。涉及付款、删除、发布等操作时，建议保留人工确认步骤。

可扩展性：ACP 协议目前支持的 Agent 框架数量有限，虽然已经覆盖主流工具，但随着 AI Agent 生态的快速演化，需要持续跟进新框架的接入。

9.2 与竞品的定位差异

ego lite 与其说是"另一个 AI 浏览器"，不如说是浏览器领域的 Android——定义了一套开放的 Agent 交互协议，让所有 Agent 框架都可以在其上运行，而不是试图建立自己的 Agent 生态围墙。

十、总结与展望

10.1 ego lite 解决的核心问题

1. 架构层：从"把 Agent 塞进浏览器"到"把浏览器改造为 Agent 基础设施"，用 Space 隔离实现人与 Agent 的真正并行
2. Token 层：Snapshot 语义快照将页面信息提取的 Token 消耗压缩 15~60 倍，让 AI 浏览器自动化进入生产级成本区间
3. 效率层：JavaScript 批量执行将多步骤任务的交互轮次从线性叠加降为常数级别，速度提升 2.6 倍
4. 生态层：ACP 开放协议让 ego lite 不做 Agent 的"看门人"，任何 Agent 框架都可以接入，用户自由选择权在自己手中

10.2 未来路线图

根据公开路线图，ego lite 接下来将重点推进三类能力：

• 可复用 Skills：跨任务保留 Agent 的操作经验，实现浏览器操作能力的渐进积累
• 开放 ACP 协议：允许更多 Agent 框架接入，包括对 Electron 和原生应用的支持，将 Agent 的操作范围从浏览器页面延伸到桌面软件
• 跨平台支持：Windows 和 Linux 版本已经在规划中，预计 2026 年内发布

10.3 一个更宏观的命题

ego lite 试图回答的是一个更根本的问题：当 Agent 持续进入日常工作，浏览器会如何演变为人和 Agent 共同使用的工作界面？

历史上，浏览器的每次重大演进都伴随着计算范式的转移：从静态 HTML 到 AJAX 动态交互，从桌面到移动互联网，每一步浏览器都在重新定义"用户"的含义。而 AI Agent 的到来，第一次让浏览器的使用者从人类扩展到了 AI——这不是一次 UI 改版，而是一次计算主体的范式转移。

ego lite 的赌注是：浏览器不会消失，但它服务的主角将从单一的人类用户，变为"人类 + Agent"的双主角模式。在这种模式下，最重要的不是给浏览器塞一个 AI 助手，而是重新设计浏览器的基础设施层，让两个主角都能高效地使用同一个入口。

这条路是否正确，70% 的用户留存率或许已经给出了初步答案。