Agent 的浏览器正在分裂成两极：真实态与并发密度为什么不可兼得

2026 年春夏之交，两个为 agent 造的浏览器方案先后浮出水面。4 月，CitroLabs 的 Ego-Lite GitHub repo 上线，三个月冲到 4k+ stars，改造桌面 Chromium 内核，让人和 agent 并行共用。7 月，Cloudflare 发布 Kitesurf，把无头浏览器挂到了边缘网络的 V8 Isolate 里。几个月内两个方案，都盯着 agent 需要浏览器这件事，走向却截然相反。

Kitesurf 把浏览器做轻，搬到云端，卖的是并发密度。Ego-Lite 把浏览器做厚，留在桌面，卖的是真实态。表面看是两种工程路线，底下是一个本体论分歧：浏览器对 agent 来说到底是什么。这个分歧不会随着技术进步消失，因为它对应的是两类不同性质的 workload。

传统自动化同时崩在两个方向

网络界面是 agent 覆盖面最广的兼容层。大批在线服务都提供网页入口，即便没有开放 API，也有一个看得见、能点击的界面。给 agent 专门开 API 涉及系统重构、合规审核、接口限流与数据壁垒，厂商缺乏主动改造的动力。直接让 agent 操控网页，是改造成本最小的路径。但一旦把这套模式推向生产环境，传统浏览器自动化工具（Playwright、Selenium、Browser-Use）会同时在两个方向上崩解。

第一个方向是云端高并发。Chromium 的多进程架构带来了数百 MiB 级别的内存开销。Cloudflare 自己的对照测试显示，处于预热状态的 Chromium 池在截图和 HTML 提取任务中分别占用 271.0 MiB 和 273.7 MiB 内存。业务请求量一涨，成百上千个浏览器进程同时跑起来，服务器内存很快见底。操作系统发现内存不够用，会强制杀掉一部分进程来自保。上层业务看到的现象就是请求超时或任务莫名其妙中断。个人开发者单台服务器扛不住高并发 agent，云厂商也背负着沉重的计算资源负担。

第二个方向是本地真实态。Playwright 每次启动一个干净的浏览器，就像开了台新电脑，没有 cookies，也没有 session。agent 第一步就撞上登录页面，好不容易过了登录还要面对人机验证码。Browser-Use 需要手动配置登录信息或单独跑一遍登录流程。就算登录解决了，传统自动化接管浏览器时会抢你的鼠标、切你的标签页，你只能等它跑完。更麻烦的是，自动化浏览器在网站看来和真人用的浏览器不太一样，反爬系统识别出来会直接拦截。独立 browser agent 因此背负一个长期代价：工程资源消耗在和反爬系统的军备竞赛上，而不是提升产品体验。

这两个方向的痛点属于矛盾，而非程度差异。它们对什么是浏览器给出了截然不同的回答。

云端高并发方向认为，浏览器的核心价值在于渲染网页内容。渲染引擎可以替换，只要能把 HTML 和截图正确返回给 agent 即可。Chromium 内部为人类视觉体验设计的优化（GPU 图层合成、V8 JIT 编译、多进程沙箱、WebRTC 解码栈），对 agent 而言并非刚需。本地真实态方向则认为，浏览器的核心价值在于真实的浏览器身份和登录态。内核不能换，因为换掉内核就会丢失真实指纹与活跃 session，能够改变的是人和 agent 之间的协作模型。

这并非工程优化方向的选择，而是本体论层面的分歧。Kitesurf 与 Ego-Lite 分别站在了这两端。

Kitesurf 的解法：做轻，搬到边缘

Cloudflare 的解题思路绕开了两件多余的事：agent 不需要人类的眼睛，面向人类视觉的高级优化可以全部剥离；本地单机跑 Chrome 太占资源，渲染重活可以搬到分布式边缘网络。

Kitesurf 没有选择移植几千万行代码的 Chromium 源码，而是将基于 Rust 开发的轻量渲染引擎编译成 WebAssembly，运行在 Cloudflare Workers 的 V8 Isolate 环境里。V8 Isolate 是语言运行时级别的隔离单元，也是 Cloudflare Workers 的执行容器，后来逐步演化成了 Agent 的物理底座。浏览器在这一架构里不再是独立的应用程序，而是分解为 Workers 平台上的组件调用。计算能力卸载到覆盖 330+ 城市的全球网络，请求会自动路由到最近的节点，本地只维持轻量信号编排与 CDP 协议握手。通过 CDP 端点兼容 Playwright 和 Puppeteer 生态，既有代码无需改动即可运行。

这套架构的取舍非常明确。以下基准数据均来自 Cloudflare 官方测试（在 14 个 URL 上每项测试 5 次取中位数，对照预热的 Chromium 池，无第三方独立复现）：在提取 HTML 数据时，Kitesurf 单页内存占用为 39.4 MiB，对比预热 Chromium 的 273.7 MiB 降低了约 7 倍，CPU 消耗节省了 3.8 倍；渲染截图时内存占用为 57.8 MiB，降低了 4.7 倍。收益背后的代价是延迟：Kitesurf 使用冷启动的软件渲染器，缺少 Chromium 的预热 JIT 优势，截图端到端耗时为 1,148 毫秒，比 Chromium 的 637 毫秒慢了约 1.8 倍，延迟差距主要来自栅格化与 JPEG/PNG 图像编码。

功能边界同样清晰。Kitesurf 目前不支持视频播放、WebGL 3D 渲染，以及要求真实 TLS 指纹的 bot challenge 握手，也不适合需要长期持久状态的认证会话。Cloudflare 官方建议，在复杂渲染或对抗反爬的场景下，回退到 Chromium。

Kitesurf 定义的浏览器是一个短生命周期、尽量无状态、可高并发的 Web 渲染通道。它适合高并发的数据提取，不适合需要登录态的真实交互。

Ego-Lite 的解法：做厚，留在桌面

Ego-Lite 走了完全不同的路径。它没有换掉 Chromium，而是保留了经过内核级定制优化的真实 Chromium 内核，用来解决浏览器自动化在人机协作场景下的三个摩擦。

传统自动化的第一个摩擦是登录态丢失。Ego-Lite 在首次启动时会询问是否迁移 Chrome 数据。用户确认后，agent 就能继承既有的 cookies、书签、扩展程序与登录态。agent 可以直接以用户的真实身份去操作 GitHub、Jira 或内部管理后台，无需暴露明文密码，也不需要配置额外的 API key。对比 Playwright 每次启动干净实例都会撞登录墙与 CAPTCHA 的尴尬，这是一个完全不同的起点。

第二个摩擦是窗口抢占。Ego-Lite 引入了 Space 隔离工作空间：agent 在专属的 Space 里操作后台标签页，用户在前台的标签页与操作完全不受影响。多个 agent 可以并行工作，各自在独立的 Space 里运行。传统自动化接管浏览器时抢鼠标、切标签页的干扰消除了。开发者可以一边在编辑器里写代码，一边让 agent 在后台帮忙填写表单或查询订单状态。

第三个摩擦是交互往返开销，这也是 Ego-Lite 很有意思的架构设计。传统浏览器自动化采用 CLI 式的指令交互：agent 发送一条命令（例如点击某个按钮），等待浏览器返回结果，再发送下一步命令。一个包含 20 个步骤的任务要发生 20 次 agent 与浏览器之间的往返，每次往返都要经历序列化、网络传输、反序列化以及等待模型推理的过程。Ego-Lite 换了一种方式，把浏览器能力直接暴露为 JavaScript 函数：snapshotText() 读取页面语义视图，click 点击元素，fillInput 填充表单，js() 执行任意自定义脚本，cdp() 调用 Chrome DevTools Protocol，captureScreenshot 获取截图，browserFetch 发送网络请求。agent 可以直接编写一段 JS 代码，把多步逻辑封装进单个脚本，交由浏览器一次性执行。Ego-Lite 将这套机制总结为 codebase not CLI base。Ego-Lite 官方基准测试显示，该机制下的执行速度比 Vercel 的 agent-browser 快 2.5 倍，消耗的 token 更少，任务复杂度越高优势越明显（该数据来自 Ego-Lite 官方，无第三方独立复现）。

内核级定制还让 Ego-Lite 能够生成其官方宣称的“市场上最强的 page snapshot”，即提供给模型阅读的压缩语义视图。该机制能够处理深层嵌套 iframe 等其他方案经常崩溃的边缘场景。这些能力通过 ego-browser skill 暴露给 agent，安装后在 Claude Code、Codex、Cursor 等 agent CLI 中可以通过 /ego-browser 触发，例如直接运行 ego-browser follow @ego_agent on x.com for me。agent 会在自己的 Space 里打开页面、读取 snapshot、执行操作并返回结果，用户的当前标签页全程不受干扰。

Ego-Lite 定义的浏览器是一个具备真实指纹、真实登录态、人和 agent 可以并行共用的真实 Chromium。代价同样明确：内存开销依旧是 Chrome 级别的开销，无法支撑云端高并发，目前仅能在 macOS 环境下运行。

两极为什么不可兼得

把这两套方案放在一起对比，可以看到两者之间的对立并非偶然的工程选择，而是系统设计约束下的必然互斥。在对比两极的选择时，我们可以从运行位置、内核形态、状态生命周期、并发能力、指纹特性与适用场景这几个维度建立清晰的基准参照：

这种对立源于底层三对互相排斥的需求：

真实态需要持久状态（cookies 与 session 不能每次任务都重新开始）、本地运行（登录态绑定在本地机器上）以及完整的 Chromium 内核（真实指纹依赖于真实浏览器）。并发密度则需要尽量无状态（任务之间相互独立，运行完即回收）、云端运行（靠分布式调度实现弹性扩容）以及轻量渲染引擎（内存节省 7 倍才能承载高并发）。这三对需求构成了底层互斥：持久状态阻碍了弹性扩容，完整内核阻碍了轻量化，本地运行阻碍了分布式调度。

这种互斥在 bot challenge 场景中表现得尤为明显。Kitesurf 官方文档明确说明，它无法处理要求真实 TLS 指纹的 bot challenge 验证。Ego-Lite 本身就是真实的 Chromium 实例，具备真实 Chromium 原生指纹。围绕 Cloudflare Precursor 的分析也指出：当 agent 用上真实浏览器后，静态浏览器属性的区分力会下降，检测方还要转向行为序列分析。这并非 Ego-Lite 在工程上做得更巧，而是它选择真实态这一极自然获得的红利。代价则是它无法拥有 Kitesurf 的并发密度，使用者无法跨边缘节点分布式启动带有真实登录态的本地 Chromium。红利与代价是深度绑定的，选择了某一头，另一头的特性就会自然消失。

这种矛盾不会随着技术演进自然消失。它由经济结构决定，而非某个尚未突破的技术瓶颈。高并发数据提取（如爬虫、监控、批量数据采集）走向 Kitesurf 路线，真实态交互（如操作 SaaS、管理订阅、代人类完成日常流程）走向 Ego-Lite 路线。这两类 workload 对基础设施的要求存在根本差异，正如事务型负载与分析型负载对数据库引擎的要求完全不同。数据库市场已经证明了这一点：OLTP 与 OLAP 使用完全不同的引擎，因为它们优化的目标不同。Ego-Lite 是 agent 浏览器的 OLTP，Kitesurf 则是 OLAP。

两极背后的同一个范式：浏览器基础设施的生成内核化

表面上看，Kitesurf 与 Ego-Lite 走向了两个极端。一个在云端运行轻量 WASM，一个在桌面运行真实 Chromium；一个提供并发密度，一个提供真实态。但如果换一个视角，不看它们建造了什么形态的软件，而是看它们交付给 agent 的究竟是什么，两者其实在做同一件事：把浏览器从需要复杂交互的应用程序，重构为一套可以按需组装的能力层。

随着 AI 将代码编写的边际成本压到接近于零，代码本身从长期维护的资产变成了廉价的消耗品。组织交付给 agent 的不再是功能固定的平台或成品软件，而是一套可以按需调用的生成内核：不可替代的核心能力承载基础资产，引导知识把设计哲学与避坑指南注入上下文，杠杆工具把容易出错的不确定任务收敛为确定性操作。Shopify已经给出了一个更大规模的实证。三者组合在一起，构成了 agent 稳定完成特定任务的接口。软件复用发生的层级改变了：不再是复用某段具体代码或某个静态 API，而是复用这套能让 agent 稳定达成目标的生成机制。把这两个方案放进这套结构里，两者的底层逻辑高度同构：Kitesurf 的结构里，Rust 编译为 WASM 的渲染引擎以及 Workers 分布式调度构成了核心能力，这是 agent 自身无法在运行时搭建的全球边缘计算网络；CDP 协议兼容性扮演了引导知识的角色，让既有的 Playwright 和 Puppeteer 代码无需修改即可直接复用；Workers 的分层沙箱隔离则是杠杆工具，每个任务在独立环境中运行且随用随废，把不确定性限制在沙箱内部。

Ego-Lite 的结构里，真实的 Chromium 内核与登录态构成了核心能力，提供了 agent 无法伪造的真实指纹与身份；ego-browser skill 扮演了引导知识的角色，把浏览器操作抽象并编码为 agent 可直接调用的 JavaScript 函数集合；Space 空间隔离机制以及 JS 单 pass 执行模式则是杠杆工具，把多步交互的不确定性压缩成一次确定性的执行。

两极在表面分歧之下共享着同一个底层趋势。Ego-Lite 提出的 codebase not CLI base，是代码从资产变成耗材在客户端的体现：agent 在现场实时编写一段多步 JS 脚本，执行完毕后即可丢弃，这段 JS 脚本不再是需要维护的代码资产，而是获取执行结果的消耗品。Kitesurf 中 isolate 运行完毕即回收的机制，则是同一套经济模型在云端基础设施上的投影。一个在本地 Chromium 里把浏览器交互收敛为一次性 JS 脚本，一个在云端 isolate 里把页面渲染收敛为一次性组件调用。执行单元从长期运行的应用程序变成了随用随废的生成物。

两者交付给 agent 的都不是传统的浏览器软件。它们各自交付的，是一条能让 agent 稳定完成网页任务的 paved road。在这条路径上，agent 能够明确自身的边界、可用的工具以及异常处理机制。agent 时代的浏览器不再是独立的软件产品，而是分层化的能力基础设施，开发者可以根据具体的 workload 在两极之间选型。复用单位从浏览器进程迁移到了一套能让 agent 稳定完成网页任务的能力层，这正是生成内核范式在浏览器基础设施领域的落地体现。

对于构建 agent 平台或基础设施的工程师而言，这两个方案按照 workload 进行的分流，而非非此即彼的选择。需要高并发数据采集时选择 Kitesurf 路线，需要真实账号代操作时选择 Ego-Lite 路线。短期内根据具体业务场景选型，长期来看浏览器基础设施会像数据库市场一样持续分化。评估的起点在于你的 agent 究竟需要操作真实账号，还是需要批量提取数据，而非哪种引擎技术更先进。