——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 手里？
mindmap
root((开浏览器赛道))
MCP 插件形态
playwright
25个MCP工具
可达性快照
独立 CLI 形态
agent-browser
不占MCP连接位
跨客户端复用
技能文件形态
chrome-automation
单个SKILL.md起步
邻位补刀
screenshot
web-access
主角先拆最重的。本会话环境实测装着 playwright 插件，它不是一份 SKILL.md 提示词，而是一整套 MCP 工具面——数下来整整 25 个，工具名全部以 browser_ 开头。这 25 个工具本身，就是一份值得逐段读的“技能设计文档”。
整个工具面里最体现设计意图的是 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"（比整棵快照便宜）。页面很大时不必每次全量拉树，搜到目标节点及其上下文即可。一个负责全量、一个负责检索，感知层的两件套分工清楚。
定位之后是动手。交互类工具覆盖得相当细：
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 四个动作管理多标签）这层最容易被竞品忽略，也是 playwright 明显厚的地方：
browser_console_messages：按 error / warning / info / debug 分级拉控制台，还有 all 参数跨导航取全程日志browser_network_requests：列出本次页面加载以来的网络请求，filter 参数直接收正则，比如只看 /api/.*userbrowser_network_request：按序号取单个请求的完整头与体，四个 part 可选：请求头、请求体、响应头、响应体这意味着 Agent 开浏览器不只是“操作”，还能做验证：点完按钮看控制台有没有红字，提交表单后看接口返回了什么。这是把“网页自动化”升级成“网页调试”的关键三件。
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 工具面的权限边界，最终靠显式命名来守。逃生舱给了（快照模型覆盖不到的场景，总需要一段自由代码），但让每个调用方在授权时都看清自己在批什么。
把 25 个工具摆开看，playwright 的 SKILL.md 级设计逻辑有三条：
unsafe 后缀 + 描述里的 RCE 警示，把安全决策推回授权层第二名 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 在装机名录里真实存在，其技能文件内容本文却无法取得（本环境未能读取其安装目录，也未能在截稿前抓取其源仓库）。一个只有名字、没有内容的评测对象，打几颗星都是编。
所以对它只说三件确定的事：
web-access 和 screenshot 两个邻位件则揭示了赛道的另一面：不是所有“开浏览器”的需求都需要真开浏览器。抓静态内容，网页访问件够了；记录页面外观，截屏件够了。三个操作型竞品抢的是中间那段——需要交互和验证的动态页面。这段需求最肥，也最难。
“评不了第三名”这件事本身，是本篇最想留给读者的横评方法论：同赛道横评的可比性，取决于你能拿到多少第一手材料。拿到工具面就拆工具面，拿到 SKILL.md 就拆结构，只拿到名字就明说样本不足。硬凑一张五星表，是评测文最常见的造假方式。
用一张流程图收拢 playwright 的典型工作方式——这也是所有“快照派”工具的通用循环：
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 留档"]
注意那个回边：操作之后重新拉快照，是快照派的核心纪律——永远基于当前树行动，不凭记忆点坐标。
# 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 为准，本文不替读者猜命令。
按场景排名，不按总分排名：
web-access 和 screenshot 更便宜。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 等场景全覆盖。