当浏览器成为 Agent 的运行时：稀缺的是隔离的执行空间

浏览器 Agent（浏览器智能体）现在已经很会点网页了。它会打开页面、读取表格、填写表单、等待结果，偶尔还能把一段冗长的后台操作跑完。演示视频里往往只需要一句自然语言指令：Agent 找到按钮，绕过一个报错，再把结果交回来。

可把它放进日常工作，麻烦通常从第二步才开始。

假设你正在客户后台核对一笔退款，同时让 Agent 去 CRM 补全十条线索。它得使用真实登录态，也得打开真实网页；可你不会希望它把当前订单页切走，更不希望它碰到你正在处理的退款。接着你又开了第二个 Agent 查竞品价格。问题马上从“会不会点”变成了：这三个人和机器，怎样共用一个浏览器而不互相碍事？

这篇文章从开源项目 Ego Lite 的公开说明出发。它试图把浏览器做成一个供人和多个 Agent 共用的执行环境：每个 Agent 任务放进独立的 Space（隔离执行空间），用户自己的标签页继续留在原处。这当然不等于浏览器自动化已经安全可靠了，但它把一个容易被演示掩盖的问题摆了出来：会操作网页的模型已经不少，能让这些操作安稳落地的执行环境却还很缺。

自动化框架，为什么总会卡在“真实浏览器”这里

传统浏览器自动化的逻辑很直接：启动一个受控制的浏览器，脚本或 Agent 调用 navigate、click、fill 等接口，让它把任务做完。

这套方式适合测试、爬取和一次性流程。但一旦任务需要进入人的真实工作环境，它会碰到两个尴尬。

第一，自动化浏览器通常是另一套浏览器。用户已登录的服务、保存的书签、经常使用的扩展和本地偏好并不在里面。重新登录不只是麻烦，有些企业服务还会触发 MFA、设备验证或风控。于是原本宣称“帮我跑个流程”的 Agent，常常先卡在“请把登录状态搬过去”。

第二，就算 Agent 直接操作用户正在使用的浏览器，体验也不一定更好。它为了找一个按钮切走当前页面，鼠标和焦点被抢占；多个任务同时跑时，标签页被来回切换。人会担心它下一步要做什么，Agent 也容易因为页面状态变化而失去上下文。

Ego Lite 的公开设计是把这两个问题合在一起处理。它允许用户在首次运行时选择迁移 Chrome 数据，包括登录态、Cookie、扩展和书签；但 Agent 接到任务后不会接管用户面前的标签页，而是在自己的 Space 中打开页面、读取 snapshot、执行操作并回报结果。

这里不必把它理解成某个 API 设计得多巧。真正变化的是，浏览器状态开始被当成一种需要分配的资源。登录态也不是“自动化时顺手带过去的配置”，它决定了 Agent 能进哪些系统、看到哪些数据、能以谁的身份完成什么动作。

图片来源：citrolabs/ego-lite 官方仓库

一个浏览器里，至少有三种东西要分开

把浏览器视为 Agent 的 runtime（运行时），并不只是多开几个窗口，而是要把原本混在一起的东西拆开。

人正在做的事，不能变成 Agent 的副作用

用户自己的前台标签页里，往往堆着很多临时状态：一封还没发出的邮件、一个不想给自动化任务看的页面，或者某个需要人工判断的后台记录。

如果 Agent 可以任意切换、关闭或复用这些页面，任何后台任务都可能破坏人的工作。更糟的是，用户很难分辨某个页面变化到底来自自己，还是来自某个正在运行的 Agent。

Ego Lite 给出的 Space 做法很直白：人的标签页归人，Agent 的页面归 Agent。按项目说明，用户能看到哪个 Space 正在执行任务，也能随时接管或停止。这个设计不只是多了一个分栏，它让“谁正在操作哪个页面”有了明确归属。

长任务里，用户未必需要盯着每个点击，却应当能在发现异常时找到任务、暂停执行，而不必在一堆标签页里猜发生了什么。

人的标签页与 Agent Space 各自运行，彼此互不干扰

多个 Agent 的任务，不能共用一个页面历史

单 Agent 演示里，页面通常被假定为稳定的。多 Agent 一起跑时，这个前提很快就不存在了。

一个 Agent 在供应商网站筛选信息，另一个 Agent 同时更新 CRM；如果两者共享同一组标签页、地址栏历史和页面焦点，任何一个任务的跳转都可能让另一个任务读到错误页面。即使最终没有误操作，反复重新识别页面也会增加工具调用和 token 消耗。

Space 在这里更像工作区，而非单纯的隔离容器。每个 Space 对应一个 Agent 或一项任务，保留自己的导航路径、页面快照和执行状态。项目用“Claude Code 在十个并行 Space 中补充线索、Codex 在另一些 Space 中抓取竞品网站”来描述这种用法。

它不能保证并发任务一定正确，却至少把最基础的冲突从“抢同一个浏览器”改成“各自管理自己的网页状态”。Agent 数量一多，能否留住任务边界，往往比模型会不会多调一个工具更早决定系统会不会失序。

登录态能复用，不等于权限可以无限扩张

Chrome 登录态迁移是这类产品最省事、也最容易被低估的功能。

它确实减少了摩擦：用户不用逐个服务重新授权，Agent 也能在已登录的系统里工作。但 Cookie、会话令牌和扩展数据并非普通文件，它们本身就是身份凭据。Agent 能复用这些状态，就可能拥有接近用户本人的访问能力。

所以，Agent 待在自己的 Space 里，只能保证任务不互相干扰；它并没有自动获得恰当的授权边界。隔离的 Space 仍可能访问敏感后台，也仍可能创建、修改或提交数据。

更可靠的产品设计，需要把两件事分开看：

隔离回答的是：哪个 Agent 在哪个页面、哪段会话里执行；
授权回答的是：它能否读取这类数据，能否把这次操作提交出去。

前者让浏览器不会一团乱，后者决定自动化不会越过边界。两层都需要，不能用其中一层替代另一层。

浏览器登录态属于身份凭据，任务边界外的高影响操作需要人工确认

浏览器运行时应该提供什么

如果浏览器只是一个被远程驱动的画面，Agent 出错后，人通常只会看到“任务失败”。把它当成运行时，就得把任务的生命周期也接住：页面如何隔离、状态如何保留、谁能看到过程、谁能中途收回控制权。

状态隔离、可观测性、控制权和审批，听上去像一套很规整的分层。实际产品里，它们往往同时出现。

任务先得有自己的页面、导航记录和临时数据，才不至于相互污染。用户接着要知道 Agent 正在访问什么站点、卡在什么位置、是否在等待登录或确认；不需要展示模型完整的推理过程，但页面、动作和任务状态至少应该查得到。

一旦流程会写数据，暂停、停止、接管和重试就不能只留在日志里。用户应该在关键节点看到明确的话，例如“将这十条线索写入 CRM”“提交该表单”“下载包含客户信息的文件”。查询公开资料和整理自己的草稿可以顺畅执行；付款、发邮件、改权限、导出数据则应该要求确认，或直接受组织策略限制。

此前写过的“上下文策略”讨论的是如何依据任务历史决定 ALLOW、ASK 或 DENY。把它放进浏览器，可以成为运行时的一部分，但不能把它和浏览器隔离混为一谈。

可以把关系简单理解成：

1
2
3


Browser Agent：在网页上读取和执行动作
浏览器运行时：给任务提供独立页面、会话状态、观察与控制
权限策略：判断这次动作是否可放行、需要确认或必须拦截

没有运行时，Agent 容易互相抢页面；没有权限策略，隔离后的 Agent 仍可能做不该做的事；没有 Agent，浏览器运行时也只是一个更复杂的多窗口管理器。

Ego Lite 官方基准测试对比图

图片来源：citrolabs/ego-lite 官方仓库。图中性能数据为项目方基准测试口径。

这和“指给 AI 看”是两件相邻的事

我之前写过 AI Pointer，关注的是用户怎样把屏幕对象交给 AI：不是把一切都重新描述进聊天框，而是直接指向“这个表格”“那张图”“这段文字”。它解决的是任务如何自然地开始。

浏览器运行时处理的是后半段：当用户已经说“帮我把这些线索补全”之后，Agent 到哪里执行，如何使用必要的登录态，多个任务怎样并行，用户又怎样随时接回控制权。

前者降低上下文搬运，后者避免执行过程失控。两条路线很容易在产品里相遇：对象入口让任务更容易发起，隔离的浏览器 Space 让任务有地方可靠地运行。

不要把“共享登录态”包装成无成本便利

从公开说明看，Ego Lite 想提供的是一种很顺滑的体验：保留用户真实浏览器的数据，让不同 Agent CLI 通过 ego-browser 接入，同时不打扰人正在使用的标签页。这对需要登录多个 SaaS 的知识工作场景确实有吸引力。

但越顺滑，越需要问几个不那么讨喜的问题。

Agent 是否应获得全部 Chrome Profile，还是只拿到某个工作账号？一个任务结束后，临时页面、下载文件和站点缓存应该保留多久？当 Agent 访问了带有个人信息的后台，后续导出、复制或外发动作如何被识别？用户接管某个 Space 后，原 Agent 是否应立即失去控制权？

这些问题没有靠“更强的网页理解”自动解决的答案。它们依赖产品是否把身份、会话、任务和审批拆成了可管理的边界。

因此，我不会把浏览器 Agent 的下一步理解为“让 AI 获得更多权限”。更合理的方向是：让它在需要权限时拿到足够但有限的能力，并且让人看得见、停得下、收得回。

稀缺的不是自动点击，而是一个能共用的执行环境

网页点击、表单填写和页面抓取会越来越便宜。模型更会看页面，工具更会操作浏览器，这些能力会持续变成基础设施。

真正难的部分发生在它们进入真实工作流之后：用户已经登录了很多服务，多个 Agent 会同时执行任务，人还要继续正常使用电脑。此时，浏览器不再只是网页的显示器，也不只是给 Agent 调用的一组 API；它开始承担会话、身份、任务隔离、观测与控制的职责。

Browser Agent 负责完成网页上的动作。浏览器运行时负责让这些动作各自待在正确的会话和任务边界里。权限策略负责判断哪些动作可以继续、哪些必须请人确认、哪些不该发生。

把三者拼起来，才接近一个可以进入日常工作的 Agent 浏览器。少了其中任何一层，体验都会走向两个极端：要么 Agent 很聪明，却总要重新登录、抢标签页；要么它足够顺滑，却把身份和控制权一起交得太多。

Ego Lite 是否会成为答案还很早。但它至少提醒了我们，下一代浏览器竞争不只在谁能帮你点得更快，也在谁能让人和 Agent 在同一个浏览器里，各自把事做完。

参考来源

以上来源用于观察 Ego Lite 的公开产品设计、项目热度和相关的浏览器 Agent / 权限治理思路，不等同于对其安全性、隐私保护或性能表现的独立审计。GitHub Trending 仅作为项目关注度背景，不作为功能事实依据。