每一篇比较智能体浏览器工具的文章都以工具数量开场，而工具数量什么也决定不了。真正决定「这东西到底能不能用」以及「页面变恶意时会有多糟」的那根轴，是智能体拿到哪个会话：没有身份、一个由它自己积累起来的专用配置档，还是你用来登录银行的那个浏览器。苹果、谷歌、微软和扩展厂商各选了一个不同的答案，而一旦你按这根轴把它们排开，选择就不再关于功能，而是关于：你愿意把什么交给一个刚刚读完一个不可信页面的模型。
一览
给智能体一个浏览器的四种方式，按它握着你多少东西排序。
| 方案 | 它是什么 | 智能体拿到的会话 | 最擅长 |
|---|---|---|---|
| Safari MCP | 苹果自家的服务器，safaridriver --mcp，自 Safari 27 起进入稳定版 |
一个隔离的自动化会话——没有 cookie、密码或历史 | 在你无法仿真的那个浏览器上调试 WebKit 渲染 |
| Chrome DevTools MCP | 谷歌对 DevTools 协议的封装 | 一个专用 Chrome 配置档，跨多次运行持久保留 | 性能追踪与网络层面的诊断 |
| Playwright MCP | 微软的服务器，在无障碍树上行动 | 默认一个专用配置档；--isolated 给你无尘室 |
可复现地驱动流程，横跨三个引擎 |
| 扩展式智能体 | 浏览器内的助手，例如 Claude in Chrome | 你真实的配置档，带着你已有的每一个登录态 | 在你已登录、又无法脚本化的站点上办事 |
为什么会话就是全部的决定
能力与暴露面是同一个变量
一个处在干净上下文里的智能体，可以加载公开页面、读 DOM、跑 JavaScript、截图。它查不了你的订单状态，因为它不是你。把你的配置档给它，它就能把整件事办完——而它访问的任何页面上的一段话，现在对话的对象是一个握着你全部会话的进程。提示词注入不再是抓取层面的烦恼，而成了账户接管的原语；不是因为模型变弱了，而是因为影响半径变大了。
这正是今年交付了 MCP 服务器的两家浏览器厂商都把你自己的会话排除在外的原因。苹果干脆走到了梯子最低那一档：一个与你的浏览相隔离的专用自动化会话，够不着 cookie、已保存的密码、自动填充或历史。谷歌则停在往上一档，在自己的缓存目录下启动一个单独的 Chrome 配置档，而不是接上你那个。两者都不是疏漏，也不是 v1 的局限——对一个任何 MCP 客户端都能接上的服务器来说，这是唯一站得住脚的默认值，而这也正是它们谁都做不了大家以为「浏览器会说 MCP 了」之后就该有的那个「智能体帮你下单」演示的原因。
中间那一档才是人们最容易读错的
一个专用配置档不是无尘室。Chrome DevTools MCP 在多次运行之间复用它的 user-data 目录，除非你显式要求隔离；Playwright MCP 默认同样是持久的。这是有意为之，也很方便：你只需登录预发环境一次，智能体就一直保持登录。但这意味着那个配置档会在数周里不断累积凭据、没人去复核里面有什么，而它就躺在一个没有任何生命周期的缓存目录里。半年之后，「一个专用配置档」里可能装着比谁记得授予过的更多会话。
Safari MCP —— 看见 WebKit 的唯一途径，而且刻意无权
它做什么
苹果把这个服务器做成了 safaridriver 的一个模式，先在 Safari 技术预览版里，现在进了稳定版 Safari 27。它暴露约十七个工具，覆盖调试闭环：截图、页面内容、JavaScript 求值、点击/输入/滚动/悬停交互、缓冲的控制台消息、网络请求列表与详情、一次无障碍审计，以及用于暗色模式、减弱动态效果等的媒体特性仿真。它以本地 stdio 子进程运行，自身不发任何网络请求。
打开它要翻两层开关
你先在 Safari 的「高级」设置里启用面向网页开发者的功能，再到「开发」面板里允许远程自动化与外部智能体。这点摩擦也是它的企业侧故事：这是一个消费级浏览器里的按用户设置，作为车队策略的依据相当单薄，值得在围绕它做规划之前先知道。
它适合谁
任何在调一个真实 WebKit bug 的人。Playwright 的 WebKit 构建很接近，但它不是 macOS 或 iOS 上的 Safari，而这个区别要紧的那一类缺陷，恰恰就是你在别处复现不出来的那一类。除此之外，隔离的会话与更小的工具面，使它成为四者中最不实用的一个。
Chrome DevTools MCP —— 诊断的那一个
它做什么
谷歌的服务器是对 Chrome DevTools 协议的一层薄而标准的封装，通过 Puppeteer 驱动 Chrome，工具面比苹果那边大好几倍——大约六十个。有区分度的那一半不是点击，而是带有提炼出的洞察的性能追踪、网络请求检视与控制台访问。如果问题是「这个页面为什么慢、为什么吵、为什么某个请求失败」，那这一个有直接的杠杆，因为它把人打开 DevTools 时看的那份数据交给了智能体。
要紧的那个配置档细节
它默认用自己在用户缓存路径下的 user-data 目录启动稳定版 Chrome，跨多次运行复用，并且同一时刻只允许一个浏览器使用它。打开 isolated 选项，你会得到一个临时目录，浏览器关闭时被清掉。在 CI 里你想要 isolated；在一次长跑的调试会话里通常不想——而这正是应当显式决定、而不是被动继承的那个选择。
它适合谁
前端与性能工作，仅限 Chrome，且智能体的活是解释一个页面而不是在上面完成一段流程。它也是四者中可复现性最弱的，因为一个持久配置档加一个真实浏览器，意味着大量隐藏状态。
Playwright MCP —— 会驱动的那一个，也是对状态最诚实的那一个
它做什么
微软的服务器在页面的无障碍树而不是截图上工作，这对智能体的意义比听起来更大：模型收到的是带角色与名称的结构化文本，于是它按语义选中元素，而不是去猜像素坐标；而每一次观察都便宜、可 diff、可记录。它能跑 Chromium、Firefox 与 WebKit，这让它成为此处唯一的跨引擎选项。
关于状态，说得很明
配置档默认持久，按渠道与工作区存放在平台缓存目录下，于是不同项目自动拿到不同的配置档，并可用 --user-data-dir 覆盖。加上 --isolated，每次会话从零开始、关闭时丢弃其存储；再配 --storage-state，就能只种入某个测试需要的那一份登录态、而不多一分。它另外还有一个扩展模式，可以接上你自己浏览器里的一个标签页——那会把它挪到梯子最上面那一档，连带所有含义。
持久、隔离、或从文件种入这三件套，是四者之中对「会话」这个问题给出的最完整的答案；尤其「带种入的隔离」正是你做评测时想要的形状：可复现、凭据范围受限，并且能从一份你可以评审的文件里重建。
它适合谁
凡是智能体要去完成一段流程、而不是去描述一个页面的场合：端到端测试、发布时的 QA、表单驱动的工作流，以及任何必须跑在 Chrome 之外的智能体。它是默认选择；而无障碍树这条路子，也正是它的轨迹最容易保留下来的原因——关于这为什么比看起来更要紧，见截图与 DOM 产物。
扩展式智能体 —— 唯一真能替你办事的那一类
它们做什么
像 Claude in Chrome 这样的浏览器内助手——自 2026 年 8 月下旬起在付费方案上全面可用——会读你正在看的那个页面并在上面行动：点击、输入、跳转、填表，用的是你已有的登录态。最后那半句就是整个产品。它也正是下面几档谁都替代不了它的原因：没有哪个自动化配置档认识你的账户。
安全记录就是论点本身，不是脚注
Claude 扩展上已公开的两类缺陷，把这种暴露面从理论变成了具体。ShadowPrompt 把一个过于宽松的来源白名单——任何匹配 *.claude.ai 的子域都能提交一条提示词去执行——串成了从被访问页面发起的零点击注入；在 2025 年 12 月底披露之后，Anthropic 在扩展 1.0.41 版把它收紧为精确来源校验。另一个 ClaudeBleed 则建立在这样一个观察上：任何已安装的 Chrome 扩展都能发送命令，因为信任被放在了命令的来源上，而不是放在它的执行上下文上。
两者都已修复。修复之后仍然成立的是那个结构性论点：一个在你受信会话内部运行的智能体是以你的身份执行的，所以一次成功的注入能读文件、读邮件、读代码，能在你的账户上行动，事后还能把界面收拾干净。下面几档是靠「没有凭据」而失败安全；这一档是设计上就失败敞开。请把它用在那些你本来也会在那个标签页里亲手做的事上、用在你自己挑的站点上，并且不要在浏览开放互联网时让它一直挂着。
真正把它们分开的那几根轴
越过会话，第二根真实的轴是智能体观察到什么。像素通用而昂贵：需要视觉模型、每步一件大产物，而坐标在一次布局变更后就会失效。无障碍树是文本，所以便宜、有语义、可 grep，这也是 Playwright 的选中更常能活过一次改版的原因。协议数据——追踪、请求、控制台——两者都不是，而它是只有 DevTools 那个服务器才真正给得起的东西。
第三根是可复现性，它直接跟着配置档那个决定，也是团队最容易被烧到的地方。一个持久配置档制造的是你在另一台机器上重现不出来的失败；带种入的隔离制造的是你能重现的那种。对任何你打算打分的运行来说，这不是偏好问题。
该选哪一个
| 情形 | 选 | 为什么 | 要留神 |
|---|---|---|---|
| 智能体必须完成一段流程，可能还要在 Firefox 或 WebKit 上 | Playwright MCP | 基于无障碍树的动作、三个引擎、显式的状态模式 | 默认是持久配置档 |
| 「这个页面为什么慢／为什么报错」 | Chrome DevTools MCP | 别家没有的性能追踪与网络数据 | 仅限 Chrome；隐藏的配置档状态 |
| 一个真正的 WebKit 或 Safari 专属 bug | Safari MCP | 检视真实引擎的唯一途径 | 隔离会话；按用户的开关 |
| 在你已登录的站点上办一件事 | 扩展式智能体 | 别的都没有你的会话 | 注入即账户接管；限定站点范围 |
| 你打算打分的评测或 CI | Playwright MCP，isolated 加种入状态 | 可复现且凭据范围受限 | storage-state 文件属于机密 |
常见问题
Safari 交付了 MCP 服务器，是不是意味着智能体现在能在 Safari 里替我买东西？
不能，而且这是设计如此。这个服务器驱动的是一个专用自动化会话，够不着你的 cookie、已保存的密码、自动填充或历史，所以它在任何站点上都无法以你的身份行动。它是一个开发者调试工具，只是恰好会说一种消费级智能体也会说的协议。
「专用配置档」可以当沙箱来看吗？
单凭它自己不行。它是一只单独的 cookie 罐，相对你的个人身份而言是真实的隔离，但它在多次运行之间持久保留，并且会累积你让它登录过的一切。请把它当共享服务账号那样复核：知道里面有什么、别把生产凭据放进去，并且对任何你想要可复现的事情使用 isolated 模式。
无障碍树还是截图——智能体该基于哪一个行动？
只要树存在就用树。它更便宜、有语义、更能活过视觉改版，还留下一份你能脱敏、能搜索的轨迹。截图是画布密集型应用的兜底，也是在某个决策点上确认「页面当时到底长什么样」的手段。
我能同时跑其中多个吗？
能，而且这是常见配置：Playwright MCP 负责驱动，DevTools MCP 负责诊断。请留神配置档的锁——DevTools 那个服务器对每个 user-data 目录只允许一个浏览器——也请留神你的上下文预算，因为两个服务器可能给每一次请求加上远超一百条工具定义。
在让它们中的任何一个接触真实站点之前，最该加的那一项控制是什么？
出网与目标限制，而不是一个更好的模型。决定浏览器可以到达哪些来源、把每个页面都当作不可信输入、并对不可逆动作要求确认——因为无论你选了四者中的哪一个，页面就是那个攻击面。
延伸阅读
本站相关：
- 浏览器智能体 —— 从头到尾把它建出来。
- 计算机操作与图形界面智能体 —— 像素驱动的那条路及其代价。
- 智能体轨迹里的截图与 DOM 产物 —— 这些工具留下了什么。
- 浏览器智能体失败模式 —— 这类运行实际是怎么坏的。
- 上下文污点追踪 —— 给页面打上标签，好让工具调用能拒绝。
项目文档：
- Introducing the Safari MCP server（WebKit）。
- chrome-devtools-mcp（Chrome DevTools）。
- playwright-mcp（微软）。