企业官网建设流程全解析

大模型浏览器自动化这两年热度一直没降，我身边做爬虫、做RPA、做 agent 的同事，几乎都在试同一个方向：让大模型自己打开网页、自己点按钮、自己读内容。可一旦真开始选型，马上就会撞上两个高频词：Browser-use 和 Playwright-MCP。光看名字，这俩都像“用 Playwright 把浏览器交给大模型”，所以很多人误以为它们是同一件事的两种实现。我自己最初也这么以为，直到把两个方案都跑完几个任务，才发现它们从架构定位上就完全不一样。

这篇文章不讲废话，直接把两边的核心差别、代码写法、选型逻辑和踩坑点一次说明白。适合谁看？正在做 LLM 自动化任务、纠结用哪个方案的人，以及想快速判断哪个工具更贴合自己场景的同学。如果你只是听过这两个名字、还没动手写代码，那这篇文章也能帮你省下不少试错时间。

1. 都是大模型浏览器自动化，但一个像大脑，一个像工具箱

先别急着比功能差异，第一步要分清楚：这俩根本不是同一个层面的东西。一个是完整的 agent 运行时，一个是把浏览器封装成标准化接口的服务层。很多人选型选错了，就是因为把“浏览器自动化框架”和“MCP 工具服务”硬放在同一维度去比较。

1.1 Browser-use：自带 Agent 循环的 Python 框架

Browser-use 本质上是一个 Python 库，核心是“让大模型自己规划动作、执行动作、观察结果、再规划下一个动作”的闭环。它内部有一个 Agent 类，你只需要给它一个任务描述，比如“打开某个文档站，搜索 MCP，提取第一页标题”，它就会自动进入循环：抓取当前页面快照、把快照喂给 LLM、得到下一步动作、通过 Playwright 执行这个动作、然后重新观察页面。

这个设计最大的特点是“决策权在框架内部”。你不需要自己写 agent 循环，不用去维护“下一步该干什么”的状态机，框架自己把 LLM 的推理结果转成浏览器操作。它还支持注册自定义工具，比如让 agent 在操作页面之外去调用你自己的内部 API、查数据库、做计算，相当于把浏览器操作扩展成了整个任务执行链路的一部分。

另外一个容易忽略的特点是它自带可视化回放。任务跑完之后，你会得到完整的动作历史，可以按步骤回看每一步的状态、截图、模型思考过程。这一点在做调试和给同事展示效果的时候非常有用。

1.2 Playwright-MCP：把浏览器能力打包成 MCP 工具

Playwright-MCP 是另一条路线。它不是一个 agent 框架，而是一个 MCP server。MCP 是模型上下文协议，你可以简单理解成“给大模型外挂工具的标准插座”。Playwright-MCP 做的就是把这个插座里的浏览器工具都填进去：打开页面、点击、输入、滚动、截图、读取可访问性快照、管理标签页，甚至连接你已经打开的 Chrome。

在这里，决策权不在 Playwright-MCP 里面。它只负责“被执行”，不负责“决定怎么做”。谁决定下一步？是接入它的那个 MCP 客户端，也就是宿主 LLM，或者是你在客户端里写好的 workflow。这跟 Browser-use 的“agent 闭环”是两种完全不同的架构思想：一个是你把任务交给一个会思考的代理，另一个是你把一堆工具交给一个会思考的大脑，让大脑自己指挥工具。

MCP 的标准化也带来了一个很实际的优势：只要支持 MCP 协议，任何客户端都能接入。桌面助手类产品、IDE 插件、你自己的 Python 服务，都可以复用同一套浏览器工具集。你不需要为每个宿主环境单独封装 Playwright。

1.3 一句人话总结两者的定位差

用开车来打比方：Browser-use 是“自动驾驶方案”，你告诉它去哪儿，它自己规划路线、自己打方向盘；Playwright-MCP 是“方向盘、油门、仪表盘”，它把底层控制能力暴露给你，但要由驾驶员（宿主 LLM）来决定往哪开、什么时候刹车。

但这并不代表“自动驾驶”一定更好。自动驾驶在复杂路况下可能犯迷糊，而手动驾驶虽然每一步都要自己做决策，但你能精确知道当前在哪个路口，也更容易纠正路线。定位差异决定了两者适合完全不同的应用场景，后面我会拆开细讲。

还有一个共同点需要记住：它们底层跑的都是 Playwright。也就是说，浏览器级别的兼容问题、页面加载超时、元素遮挡、iframe 问题，这些坑两边都会遇到。差别只在于“谁来定位元素”和“谁来编排步骤”。

2. 核心差别：决策权、元素定位、浏览器接管方式

前面说的是顶层架构，本节落到实际使用中最关键的三个差异点：谁来做多步决策、怎么定位页面元素、怎么管理浏览器实例。这三个问题决定了你的代码长什么样，也决定了任务跑起来之后的稳定性和成本。

2.1 决策权在谁手里：内置循环 vs 宿主调度

Browser-use 的执行单位是“任务”。你把任务描述给它，它内部有一个 Agent 主循环，每一轮都会经历“观察页面 → 推理决策 → 执行动作 → 记录结果”的过程。它自己判断任务是否完成，自己决定当页面出现意外时应该重试还是换一条路径。max_steps参数用来限制最大轮数，防止模型陷入死循环。

这意味着你不需要操心“怎么把任务拆成一步步操作”。哪怕你只说“帮我对比三个平台的价格，总结差异”，只要页面结构不是特别刁钻，Browser-use 也能自己拆解成多次搜索、多次访问、逐页提取。对开放型任务非常友好。

Playwright-MCP 没有任务循环。它向客户端暴露的是一组原子工具：browser_navigate、browser_click、browser_fill、browser_snapshot等等。每一步动作都由宿主 LLM 决定调用哪个工具，MCP server 只是接到调用后执行并返回结果。所以你实际看到的工作方式是“对话式”：你发起一个需求，LLM 思考后决定调用某个工具，拿到结果后再决定下一个动作。

这两者的直接差异是：如果你只有一个非常简单的 Python 脚本调用 Playwright-MCP，而不通过任何带 agent 能力的宿主，那它就只是一个普通的浏览器控制库，不会帮你做规划。Browser-use 就不一样，它自身就是规划器。在架构选型时，这一点会直接决定你要不要额外写一个“编排循环”的代码。

2.2 页面元素定位：语义推理快照 vs 结构化可访问性树

元素定位是浏览器自动化里最容易出问题的环节。传统 Playwright 用 CSS 选择器或 XPath，要求页面结构稳定。到了 LLM 自动化这里，思路变成“让模型理解页面，而不是让脚本匹配页面”。

Browser-use 的定位思路偏“语义推理”。它会抓取页面的可访问性树、文本内容、区域截图，把这些信息塞给 LLM，让模型判断“下一步要点哪个”。这样做的好处是抗页面结构变化，只要页面上还有那个功能，哪怕按钮位置变了、颜色变了，LLM 通常也能认出来。代价也非常直接：页面上下文很大，每一轮都要把页面描述发给 LLM，token 消耗不小。遇到那种几百个表单控件的复杂后台，快照很容易超长。

Playwright-MCP 更加结构化。它会对页面生成可访问性快照，给可交互元素标记 ref 编号，点击、填表工具可以直接按 ref 操作。同时它会生成 Playwright 定位器建议，底层还是getByRole、getByText、locator那一套。也就是说，它是把“精确定位”和“LLM 理解”结合了起来：LLM 不直接猜坐标，而是选择一个语义化元素或接受工具给出的 ref。

你可以这样理解：Browser-use 更依赖 LLM 的“看图说话”能力，Playwright-MCP 更依赖页面结构化的“语义锚点”。实际使用中，如果目标站点页面频繁改版、没有稳定 test-id，Browser-use 往往更耐折腾；如果你自己维护的站点，或者你有能力给页面加上稳定的>import asyncio from browser_use import Agent, Browser async def main(): browser = Browser() agent = Agent( task="打开 https://example.com/docs ，在搜索框输入 MCP，点击搜索按钮，列出第一页搜索结果标题，然后点击第一条结果，等待详情页加载完成。", browser=browser, llm=..., # 传入配置好的大模型实例 ) history = await agent.run(max_steps=20) # history 里包含每一步动作、状态和截图 print("任务完成，总步骤数:", len(history)) asyncio.run(main())

注意，整个代码里没有一句“怎么定位搜索框”。我不知道搜索框的 id、class、name，也不需要知道。LLM 会根据页面快照理解“这是搜索框”，然后调用框架内置的填表动作。这就是 Browser-use 的价值：把“怎么做”的问题交给模型，你只负责定义“做什么”。

max_steps=20是一个我很常用的安全阀。任务太复杂时，20 步可能不够，但先设置一个偏小的值可以避免模型在页面上反复试探浪费 token。跑通之后再逐步加大。

跑完后 history 里的内容很值得看。你会看到模型每一步都在想什么，它认为页面上哪里是可点击的，它为什么选择先滚动再点击。这些信息对排查问题非常有用。

3.3 Playwright-MCP 版本：对话式工具调用

Playwright-MCP 的典型用法是作为 MCP 服务接入到支持 MCP 的客户端里。启动命令大致是：

npx @playwright/mcp@latest

然后你在客户端里添加这个 server，接下来直接用自然语言对话，例如：

“打开 example.com/docs，搜索框输入 MCP，点击搜索，列出第一页标题，打开第一条。”

宿主 LLM 会自己决定调用browser_navigate、browser_fill、browser_click这些工具。你看到的是这个协议过程：

• LLM 调用browser_navigate，参数是https://example.com/docs；
• MCP server 返回页面加载完成后的可访问性快照；
• LLM 在快照里看到搜索框元素，调用browser_fill；
• 再调用browser_click触发搜索；
• 最后用工具提取标题列表。

如果你不想用现成客户端，而是想在 Python 代码里以编程方式调用它，也可以用 MCP 的 Python SDK 建设一个简易会话。下面的代码框架展示的是连接方式和列出工具，实际调用每个工具时再按需传参：

import asyncio from mcp import ClientSession, StdioServerParameters, stdio_client async def main(): params = StdioServerParameters(command="npx", args=["@playwright/mcp@latest"]) async with stdio_client(params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools = await session.list_tools() for t in tools.tools: print(t.name) asyncio.run(main())

你可以看到，MCP 模式的核心是“server 暴露工具，客户端调度工具”。它跟 Browser-use 最大的代码形态差异是：Browser-use 用一个 Agent 把主循环、任务判断、执行能力全部内聚；MCP 模式下，server 只是工具的执行端，循环和判断都在调用方那里。

3.4 两条链路在浏览器内部经历了什么

从计算机角度画一下两者的执行链路，区别会更明显。Browser-use 链路是：任务描述 → Agent 循环启动 → 抓取页面快照和可交互元素 → 拼接 prompt 发给 LLM → LLM 返回“填写搜索框，值为 MCP” → Agent 调用 Playwright 执行 → 再次抓取快照 → 判断是否完成。整个过程是闭环，框架自身负责每个环节。

Playwright-MCP 链路是：用户输入需求 → 宿主 LLM 看到 MCP 工具列表 → LLM 决定先调用browser_navigate→ MCP server 执行并返回页面快照 → LLM 根据快照决定browser_fill→ 如此循环直至需求完成。如果没有宿主 LLM，或者你只是写脚本固定调用这几个工具，那就退化成普通 Playwright 脚本。MCP 本身并不提供任务完成判断，它只是把“浏览器能力”以标准工具形式开放出去。

我把两者的关键差异整理成了一个表：

这张表基本上就是选型时的“速查地图”。

4. 实际选型怎么定：场景、成本、调试三维度

聊完差异，最终还是要落到“我该选哪个”。我的建议是别按“哪个更先进”来选，而是按场景、成本、调试体验三个维度来定。这三者甚至可能指向不同的方向，你需要结合自己的实际情况做取舍。

4.1 什么场景优先 Browser-use

第一类是无人值守的开放任务。你需要一个完全自动的链路，中间可能遇到各种计划外的页面变化，希望模型能随机应变。比如批量采集多个站点数据、自动巡检后台页面、做一个“由自然语言驱动”的 RPA 工具。Browser-use 的优势在这里最明显：你提交一个高层目标，它自己拆解成动作序列。

第二类是你已经在写 Python 服务，希望把 agent 能力直接内嵌到业务代码里。Browser-use 是以 Python 包的形式提供的，跟现有代码融合得很顺畅，不需要额外跑一个 server，也不需要解决 MCP 客户端和宿主 LLM 的配置问题。

第三类是你需要“可解释的轨迹”。它每一步的思考过程、动作、截图都被记录下来，适合复盘模型到底在页面上做了什么，也适合给没有技术背景的同事展示效果。

4.2 什么场景优先 Playwright-MCP

第一类是你已经深度使用 MCP 生态。桌面助手、IDE 插件、自定义 agent 服务，只要支持 MCP 协议，Playwright-MCP 就是即插即用的浏览器能力包。你不用为每个宿主重新写一遍浏览器控制逻辑，配置一次搞定，多端复用。

第二类是追求确定性和可控制性的任务。比如你已经知道每一步要操作哪个元素、点哪个按钮，只是想用 LLM 来帮你调度，而不是让 LLM 自己重新理解页面。Playwright-MCP 提供的结构化 ref 和稳定定位器，会让执行过程更可控，出错也更容易定位。

第三类是需要复用现有浏览器会话的场景。比如目标系统登录流程复杂，最好人工先登录，再把已打开页面交给 MCP 接管。这种情况下你直接连接现有 Chrome，避免代码里去处理登录态和验证码问题。Browser-use 虽然也能用 user data directory 做类似的事，但明显更繁琐。

4.3 从 token 消耗、稳定性、可调试性判断取舍

token 消耗方面，两者其实都不小，因为它们都需要把页面快照发给 LLM。但结构上有差异：Browser-use 每一轮循环都会重新组织页面快照和思考过程，一旦页面元素多，上下文会迅速膨胀。Playwright-MCP 由宿主 LLM 管理上下文，快照虽然也发，但工具粒度更小，你也可以在外层做上下文裁剪，成本控制更灵活一些。不过真正的瓶颈通常还是页面本身的可访问性树大小，这两个方案都会建议你把 viewport 调小、排除无关元素。

稳定性方面，底层同是 Playwright，浏览器操作本身的稳定性差异不大。差异主要体现在抗页面变化能力上：Browser-use 靠语义理解，页面结构变了也可能蒙对；Playwright-MCP 靠定位器和 ref，一旦页面结构大变，之前指定的元素可能找不到，需要重新快照再定位。但反过来，页面保持稳定时，Playwright-MCP 的确定性明显更好，不太会“灵机一动”点错按钮。

可调试性方面，Playwright-MCP 的优势是天然贴近 Playwright 生态。支持 DevTools 协议、支持 trace 回放、支持视频录制，甚至可以连接浏览器看实时日志。Browser-use 的调试主要依赖 agent 运行历史，它能告诉你“模型选择了什么”，但你要查底层 DOM 状态、网络请求，往往还得手动去浏览器里核对。

下面这张表是我个人选型时的常用参考：

5. 实测中的高频问题与排查技巧

工具跑起来之后，真正的战斗才刚开始。下面这些坑是我和身边同事实际踩过的，不是从文档里抄来的。按 Browser-use、Playwright-MCP、通用逻辑三块来写，希望能帮你少走点弯路。

5.1 Browser-use 踩坑实录

最容易遇到的坑是模型不支持工具调用，或者工具调用能力不稳。Browser-use 的每一步决策本质上依赖 LLM 按照约定输出结构化动作，如果模型工具调用格式偶尔出错，agent 就会在同一页面上反复横跳。我的处理方式有两个：一是换一个工具调用更稳的模型，二是把过大的页面快照精简后再喂给模型。

第二个高频坑是max_steps设置不合理。设太小，任务在关键时刻被截断，重跑时模型又要从头规划；设太大，模型可能会在页面上做出大量无意义尝试，白烧 token。我一般先设 15～20 步跑通主链路，成功后逐步增加到业务可接受的上线值。

第三个坑是页面上下文爆炸。某些后台页面光可访问性树就有几百个节点，塞进 prompt 后 LLM 反而抓不到重点。建议把浏览器窗口尺寸调小，限制可见区域；在任务描述里明确“只关注表格区”；实在不行就在 agent 工具层面过滤掉不需要的节点类型。

还有一个很隐蔽的问题：并发跑多个 agent 任务时，多个浏览器实例同时启动，资源竞争会让页面加载变慢。如果同时跑的任务很多，我建议给每个浏览器实例配置独立的 user data directory，并且控制并发数量，不要无脑开线程。

5.2 Playwright-MCP 踩坑实录

Playwright-MCP 这边第一个坑就是首次启动慢。通过npx启动时它要下载依赖包，网络状况不好时可能要等很久。可以提前在本地把 npm 包装好，配制到固定路径，这样每次启动都快很多，也不会因为临时目录被清理导致下次又得重新拉。

第二个坑是“接管现有浏览器”的细节。连接已有 Chrome 需要浏览器以调试端口模式启动，光装个 Playwright-MCP 是没人替你开这个端口的。你需要在启动浏览器时加上远程调试参数，并确认端口没被防火墙挡住。很多同学卡在这一步，其实是浏览器没开对，不是 MCP server 的问题。

第三个坑是快照过大拖垮性能。页面很复杂时，browser_snapshot返回的文本快照可能会有几十 KB，传回给 LLM 不仅慢，还容易把上下文填爆。建议先把 viewport 调小，配置里排除掉无关区域；如果页面有 iframe，也需要注意快照是否包含了嵌套帧里的内容，必要时单独定位。

第四个坑是“元素明明存在，但点击报错”。很多情况下是元素不在可视区内，浏览器拒绝交互。先滚动到元素附近再看快照里 ref 是否有变化，再执行点击。这也提醒我：不管哪个方案，遇到“我明明让模型点了，它却说点不到”的时候，第一反应都应该是检查元素是否可见，而不是怀疑模型瞎了。

5.3 两条路线通用排查思路

不管用哪边，有两件事建议放到第一步做：手动走一遍目标流程，确认页面本身正常；打开浏览器控制台和网络面板，观察异常请求和报错。很多自动化任务失败，不是工具问题，而是页面逻辑、权限、数据加载本身就出了问题。自动化和人工看到的页面状态一致时，才轮到模型和代码背锅。

另外要特别注意 iframe 和多窗口场景。页面内嵌 iframe 会让元素定位复杂度上升，Browser-use 和 Playwright-MCP 在 iframe 场景下都需要额外处理。多标签页场景更容易乱：页面一跳转，旧的标签页可能还挂着，工具却去操作了新标签。如果任务流程较长，建议把操作集中在同一个页面实例里，减少标签切换带来的状态混乱。

最后说一句合规层面的提醒：自动化浏览器操作不等于可以随便抓取任何站点。请优先遵守目标站点的服务协议和 robots 规范，对明显有访问限制的站点不要硬闯。工具能做和应该做，是两件事。把这个底线守住，后续扩展和使用才会更稳妥。

结合我自己的使用习惯来看，两套方案并不是只能二选一。我现在的做法是：开放、探索型的任务，先扔给 Browser-use 跑通思路；需要精确定位、严格验证每一步、或者要接入现有 MCP 基建时，再切换成 Playwright-MCP。你也可以把 MCP 的工具服务嵌入到自己的 agent 框架里，让两个生态互相配合。工具本身只是起点，真正见功夫的是你对任务场景的理解和对执行过程的控制能力。把基础打牢，哪种方案都能撑起你的自动化需求。