Agent Browser 如何省 93% 上下文？AI 驱动浏览器自动化新范式

最近看到 Vercel 放出 Agent Browser 的消息，第一反应是：终于有人正面处理那个我一直骂骂咧咧的痛点了。从标题来看，Agent Browser 的核心卖点是“让 AI 自己控制浏览器”，而且明晃晃地写着“比 Playwright 省 93% 上下文”。这两个关键词放在一起，基本能猜到它瞄准的并不是传统自动化测试人群，而是所有在做 AI Agent、想让大模型去操作网页的人。

我自己过去大半年一直在折腾“LLM 驱动浏览器操作”这件事，试过 Playwright 套壳、试过截图喂多模态模型、也试过把整个 DOM 文本一股脑塞给大模型让它自己选。结论是：这条路非常烧钱、非常烧 token，而且烧了钱还不一定准。如果你也在做同样的尝试，或者打算用 Vercel 这套新方案，这篇东西可以帮你把底层逻辑捋清楚：Agent Browser 到底改了什么、为什么能省那么多上下文、以及它和 Playwright 之间到底是什么关系。

1. Agent Browser 到底改了什么：从“定位元素”到“让模型自己看图”

1.1 传统浏览器自动化的底层逻辑

先把 Playwright 的老底翻出来看。Playwright 这一类工具的设计前提是：人预先知道页面结构，然后告诉工具“你要找哪个按钮、哪个输入框、哪条链接”。它的定位方式极度精确——CSS 选择器、XPath、文本匹配、还有各种waitFor状态同步。这整套体系的根是确定性：每一次运行，只要页面结构不变，就能以同一套选择器稳定点击同一个位置。

这套思路在自动化测试领域完全没问题，但到了 AI Agent 这里就尴尬了。你想让大模型自己操作网页，可大模型根本不认识 CSS 选择器，更不知道#nav-submit > button.primary到底指代页面上的哪个东西。于是大家开始走一条“伪 AI 化”的路线：用 Playwright 把页面的 DOM 文本全部抠出来，塞给大模型，让它读完文本之后判断应该点哪里。

这个过程有个很直观的比喻：大模型就像一个戴着一万度近视眼镜的操作员，面前摆着一张网页的文字稿，但没有布局、没有颜色、没有位置关系。它知道页面上有哪些字，但完全不知道这些字在视觉上是怎么分布的，更不知道哪个按钮和哪个区域是关联的。有时候你问它“页面上有没有保存按钮”，它能从文本里找到一个“保存”，但它不知道这个按钮是在表单底部、还是弹窗角落、是红色还是灰色、是不是可点击状态。

1.2 LLM 驱动浏览器时的“隐形成本”

把 DOM 文本喂给大模型，表面上解决了“大模型知道页面上有什么”的问题，但成本被严重低估了。一个稍微像样的内容型页面，DOM 全量文本少说几万字符，后台管理面板那种动辄几十万字符的也很常见。中文字符转 token 的比例通常 1 个字符约等于 0.6 到 1 个 token，英文稍低一些，你可以粗算一下：一个 5 万字符的页面，塞进模型可能就是 3 到 5 万 token。

真正的痛点是：这不是一次性的成本，是一个任务链里每走一步都要付的钱。AI Agent 操作浏览器从来不是“读一次页面→点一下→结束”，而是“读页面→判断→点击→页面刷新→再读页面→再判断→再点击”，上一个页面的操作结果会影响下一个页面的状态。如果你用的是对话式大模型 API，前面步骤的截图、DOM 文本、历史动作记录全部要保留在上下文里，于是每执行一步，上下文就膨胀一层。我见过不少做 AI 测试开发的朋友，项目跑到一半就卡住了——上下文窗口用完了，后面该做的步骤全部断掉。

如果大家最近有关注开源社区，会发现 midscene 这类项目被 Playwright 调用的思路其实就是这么玩的：Playwright 负责打开页面、做截图、做 DOM 提取，然后把这些信息交给大模型判断。路线本身是可行的，但代价就是上下文消耗极其惊人。社区里大量反馈“跑几步就超限”“单次任务成本高得离谱”，根子就在这里。

1.3 Agent Browser 的切入方式

Agent Browser 不一样的地方在于，它把信息交付的顺序整个掉了个头。以目前公开的信息来看，这套方案更像是“视觉分割器 + 可交互元素提取器”的组合：先把网页截图按视觉区域切块，然后提取每一块里真正可以交互的东西——按钮、链接、输入框、下拉框，把它们整理成一个结构化清单交给大模型。

大模型拿到的不是一份几百 KB 的 HTML 文本，而是一张“网页地图”：左边是导航区，中间是主内容区，右下角有一个“提交”按钮，顶部搜索框支持输入关键词。这种呈现方式本质上是把人类浏览网页的注意力机制复刻给了模型。人打开一个页面，不会把整页文字从头到尾读一遍，而是先扫一眼布局，找到目标区域，然后把注意力聚焦到具体的按钮和链接上。Agent Browser 把这一步搬到了 AI 侧。

从这个角度看，上下文差距的巨坑就这么被填平了：DOM 全量文本是给工程师调试用的，不是给大模型做决策用的。真正驱动决策的，是“页面有哪些可操作元素 + 它们大概在什么位置 + 当前页面的核心内容是什么”。而这三样东西，用结构化描述表达出来，信息量比原文小一两个数量级。

2. 省 93% 上下文这笔账：一次长页面交互的 token 消耗拆解

2.1 一个典型页面的 token 量级估算

我实际拿一个典型的后台管理页估算过一次。这个页面是内容运营后台，包含左侧导航、顶部搜索、中部数据表格、右下角操作按钮区。用 Playwright 的inner_text或者 DOM 全量提取，出来的文本大概是 2 万到 3 万个字符，按中文内容算，喂给大模型大概是 1.2 万到 1.8 万 token。这是个什么概念？如果你用的是 128K 上下文窗口的模型，一个页面文本就能吃掉 10% 到 15%，任务跑个五六步，窗口就只剩一半不到，后面每一步的判断质量都会肉眼可见地下降。

而同样的页面，如果只提取可交互元素和关键区域结构，会得到什么？大概是一份这样的清单：

• 导航区：8 个链接（仪表盘、内容管理、用户管理、设置……）
• 顶部：搜索输入框、通知按钮、用户头像菜单
• 内容区：数据表格，6 列 20 行；行内操作按钮（编辑、删除、审核）
• 底部：分页控件，当前第 2 页，共 15 页

再加上每个元素的简短描述和坐标区域，这一份结构化清单大概只有 800 到 1500 token。两相对比，单次页面读取就从 1.2 万 token 降到了 1000 token 上下，节省幅度在 90% 到 95% 之间。

当然，具体数字会根据页面复杂度浮动。一个只有三个按钮的极简页面，怎么提取也省不了多少；但凡是信息密集的后台、门户、列表页，DOM 文本和交互清单的差距是数量级的。“省 93% 上下文”作为一个宣传数字，我认为它背后对应的就是这种典型的信息密集型页面场景，公式大概就是：

上下文节省比例 = 1 - (结构化交互清单的 token 数 / DOM 全量文本的 token 数)

页面信息密度越高，DOM 里冗余文字、格式化字符、脚本噪声就越多，这个比例就越极端。

2.2 不要只算单次，要算整条任务链

很多人看到一个页面省 90% 上下文，第一反应是“不错，但我一次任务也就操作两三个页面，省这点有意义吗？”其实意义不在单次，而在整条任务链的累积效应。

举一个我实际做过的场景：让 Agent 自动去行业网站上查三家竞品的价格信息，然后把结果整理成表格，最后打开公司后台的数据录入页面，把竞品数据填进表单并提交。整个过程涉及至少四五个不同的页面，而且每打开一个新页面，模型要先理解页面内容、再决定怎么操作。如果每个页面都喂全量 DOM 文本，保守估计整条链跑下来需要消耗 8 万到 12 万 token，这对于中小型项目来说已经很难承受，因为你不是只跑一次——你是要反复调优、反复改提示词、反复验证的。

另一个被很多人忽略的坑是对话历史。Agent 操作浏览器通常要保持多轮对话，前面步骤的截图、文本、动作描述都要留在上下文里，作为后续决策的参考。传统方式下，每读一次页面就往历史里塞几万 token，跑完一轮任务，历史里的 token 已经冗余到模型自己都分不清该看哪里。而 Agent Browser 的方式是：每一步只往历史里追加“本次看到了哪些交互元素、做了哪个动作、页面状态变成了什么”，上下文里保留的是决策过程，而不是原始网页数据。

整条链算下来，省 93% 上下文完全说得通。这不是一个单步优化，是任务级别上下文管理策略的转变。

2.3 省下的上下文换来了什么

省 token 只是最表面的收益。真正有价值的是，省下的上下文预算被转嫁到了更值得的地方：任务长度、长链路规划、跨页面记忆、错误恢复。

在上下文紧张的时候，Agent 根本不敢做多步规划，因为做完第一步就得把第一步的历史忘掉，否则后面的没空间装了。所以大家在做 Playwright + 大模型集成时，普遍只敢做“识别→点击→识别”的两步短循环，本质上和凭感觉走路没区别，走一步看一步，遇到意外就卡死。

上下文腾出来之后，Agent 可以在任务开始时先花 2000 token 做一个完整的计划拆解，然后逐步执行，并且在执行过程中保留每一步的关键决策依据。如果某一步失败了，它还能带着前面的完整历史回溯，判断是选择器问题、页面加载问题，还是自己理解错了页面结构。这种能力在传统模式下是奢侈品，因为几万 token 的页面文本根本不允许你保留那么多决策历史。

3. 上下文被解放后，Agent 任务链可以走到哪里

3.1 从“单步点击”走向“多步规划”

如果用一句话总结上下文被解放后的变化，我觉得是从“能用”变成了“好用”。

还在用短循环模式的时候，Agent 的能力边界非常明显：它能完成“打开某个页面→按预设关键词搜索→把第一条结果拿回来”这种别人给它铺好路的任务，但一旦需要它自己判断“搜索出来的结果哪个才是有效的、要不要点进详情页看看、如果没找到需要的信息是不是要换关键词再搜一次”，就抓瞎了，因为每一步都需要消耗大量 token 去重新理解页面。

现在上下文预算充足了，Agent 的行为模式会完全不一样。它会在拿到一个目标之后，先花一点上下文把任务拆成子目标，然后逐个执行。举个例子，一个批量审批场景的 Agent：打开 OA 系统的待办列表，识别哪些是“申请休假”、哪些是“报销单”、哪些是“合同用印”，再根据预先设置的规则逐条处理，遇到状态异常的还要跳转到详情页核实。这种任务用短循环模式做，十条待办就能把上下文烧穿；用 Agent Browser 的方式做，每条待办只消耗几条精炼的交互记录，跑二三十条完全没压力。

3.2 多 Agent 协作与工具链融合

再往上走一步，就牵扯到最近特别热的“多 AI 协作”概念。Swarm 框架里那个 handoff 机制，说白了就是 Agent 之间互相移交任务和上下文变量。但这里有个实际难题：如果主控 Agent 刚处理完一个页面操作，移交出去的上下文里带着整份 DOM 文本，下一个 Agent 接手时会直接内存爆掉。Agent Browser 在这里的价值是：交出去的上下文变量可以是一份精炼的“页面操作记录”，而不是原始网页数据。

我在自己的项目里试过类似的组合：决策 Agent 负责分析任务、规划步骤，操作 Agent 负责通过浏览器工具执行，执行完之后只把“做了什么、页面变成什么样、提取到了什么数据”回传给决策 Agent。这种分工在上下文受限的时候根本跑不起来，因为操作 Agent 一回传就是几万 token 的页面快照。但用了结构化交互清单之后，回传内容非常干净，决策 Agent 可以安心处理多个操作 Agent 并发回来的结果。

如果你在用 Dify 这类工作流平台，这个思路也可以直接接进去。把浏览器操作封装成工作流里的一个工具节点，Agent Browser 负责执行，产出的是结构化 JSON，下游节点拿这份 JSON 继续做判断或写入数据库。相比之前把 Playwright 硬接进工作流、然后让大模型手工解析一堆 HTML，这种方式的数据流动要健康得多。

3.3 对自动化测试领域的冲击

热搜词里“ai 测试开发”“playwright 测试用例”出现的频率很高，说明测试圈子确实在往 AI 方向试探。过去大家写测试用例是写确定性断言：打开页面、点击按钮、确认文案是否出现。这套东西很稳，但维护成本高——前端一改版，选择器全废。

Agent Browser 如果成熟，测试行业可能会分化出两条平行线：一条还是 Playwright 负责的确定性回归测试，跑核心链路用；另一条是探索式测试，用自然语言描述验收标准，让 Agent 自己去页面上找到对应的功能并验证。比如“登录之后应该能在右上角看到用户头像，点击之后出现下拉菜单，包含退出登录”。这种用例不需要选择器，不依赖 DOM 结构，页面改版之后它依然能通过视觉和语义找到对应元素。

这也是“比 Playwright 省 93% 上下文”这句话最容易被误解的地方。很多人以为 Agent Browser 要替代 Playwright，其实它是从另一个维度杀进来的：Playwright 在做“精确执行”，Agent Browser 在做“理解与探索”。这两件事在未来很长一段时间里是互补关系，而不是替代关系。

4. 别急着卸载 Playwright：回归测试与开放探索的分工

4.1 一张选型对比表

下面这张表是我自己实际选型时会参考的维度，列出来给大家一个直观的对照：

整个看下来，两者的定位很清楚。Playwright 的优势是确定性：它能做到一千万次点击都落在同一个坐标上，一分钱都不会点错。这种确定性在支付流程、订单提交、权限校验这些场景里是不可妥协的——你不会想让大模型来帮你判断“这次购买能不能提交”。而 Agent Browser 的优势是鲁棒性和灵活性：页面改版了它照样能找到提交按钮，因为它是按视觉布局和语义来理解的，而不是死磕一个选择器。

4.2 什么场景坚决继续用 Playwright

我自己心里有一条底线：凡是直接涉及资金、权限、核心数据变更的链路，一律以 Playwright 为主。

原因很简单：AI 的推理能力再强，也扛不住黑天鹅。电商下单、退款操作、账号改密、权限变更，这些操作一旦出错，后果不是测试环境里多几条失败记录那么简单。Playwright 的价值在于它永远会按你写的规则执行，不存在“今天模型状态不好，把删除按钮当成了编辑按钮”这种问题。

另外，高频的批量回归也适合 Playwright。你有三千条用例，每个版本都要跑一遍，如果每条都用大模型去理解页面再操作，成本和时间都扛不住。这种场景要的是速度、稳定、可重复，AI 在这里没有用武之地。

还有一个容易被忽略的场景：需要做严格断言的。比如“这个接口返回的字段值必须和数据库一致”“这个弹窗必须在 3 秒内出现并且文案不能变化”。Agent Browser 这类组件更擅长“找到元素并操作”，要它做数据级别的精确校验，既浪费它的能力，也不够可靠。

4.3 什么场景值得试用 Agent Browser

反过来讲，有几类场景我会第一个冲上去试用：

• 探索式验收：你有一个新功能上线，不确定各种操作路径是否都正确，与其手写几十个用例，不如让 Agent 自己从用户视角走一圈。它能发现一些你写用例时没考虑到的路径。
• 页面结构高频变动但测试目标是稳定的：比如后台管理界面三个月一大改，但核心操作流程没变过。这种项目用 Playwright 写着写着就陷入选择器维护的泥潭，换成 Agent Browser 之后几乎免疫改版问题。
• 跨系统数据搬运：从旧系统导数据到新系统、从 OA 抄数据到财务系统、从外部网站抓取内容填入自己的表单。这些任务不会像支付链路那样必须万无一失，但对适应能力要求很高，Agent Browser 的视觉理解能力在这里很值钱。
• 快速原型验证：产品经理给你一个流程描述，你想快速验证这个流程的完整性和可达性，写一套 Playwright 用例可能要半天，用自然语言让 Agent 跑一遍可能十分钟就出结果了。

5. 上手前值得先想清楚的三件事

5.1 你的任务链是否真的“需要长上下文”

省 93% 上下文是个很耀眼的数字，但如果你做的事情根本不需要多少上下文，那这个数字对你没意义。什么叫需要长上下文？典型特征是：任务多步骤、步骤之间存在依赖、需要跨页面记忆、需要纠错回溯。

反过来，如果你的任务就是“打开页面、点一下、拿结果、关掉”，这种单步短链路用 Playwright 或者直接 API 调用就够了，没必要引入 Agent Browser，更没必要引入大模型。工具不在多，够用就行。

5.2 模型的视觉推理能力决定了体验上限

从 Agent Browser 的工作原理推测，它大概率是把视觉分割结果和结构化元素信息结合起来交给大模型的。这就意味着，你接的大模型本身的视觉理解能力，直接决定最终效果。

如果你用的模型是纯文本模型，它只能看到交互清单，看不到真实的页面截图，那当一个按钮的文案在页面上一字不差地写着“确定”但实际作用是“提交订单并扣款”时，纯文本模型很难识别这种语义陷阱。如果你用的是较强的多模态模型，它既能看结构化清单，又能随时拉取页面截图做二次确认，那准确率会明显高一截。

这里想提醒大家：刚上手时先别急着追求最低成本，把一个能力足够强的模型先跑通全链路，再逐步往下调。否则你很难判断问题出在 Agent Browser 提取的信息不够，还是模型本身理解不到位。

5.3 提示词和任务设计要换一套思路

如果用 Playwright 习惯了，你写提示词时容易不自觉地往“告诉模型页面上有什么”这个方向走。但 Agent Browser 本身已经帮模型把页面信息压缩好了，你真正应该做的，是告诉模型你要什么、边界在哪里、出错之后怎么处理。

举个例子。以前你可能会写：“页面上有搜索框，输入关键词‘无线耳机’，点击搜索按钮，然后把结果列表里的商品名和价格提取出来。”这种写法把页面结构交代得很细，反而让模型带着既有的预判去读页面，一旦页面结构和预期不符就出错。

现在我会改成：“目标是获取无线耳机的搜索结果。请自己找到页面上的搜索入口，输入关键词并执行搜索，然后提取结果列表中的商品名称和价格。如果搜索结果为空，请重新尝试一次；如果两次搜索都为空，请停止并标记为异常。”这种写法才是真正把决策权交给 Agent，让它活用结构化信息，而不是当一个死板的“点按钮机器”。

还有一个心得：给 Agent 一个“我不确定时怎么办”的出口。浏览器操作最怕的就是 Agent 自己不确定还硬着头皮做，一顿操作之后页面状态完全乱了。我一般会在提示词里加一条：“如果页面上的可交互元素与任务预期严重不符，直接停止操作并把当前页面状态写成错误报告。”这个兜底规则在省了上下文之后尤其重要，因为模型现在看到的是一条很长的任务链历史，它能做的操作很多，反而需要有纪律地克制自己。

写在最后

这次 Vercel 的 Agent Browser 方向，我认为是对的。它切中的不是“自动化”这个老命题，而是“AI 时代如何让大模型理解网页”这个新命题。之前大家硬用 Playwright 作为桥梁，本质上是拿旧工具去做新事情，中间损耗全由上下文窗口来兜底，代价惨重。现在有一个专门为“AI 控制浏览器”设计的组件，把网页信息的组织方式重新做了一遍，这才是真正值得关注的地方。

如果你现在正被“Playwright + 大模型”的上下文成本折磨，我的建议是：不必急着把现有架构推翻，先挑一个不涉及核心资金链路的场景，接上 Agent Browser 的思路试一遍，对比一下同一个任务在两种方案下的 token 消耗和成功率。你大概率会惊掉下巴——原来省下来的上下文，可以换来这么多本来不敢想的能力。