# 开浏览器这条赛道，挤了五个件 **——Skills 生态第 7 轮观察：浏览器自动化赛道同台横评** ## 概述 本篇是 Skills 生态系列第 7 轮，按惯例做同赛道横评：选一条赛道，把 3-4 个竞品 Skill 拉到同一张桌上逐项对比。本期选的赛道是**让 Claude 开浏览器**。起因是一次装机观察：在一个日常使用的 Claude Code 环境里，与浏览器相关的条目至少同时存在五个——`playwright`、`agent-browser`、`chrome-automation`、`web-access`、`screenshot`。需求已经收敛（Agent 要看网页、点按钮、填表单），但产品形态远未收敛：MCP 插件、独立 CLI、单个技能文件三种路线同场竞技。本文以第一手实测的 playwright 为主拆对象（其暴露的 25 个 MCP 工具全部过手），以 agent-browser 为形态对照，并讨论这个赛道里“评不了”的部分。 **说明**：本文截稿前未能联网核验外部数据，仓库星数、下载量一律不给；所有工具级细节来自本会话环境的真实工具定义，其余社区信息明确标注出处与核验状态。 ## 评测对比表 | 维度（权重） | playwright | agent-browser | chrome-automation | |---|---|---|---| | 功能完整度（25%） | ★★★★★ | ★★★★ | 待评 | | 设计质量（25%） | ★★★★★ | ★★★★ | 待评 | | 实战效果（20%） | ★★★★★ | ★★★☆ | 待评 | | 上手难度（15%） | ★★★★ | ★★★☆ | 待评 | | 生态热度*（15%） | ★★★★★ | ★★★★ | ★★★ | | **加权总分** | **4.85** | **3.8** | — | > \* 生态热度以“是否进入常用环境装机名录、是否被社区聚合站（skillsmp.com、skills.sh 等）收录讨论”为代理指标，非精确数据。chrome-automation 因其技能文件内容未能取得，按本文诚实原则不给评分，只做生态位讨论。 ## 一、赛道全景：一台机器上的五个条目 先说装机事实。在这台环境的可用技能名录里，浏览器相关条目如下，全部真实在装： - `playwright` —— 以插件形式提供，挂载为一批 `browser_*` 前缀的 MCP 工具 - `agent-browser` —— 名录在装，背后对应同名开源 CLI 项目 - `chrome-automation` —— 名录在装，技能文件形态 - `web-access` —— 名录在装，网页访问类 - `screenshot` —— 名录在装，截屏类 五个条目覆盖了同一条需求链的不同环节：抓内容（web-access）、看页面（screenshot）、操作页面（playwright / agent-browser / chrome-automation）。操作页面这个核心环节挤了三个竞品——这就是本期的横评主体。 一个赛道出现三个同位竞品，通常意味着两件事：需求是真的；技术路线还没收敛。浏览器自动化恰好是后者最极端的案例，因为它的底层就两条路——CDP（Chrome DevTools Protocol）直连，和 Playwright 这类成熟自动化框架封装。分歧不在底层，在**包装形态**：这套能力以什么形态交到 Agent 手里？ ```mermaid mindmap root((开浏览器赛道)) MCP 插件形态 playwright 25个MCP工具 可达性快照 独立 CLI 形态 agent-browser 不占MCP连接位 跨客户端复用 技能文件形态 chrome-automation 单个SKILL.md起步 邻位补刀 screenshot web-access ``` ## 二、深拆 playwright：25 个工具怎么分工 主角先拆最重的。本会话环境实测装着 playwright 插件，它不是一份 SKILL.md 提示词，而是一整套 MCP 工具面——数下来整整 **25 个**，工具名全部以 `browser_` 开头。这 25 个工具本身，就是一份值得逐段读的“技能设计文档”。 ### 2.1 感知层：快照优先，不是截屏优先 整个工具面里最体现设计意图的是 `browser_snapshot`，其官方描述原文是： > Capture accessibility snapshot of the current page, this is better than screenshot “比截图更好”——这句话是整条技术路线的纲领。传统 RPA 靠像素和坐标，Agent 开浏览器靠**可达性树**：页面被序列化成一棵带 `ref` 引用的结构化快照，模型读树、按 ref 定位元素、再发起操作。像素方案对分辨率和布局敏感，树方案对 AI 天然友好，因为这就是它最擅长读的东西。 配套还有个省钱设计：`browser_find`，描述写明它可以在快照树里按文本或正则搜索定位元素，"cheaper than capturing the whole snapshot"（比整棵快照便宜）。页面很大时不必每次全量拉树，搜到目标节点及其上下文即可。一个负责全量、一个负责检索，感知层的两件套分工清楚。 ### 2.2 交互层：每个读操作都有写操作配对 定位之后是动手。交互类工具覆盖得相当细： - `browser_click`：支持左中右键、双击、Alt/Control/Meta/Shift 修饰键 - `browser_type`：整段填入或逐键输入（`slowly` 参数，专门用于触发页面的按键事件监听） - `browser_fill_form`：批量填表，字段类型明确枚举为 textbox / checkbox / radio / combobox / slider 五种 - `browser_select_option`：下拉框，支持多选值数组 - `browser_hover`、`browser_drag`、`browser_press_key`：悬停、拖拽、按键 - `browser_navigate` / `browser_navigate_back` / `browser_tabs`（list / new / close / select 四个动作管理多标签） ### 2.3 观测层：把调试器搬进工具面 这层最容易被竞品忽略，也是 playwright 明显厚的地方： - `browser_console_messages`：按 error / warning / info / debug 分级拉控制台，还有 `all` 参数跨导航取全程日志 - `browser_network_requests`：列出本次页面加载以来的网络请求，`filter` 参数直接收正则，比如只看 `/api/.*user` - `browser_network_request`：按序号取单个请求的完整头与体，四个 part 可选：请求头、请求体、响应头、响应体 这意味着 Agent 开浏览器不只是“操作”，还能做**验证**：点完按钮看控制台有没有红字，提交表单后看接口返回了什么。这是把“网页自动化”升级成“网页调试”的关键三件。 ### 2.4 环境层与逃生舱 - `browser_emulate_media`：仿真暗色模式、减弱动效、强制高对比度等媒体特性 - `browser_resize`：调视口尺寸，测响应式布局用 - `browser_wait_for`：等某段文案出现或消失，或干脆等 N 秒 - `browser_file_upload`：接管文件选择器；`browser_drop`：向元素投掷文件或 MIME 数据 - `browser_handle_dialog`：处理原生弹窗，可选是否接受、填什么提示文本 最后是全工具面里命名最扎眼的一个：`browser_run_code_unsafe`。它的描述原文值得逐字读： > Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent. “等价于远程代码执行”。工具作者没有掩饰这个能力的危险性，反而把 `unsafe` 写进名字、把 RCE 写进描述。这呼应了本系列此前拆安全件时的观察：Agent 工具面的权限边界，最终靠**显式命名**来守。逃生舱给了（快照模型覆盖不到的场景，总需要一段自由代码），但让每个调用方在授权时都看清自己在批什么。 ### 2.5 设计哲学小结 把 25 个工具摆开看，playwright 的 SKILL.md 级设计逻辑有三条： 1. **给模型可达性树，不给像素**——感知层的根本取舍 2. **读操作与写操作严格配对**——navigate 配 navigate_back，snapshot 配 find，写完还能用 console / network 验证 3. **危险面显式命名**——`unsafe` 后缀 + 描述里的 RCE 警示，把安全决策推回授权层 ## 三、agent-browser：不占 MCP 位的那一派 第二名 agent-browser 走的是另一条路：它不是 MCP 工具面，而是**独立 CLI**。名录在装是第一手事实；其背后同名开源项目以命令行工具形态运作、采用与“快照 + ref 引用”同源的交互模型（打开页面、拉快照、按元素引用点击），此点据该项目公开介绍，**本文截稿前未做二次核验**，细节以仓库 README 为准。 撇开实现细节，CLI 形态与 MCP 形态的**结构性差异**是可以纯分析讲清的： | 结构维度 | MCP 插件（playwright） | 独立 CLI（agent-browser） | |---|---|---| | 能力暴露方式 | 启动时挂载工具面，常驻会话 | SKILL.md 教模型按需调命令 | | 连接位成本 | 占 MCP 服务器配置位 | 不占，就是一个可执行文件 | | 跨客户端复用 | 每个 MCP 客户端各配一遍 | 装一次，任何能跑 Bash 的 Agent 都能用 | | 发现成本 | 工具面全部可见，模型“看得见”能力 | 模型要先读过 SKILL.md 才知道有这能力 | | 升级耦合 | 插件版本与服务端版本绑定 | CLI 与技能文档可各自演进 | 这张表解释了为什么赛道没收敛：MCP 形态赢在**能力可见性**——工具面摆在那里，模型天然知道能干什么，不用提示词教育；CLI 形态赢在**部署轻量与通用性**——不挑客户端、不占配置、一套命令行走天下。两者是工程权衡，不是技术优劣。playwright 拿 25 个工具换“开箱即知”，agent-browser 拿一份 SKILL.md 换“处处能跑”。 实战层面本文对 agent-browser 只给中等把握评分（★★★☆）：形态优势成立，但本次未能实测其快照质量与稳定性，不替它背书。 ## 四、chrome-automation 与赛道长尾：评不了，也是发现 按横评惯例，第三个竞品应该同样逐项打分。但这里必须先讲一个生态的真实状况：chrome-automation 在装机名录里真实存在，其技能文件内容本文却无法取得（本环境未能读取其安装目录，也未能在截稿前抓取其源仓库）。一个只有名字、没有内容的评测对象，打几颗星都是编。 所以对它只说三件确定的事： 1. **它存在，且被装进了常用环境**——说明安装渠道通畅，至少有真实用户 2. **命名直白**——"chrome + automation"，从名字即可判断生态位：围绕 Chrome 做自动化，与 playwright 的“框架无关”路线可能存在差异（此为推断，非核验结论） 3. **技能文件形态的单件成本最低**——一个 SKILL.md 就能上架，这正是技能生态的入口红利，也是入口泥沙 `web-access` 和 `screenshot` 两个邻位件则揭示了赛道的另一面：不是所有“开浏览器”的需求都需要真开浏览器。抓静态内容，网页访问件够了；记录页面外观，截屏件够了。三个操作型竞品抢的是中间那段——**需要交互和验证的动态页面**。这段需求最肥，也最难。 “评不了第三名”这件事本身，是本篇最想留给读者的横评方法论：**同赛道横评的可比性，取决于你能拿到多少第一手材料**。拿到工具面就拆工具面，拿到 SKILL.md 就拆结构，只拿到名字就明说样本不足。硬凑一张五星表，是评测文最常见的造假方式。 ## 五、playwright 感知-操作循环 用一张流程图收拢 playwright 的典型工作方式——这也是所有“快照派”工具的通用循环： ```mermaid flowchart TD A["用户一句话指令"] --> B["browser_navigate 打开页面"] B --> C["browser_snapshot 拉可达性树"] C --> D["browser_find 按需检索节点"] D --> E["模型按 ref 定位元素"] E --> F["click 或 fill_form 操作"] F --> G["console 与 network 验证"] G --> H{"状态符合预期吗"} H -->|否| I["browser_wait_for 等待"] I --> C H -->|是| J["take_screenshot 留档"] ``` 注意那个回边：操作之后重新拉快照，是快照派的核心纪律——**永远基于当前树行动，不凭记忆点坐标**。 ## 六、安装与上手命令 ```bash # playwright：以 MCP 插件接入（包名以微软官方仓库说明为准） claude mcp add playwright -- npx @playwright/mcp@latest # agent-browser / chrome-automation：先用 skills CLI 检索，再按各自仓库说明安装 npx skills find agent-browser npx skills find chrome-automation ``` playwright 的接入命令是社区通行的标准写法；另两件的安装方式请以检索到的仓库 README 为准，本文不替读者猜命令。 ## 七、推荐排行榜 **按场景排名，不按总分排名：** 1. **长会话深度测试**（登录流程、多步表单、提交后验证接口）→ **playwright**。25 个工具的观测层没有对手，控制台加网络请求两件套是验证闭环的关键。 2. **多客户端复用、连接位紧张**（同时用多个 Agent 工具，MCP 配置位不够分）→ **agent-browser**。CLI 形态的结构优势场景，装一次处处跑。 3. **轻量单页交互**（填一个表单、点一个按钮）→ **chrome-automation** 类技能文件件。单件成本低，够用就好，前提是你读得懂它的 SKILL.md。 4. **静态内容抓取与外观留档** → 别进这条赛道，`web-access` 和 `screenshot` 更便宜。 5. **需要执行任意页面脚本的特殊场景** → playwright 的 `browser_run_code_unsafe` 是明码标价的逃生舱，授权前想清楚 RCE 四个字母。 ## 参考来源 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。