让一个 Browser Agent 订一张机票。打开网站、登录、输入出发地和目的地、筛选时间、选航班、提取价格——听起来就六个动作。
但你真的去看第一代 Browser Agent 跑这个流程，会发现它的大部分时间根本没花在这六个动作上。它在登录——它新起的那个浏览器没有任何登录态；它在等待——等页面加载、等元素出现；它在定位 DOM——CSS 选择器又变了；它在重试——某一步失败，推倒重来。真正的业务逻辑，占比很小（这是我观察执行 trace 的估算，不同任务差异很大）。
问题不在模型不够聪明，在架构：浏览器是一次性工具，这些成本就永远摊不掉。
最近有人丢给我一个新产品 ego Lite 的资料，问值不值得试。我的第一反应和大多数人一样：又一个 Browser Agent？但把它的架构看完，我意识到这个理解是错的——它真正动的不是 Prompt，不是模型，而是浏览器在 Agent 系统里的角色。
过去 Browser 是 Tool。现在 Browser 开始变成 Runtime。
这是我认为 Browser Agent 最近一年最值得关注的技术方向。
一、Browser Automation 已经进入瓶颈
第一代 Browser Agent 基本都是这个架构：
LLM
↓
Tool Call
↓
Playwright
↓
Chrome
# generated by hugo AI
在 Agent 操作浏览器的九条路线 里我梳理过，这条路线的底子是 Playwright——最稳定、社区最大，但有三个结构性短板：每次启动新 Browser、Session 不共享、企业登录体验差。ego Lite 之前的所有方案，几乎都共享同一个架构假设：浏览器是 Agent 调用的对象。
这个假设下的系统，特点是：
- Browser 是一次性的
- 每个 Agent 一个 Browser
- Cookie 独立
- Login 独立
- Session 独立
- 每一步都是 Tool Call
所以 Agent 大量时间花在：登录、等待、DOM 定位、重试。真正业务逻辑占比很低。
换更强的模型解决不了这个问题——模型再聪明，也得先等 Playwright 把页面加载完。瓶颈在架构，不在智力。
二、ego 最大的变化：Browser Runtime
ego 的思路是：
Browser 不再是 Agent 操作的对象。Browser 本身就是 Runtime。
Human
Browser Runtime
├ Human Space
├ Agent Space A
├ Agent Space B
└ Agent Space C
# generated by hugo AI
这意味着多个 Agent 可以共享：
- 浏览器进程
- 登录态
- Cookie
- Session
- Cache
- Browser State
而不是每个 Agent 启一个 Chrome。
这是 Browser Agent 的一次架构升级。有点类似：
VM
↓
Container
# generated by hugo AI
Browser 从「虚拟机」变成「宿主 Runtime」。以前每个 Agent 都要启一台「虚拟机」——一个完整的 Chrome 实例，连同它空白的登录态；现在所有 Agent 共享一个宿主，隔离发生在更轻的层级。容器化没有发明任何新的操作系统技术，但它改变了部署的成本结构。ego 对浏览器做的事，是同一类。
三、Space：比 Browser Profile 更高级
传统方案：
Chrome Profile
# generated by hugo AI
ego：
Browser
Space A
Space B
Space C
# generated by hugo AI
Space 不是：
- Window
- Tab
- Profile
而是： Agent Workspace。
每个 Agent：
- 有自己的上下文
- 有自己的状态
- 可以长期运行
Browser 更像： Agent OS。
这是一个很容易被低估的差别。Chrome Profile 解决的是「多个人的数据隔离」，Space 解决的是「多个 Agent 的工作并存」。它的开源仓库里有个细节我很欣赏：你可以随时看到哪个 Space 里有 Agent 在跑，随时接管或停掉它。人没有被关在浏览器外面，而是保留了随时接管的权限——这个设计把「Agent 自主」和「人类可控」放在了同一层。
四、Semantic Snapshot：Agent 不再直接看 DOM
传统 Browser Agent：
DOM
↓
HTML
↓
LLM
# generated by hugo AI
问题：HTML 太大。DOM 不稳定。Token 爆炸。
ego：
DOM
↓
Accessibility Tree
↓
Semantic Snapshot
↓
Reference ID
# generated by hugo AI
例如一个按钮，在 Snapshot 里就是：
Button
↓
#17
# generated by hugo AI
Agent 的动作是：
Click #17
# generated by hugo AI
而不是：
Click div:nth-child(...)
# generated by hugo AI
优势：
- Token 更少
- 更稳定
- 不依赖 CSS
- Shadow DOM 支持更自然
- iframe 更容易处理
需要说明：Accessibility Tree + 元素引用这个思路本身不新，Playwright MCP 等方案也在用。ego Lite 的差异在它把这层做进了浏览器内核——按其官方材料的说法，通过 kernel-level customization 处理深层嵌套 iframe，而那正是多数 Snapshot 方案翻车的地方。这是 Browser Agent 很重要的一层 Runtime：看页面这件事，从此由 Runtime 负责，而不是每个 Agent 自己糊一套解析。
五、Batch Execution：减少 Agent Loop
很多 Browser MCP：
Click
↓
LLM
↓
Type
↓
LLM
↓
Wait
↓
LLM
↓
Extract
# generated by hugo AI
每一步：一次 Tool Call。
ego 更倾向：
生成完整 JS
↓
Browser 一次执行
# generated by hugo AI
例如：
login()
search()
open()
extract()
return
# generated by hugo AI
一次完成。它的开源 skill（ego-browser）把 snapshot、fill、click、navigate 暴露成页面内的 JavaScript 工具，让 Agent 把多步任务组合成代码，而不是一条一条 CLI 命令地往返。
优势：
- Tool Call 更少
- Token 更少
- Latency 更低
- Agent Loop 更短
我判断未来 Browser Runtime 很可能都会往这个方向演化——Agent 与浏览器之间的对话，会从「一问一答」变成「提交一段计划」。
六、State 是第一等公民
过去 Browser Agent：状态来自 Prompt。
现在： 状态来自 Runtime。
例如，Browser 已经知道：
- 登录状态
- Cookie
- Tab
- 页面历史
- LocalStorage
- IndexedDB
Agent 不需要重新理解。Runtime 就已经保存。
这一点非常重要。状态在 Prompt 里，Agent 每次重启都「失忆」，上下文要靠对话历史一点点喂回去；状态在 Runtime 里，Agent 可以被暂停、重启、交接——上下文在浏览器里，不在聊天记录里。这也解释了第二节那个设计为什么成立：多个 Agent 共享登录态之所以安全，前提是状态归 Runtime 管、按 Space 隔离，而不是靠 Prompt 约定。
七、真正先进的是 Runtime，不是 Prompt
过去大家都在卷：
- Prompt
- Planning
- Tool Use
ego 更多是在卷： Runtime。
包括：
- Browser 生命周期
- Session 生命周期
- State 生命周期
- Workspace 生命周期
把视角拉远一点，这其实是一次更大转移的一部分。我的判断是：
Agent 基础设施正在发生一次重心转移：过去竞争的是 Model + Prompt，今天竞争的是 Runtime。
近一年很多产品的发展方向，都可以串在这条线上：
- OpenAI 的 Codex CLI / ChatGPT Agent
- Claude Code
- Browser Runtime（ego）
- Computer Use
- OpenCode
- 以及企业语境里的数字员工 Runtime
它们本质上都在回答同一个问题：
模型越来越接近，真正拉开差距的，将是 Agent 运行时（Runtime）而不是 Prompt。
模型在趋同，Prompt 会被抄平，只有 Runtime——你为 Agent 搭的生命周期管理、状态管理、隔离边界——是随时间积累的资产。这说明 Browser Agent 已经开始进入： Infrastructure Competition，而不是 Prompt Competition。
对做 Browser Agent 的团队来说，这意味着评估问题变了：过去问「哪个方案的 Prompt 更好」，现在应该问「状态在哪里、生命周期谁管、隔离边界画在哪」。如果你的答案还是「在 Prompt 里」，那你的优化方向可能已经落后一代。
八、它和 MCP Browser 的区别
很多 MCP Browser：
LLM
↓
MCP
↓
Playwright
↓
Browser
# generated by hugo AI
ego：
LLM
↓
Browser Runtime
↓
Semantic Layer
↓
Execution Engine
# generated by hugo AI
左边是一根「工具链」——每一环都可替换，浏览器仍是末端的执行器。右边是一整套 Runtime——语义层和执行引擎长在浏览器里面。Browser 不再只是 Tool，而是一整套 Runtime。
这一层未来可能成为所有 Agent Framework 的基础设施。就像今天没有哪个应用框架会自己实现一套 TCP 栈，未来可能也没有哪个 Agent Framework 会自己糊一套浏览器控制——它们会调用 Browser Runtime。
九、局限性
如果站在 Enterprise Agent 角度，ego 仍然主要解决： Browser Runtime。
它没有覆盖：
- Identity（身份）
- Organization（组织）
- Permission（权限）
- Memory（长期记忆）
- Eval（评估）
- Learning（学习）
- Enterprise Context（企业上下文）
因此它更像这张图里的一块：
Enterprise Agent Runtime
├ Identity
├ Permission
├ Memory
├ Eval
├ Learning
├ Connector
└ Browser Runtime ← ego 所在的位置
# generated by hugo AI
在 数字员工背后的 Agent，是五层基础设施的叠加 里我展开过这个完整栈：身份层、上下文层、执行层、验收层（Eval 集就是上岗考试）、学习层。Browser Runtime 属于执行层的一部分——它解决「Agent 怎么安全高效地操作网页」，但不回答「这个 Agent 是谁、有没有权限、做错了谁负责」。
Browser Runtime 是数字员工的重要组成部分，但不是全部。
十、Browser Agent 的四个阶段
Browser Agent 的演进路径，大致可以概括为四个阶段：
Automation
↓
Browser Agent
↓
Browser Runtime
↓
Enterprise Runtime
# generated by hugo AI
第一阶段解决的是「能不能操作浏览器」。
第二阶段解决的是「能不能让 LLM 操作浏览器」。
第三阶段解决的是「浏览器如何成为 Agent 的运行时」。
而下一阶段，更值得关注的是： 如何把 Browser Runtime 与 Identity、Organization、Permission、Memory、Eval 等企业能力融合，构建真正的 Enterprise Agent Runtime。
ego Lite 的价值，不在于它现在做到了多少，而在于它把第三阶段的形状提前画了出来。
你的团队的 Browser Agent，现在在哪个阶段？欢迎留言聊聊。