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 一张选型对比表下面这张表是我自己实际选型时会参考的维度列出来给大家一个直观的对照对比维度PlaywrightAgent Browser核心目标确定性执行智能化判断与操作元素定位方式选择器、XPath、文本匹配视觉分割 交互元素提取上下文消耗高全量 DOM / 截图低结构化清单环境依赖无模型依赖依赖大模型的语义理解能力适合任务回归测试、CI 断言、高频重复操作探索式测试、RPA、跨系统数据搬运稳定性极高取决于模型能力和页面复杂程度维护成本页面改版需维护选择器页面改版影响较小整个看下来两者的定位很清楚。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 消耗和成功率。你大概率会惊掉下巴——原来省下来的上下文可以换来这么多本来不敢想的能力。