浏览器自动化工具横评
主要对比以下工具的功能差异，和用途用法介绍。
- chrome devtools mcp
- playwright
- ego lite
- browser use
- codex chrome插件/内置浏览器
首先从原理上来讲，这些工具都基于CDP (chrome debug protocol)提供的接口，实现了对浏览器的控制，所以核心能力上不会有太大的区别。
CDP就是chrome最高权限debug权限，右键检查打开的就是devtools的面板，在这里你可以执行任意脚本、修改css、查看网络、查看cookie、模拟设备网络等等。这是人能访问的途径，而CDP代码访问的渠道主要有3种，分别是
| 进程管道 | chrome插件 | 远程调试(老) | 远程调试(新) | |
|---|---|---|---|---|
| 交互协议 | 管道 | 自行设计，如codex使用的native message | Http+Websocket | Websocket |
| 复用自己profile | 不可 | 可 | 不可 | 可 |
| 典型代表 | playwright, chromemcp, codex内置浏览器等 | codex chrome插件，playwright chrome插件 | chromemcp | chromemcp，browser use |
| headed | 可 | 可 | 可 | 可 |
| headless | 可 | 一般不可 | 可 | 可 |
| 警告提示 | 无 | 有横幅提示 | 无 | 每次需手动确认，且有横幅提示 |
ego lite这种比较特殊，他是基于chromium内核自己写的浏览器，协议是自己的原生定义的事件消息，缺点是要更换浏览器，且目前没有windows。
chrome devtools mcp
这是chrome官方推出的mcp工具，简称chromemcp吧，他支持进程管道和远程调试两种方式启动，自动化调试用进程管道方式这也是默认的配置方式，而如果要复用自己当前的profile，可以使用远程调试方式。
配置方式：
# 最简单配置，进程管道 + 有头
npx -y chrome-devtools-mcp
# 进程管道 + 无头
npx -y chrome-devtools-mcp --headless
# 远程调试 老 有头 (需要先用remote模型启动进程)
npx -y chrome-devtools-mcp --browser-url=http://127.0.0.1:9222
# 远程调试 新（自动连接9222，需要你打开这个配置，否则方法报错） 有头
npx -y chrome-devtools-mcp --autoConnect
另外一些常见的会开启的feature flag
npx -y chrome-devtools-mcp \
--experimentalVision # 开启视觉检测,开启后可以调用click_at方法
这里说一下为什么新老版本的都是9222端口，这是本质上就只有老版本，他是将进程通信的调试能力通过9222端口开放，以便于远程调试，而这个协议下需要先访问/json/version的http接口，来获取websocket的调试地址。
这里介绍下新老版本的前置配置方式，老版本需要用chrome启动一个新的进程，带上如下启动指令remote-debugging-port：
& 'C:\Program Files\Google\Chrome\Application\chrome.exe' `
--remote-debugging-port=9223 `
--user-data-dir="$env:TEMP\chrome-debug-profile"
然后mcp中配置npx -y chrome-devtools-mcp --browser-url=http://127.0.0.1:9223即可连到这个浏览器上了，这里额外说一下老版本的远程连接的方式和进程管道的方式，在各方面能力和限制是一样的，而进程管道还不占用端口，所以旧版的远程方式的使用场景较少，主要是真的部署了远程托管的浏览器这种场景会用到，进程管道要更实用一些。
而新版本其实主要是允许浏览器启动的时候，不添加remote-debugging-port的启动指令，在设置页面中手动开启，并且新版本手动开启后，并不提供/json/version的endpoint，而是chromemcp通过--autoConnect参数，自己去发现chrome进程，进而找到对应的ws端口和browserid，自己拼出来上图中的websocket url，后续还是走的原来的标准cdp调用的协议交互规范。
新版本的最核心的作用就是不用在启动的时候指定参数，进而使得我们自己用户的profile打开的浏览器也可以在chrome://inspect#remote-debugging中远程调试，这样chromemcp就可以使用用户当前的浏览器进行操作，这应该是新版本远程调试协议的最大用途。
接下来我们来介绍，mcp中的工具列表和功能(chromemcp的返回结构都是纯文本的，可能觉得json太冗余)：
| 类别 | 工具 | 用途 |
|---|---|---|
| 页面 | list_pages | 列出可操作页面 (自增数字id + title + url + [selected]) |
select_page | 选择页面（用的是上面的自增id，click等操作都是针对选中标签的） | |
new_page / close_page | 新开、关闭标签 | |
navigate_page | 打开 URL、前进后退、刷新 | |
resize_page | 改页面尺寸 | |
handle_dialog | 接受/取消 alert、confirm、prompt | |
get_tab_id | 取得 Chrome 原生 tab id （插件中一般用这个id） | |
| 截图 | take_screenshot | viewport 或完整页面截图；可存入 MCP roots 允许的路径 |
take_snapshot | 返回可访问性树及稳定 uid （形式：uid=1_3 button "Pages"）可根据text确认功能，然后用uid触发click等 | |
| DOM/等待 | wait_for | 等文字出现或等待指定时间 |
| 输入 | click | 按 snapshot 的 uid 点击元素 |
hover | 悬停指定元素 | |
fill | 清空后填写单个输入框 | |
type_text | 在焦点元素输入文字 | |
drag | 按两个元素的 uid 拖拽 | |
fill_form | 一次填写多个表单字段 | |
upload_file | 给文件输入框上传 workspace 内文件 | |
press_key | 按键或组合键，如 CTRL+A、ENTER | |
| JavaScript | evaluate_script | 在页面执行 JavaScript 函数，返回值必须 JSON 可序列化 |
| Console | list_console_messages | 获取本次导航以来的 console 日志，可过滤类型、分页 |
get_console_message | 按日志 id 获取完整消息 | |
| Network | list_network_requests | 列网络请求，支持过滤和分页 |
get_network_request | 查看某请求的完整 headers、body、响应等 | |
| 性能 | performance_start_trace | 开始录制 trace |
performance_stop_trace | 停止并分析 trace，返回性能洞察 | |
performance_analyze_insight | 查看某一条性能洞察的详细证据和建议 | |
| Lighthouse | lighthouse_audit | 运行 Lighthouse，返回性能、可访问性、SEO 等审计结果 |
| 模拟 | emulate | 设备/视口、DPR、UA、地理位置、网络及主题等模拟 |
用feature flags开启的功能:
| 开关 | 新增工具 | 用途与限制 |
|---|---|---|
--experimentalVision | click_at | 用 CSS viewport 坐标点击。截图像素与 DPR 不一致时要换算，正是你之前遇到的缩放偏差来源。 |
--memoryDebugging | take_heapsnapshot 及 10 个分析工具 | 堆快照摘要、详情、类实例、引用边、retainers、保留路径、dominator、重复字符串、两份快照 diff、关闭已加载快照。用于查内存泄漏。 |
--experimentalScreencast | screencast_start / screencast_stop | 录制页面操作视频；需要 ffmpeg 在 MCP 的 PATH，或传 --experimentalFfmpegPath。 |
--categoryExperimentalThirdParty | list_3p_developer_tools / execute_3p_developer_tool | 调用被测页面通过 window.__dtmcp 暴露的第三方开发者工具。页面自己必须实现它。 |
--categoryExperimentalWebmcp | list_webmcp_tools / execute_webmcp_tool | 调用页面暴露的 WebMCP 工具；Chrome 149+ 并要带 WebMCP,DevToolsWebMCPSupport feature flags。 |
--categoryExtensions | list_extensions、install_extension、uninstall_extension、reload_extension、trigger_extension_action | 管理/调试扩展。1.6.0 的说明中该能力要求 MCP 自己用 pipe 启动 Chrome，不能与 --autoConnect、--browser-url、--wsEndpoint 合用。 |
例如一套基本的操作流程，通常会包括：
new pageurl 打开测试的页面wait_for等待页面完成take_snapshot获取元素文本和uidfill或click+press_keyuid 输入表单clickuid 点击提交按钮
对于有些复杂一点的页面，比如按钮上没有明显的提交字样，而是画了个svg，这种snapshot得到的信息就很难推断出这个按钮是提交的作用，这种只能用兜底方案take_screenshot截图，然后大模型识图，找到提交的按钮的坐标，通过click_at进行点击。当然这需要--experimentalVision开启。
此外要说一点的是，截图这个功能在有头模式下，有系统缩放的坑，例如你是windows，你的屏幕分辨率太高，所以你开了缩放125%，那么这个截图大小如果是1250x1250的窗口，那么实际窗口其实是1000x1000的css scale大小。
这会导致，如果右下角有一个按钮，大模型识图之后给你点击的位置是1240,1240，但是实际是按照css取的坐标来触发点击的，1240已经在页面之外了，页面最多就到1000，而这个坑，在无头模式下是没有问题的，无头的截图就是1000x1000，只有有头模式会有问题。那如何避免呢？前面介绍了emulate这个函数，他可以传viewPort参数，来重设当前page的viewport，参数是1000x1000x1这个形式，最后的x1是设备缩放比例，通过这个参数可以把比例调回1，然后再截图，得到的就是1000x1000的了。