Safari Technology Preview 247 里多了一行命令:safaridriver --mcp。敲下去之后,Safari 就不再只是一个浏览器窗口,而是变成了一个可以被 AI agent 直接连接、读取、操作的调试对象。苹果管它叫 Safari MCP server

这不是一个花哨的噱头功能。它开放了 17 个工具,涵盖标签页管理、页面导航、DOM 交互、JS 执行、网络请求详情、截图和控制台日志。Claude、Codex 之类的 agent 接上之后,可以自己打开你的网站、自己找 bug、自己判断样式有没有崩、可访问性有没有硬伤,不用你截图、不用你描述“这里怎么怪怪的”。

省掉的是那个来回跳窗口的循环

前端开发者都熟悉那套动作:看浏览器出问题,开控制台,点样式面板,截图,描述给 agent,改代码,再验证——错了就重来一遍。这个循环里最耗时间的不是改代码,是“把浏览器里发生的事说清楚”这一步。Safari MCP server 想解决的正是这一步。

调试方式:两种循环 传统流程 1. 看浏览器发现问题 2. 开控制台 / 样式面板 3. 截图 + 手动描述 4. 喂给 agent 改代码 5. 没修好,回到第1步 Safari MCP 流程 1. 一句话:“找找Safari上的bug” 2. agent 自己连Safari 3. 直接读DOM/截图/网络 4. 定位问题并给出修复 循环缩短到一轮对话

苹果给的启用方式也很直白:装 STP,打开开发者选项,勾选“启用远程自动化和外部 agent”,然后用一行命令把 Safari 挂到 Claude 或 Codex 上。别的 agent 可以自己写进 mcp.json。反馈渠道不是 GitHub,是 WebKit Bugzilla——这一点透出个信号:苹果目前还是把它当 WebKit 内部功能来运营,而不是一个独立开源项目在对外经营。

安全声明,只讲到自己家门口

苹果的说法是:server 完全本地运行,自己不发起任何网络调用,也不碰 AutoFill 之类的个人数据。这话没毛病,但它只回答了一半问题。

真正敏感的东西——页面截图、DOM 结构、控制台日志——一旦被 agent 读取,就会离开 Safari,流向你连接的那个 agent 和它背后的模型。这条链路苹果管不了,也没打算管。

信任边界分层 本地进程:safaridriver --mcp,不发起网络调用 不碰的部分:AutoFill、其他浏览活动 会被抓取:DOM、截图、网络请求、console日志 流向下游:所接的agent与背后模型,苹果不再负责

MCP 生态里已经不是第一次被人提醒这个问题。远程 MCP 结合 OAuth 流程的钓鱼和 token 泄露风险,此前在社区里已经被公开讨论过(GitHub issue #544)。Safari MCP server 目前是本地直连,风险面比远程场景小,但“本地”只是说明数据没经过额外的网络跳转,不代表数据出了 safaridriver 之后就一直安全。

  • 风险.企业环境里如果大规模开启这个功能,页面数据默认交给 agent 背后的模型提供商,合规和数据留存策略需要单独评估,苹果的“本地无网络调用”声明并不覆盖这一段。
本地运行不等于数据不出圈,它只是换了一道门。

放进对手的坐标系里看

浏览器自动化这条赛道并不是苹果先跑的。Chrome DevTools MCP 偏底层,基于 CDP,擅长挖性能和网络细节;Playwright MCP 走的是跨浏览器高层自动化,agent 用起来更省心,Chromium、WebKit、Firefox 都能覆盖。

Safari MCP server 的位置更窄:它只服务 Safari 自己,目的很明确——补上“别的浏览器测过了,Safari 单独漏测”这道长期存在的兼容性缺口。这个定位足够具体,但也意味着它天然不是一个通用工具,而是一块专门补给 WebKit 生态的补丁。

现在它还停留在 Technology Preview 阶段,什么时候进入正式版 Safari、会不会扩展到 iOS/iPadOS,苹果没说。“本地无网络调用”这句安全承诺,目前也只是苹果自己的表述,没有看到第三方审计的验证。这两件事,想认真把它用进团队工作流的人,值得先记在心里再动手。