企业官网建设流程全解析

1. 先说结论：两个方案压根不在同一层，选错等于白折腾

在聊大模型浏览器自动化之前，得先承认一件事：这个领域发展得太快了，快到大多数人还没搞清楚工具边界就被卷进了选型泥潭。我见过太多人拿着 Browser-use 的文档去套 Playwright-MCP 的场景，也见过把 MCP 当万能钥匙追着让它在爬虫脚本里跑全自动流程的，结果自然都不太好看。

先说一个我这边的真实背景。前阵子有位朋友拿了个需求来找我，说想做一个半自动化的电商商品信息采集工具：用户输一个商品关键词，程序自动打开搜索页、筛选条件、逐条抓取价格和销量，最后按表格整理出来。他一开始听人说“用大模型驱动浏览器，Browser-use 一步到位”，就写了个脚本让模型全自主跑，结果发现每次跑同一个关键词，模型的操作路径都不同，偶尔还会卡在登录弹窗上一直点“关闭”，也不管那个叉到底有没有点中。后来又试了 Playwright-MCP，发现它更像一个“给大模型用的浏览器遥控器”，得有人在对话里发指令，模型才一步步操作，跟“全自动脚本”的预期差了很远。

这个例子基本就概括了这两者的本质区别：Browser-use 是一个运行在你自己 Python 代码里的 Agent 框架，模型负责做决策，你负责给它目标和工具集；而 Playwright-MCP 是把浏览器操作封装成一套标准工具接口，供 MCP 客户端里的对话模型随时调用。前者解决的是“怎么让大模型独立把一件事做完”，后者解决的是“怎么让大模型在对话中像使唤工具一样操作浏览器”。

所以如果你现在正在纠结“用哪一个”，我的建议是先别急着选，因为选择的前提是搞清楚自己要解决的是哪一层问题。下面我会把两者的运行机制、实操方式、成本模型和踩坑点逐层拆开讲。

2. 底层逻辑拆解：Agent 编排和工具服务，驱动的暗号完全不一样

很多文章会把 Browser-use 和 Playwright-MCP 放在一起做对比，好像它们是同一类东西的两种实现。但从架构上看，两者的定位差了整整一层。

2.1 Browser-use：浏览器操作是“模型自主决策”的结果

Browser-use 的核心设计思路，是把浏览器封装成一系列工具（点击、输入、滚动、截图、提取内容等），然后把这些工具连同当前的页面信息一起交给大模型。模型根据自己的推理来决定下一步调哪个工具、传什么参数，你写的代码只是把模型输出的动作翻译成实际的浏览器操作。

举一个最直观的例子：你要让模型在一个搜索框里输入关键词并点击搜索按钮。Browser-use 的流程大致是这样的：

1. 框架截取当前页面的 DOM 树（经过压缩和提炼），连同截图一起发给大模型；
2. 模型“看到”页面上有一个搜索框和一个搜索按钮，于是输出一个工具调用动作，比如input_text(selector="#search", text="无线耳机")；
3. 框架执行这个动作，再次抓取页面状态发给模型；
4. 模型判断结果是否符合目标，不符合就继续输出下一步动作。

在这种模式下，整个任务的路径规划是动态生成的。模型没有预先写好的步骤清单，每一步都是根据当时的页面状态现场推理出来的。这意味着它能处理一些没见过的页面变化，但也意味着每一次运行都可能选择不同的路径，行为和结果不完全可预测。

这里有必要补充一个原理层面的细节：Browser-use 之所以要把 DOM 树精简后再发给模型，是因为完整的 DOM 可能涉及上万个节点，直接丢给大模型既浪费 token 又不精确，还会让模型被无关信息干扰。所以框架会先做一个“相关性提取”，保留表单、按钮、链接等可交互元素，再拼接成结构化的文本快照。这一步处理质量直接决定了模型后续决策的准确率。我在实际调试中甚至遇到过，同一个页面，只改了提取时的属性白名单，模型的操作成功率就提高了三成。

2.2 Playwright-MCP：浏览器变成了可以被对话调用的服务

MCP 的设计思路则是另一套逻辑。它解决的并不是“怎么让模型自动规划任务”，而是“怎么把浏览器的能力以标准协议暴露给任何 MCP 客户端”。Playwright 官方提供的 MCP 服务器，把浏览器操作拆成了几十个独立工具，比如打开页面、点击元素、填写文本、读取地址栏、执行 JavaScript、等待页面跳转等。MCP 客户端（也就是你正在用的支持 MCP 的对话工具或 IDE）在拿到这些工具列表之后，会根据你的自然语言指令决定调用哪一个。

你可以把 Playwright-MCP 想象成一个遥控器转接站：它自己不做任何任务规划，只保证“你提需求，模型选工具，它执行工具”这条链路是通的。至于模型要不要一次点到底，完全取决于用户在当前对话里下了多少轮指令。

和 Browser-use 最大的不同在于：Playwright-MCP 运行在一个已经存在的对话上下文里，模型的决策依据不只有当前的页面状态，还有你和模型之间来回沟通的语言信息。比如你可以在对话里告诉模型“点一下右上角的登录按钮，但如果没有跳转就换成手机验证码登录”，模型会结合这句指令和实际页面反馈来调整工具调用。

2.3 核心差别：决策到底由谁来做

把两者的运行机制放在一起看，差别就很清楚了。

顺着这张表往下走，你会发现其实两个方案没有绝对的高下之分，只有合不合适的问题。接下来我拿一段真实代码来演示两边各自的写法，这也是很多人最容易走弯路的地方。

3. 实操对照：同一个需求，两边的代码和接入方式长什么样

理论说了一堆，不如直接上手跑一遍。这里就拿前面“搜索商品并抓取列表数据”的需求来做样例，分别用 Browser-use 和 Playwright-MCP 走一遍。

3.1 Browser-use 的代码骨架

Browser-use 需要你写 Python 代码来定义一个异步任务，核心是Agent这个类。你要指定模型、指定任务目标、指定需要使用的浏览器工具。以下是一个最精简但能跑的骨架：

import asyncio from browser_use import Agent, Browser from langchain_openai import ChatOpenAI async def run_task(): # 初始化浏览器实例 browser = Browser() # 初始化模型。这里用 OpenAI 兼容接口，其他模型同理 llm = ChatOpenAI( model="gpt-4o", temperature=0, ) # 创建 Agent，传入任务目标 agent = Agent( task="打开某个电商网站的搜索页，输入关键词‘无线耳机’，" "点击搜索按钮，然后把第一页每个商品的价格和销量抓下来，" "以 JSON 格式输出", llm=llm, browser=browser, ) # 启动任务，拿到最终结果 history = await agent.run(max_steps=30) final_result = history.final_result() print(final_result) await browser.close() if __name__ == "__main__": asyncio.run(run_task())

这里面最值得关注的是task参数。它不是一段固定的操作指令，而是一个目标描述。你写得越接近真实的业务语义，模型自己对步骤的拆解就越合理。比如上面这段里我说“抓下来”，模型就会判断需要读取哪些节点；如果我说“整理成表格输出”，模型甚至会把表格结构也生成出来。

另外值得提一句的是max_steps参数。它限制了模型最多执行多少步动作，是防止模型陷入死循环的关键防线。实际项目中我一般会根据任务复杂程度设置在 20~50 步之间，而且会在任务描述里加一句“如果尝试 3 次都失败，就停止并报告原因”，这样能避免模型在一个弹窗上反复折腾。

3.2 Playwright-MCP 的接入方式

Playwright-MCP 这边则完全是另一种体验。你不需要在自己的程序里写任何编排逻辑，只需要启动一个 MCP 服务器，然后去支持 MCP 的客户端里配置连接。

MCP 服务器的启动命令一般是这样的：

# 以 stdio 模式启动 Playwright MCP 服务器 npx @playwright/mcp@latest

如果你用的是某个支持 MCP 的桌面对话应用，通常只需要在“添加 MCP 服务器”的配置界面里填一条命令：

{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] } } }

配置完成之后，接下来就是纯对话。比如你可以在对话框里输入“打开https://example.com的搜索页面，在搜索框输入无线耳机，点击搜索，把第一页搜索结果里的商品标题和价格列出来”。模型会自行调用browser_navigate、browser_click、browser_snapshot这类工具，一步一问地完成操作。

注意这里的关键词是“一步一问”。如果你的指令是一整段复杂的任务描述，模型通常也会尝试一次性把步骤全部规划出来，但在 MCP 模式下，它拿到页面状态后会停下来等你确认，尤其是遇到了登录、验证码、弹窗这类模糊场景。这种“每走一步都需要人类在场”的交互，对某些需求来说是麻烦，对另外一些需求来说是安全保障。

3.3 两种模式下“人类介入程度”的天壤之别

从上面的代码和配置其实已经能看出，两者的最大分化点在于整个流程里人的位置。

Browser-use 模式下，任务一旦启动，程序就像一个实习生被下达了“把这件事办完”的指令，除非你加了复杂的回调逻辑，否则它默认不需要你参与每一步。我见过有人在生产环境里用 Browser-use 跑定时采集任务，配合代理池和结果校验，每周无人值守跑几百个页面，靠的就是这套逻辑。

Playwright-MCP 模式下，人的角色更像是一个“监工”，模型是“操作员”。每一步操作都在对话里透明可见，你想打断就打断，想纠正就纠正。这个特性决定了它特别适合用在需要决策辅助的场景里，比如你正在做一个竞品页面分析，想让模型帮你点开几个 tab 看看布局；或者你在 IDE 里写前端，想让模型打开 localhost 页面验证某个交互效果。

4. Token 成本、稳定性与可控性：选型的隐藏决定性因素

很多人选型只看“代码好不好写”和“效果猛不猛”，忽略了成本模型和稳定性约束。这两个因素在项目跑到中期时，往往会反过来主导技术决策。

4.1 Token 消耗逻辑完全不同

先算一笔账。Browser-use 在执行每一步操作前，都要把压缩后的页面 DOM 连同操作历史发给模型。一个中等复杂度的页面，光 DOM 快照就可能占掉 3000~6000 个 token；如果还附带页面截图，那成本还要叠加（视觉输入的 token 通常按图像分辨率折算，一张截图可能等同于几百到一千多个 token）。

假设一个采集任务需要执行 30 步操作，每步平均消耗 5000 token，那单次任务大概会烧掉 15 万 token。如果每天跑 100 次，那就是 1500 万 token。这个数字在商用 API 的价格体系下，是一个完全不能忽略的日常开支。

Playwright-MCP 的成本模型就要分情况看了。如果你在对话里明确告诉模型“读取当前页面的可见文本”，模型调用的工具只会返回精简后的文本信息，token 消耗可能只有几百；但如果你让模型频繁使用截图功能，或者让它打开元素树查看完整 DOM，消耗就会飙升。换句话说，MCP 的成本更取决于使用者怎么和模型对话，而 Browser-use 的成本更多取决于页面本身有多复杂。

我自己的经验是：对于同样一个“抓取列表页 20 条商品信息”的任务，用 Browser-use 跑一次完整流程，API 费用大约是用 Playwright-MCP 在对话里手动操作的 3~5 倍。但如果不让模型自主跑，就得付出额外的人工时间盯着它操作，这笔人力账要怎么算，每个团队的情况不一样。

4.2 稳定性和可控程度

稳定性这个问题，我用“可控性”来定义可能更准确。

Browser-use 的可控性在于“任务层面”：你给它一个目标，它会想尽办法完成它。但代价是它在“过程层面”是不稳定的，每一次执行的具体操作路径可能都不同。这对某些场景来说是优点（能处理异常页面），对另外一些场景来说是缺点（不好做回归测试、不好复现 bug）。

Playwright-MCP 的可控性在“操作层面”：每一步操作都由当前对话指令驱动，如果你想让它“点两次同一个按钮”，它会老老实实点两次。但在任务层面，它反而不适合做长链路的自动化——因为指令太多之后，上下文窗口容易被对话历史撑爆，模型也容易忘记前面已经做过什么。

我在某高校实验室帮学生调试过一个用 Browser-use 做文献信息批量抓取的项目，碰到过非常典型的问题：模型跑到第 14 步时突然把页码从“2”点成了“退出登录”，而且它对自己的失误毫无感知，继续在未登录状态下尝试访问受限页面。这种问题在 Playwright-MCP 的对话模式下几乎不会发生，因为人会在对话里立刻纠正。反过来说，如果要在无人值守的服务器上连续跑 8 小时任务，Playwright-MCP 那套“每一步都要人回话”的模式根本做不了。

4.3 场景匹配：什么样的需求用什么样的工具

结合成本和可控性的讨论，我整理了一份选型对照表，基本覆盖了我在实践中遇到的主要场景：

这张表是我多次踩坑后的经验总结，不是理论推演。尤其是最后一行“数据分析师做探索性网页调研”，我见过太多非技术背景的人被爬虫门槛劝退，而 Playwright-MCP 能让他们用自然语言完成浏览、点击、提取的全过程，这才是它真正的应用价值。

5. 踩坑实录：两边各自让人抓狂的地方，以及我的解法

写代码一时爽，排坑火葬场。这里我没有办法面面俱到，只挑几个我在实际项目里反复遇到、而且非常具有代表性的问题，把它拆透。

5.1 Browser-use：页面状态感知迟钝与“幻觉操作”

Browser-use 最常见的坑就是模型对页面状态的变化感知不够及时。比如页面正在加载时，模型已经尝试点击某个还没出现的元素，结果点击失败，它又根据失败结果重新猜测，最后陷入“点击-失败-猜测-再点击”的循环里。

我第一次跑通一个登录流程时就卡在这上面：模型在输入完用户名密码之后，点击登录按钮时速度太快，页面还没来得及完成跳转，模型就判断“登录按钮没有响应”，然后擅自刷新了页面，结果用户信息被清空。整个过程看下来既合理又离谱。

我的解决办法是：在做关键操作之后，强制加入等待节点。具体来说有两个技巧：

1. 在任务描述中明确写上“每次点击后等待页面出现明显变化，再进入下一步”；
2. 在浏览器工具的调用参数里，设置固定的等待时间，比如点击后等 2 秒。

不要小看这种“笨办法”。大模型很擅长利用你给的约束条件，你越是把延迟策略说清楚，它就越不容易被瞬时状态误导。另外，我还习惯给每个Agent任务加一个“重新尝试 2 次”的护栏，如果同一个操作连续失败两次就跳过或终止，宁可漏一个数据也好过让它在错误路径上越走越远。

另一个坑是幻觉操作。模型经常会“看到”页面上根本不存在的元素——这种情况多出现在截图缩略、DOM 提取不完整的时候。它可能会输出一个包含完整参数的点击动作，但目标元素 ID 并不存在，执行结果自然是失败。遇到这种问题，优先检查框架发给模型的页面快照是否完整，而不是急着换模型参数。我调试的时候，会先把 DOM 快照打印出来看一眼，看模型“看到”的页面和实际页面差多少。

5.2 Playwright-MCP：上下文污染和浏览器实例隔离问题

Playwright-MCP 的坑主要集中在“对话环境”上。

第一个非常典型的问题是上下文污染。MCP 服务器可能在同一个浏览器实例上打开过很多不同的页面，如果你在某个对话里先访问了 A 网站，又访问了 B 网站，那么之前页面的状态仍然游离在浏览器进程里。模型如果不够严谨，可能会拿着前一个页面的截图去匹配后一个页面的元素，产生张冠李戴的操作。

我的做法是每次开始一个新的调研任务，先让模型执行“关闭所有标签页并打开新页面”的指令，如果客户端支持的话，还可以直接给 MCP 服务器配置--isolated参数，让它每次启动都用独立的用户数据目录。这样能避免大部分跨站状态污染。

第二个坑是图片类页面操作的低效。有些网站会把关键信息直接绘制在 canvas 里，不用 DOM 节点承载。Playwright-MCP 的默认工具集基于 DOM 操作，遇到 canvas 只能靠截图。而截图又需要模型具备视觉理解能力，token 消耗和延迟都会大幅上升。遇到这种页面，我通常是干脆放弃 MCP 的对话式操作，自己写一小段 Playwright 脚本把 canvas 里的数据抓出来，再回到对话环境里继续后续步骤。

5.3 一个我目前在用的取巧组合方案

如果项目既想要 Browser-use 的自主性，又想要 MCP 的交互性，其实可以两个一起用。我在几个实际项目里摸索出一种组合模式：用 Playwright-MCP 做前期探索和流程设计，再用 Browser-use 做批量执行。

具体操作是这样的：先用 Playwright-MCP 在对话里手动走一遍完整的业务流程，把每一步的 URL 变化、元素选择器、需要等待的条件都记录下来。当一个流程验证通过之后，再把这些信息整理成 Browser-use 的任务描述或者约束条件，直接丢给脚本批量跑。相当于用人工对话“教”了一次模型怎么做事，然后再让它规模化复现。

这个方案的好处很明显：前一步能把流程走通并且发现各种边界情况，后一步能充分利用大模型的自主性和容错能力，整体投入的人工时间最少。缺点也很明显，就是整个流程的搭建周期会长一点，适合那种流程灵敏度高、需要频繁调整的项目。

最后分享一个关于投入产出比的小经验

写到这，我并没有打算给一个“最终选择谁”的答案，因为答案完全取决于你手头的项目形态。我个人的体会是：如果在你的工作流里，人愿意待在屏幕前，Playwright-MCP 带给你的体验远大于 Browser-use；如果人不想待在屏幕前，那就咬咬牙用 Browser-use 并接受它的不确定性，然后把 token 预算和重试机制设计好。

最后再补充一个很多新手容易忽略的细节：无论选哪个方案，都不要让大模型直接操作生产环境的核心业务系统。大模型浏览器自动化的容错率远没有传统自动化脚本那么高，适合它发挥价值的场景，永远是那种“错了也没关系，可以重来一次”的任务。先拿一个低频、低风险的流程跑通，跑顺三个星期，再考虑扩大范围，这个顺序比什么都重要。