AI 浏览器真正该卷的不是 OCR，是人机协作协议

AI 跟你抢同一个浏览器

OpenAI 的 Operator 正式开放，Anthropic 的 Computer Use 也跑了大半年，所有人都在比"谁的 AI 更会点网页"。

但有个更基础的问题咱们都没想过：AI 跟你打开同一个浏览器的时候，我们和AI到底怎么共处？

场景不复杂。

你正开着 Chrome 写周报，agent 想帮你查一下航班。

它有三种选择：自己开个无头浏览器（独立、但反爬检测一抓一个准）；用 Playwright 远程控制你的 Chrome（直接、但会抢你的鼠标、抢你的 tab）；走 CDP 跟你的浏览器共享进程（优雅、但网站会通过 TLS 指纹把你揪出来）。

最近我们试了一个新工具 ego lite（也叫 ego-browser），它的解法还真挺有意思。

它不是新开一个浏览器进程，是直接 fork 你 Chrome 里那个真实的 profile（cookie、登录态、TLS 指纹、canvas 渲染历史全部继承）。对网站来说，agent 的请求和你本人的请求是同一个浏览器发出来的，根本无法区分。

这个设计里藏着整个 AI 浏览器赛道真正应该卷的方向：人机协作的语义层。身份、所有权、反爬、跨网络、上下文、错误恢复——这一组问题，OCR 准不准、iframe 识别快不快，跟它们比都是表层。

人机协作的语义层

我们把视角拉远一点看 AI 浏览器赛道，会发现 2024 年到 2026 年，大家比拼的核心其实发生了一次迁移，只是动静不大。

第一阶段（2023-2024）：谁点网页元素更准。 

OCR 准不准、iframe 识别快不快、动态渲染等不等得到。Playwright 风格的 API 是行业标准，snapshot 出一个 accessibility tree，然后按 ref 或 selector 去点。ego lite 在这一层做得不差，但也没比 Browser Use、Stagehand 这些开源方案强多少。

第二阶段（2024-2025）：谁能跑得更稳。 

解决网络抖动、iframe 嵌套、SPA 路由变化这些工程问题。有人开始引入事件等待、网络空闲检测、视觉重试。ego lite 的 waitForElement / waitForNetworkIdle 在这一层同样中规中矩，不是核心卖点。

第三阶段（2025-2026，现在正在发生）：谁能解决"人机共处"。 也就是我们今天真正想聊的事。

"人机共处"听起来很玄，拆开其实就是几个问题：

身份

agent 操作的是谁的浏览器？它生成的 cookie 归谁？它发的评论算你的还是算它的？这步没想清楚，后面全是坑。ego lite 的解法是 task space 继承用户 profile，agent 用的就是你 Chrome 里那个"你" profile，cookie、登录态、偏好设置全部继承。意味着 agent 帮你发的推文，从社交应用的视角看就是你本人发的。

所有权

agent 开了一个 tab，你点过去看了一眼，谁有控制权？听上去很小，实际跑起来很微妙。ego lite 引入了 ownership 字段，task space 可以是 agent、user、或者 agentDelegatedToUser 三种状态。agent 创建的 space 默认是 agent 拥有；agent 可以 claim 一个 user 的 space（"我接过来干活"），也可以 handOff 回去（"活干完了还你"），中途 user 想拿回去用 takeOver。协议在文档里写得清楚，但更重要的是它真的能在运行时强制执行。

前两天就撞上了一次。让 agent 去抓 Unsplash 的图，它得先去 claim 我的 task space 1（里面开着 Unsplash、Pinterest、公众号后台好几个 tab）。claim 完 agent 还没开始抓，我自己在 Chrome 里点了一下 Pinterest，task space 立刻变成 agentDelegatedToUser 状态，agent 那边所有浏览器命令直接 pause，返回了一个搞笑的错误：

"The user is controlling task space 1. Browser commands are paused. Do not take over automatically. Wait for the user to return control or ask you to continue."

这句话值得所有做 AI 浏览器的团队抄一遍。它没说"权限被回收"，没说"操作失败"，而是把人机协作的边界讲清楚了：你正在控制，我等着，你说继续我再继续。Computer Use 至今会在 agent 跑着的时候直接抢你的鼠标，这个设计哲学跟 ego lite 完全不是一个段位。

上下文

agent 跑完活，登录态、tab 历史、cookie 还在不在？user 想接手继续干，能不能直接接着来？ego lite 的解法是 task space 持久化，agent 跑完不销毁 tab，user 拿回去直接能接着用。这一步看似理所当然，但很多 AI 浏览器是"agent 跑一次，临时启一个，结束销毁"，用户的登录态、收藏夹、上下文全部丢失，user 想接手得从头来。

错误恢复

agent 跑挂了怎么办？网络断了怎么办？登录页点错了被风控怎么办？ego lite 引入了 markTaskSpaceError 和 setAgentTaskState 这两个方法，agent 出错时显式标记错误状态，user 能看到这个 task space 是"agent 跑挂的"，再决定是清理掉重跑还是手动救一下。

除了上面这几个以外，赛道里还有两个被严重低估的子问题，单独提一下。

反爬这件事，不是"工程优化"是"架构选择"

前文已经讲过：navigator.webdriver、headless 指纹、JA3 / Akamai HTTP/2 指纹、p0f TCP 指纹，这些东西在你装 Chrome 那一刻就固定了。Anthropic 的 Computer Use 用真机带 GUI 的虚拟机去规避，但成本上天，不是普通 agent 能玩的方案。ego lite 用 fork 用户真实 profile 的方式，从根上绕过了反爬这个赛道里最头大的问题。这不是一个工程优化，是一个架构选择。

跨网络这件事，决定了 agent "能不能跑通"

前两天抓 Pinterest 图的时候撞上过：外部 shell 走我的网络，curl i.pinimg.com 直接 TCP 超时；但 ego lite 内部浏览器进程能正常加载。agent 运行的网络环境跟用户自己的网络环境经常不一样，如果 agent 跑在云端、被防火墙隔离的集群里，单纯靠无头浏览器连某些站点根本连不上，更别说抓图、填表、登录了。

ego lite 这块的解法是 task space 直接 fork 用户的本地 Chrome，agent 的所有网络流量都从用户本机出口走，跟你手动打开 Chrome 是同一条路径。这不是"性能优化"，是"能不能跑通"的区别。我抓 Pinterest 6 张图那次就是活生生的例子——外部 curl 走不通，但 page 内 Image.crossOrigin='anonymous' + canvas.toDataURL 把图转 base64 走出来了。如果没有这个 fork 设计，agent 跑在云端，100% 抓不到 Pinterest。

把这几件事放在一起，我们会得到一个结论：AI 浏览器赛道的真正护城河不是底层能力，是协议。 谁先定义清楚"人机协作"的语义，谁先把这套协议在产品里跑通，谁就是下一代浏览器的入口。

这个判断如果成立，那 Manus、ChatGPT Operator 这些想从应用层切浏览器的项目会非常尴尬。它们绕过了"人机协作"这层，直接从"AI 替代人"切。但用户真正需要的不是"AI 替代我"，是"AI 帮我跑、我在旁边看、随时能接手"。这两件事的差异，就是工具和替代品之间的鸿沟。

文档一致性

聊完赛道判断，再说一个更工程师视角的观察。

我装好 ego lite 之后干的第一件事是按官方 SKILL.md 写脚本，结果发现文档跟实际 API 严重对不上。SKILL.md 写的是 v1.2.5，描述了一整套 Playwright 风格的 API：

const task = await taskSpaces.useOrCreate('inspect example page') await browser.openOrReuseTab('https://example.com') const heading = await page.getByRole('heading').first().innerText() 

我装的是 v0.4.4.17，runtime 暴露的根本不是 taskSpaces / page / browser 这些顶层 global，是一个 ego 对象，里面挂着 21 个方法。taskSpaces.useOrCreate 在实际 API 里是 ego.createTaskSpace；page.getByRole 不存在，要么用 ego.helpers.snapshot 拿 ref，要么用 ego.helpers.js 直接跑 JavaScript 拿 DOM；browser.openOrReuseTab 是 ego.helpers.openOrReuseTab，开关参数跟文档写的不一样。

更过分的是，文档里描述的 cdp 这个 global 在 runtime 里根本是 undefined，它实际叫 ego.sendCDPMessage，而且是 fire-and-forget 的（返回 undefined），响应通过 ego.onCDPMessage 回调拿，跟文档写的 request-response 模型完全不一样。

我花了大概 30 分钟才把这套错位的 API 摸清楚。这事在 ChatGPT 时代问题不大，人写错调一下就行。在 agent 时代是完全不同级别的问题。

agent 读 SKILL.md，照着写代码。文档错，agent 写的代码就错。代码错，agent 跑出来的结果就错。agent 不会像人一样"试试别的写法"，它按 SKILL.md 写的跑，跑不通就报错，报错就放弃，整个 workflow 直接断掉。

本质是：agent 工具的文档不是给人看的，是给 agent 看的。 给人看的文档允许 70% 准确率，剩下 30% 用户自己脑补；给 agent 看的文档需要 100% 准确率，少一个 0 整个流水线就崩。

这意味着 AI 时代的开发者工具会分出一个新赛道：文档工程的工业化。谁能保证 SKILL.md / 工具描述 / 错误码返回跟 runtime 100% 对齐，谁的 agent 跑起来就更稳。这是现在所有 agent infra 公司都在偷偷卷但没怎么公开说的事。

ego lite 这家做得相对好，它有版本号、有 changelog、有专门的 references/install.md 讲怎么装、SKILL.md 里专门有一段讲"如果出现某个 notice 怎么办"。但即便是他们，runtime 跟 SKILL.md 还是错位了两个大版本。说明这件事的工程难度比想象中要高。

我的判断是：未来几个月，"AI 工具的文档质量"会成为一个独立赛道。会有人专门做"agent 友好的工具描述协议"、做"文档-runtime 一致性的自动化校验"、做"SKILL.md 的 lint 工具"。这块现在没人做，但所有用过 agent 的人都被坑过。

浏览器其实是个伪命题

聊到这里，我想抛一个可能得罪人的判断。

AI agent 真正需要的不是"浏览器"，是"知道真实世界当前状态的通道"。

浏览器只是这种通道的一种实现，而且是相当烂的一种。浏览器是为人类视觉设计的，有窗口、有 tab、有滚动条、有鼠标 hover 效果。agent 拿到这些信息的成本极高：它得跑一个完整的 Chromium、解析 HTML、渲染 DOM、跑 JavaScript、然后把结果转成 accessibility tree 才能用。整个流程里 99% 的算力都在做"为了让人类看"这件事，agent 真正用得上的不到 1%。

更好的设计是什么？应用直接给 agent 暴露结构化 API。就像今天很多 SaaS 给开发者开 API 一样，未来的应用会给 agent 开"语义层 API"，不返回 HTML，返回"这是航班搜索结果页面，有 3 个航班可选，价格分别是 X、Y、Z"。

这件事其实已经在发生了。OpenAI 的 Operator 本质上是一个协议转换层，它把网页转成 agent 能理解的结构化操作。但它的实现方式还是"中间套一个浏览器"，不是"让应用主动把结构化数据喂给 agent"。

如果让我下注，我会赌未来 3-5 年会出现一个新的协议，我先叫它 Agent-Native Web Protocol（ANWP），专门为 agent 优化：

• 应用主动声明"我能做什么"（"我是 X.com，我能发推、能点赞、能关注"）
• 应用主动暴露"当前状态"（"你关注的人中没有人关注 @TeamMessi"）
• agent 跟应用直接对话，不需要浏览器中间层
• 浏览器退化成一个"渲染器"，只在 agent 完成任务、需要给人类展示结果时才介入

这个判断如果成立，今天所有做 AI 浏览器的团队（ego lite、Browser Use、Anthropic Computer Use、OpenAI Operator、Google Project Mariner）都只是过渡产品。它们的价值是把"agent 时代"从 0 推到 0.7，真正的 1.0 是没有浏览器的 agent。

ego lite 团队显然也意识到了这件事，他们的产品定位不是"AI 浏览器"，是"为人与 agent 协作设计的浏览器"。从命名就能看出来：ego 是"自我"的意思，lite 是"轻量"，合起来是"为自我（无论是人还是 agent）打造的轻量级载体"。这个定位比"AI 浏览器"高了一个维度。

但即便如此，他们的核心产品还是浏览器。只要浏览器还是核心，"人机共处"的语义层就是他们的护城河。一旦 ANWP 这种协议跑通，浏览器的角色会被边缘化，ego lite 的护城河会变成"他们离用户最近、最懂人机协作"，这个护城河还在，但不再来自浏览器本身。

所以真正值得押注的不是 AI 浏览器公司，是"AI 协议公司"。谁先定义清楚 agent 跟应用怎么对话，可以说谁就是下一个十年的 Oracle。

芯知解读

把上面三段放在一起，在这里给三个的建议。

做 AI agent 产品的人

别再卷"截图准确率、iframe 识别、动态渲染等待"这些表层能力了。卷"人机协作的语义层"，从六个子问题里选一个深扎：身份怎么隔离、所有权怎么交接、反爬怎么被解快、跨网络怎么不被隔断、上下文怎么持久化、出错怎么优雅降级。ego lite 的 task space 协议是这一层里现阶段设计得最完整的一个样本，值得拆开看一遍。

做开发者工具的人

立刻开始严肃对待"文档一致性"。你的 SKILL.md / API 文档 / 错误码返回必须跟 runtime 100% 对齐。引入自动化校验，每次 release 跑一遍"文档 vs runtime"的 diff，错一个字都不让发。这件事现在没人在做，但你做了，你的 agent 跑起来就比别家稳，用户就选你。

agent 的重度用户

选工具的时候别只看 demo 多炫。看它的协作协议，你能不能随时接管、agent 跑挂了状态会不会丢、你跟 agent 共享的登录态安不安全、它在反爬这件事上是不是有架构层面的解法、它跑的网络环境跟你是不是同一条路。Computer Use 这种"AI 抢你鼠标"的设计哲学，在 agent 普及之后会被淘汰。

ego lite 这个产品让我意外的不是它能跑通 Playwright 那套 API，这事大家都能做。让我意外的是它把"AI 跟你抢浏览器"这件事想清楚了，并且用 task space 这个抽象把解法落到了产品里。赛道里大部分玩家还在第一阶段卷 OCR 准确率，他们已经跑到第三阶段了。

至于浏览器本身会不会消失，我押 5 年这个判断。不是 ego lite 会不会活下来，是 AI 时代的应用层协议会往"主动暴露结构化数据"这个方向走。

如果 5 年后没人提 ANWP 这种东西，我收回这句话；如果有人真的在写类似协议，欢迎引用我今天这篇文章。