EgoLite Agent浏览器发布：为AI智能体打造底层浏览工作台

刚还在借助 Agent 收发邮件，此刻已经让 Agent 驱动浏览器主动采集信息——AI 的边界，又一次被拓宽了。

1

最近我在深度体验一款名叫 Ego Lite 的浏览器工具。这款浏览器，是专为 Agent 准备的。例如，我在 Agent 工具 Codex 里发出这样的指令：

@ego lite 看下 mowen.cn 里，首页“正在关注”中有哪些更新，取前二十条，包括作者、文章名称（附链接）与文章摘要。

在此过程中，Ego Lite 的人机界面纹丝不动，Agent 也不会像在传统方案中那样弹出新的浏览器窗口——比如 Codex 直接驱动 Chrome，在你的窗口上点来点去翻找内容。Agent 只在背后安静工作，最后把结果输出给你。这，就是 Agent Browser。

2

此前我推荐和使用过的 AI 浏览器（Dia、Tabbit 等），是把大模型植入浏览器，经过大量工程化适配，让用户在阅读、查找、翻译、重构页面、总结和写作时，能快速与 AI 协同。这类浏览器确实好用，但它们是为人类设计的。

Ego Lite 实则是给 Agent 用的——当然人类也能操作，这一点与我们之前介绍过的 QQ 邮箱团队出品的 Agent Mail 如出一辙。Agent Mail 更为激进，甚至移除了人类操作入口，只能由 Agent 来执行邮件任务。

让 Agent 打开浏览器，过去的方案基本是 Computer Use：操作电脑打开浏览器，完成打开网页、滚动、点击、复制、整理等步骤。Agent 要解决的是保持登录态、看懂页面结构、准确点击按钮，必要时还要从页面脚本里抓取真实数据接口。Ego Lite 的做法并非让 Agent “看”网页，它更像一个坐在浏览器背后的程序员。页面只是入口，DOM、网络请求、前端 bundle、返回的 json、并行任务……这些才是 Agent 真正要处理的对象。也就是说，浏览器本身成为了 Agent 的工作台。

3

这个方向颇有深意。和人不同，Agent 需要的是浏览器更底层的能力。它不仅要会读页面，还要稳定地控制页面，不干扰用户已有的窗口，在需要时继承登录态，又能在自己的隔离空间里完成任务。

Ego Lite 是一个基于 Chromium 的浏览器，实现方式依然是 CLI 加上 Skills。安装 Ego Lite 时，系统会自动为 Agent 暴露一套 CLI 可访问的 Node.js 运行时环境。Agent 通过 ego-browser nodejs 执行脚本，脚本里预置了 snapshotText、click、js、cdp、browserFetch、captureScreenshot 等帮助函数。也就是说，Agent 在用脚本驱动一个真实浏览器：打开页面、等待加载、读取页面状态、抓取语义快照、点击元素，再检验结果。

Ego Lite 有一个很关键的概念叫 task space，它是专为 Agent 准备的隔离浏览上下文。每个 task space 拥有自己的标签页，同时默认继承用户当前的登录信息。这个设计非常精妙：Agent 可以进入需要登录的网站做事，但不会直接和用户正在操作的浏览器窗口争夺控制权。同一项任务如果需要分几轮完成，也可以复用同一个 task space，避免每次都从零开始。

因此，Ego Lite 和当前所有的 AI 浏览器都不一样——它能像普通 Chrome 一样正常使用：

然而，Ego 在浏览器旁边为 Agent 构建了一套可调用的操作层：创建 task space，打开或复用标签页，读取 pageInfo，获取语义快照，点击元素，执行 JavaScript，必要时截图验证，最后关闭任务空间，任务完成。

再比如，我还能这样做：看下 CatReader 里最新更新的 20 篇文章，附上链接和摘要。

墨问的 CatReader，首页并没有直接列出最新 20 篇文章，仅展示分类、文章总数、AskCat 入口和阅读面板等。传统做法可能是靠肉眼寻找列表，或者在页面中反复点击试探。Agent 的路径更像在调试一个真实 Web 应用：先观察页面，再探测接口，发现同域 /api/articles 返回的是前端 HTML，于是进一步读取前端 bundle，找到真正的 API base 与文章接口形态。

许多网页对人而言是“可见”的，对 Agent 却不一定“可用”。人可以一眼看到右上角的按钮，Agent 却需要知道这个按钮有没有可访问名称、是不是自定义 div、点击后状态是否改变。人可以凭经验判断一个列表按时间排序，Agent 则需要拿到返回字段，确认 publishedAt、fetchedAt、feedTitle 和 link。

Ego Lite 为此准备了三条执行路径。普通网页优先走语义工作流，用 snapshotText() 抓取页面文本、按钮、链接和可点击引用，再用 click 或 fillInput 操作。遇到富文本、表格、地图、白板这类 DOM 与真实界面不完全同步的页面，则退到视觉工作流，借助截图、坐标和键盘动作验证。当需要读取页面内部状态、查询 DOM 或调用浏览器协议时，再启用 js() 和 cdp()。

js() 这一点尤其有意思。它本质上接近 Chrome DevTools Protocol 里的 Runtime.evaluate，是在浏览器页面上文直接执行代码。所以刚才查询 CatReader 时，Agent 会先读页面脚本，再从前端 bundle 里找到真实 API base，最后利用浏览器上下文请求文章接口——它能直接理解页面结构与前端状态。

4

Agent 浏览器最大的价值，在于让 Agent 拥有了一个可持续工作的前台环境。很多任务都卡在：邮箱需要登录，内部系统存在权限限制，网页采用动态加载，数据深藏在前端状态中，普通的 HTTP 请求什么也拿不到。过去 Agent 要么让人手动复制粘贴，要么写脚本绕路，要么干脆直接操作浏览器。

Agent 浏览器则既能像人类一样打开页面，又能像工程师一样检查页面。它拥有隔离的 task space，不必抢占用户当前窗口；可以复用用户登录态，却将控制权与日常浏览分离开；还能在需要人工介入时交接控制权，等待确认后再继续执行。

这类浏览器也重新定义了“验证”的含义。以前让 AI 写下结论，验证大多依赖模型自检或人工复核。如今 Agent 可以打开真实网页，执行真实操作，读取真实返回，再将结果整理出来。它能发现页面上“广场”按钮并非普通文本节点，也能觉察某个 API 路径实际返回 HTML。模型的判断开始被浏览器现场校准，这比空想可靠得多。

对 Vibe Coding 同样大有助益。如果是 Web 应用，直接让 Ego Lite 理解功能验收成果，更快、更准、更方便。

5

普通用户对 Agent 浏览器的感知或许不会很强。对大众而言，AI 浏览器更具吸引力——它能读取浏览器上下文、直接给出解决方案，还能借助大模型重塑界面、辅助写作，完全是全新的功能体验。而 Agent 浏览器更像基础设施，它的价值隐现在长任务里：查资料、做任务、验证页面、整理数据、测试产品、排查问题等。

它为浏览器提出了另一种默认设定：通过 Agent 和 Skills 理解页面、读取状态与上下文、保障安全，而且不打扰用户。

AI 浏览器解决的是人和信息之间的距离。Agent 浏览器解决的是任务和执行环境之间的距离。前者让网页更容易被理解，后者让网页更容易被操作。如此看来，两者相辅相成，互为补充，颇为奇妙。

似乎，所有的工具，都值得为 Agent 重新再做一遍。