给 Agent 用的浏览器 Ego Lite 来了 ！

刚刚还在用 Agent 处理邮件 Mail，现在我又用 Agent 驱动浏览器获取信息了。

1

最近我在使用的一款浏览器工具叫做 Ego Lite。这款浏览器，是给 Agent 准备的。比如我在 Agent 工具（Codex）里说，

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

在此期间，Ego Lite 的人机交互界面不受任何影响，Agent 也不会打开新的浏览器界面——比如 Codex 操作 Chrome 那样，在你的浏览器里点来点去翻找内容——Agent 只是默默干活，然后给你最终结果。

这叫 Agent Browser。

2

之前我推荐和使用过的 AI 浏览器（Dia、Tabbit 等），是在浏览器里植入大模型，然后做大量的工程工作，让用户可以在阅读、查找、翻译、重构页面、总结和写作的时候，快速使用大模型和我们一起协作。这种浏览器当然很好用，并且是给人类使用的。

Ego Lite 其实是给 Agent 用的，当然人类也能用，这一点和我们之前介绍过的 QQ 邮箱团队出品的 Agent Mail 如出一辙。Agent Mail 更加超前，甚至没有人们操作的入口，只能用 Agent 操作邮件。

让 Agent 打开浏览器，以前的方案基本是 Computer Use，操作电脑打开浏览器，打开网页、滚动、点击、复制、整理等等。Agent 要做什么呢？保持登录态，看懂页面结构，能点击正确的按钮，必要时还得从页面脚本里找到真实数据接口。

Ego Lite 的做法不是在浏览器里“看网页”，它更像一个程序员坐在浏览器后面干活。页面只是入口，DOM、网络请求、前端 bundle、返回的 json、并行任务……这些才是 Agent 真正要处理的内容。

也就是说，浏览器本身成为了 Agent 的工作台。

3

这个方向就很有意思了。和人不一样，对于浏览器，Agent 需要的是更底层的东西。它不只要读页面，还要稳定地控制页面，不打扰用户已有窗口，必要时继承登录态，又能在自己的隔离空间里完成任务。

Ego Lite 是一个基于 Chromium 的浏览器，怎么做到给 Agent 用呢，还是老方法：CLI 和 Skills。

当我们安装 Ego Lite 的时候，系统会自动为 Agent 暴露一套 CLI 可访问的 Node.js 运行时环境。Agent 通过ego-browser nodejs执行脚本，脚本里预置了snapshotText、click、js、cdp、browserFetch、captureScreenshot等 helper。也就是说，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 时，它会先读页面脚本，再从前端 bundle 里找到真实 API base，最后用浏览器上下文请求文章接口，它能直接理解页面结构和前端状态。

4

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

Agent 浏览器呢，既可以像人类一样打开页面，也可以像工程师一样检查页面。它有自己的隔离任务空间，不必抢用户正在使用的窗口；它可以复用用户登录态，又不把控制权和日常浏览混在一起；它还能在需要人工介入时交还控制权，等用户确认后继续工作。

这类浏览器也改变了“验证” 的含义。以前让 AI 写一段结论，验证大多靠模型自我检查，或者靠人再看一遍。现在 Agent 可以打开真实网页，执行真实操作，读取真实返回，再把结果整理出来。它可以发现页面上“广场” 按钮不是普通文本节点，也可以发现某个 API 路径实际返回 HTML。模型的判断开始被浏览器现场校准，这比空想可靠得多。

对于 Vibe Coding 也有很大的帮助，如果是 Web 应用，直接让 Ego Lite 理解功能验收成果，更加快捷、准确和方便。

5

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

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

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

看起来，所有的工具，都需要为 Agent 再做一遍。

文章来自于微信公众号 “MacTalk”，作者 “MacTalk”