前两年大家对大模型的期待，主要还是“会写、会答、会总结”。但到了这两年，越来越多团队突然开始关心另一件事：怎么让 AI 真正去操作网页。
这不是一个小变化。因为互联网里最真实、最杂乱、也最有价值的大量工作，本来就发生在浏览器里：登录后台、查价格、复制信息、填表单、下指令、看仪表盘、切换页面、处理异常弹窗。
如果 AI 只能聊天，它再聪明，很多事情也只能停留在“告诉你怎么做”。可一旦它开始会点网页、读页面、切换标签、执行流程，Agent 才第一次接近“真的能干活”。
一、为什么“浏览器能力”会突然变成 Agent 的核心战场？
因为太多真实工作没有标准 API。
很多人最初做自动化时，会默认认为：只要系统足够现代，就一定有 API。现实恰恰相反。大量企业后台、运营平台、B 端工具、行业系统，接口并不开放，或者开放得很不完整。最稳定、最通用的入口，反而是网页本身。
这意味着，只要你想让 AI 进入真实业务流程，它迟早会面对浏览器。
比如这些任务：
- 到后台核对订单状态
- 打开广告平台查看投放数据
- 在 CRM 里查联系人并补录字段
- 去官网、论坛、电商站抓取公开信息
- 在管理系统里批量提交、审批、导出
这些事情，本质上都不是“知识回答”，而是“网页工作流执行”。
二、这也是为什么 Browser Use 会爆红
如果说这一波“AI 操作网页”浪潮里最有代表性的项目之一，Browser Use 一定排得上号。
截至 2026-04-15，browser-use/browser-use 的 GitHub Star 约为 87898，最近仍在持续更新。它的项目描述非常直接：让网站对 AI Agent 可访问，并让在线任务自动化变得更容易。
它为什么吸引人？因为它不是把浏览器当成一个附属能力，而是直接把“浏览器”变成 Agent 的主战场之一。
从公开文档看，Browser Use 的核心特点有几件事：
1. 它是 Agent-first 的
你不是在手写一长串固定脚本，而是给出任务，让 Agent
在浏览器环境里一步步推进。它支持较高步数上限、失败重试、视觉处理、结构化输出、fallback LLM 等机制，本质上更像一个“可执行网页任务的智能体框架”。
2. 它同时重视视觉与结构
它支持截图参与，也支持页面内容提取和浏览器会话控制。这一点很关键。纯视觉容易脆弱，纯 DOM 又可能不够理解真实页面语义，而 Browser Use 的路线更像是在二者之间找平衡。
3. 它考虑了真实运行时问题
比如 allowed_domains、prohibited_domains、keep_alive、user_data_dir、storage_state、proxy、权限配置等。这些参数看起来不像“炫技能力”，但它们决定了系统能不能进入真实生产环境。
换句话说，Browser Use 的真正价值，不只是会自动点按钮，而是开始认真处理“Agent 如何在浏览器里长期活着”这个问题。
三、但 Browser Use 不是唯一答案，Playwright MCP 代表了另一条路线
如果说 Browser Use 更像“完整网页 Agent 框架”，那么 Microsoft 的 Playwright MCP 更像“把成熟浏览器自动化能力包装成标准化 AI 接口”。
截至 2026-04-15，microsoft/playwright-mcp 的 GitHub Star 约为 30867，同样保持高频更新。
它的 README 里有一句非常值得注意的话：这个 MCP Server 通过 Playwright 提供浏览器自动化能力，并使用结构化的 accessibility snapshot，让 LLM 不必依赖截图或视觉模型，也能与页面交互。
这句话的含义很重要。
它代表的是另一种设计哲学：
- 尽量不要让模型盯着像素猜
- 尽量把页面转成结构化、可遍历、可定位的信息
- 尽量让交互更确定、更可复现
这条路线的优势非常明显：
- 更省 token
- 更适合自动测试和工程场景
- 更容易做确定性复现
- 对视觉模型依赖更低
但它也有边界：
当页面视觉语义非常强、布局复杂、广告弹窗很多、非标准控件很多时，纯结构化视图未必总是够用。
所以你会发现，今天网页 Agent 领域其实并不是“谁对谁错”，而是在探索不同任务适合怎样的表示层。
四、真正的分水岭，不是“会不会点”，而是“能不能持续完成”
很多网页 Agent demo 看起来都很惊艳：
- 会打开网站
- 会输入关键词
- 会点击按钮
- 会拿到结果
但只要把任务稍微拉长，难题立刻就来了：
1. 页面会变化
元素位置、按钮文案、加载顺序、弹窗逻辑，都可能变化。一次能跑通，不等于每天都能跑通。
2. 网站并不配合你
登录态会失效，验证码会出现，反爬会加强，请求会限流，区域网络会不同。
3. 模型很容易“自信误操作”
AI 最危险的时候，不是完全不会做，而是做得像模像样但方向错了。网页场景里，一个错误点击就可能带来真实业务后果。
所以，浏览器 Agent 的真正难点从来不只是“执行动作”，而是：
- 识别当前状态
- 判断下一步目标
- 在失败后恢复
- 确保权限边界
- 在长流程中保持上下文一致
这也是为什么很多成熟项目开始同时重视观察、规划、执行、重试和约束，而不是只强调单步操作能力。
五、如果把 Browser Use 和 Playwright MCP 放在一起看，差异在哪里？
可以把两者粗略理解成两种偏好不同的路线。
1. Browser Use 更偏“开放式任务执行”
它更适合需要 Agent 自主推进、跨页面探索、结合视觉与工具、处理复杂环境变化的任务。它的吸引力在于灵活、像人、任务感强。
2. Playwright MCP 更偏“工程化浏览器能力暴露”
它更适合把已有的浏览器自动化能力，通过 MCP 暴露给 AI 客户端，尤其适合强调结构化、稳定性和可控性的场景。它的吸引力在于明确、可组合、易接入 MCP 生态。
3. 两者共同说明了一件事
浏览器正在从“自动化测试工具的地盘”，变成“AI Agent 的基础设施层”。
这件事的意义，比单个项目的 Star 数更大。
六、为什么网页 Agent 会成为下一代 AI 产品的关键能力？
因为浏览器几乎就是数字世界的通用操作台。
API 是理想世界的接口，浏览器是现实世界的接口。
在很多公司里，真正能跑业务的人，不是因为他懂所有底层系统，而是因为他会在一堆网页之间切换、判断、录入、确认、追踪。现在，AI 正在被训练成这种新的“网页型执行者”。
一旦这条路继续成熟，会出现非常具体的变化：
- 客服和运营流程会出现更多半自动代理
- 数据搜集、竞品监测、报价整理会更容易自动化
- 没有完善 API 的老系统，会重新被 AI 激活
- 个人工作流里，大量“打开网页点几下”的重复操作会被接管
七、但网页 Agent 最终不会只有“一个大脑”
很多人想象中的网页 Agent，是一个万能模型盯着页面一路做完所有事。现实更可能是分层协作：
- 有的模块负责理解页面结构
- 有的模块负责视觉判断
- 有的模块负责计划与反思
- 有的模块负责执行与回滚
- 有的模块负责权限控制和人工确认
也就是说，未来真正好用的网页 Agent，不会只是“更会点”，而会更像一个有纪律的执行系统。
八、最后给一个判断：浏览器能力，决定了 Agent 是否真的走出聊天框
今天很多 AI 产品还停留在“给建议”的阶段，这当然已经很有价值。但如果你关心的是生产力、流程自动化、业务接入、企业落地，那浏览器能力几乎绕不过去。
Browser Use 的爆发、Playwright MCP 的快速增长，都在说明同一件事：行业已经不满足于让模型会说，开始认真训练它去做。
而“做”这件事，浏览器往往就是第一现场。
所以，别把网页自动化理解成 Agent 里的一个小插件。它更可能是未来几年里，决定 AI 能不能从聊天助手进化成工作助手的关键分水岭。
更多内容欢迎关注公众号：
