我数了13个。MCP服务器注册表里所有浏览器自动化工具，无一例外全绑着Chromium——Chrome DevTools Protocol、Puppeteer、Playwright，或者它们的包装壳。AI代理想操作网页？选项只有一个：启动Chrome。
这事比你想象的麻烦。不是因为什么浏览器多样性的抽象争论，而是Chrome成了开发者MCP设置里最吃资源的黑洞——而95%的自动化任务根本不需要它。
一台M2 Pro的风扇为什么狂转
我自己跑自动化业务。日常工作流里Claude Code同时连着6-7个MCP服务器。有天我发现，明明只是让AI读个仪表盘、填个表单，M2 MacBook Pro的风扇却转起来了。
打开活动监视器一看：Chrome（被浏览器MCP服务器拉起来的）占了38% CPU。就干坐着。调试端口开着，等命令。
与此同时，Safari——我本来就开着、所有账号都登好的那个浏览器——11个标签页，CPU占用0.3%。
那一刻我反应过来：为什么要跑两个浏览器？我手里这个明明什么都能干。
Safari MCP的双引擎赌局
Safari MCP是个原生MCP服务器，直接用AppleScript和JavaScript控制Safari。没有Chrome，没有Puppeteer，没有WebDriver，没有无头浏览器进程。
安装就两行：
npm install -g safari-mcp
配置也极简，往MCP客户端配置文件里塞一段就行。不用装Chrome，不用开调试端口，不用下载Playwright的浏览器二进制包。
多数人看一眼这个项目，以为是"就一AppleScript"。不是。Safari MCP跑的是双引擎架构，两条完全不同的执行路径竞争每个命令的最佳处理方式：
引擎1：AppleScript + Swift守护进程（永远可用）
这是底子。一个常驻的Swift辅助进程，接收AppleScript命令，约5毫秒响应。执行标签切换、获取页面信息、跑JavaScript——全靠系统级集成。
引擎2：Safari扩展（HTTP，5-20毫秒）
需要精细DOM操作时启用。通过原生消息通道与Safari扩展通信，内容脚本直接注入页面。获取完整HTML、执行复杂JavaScript、处理动态内容。
两个引擎同时待命，哪个快用哪个。AppleScript路径保底，扩展路径抢速度。
实测数字：从38%到0.3%的落差
Chrome方案的资源消耗是系统性的。Playwright要下载Chromium二进制（约100MB），启动后常驻内存，调试端口暴露在外。每个新页面都是新进程，很快吃掉几百MB内存。
Safari MCP用的是你已经开着的Safari。没有额外进程，没有重复渲染引擎，没有调试端口。内存占用就是你本来就在用的那些标签页。
我那38% vs 0.3%的对比，本质是"为自动化单独跑一个浏览器" vs "控制你已经在用的浏览器"的差距。
更深一层：Safari的JavaScript引擎（Nitro）和WebKit渲染引擎针对Apple Silicon优化过。跑在M系列芯片上，比Chromium的V8+Blink组合更省电。
为什么整个行业集体踩进这个坑
13个工具全选Chromium，不是技术必然，是路径依赖。
Puppeteer和Playwright把Chrome DevTools Protocol做成了事实标准。开发者顺手就用，文档齐全，社区成熟。Safari的自动化接口？AppleScript文档散落在各处，WebDriver支持直到近年才完善，扩展生态和Chrome Store没法比。
结果是：哪怕你的AI代理只是读个静态页面，也得拉一整套Chromium起来。就像为了开家里的门，专门去租了辆卡车。
Safari MCP的作者Achiya在GitHub上写得很直接：「我受够了每次跑简单任务都要等Chrome启动。」这项目始于个人痛点，但戳中的是结构性盲区。
苹果生态的隐藏接口
这个项目能做成，靠的是苹果生态里几个被忽视的机制。
OSA（开放脚本架构）让AppleScript能控制原生应用，这套东西从System 7时代就有了，现在反而成了优势——稳定、低延迟、不需要额外权限模型。
Safari 14之后引入的扩展API，支持原生消息通道。Safari MCP的扩展部分用Swift写的，通过App Extension机制与主进程通信，绕过JavaScript的性能天花板。
双引擎架构的聪明之处，是把"系统级控制"和"页面级控制"解耦。AppleScript管浏览器行为，扩展管DOM操作，各干各的，不互相拖累。
一个未回答的问题
Safari MCP目前只支持macOS。Windows和Linux用户怎么办？Firefox有没有类似的Native Messaging方案？Edge作为Chromium系但系统集成更深的浏览器，能不能走出第三条路？
作者Achiya在Issues里提过Windows支持的可能性，结论是：「需要完全不同的架构，可能得用Edge的WebDriver2或者等微软开放更多原生接口。」
换句话说，浏览器自动化的"去Chromium化"才刚开始。Safari MCP证明了另一条路走得通，但能不能从"Mac用户的偏方"变成跨平台选项，要看有没有更多人愿意挖各自平台的隐藏接口。
你的MCP服务器列表里，Chrome还占着多少CPU？
热门跟贴