Safari MCP把Chrome CPU占用从38%打到0.3

13个浏览器自动化服务器，100%依赖Chromium。这不是技术选型，是集体失忆。

我翻遍了MCP官方注册表。Playwright、Puppeteer、Chrome DevTools Protocol——名字换了几轮，底层全是同一套东西。你的AI代理想点个按钮？先启动一个Chrome实例，开调试端口，等进程吃满内存再说。

这事比你想象的更蠢。不是因为什么浏览器多样性的大道理，而是因为Chrome是开发者MCP设置里最肥的资源黑洞——而95%的自动化任务根本不需要它。

一台风扇狂转的M2，暴露了行业通病

我自己跑自动化业务。日常是Claude Code同时挂6-7个MCP服务器。某天发现M2 MacBook Pro风扇在转，而AI只是在读仪表盘、填个表单。

打开活动监视器：Chrome（浏览器MCP服务器启动的）占用38% CPU。就干等着。调试端口开着，命令没来，电先耗光。

旁边的Safari呢？11个标签页，0.3% CPU。而且我需要的登录状态全在里面。

两个浏览器同时跑，一个在做全部工作，另一个在吃全部资源。

Safari MCP的作者Achiya也是这么想的。他的解决方案简单粗暴：用AppleScript和JavaScript直接控制Safari。没有Chrome，没有Puppeteer，没有WebDriver，没有无头浏览器进程。

安装两行命令：

npm install -g safari-mcp

或者在配置里加一段：

{
"mcpServers": {
"safari": {
"command": "npx",
"args": ["-y", "safari-mcp"]
}
}
}

完事。不用装Chrome，不用下Playwright浏览器二进制文件，不用开调试端口。

双引擎架构：两条路，谁快用谁

很多人以为这只是"AppleScript套壳"。实际架构复杂得多——两条完全不同的执行路径竞争处理每个命令：

路径一：AppleScript + Swift守护进程（5毫秒响应，永远在线）

路径二：Safari扩展 → 内容脚本 → 页面DOM（HTTP通信，5-20毫秒）

系统根据任务类型自动选择。要执行标签页里的JavaScript？AppleScript直接上。要操作DOM？扩展通道更快。两条路最终都指向同一个页面，但从不互相阻塞。

这个设计有个副作用：Safari MCP能做的事，Chrome方案做不到。

比如读取已登录页面的数据。Chrome方案需要重新登录——因为无头浏览器是全新会话。Safari MCP直接操作你眼前这个浏览器，Cookie、LocalStorage、登录状态全在。

自动化工具终于记得"用户已经打开浏览器"这件事了。

性能数字：不是优化，是数量级差距

作者跑了对比测试。同一台机器，同样任务：

Chrome + Playwright：启动时间2-4秒，内存占用300-500MB，空闲CPU 10-15%

Safari MCP：启动时间<100毫秒，内存占用<50MB，空闲CPU接近0%

差距不在百分比，在体验质变。Chrome方案让"快速自动化"成了笑话——每次执行先等浏览器启动，风扇起飞，任务做完进程还挂着。

Safari MCP的延迟低到能写交互式工作流。AI代理可以实时观察页面变化，逐行调试，像人类一样"看着屏幕操作"。

这引出一个尴尬问题：为什么整个行业默认Chrome是唯一选项？

答案藏在历史路径里。Puppeteer 2017年发布，Playwright 2020年跟进，两者都押注Chrome DevTools Protocol。MCP生态2024年爆发时，开发者直接搬来现成工具，没人追问"用户电脑里已经开了什么浏览器"。

Safari MCP的Star数在GitHub上涨得很快。但注册表里那13个Chromium方案依然占据绝对主流——不是因为更好，而是因为先发。

作者收到过一条Issue反馈：某团队把CI流程从Chrome迁到Safari MCP后，Mac mini集群的并发量从8路提到40路。不是机器变强了，是每台机器终于不用养Chrome了。