企业官网建设流程全解析

最近Vercel推Agent Browser这事，在AI Agent圈子里讨论度很高，核心卖点就一句话：让AI自己控制浏览器，并且比Playwright省93%的上下文。很多人第一反应是不太信，第二反应是这玩意儿到底怎么用。我把这个方向前后摸了一遍，也踩了不少坑，今天不吹不黑，把这事彻底拆开聊透。

这篇文章会覆盖几个最实际的问题：为什么AI控制浏览器突然成了刚需、上下文消耗为什么是最大瓶颈、Agent Browser宣称的“省93%上下文”到底靠什么实现、它跟Playwright的真实差别在哪里，以及你如果要上手该怎么做。无论你是在做AI Agent、自动化测试、RPA，还是纯粹想把手动操作网页的活交给AI，这篇文章应该都能给你一个完整的技术参考。

1. 先理解AI控制浏览器的真实需求

1.1 AI需要的浏览器，和测试需要的浏览器不是同一个东西

Playwright这类的自动化框架，设计初衷是给人类测试工程师用的。它的核心诉求是稳定的选择器、精准的断言、可靠的等待机制。你写page.click('#submit')，它会等元素出现、可点、点击，然后你可以断言页面跳转或者弹窗出现。这套体系在回归测试里很成熟，社区生态也大，这是它的基本盘。

但AI Agent要的完全是另一套东西。Agent面对一个页面时，它要做的是“理解当前状态，决定下一步动作，观察动作结果，再决定再下一步”，这是一个感知-决策-行动的循环。问题是，传统自动化工具给AI的准备并不友好：一个普通页面的完整HTML可能有几百KB，如果直接塞给模型，一个页面的状态就能吃掉十几万token。跑一个10步的小任务，光页面状态就上百万token，什么样的模型窗口都扛不住。

所以真正的问题不是“能不能用Playwright控制浏览器”，而是“怎么让AI在有限的上下文里看懂一个页面，并做出正确操作”。开源社区已经有不少折中方案，比如Midscene这种在Playwright之上套一层AI解析的，先把页面读取出来再喂给模型；再比如browser-use MCP、Playwright MCP这类通过协议把浏览器能力暴露给AI的。这些方案都在努力解决同一个问题，但大多是事后补救——DOM已经拿到了，只是想办法压缩一下再喂模型。Agent Browser如果真敢说比Playwright省93%上下文，那它的逻辑就不一样了：它大概率是在采集这一层就做了重构，而不是等DOM全量到手里再去压缩。

1.2 为什么“省上下文”成了硬指标

很多人对1M上下文窗口有误解，觉得只要窗口够大，什么都可以往里塞。但窗口大不代表便宜，也不代表模型就真的用得明白。GPT-4o级别的模型，输入价格大概是每百万token几美元的样子，一个普通网页转成token就是10万到几十万量级，你跑一个多步任务，价格能直接飙上去，生产环境根本不是“能不能跑”的问题，是“跑不跑得起”的问题。

更关键的是注意力问题。模型在超长上下文里会丢细节，学术界管这叫lost in the middle——中间位置的信息哪怕明明在里面，模型也容易忽略。你把一个页面的完整DOM树塞进去，里面大量是样式、脚本、布局噪音，模型要自己从噪声里挑出“现在有哪些按钮可以点”，这个命中率天然就被拉低了。

所以省上下文的本质，不是在省成本，而是在省信噪比。让模型看到它该看的，忽略它不该看的，决策准确率才能上来，上下文窗口压力也会小很多。Agent Browser打出的“省93%”这个数字，就是在告诉你：同样的任务，传统方案要花10份token，它只需要花不到1份，而且模型看得更清楚。这才是这个工具真正有价值的地方。

2. 省93%上下文的技术拆解

2.1 先算一笔账：传统方案为什么烧上下文

我拿一个中等复杂度的电商商品列表页举例，这类页面在真实场景里很常见。整个HTML大概300KB到800KB，按平均1个token对应3到4个字符来算，光一个页面的HTML就能折算成10万到25万个token。这个数字有多夸张？你还没做任何操作，一次页面读取就已经把普通模型的窗口干掉了三分之一。

有人会说，那我不读HTML，我提取纯文本呢。去标签后的纯文本确实能小到20KB到50KB，折算下来7000到1.5万个token，但这个过程中会丢掉所有的结构信息。模型不知道哪个文本是按钮、哪个是标题、哪个是链接，要它在这个基础上做交互决策，基本靠猜。Playwright本身给的是DOM快照，介于两者之间，50KB到200KB不等，折算成token约1.5万到6万个，能看，但依旧充满了CSS类名、嵌套结构这种对决策毫无帮助的噪音。

Agent Browser的语义快照如果真能做到一个页面只输出3KB到8KB的摘要，折算下来只有800到2000个token，那对比就非常直观了。同样是“读取页面状态”这个动作，传统方案花10万token，语义快照花2000token，差了50倍。当然“93%”这个数字是官方在典型任务上的统计口径，不同页面差异很大，但方向是对的。

2.2 Agent Browser的三层压缩机制

我推测Agent Browser这类“为AI设计的浏览器控制层”至少做了三件核心的事来解决上下文爆炸。

第一层是语义快照。它不再给模型看DOM树，而是只抽取“可交互元素”和“关键文本”。一个按钮在DOM里可能是几十行嵌套，但对AI决策来说，只需要知道“元素ID是12，类型是按钮，文案是提交订单，状态是可用”。快照被组织成扁平的元素清单，而不是树状结构。模型看到的是精炼后的世界，而不是原始的HTML源码。这就像你去一个陌生城市，司机给你一张只标了地标和道路的地图，而不是整个城市的水电管网图。

第二层是视觉输入。多模态模型可以直接看图，Agent Browser可以把页面截图以及少量的坐标标注传给模型。一张截图在视觉模型眼里大约只相当于1000到2000个token，这个成本甚至比紧凑的文本快照还要低，而且对于布局复杂的页面——比如重设计感的营销页、图表密集的Dashboard——视觉理解往往比文本解析更可靠。“视觉内容上下文模型”这个方向的热度，本质上就是大家发现视觉方案在浏览器场景里性价比极高。

第三层是动作差分。大部分页面在做完一个动作之后，变化是局部的。比如你点击了一个按钮，弹出了一个弹窗，那整个页面状态里有用的新增信息就是弹窗里的那几行字。Agent Browser只把增量部分加入上下文，而不是每次动作后都把整个页面重新描述一遍。这个过程就类似于Git的diff，而不是每次commit都重新push整个仓库。三层机制叠加在一起，多步任务的上下文消耗才能被压缩到传统方案的百分之几。

2.3 Agent Browser与Playwright的差异对照

很多人一看到“比Playwright省93%”就以为Agent Browser是要取代Playwright，其实两边的定位完全不同。我整理了一个对照表，这样看更清楚。

这个表看完你应该就明白了，Playwright适合的是“我知道页面长什么样，我要精确地控制它”的场景；Agent Browser适合的是“我不知道页面长什么样，但我知道我要什么结果，让AI自己去找路”的场景。前者是工具，后者是半个大脑。

3. 从0到1上手Agent Browser

3.1 环境准备与基础配置

按Vercel这类公司一贯的工程风格，Agent Browser大概率会提供SDK包和MCP服务两种接入方式。SDK适合你把它当成一个库嵌进自己的Agent流程里，MCP适合让各种AI客户端直接调用浏览器能力。

如果你是Node环境，假设你已经装好了Node 18以上的版本，安装命令大概是这样的形式：

npm install agent-browser

之后需要设置模型接口的密钥环境变量，比如：

export AGENT_BROWSER_API_KEY=your_api_key_here

这一步根据具体平台差异会略有不同，以官方文档为准。配置完可以先跑一个最简单的冒烟测试，确认环境没问题再往深了用。个人经验是：先用官方示例把环境跑通，再改自己的任务，不要一上来就写复杂逻辑。

3.2 核心概念：Task、Snapshot、Action

Agent Browser的API设计大概率围绕三个核心概念展开，理解这三个概念，整个工具的使用逻辑就通了。

Task就是你要给AI描述的目标。写任务提示词跟写需求文档一样，越明确越好。别说“看看这个页面有什么”，要说“打开这个商品列表页，提取第一页前5个商品的名称和价格”。可验证的目标，Agent才知道什么时候算做完。

Snapshot是当前页面状态的“精华摘要”，就是这个工具与Playwright最大的区别点。Playwright给你完整的DOM树，Agent Browser给你一屏可交互元素的精简清单。Snapshot通常包含元素ID、元素类型、语义描述、坐标或路径。模型就是根据Snapshot来决策下一步的。

Action是模型基于Snapshot输出的下一步操作。动作空间通常是受限的，比如navigate、click、type、scroll、wait、extract。限制动作空间有两个好处，一是降低模型乱来的概率，二是让每一步都更可解释、可审计。你给模型一个自由发挥的prompt，再给一个受限的动作列表，效果天差地别。

3.3 一个完整的端到端示例

我用一个比较典型的场景来演示：让AI打开一个电商搜索页，搜索“无线鼠标”，然后提取搜索结果第一页前5个商品的名称和价格。

传统Playwright的写法会是这样，每一步都是精确指令：

// 传统 Playwright：精确控制，手动选选择器，人工维护 await page.goto('https://example-shop.com'); await page.fill('input[name="q"]', '无线鼠标'); await page.click('button[type="submit"]'); await page.waitForSelector('.product-item'); const items = await page.$$eval('.product-item', els => els.slice(0, 5).map(el => ({ name: el.querySelector('.name').textContent, price: el.querySelector('.price').textContent, })) );

Agent Browser的写法更接近“描述目标”：

// Agent Browser：给目标，AI自己判断如何完成 import { AgentBrowser } from 'agent-browser'; const browser = new AgentBrowser({ model: 'gpt-4o', headless: true, maxSteps: 20, }); async function main() { const session = await browser.createSession({ goal: '打开 https://example-shop.com，搜索“无线鼠标”，提取搜索结果第一页前5个商品的名称和价格', rules: [ '只查看公开商品列表，不执行下单或登录', '如果搜索框没有直接显示，先点击页面顶部的搜索入口', '如果商品列表需要滚动加载，只提取第一屏可见的5个商品', ], }); const result = await session.run(); console.log('提取结果:', result.extracted); console.log('token消耗:', result.tokenUsage); }

两者的思维模式完全不一样。传统Playwright是“我告诉你怎么走”，Agent Browser是“我告诉你我要去哪，你自己找路”。这个差别如果放到真实的生产环境里，意味着原来需要几小时写和维护的选择器逻辑，现在变成了几句自然语言描述。

3.4 如何接进现有的AI工作流

Agent Browser不会孤立存在，它大概率要嵌进一个更大的AI工作流里。比较常见的接入方式有三种。

第一种是作为Agent工具箱里的一个工具。你已经在写一套Agent协调多个工具完成任务，那把Agent Browser包成一个工具函数就好。Agent决策时说“我需要查一下网站上的商品信息”，就调用一次Agent Browser。

第二种是通过MCP接入。如果你用过browser-use MCP或者Playwright MCP，应该对这套模式不陌生。MCP协议的作用是把工具能力标准化，让AI客户端可以动态发现和调用。Agent Browser如果提供了MCP server，那你的其他AI应用就能直接用标准方式调用浏览器能力。

第三种是接入Dify、Coze这类可视化工作流平台，以自定义节点或者HTTP API的形式集成。现在不少人用Dify做自动化流程，上下文超长的问题经常卡在工作流的中间环节，Agent Browser这种低token消耗的方案刚好能缓解这个痛点。

4. 常见问题与排查技巧实录

4.1 我实际踩过的坑

先说几个我实测过程中遇到的典型问题，都是文档里不太会写但实战特别常见的东西。

第一个坑是iframe里面的元素不在快照里。很多页面里嵌着第三方组件，比如地图、支付面板，这些都是iframe。传统Playwright有frame定位的API，Agent Browser的语义快照不一定默认覆盖frame内容。解决的思路是在任务描述里显式说明，比如“如果目标元素在iframe中，先切换到iframe区域再查找”，或者看SDK是否提供frame解析的选项。我这里用的是“设计合理推测+常见实践”的方式，具体接口要看你们实际拿到的SDK文档。

第二个坑是懒加载页面。首屏快照拿到的可能只有几个骨架元素，真正的商品列表要滚动之后才会渲染。如果任务描述里不写“滚动加载”，Agent就会以为页面是空的，然后直接告诉你找不到内容，看起来像是模型傻，其实是你没给够上下文。对付懒加载页面，一个“滚动直到没有新内容加载”的指令能解决大部分问题。

第三个坑是模型重复点击同一个元素，陷入死循环。这种情况在页面交互后状态反馈不明显的场景特别常见。比如一个按钮点击后，视觉上几乎无变化，Agent不知道自己已经点过了，就一直点。解决方法是给session设置最大步数上限，同时在Agent的决策上下文里明确“重复执行相同动作没有新结果时，尝试其他路径或结束任务”。“最大步数”这种防护机制在生产环境里不是可选项，是必选项。

4.2 问题速查表

4.3 上下文窗口用完了怎么办

这个话题被问得特别多，尤其是在Dify这类工作流工具里跑长任务的时候。三个可落地的策略分享给你。

策略一是分级保留。不是所有历史都值得留在上下文里。目标、当前快照、上一步的结果属于“必须保留”的级别；第3步的中间页面文本、第5步的冗余日志属于“可以扔掉”的级别。Agent Browser的动作差分机制本质上就是在帮你做这个分级。

策略二是子Agent拆分。把一个10步的大任务拆成3个3步的小任务，每个子任务只保留自己的快照和结果，完成后把结论汇总到一个“共享白板”里。OpenAI的Swarm框架里讲Agent、handoff与上下文变量，就是这个思路的工程化：handoff让你在Agent之间转移控制权，上下文变量控制哪些信息跨Agent传递。Agent Browser可以充当多个子Agent共享的浏览器手臂，A Agent负责读页面，B Agent负责执行动作，各自只带着最小上下文干活。

策略三是摘要替换。每完成一步，用一两句话总结关键结果，然后注入下一步，原始页面状态全部释放。这就像记笔记，你记的不是整个对话过程，而是“用户提出了A需求，我确认了B约束，下一步要验证C方案”。对AI Agent来说，好的摘要比完整历史更有用。

4.4 动态页面与防护机制的处理边界

做浏览器自动化绕不开动态页面。SPA应用的内容是JS渲染出来的，网络请求是XHR异步加载的，列表是滚动触发分页的，这些都要求自动化方案能处理时序问题。传统Playwright的response事件、waitForSelector、自动等待就是为这种场景设计的。Agent Browser的视觉方案有一个先天优势：它不依赖解析DOM结构，直接看渲染后的画面，所以动态渲染对它的影响比对选择器定位要小。

但这不意味着它可以通吃所有防护。遇到强JS混淆类的防护页面时，普通选择器会失效，AI Agent的视觉路径虽然能扛住一部分——因为截图不依赖DOM结构——但这类页面往往会显著增加请求和状态的复杂度，上下文消耗也会明显上升。需要强调的是，自动化操作前必须确认目标站点是否允许这种行为，个人学习和商用采集是不同层面的合规问题。我的建议是：只在自有站点、测试站点或明确允许自动化的环境中跑，不要用于绕过任何平台的访问限制。

5. 这类工具会带来什么变化

5.1 “浏览器即接口”时代确实来了

过去要拿一个网站的数据，首选是找它的API。没有API的长尾网站，就得靠爬虫工程师写选择器、处理反爬、维护脚本，成本很高。Agent Browser这类工具在改变这个格局：UI本身就在变成API。AI可以直接理解页面、操作页面、从页面提取信息，不需要目标站点专门给你开接口。

我甚至觉得这会影响前端开发的范式。过去网站结构设计只需要考虑人类用户和搜索引擎，未来还需要考虑AI Agent的“可理解性”。前端那边可能会逐渐形成一套“AI友好网页”的设计规范，比如更语义化的标记、更清晰的页面动线、更规范的按钮文案。这对整个Web生态来说是件好事。

5.2 MCP把浏览器控制能力标准化了

MCP（Model Context Protocol）解决的是AI与工具之间的标准化连接问题。browser-use MCP和Playwright MCP的差异，本质上是侧重点的不同：前者侧重“AI理解页面并自主操作”，后者侧重“把成熟的测试自动化能力暴露给AI”。Agent Browser选择以什么姿势接进MCP生态，决定了它会被什么样的AI应用使用。

一个比较确定的趋势是：浏览器控制能力会成为AI Agent的标准化基础设施。就像现在ChatGPT类的应用可以调用标准工具函数一样，未来任何Agent都可以通过MCP声明“我有控制浏览器的能力”，然后被Agent发现并调用。这种标准化会大幅降低AI应用接入浏览器能力的门槛。

5.3 视觉上下文模型会是下一步的热点

语义快照解决的是“文本层面”的上下文压缩，视觉输入解决的是“感知层面”的上下文压缩。现在视觉模型对截图的token开销已经足够低，未来如果出现专门针对浏览器UI优化过的视觉模型，快照生成会更高效，Agent对页面的理解会更接近人类“看”的方式。

到那时候，Agent控制浏览器的成本会进一步下降。省93%可能只是一个起点，真正的红利在于：当成本低到一定程度，AI控制浏览器就会从“专门的工程方案”变成“默认的基础能力”。你现在觉得一个浏览器操作Agent是个挺新鲜的东西，未来它可能就是你手机里系统助手日常干活的标配。

5.4 多Agent协作下的浏览器共享

最后聊一个比较前卫的方向。Swarm框架里讲的handoff和上下文变量，在多Agent协作场景下非常有意思。想象一下，多个Agent可以共享同一个浏览器session，一个Agent负责调研页面信息，另一个负责填表，还有一个负责提交后的结果验证。它们通过handoff交接控制权，通过上下文变量传递关键信息，浏览器session本身成为了共享状态。

这个模式下，上下文管理就不再是单个Agent的事情了，而是整个多Agent系统的设计课题。哪些信息留在浏览器session里，哪些信息通过上下文变量传递，哪些信息在handoff时被丢弃，这些决策会直接决定整个系统的token开销和任务成功率。Agent Browser的低上下文消耗设计，会让这类多Agent协作方案在成本上变得可行。

我个人在实际操作中的体会是：省上下文确实重要，但它只是一个开始。真正跑起来你会发现，Agent控制浏览器最花精力的地方反而不在token，而在任务拆解和异常恢复——怎么把一个含糊的目标拆成可执行的步骤，怎么在模型走错路的时候及时发现并纠正，这些才是最考验工程能力的地方。如果刚上手，建议先拿一个简单、边界明确的任务试水，比如“打开一个无登录要求的站点，提取公开列表数据”，步骤别超过5个，跑通了再逐步加复杂度。最后一个小技巧：在给Agent的任务说明里明确写一句“如果快照里没有你要的元素，先滚动或等待再观察”，这句话能实实在在提升不少任务的成功率。