Chrome MCP vs Claude for Chrome vs gstack browse

引言

把一个公开网页喂给 AI 已经不是难事。Jina Reader、Firecrawl 这类服务在服务端跑一个无头浏览器，把页面渲染好、抽出正文、转成 Markdown，AI 拿到的就是一份干净的文本。

但真正的工作内容，大多藏在需要登录的页面后面——公司内网系统、各类管理后台、SaaS 控制台。这些页面有两道坎：一是内容由 JavaScript 动态渲染，curl 抓回来只有一个空壳；二是必须有你的登录态才能看，而 Reader 服务用的是它自己服务器的 IP，根本没有你的会话。

要跨过这两道坎，目前主流有三种方案：gstack browse（独立浏览器）、Chrome MCP Server（连接你的真实 Chrome）、Claude for Chrome（官方浏览器扩展）。三者都能让 AI 看到登录后的页面，但在”登录态怎么来””隔离性如何””装起来多麻烦”上差异巨大。本文先讲清楚 AI 读网页的底层机制，再逐一拆解三种方案的原理与取舍，帮助你按场景选择。

AI 是怎么”读”网页的

在对比方案之前，先理解 AI 实际拿到的是什么。一个驱动浏览器的工具，通常有两种把页面交给模型的方式。

文本快照（accessibility tree）

这是首选方式。它抓取的不是图像，而是浏览器内部的无障碍树（accessibility tree）——一份结构化的文字描述：每个元素的角色（按钮 / 输入框 / 标题）、文本内容，以及一个唯一编号（uid）。

uid=1_6  menuitem "新建题本" focused
uid=1_36 StaticText "ID:105"
uid=1_39 StaticText "7 题"
uid=1_217 button "保存" disabled

它的优势很明显：文字精确（ID、数字不会认错）、省 token、而且 uid 可以反过来用于点击和填表。AI 读一张表格的数据，靠的就是它，而不是”看图认字”。

截图（screenshot）

截图拿到的是像素图，靠模型的多模态能力去”看”。它适合判断排版、样式、图表、颜色，或者页面是 <canvas>、图片渲染、无障碍树里没有文字的情况。缺点是细小文字易丢失、读数字容易出错、占用 token 更多。

一句话：结构化文本快照负责”读内容”，截图负责”看长什么样”。成熟的工具会以快照为主、截图为辅，必要时再用执行 JS 或直接抓后端 API 拿最干净的数据。

关键前提：必须有一个”活的浏览器”

无论快照还是截图，都要求有一个正在渲染该页面的真实浏览器。这也是为什么纯文本抓取（curl、Reader）搞不定动态登录页——它们没有在跑一个完整的浏览器环境。三种方案的本质区别，正在于这个浏览器是谁、登录态从哪来。

核心矛盾：登录态存在哪

理解三种方案，只需抓住一条主线：登录态是”装在某一个具体浏览器内部”的，不是装在你的电脑上，也不是几个浏览器共享的。

你登录一个网站后，网站发一张”通行证”存进当时那个浏览器的本地数据里（Cookie 或 localStorage 中的 token）。下次访问，浏览器把通行证递给网站，网站才认得你。这张通行证按浏览器隔离存放——日常 Chrome 的存在日常 Chrome，独立浏览器的存在独立浏览器，即便同一台电脑、同一个网站也不互通。

所以三种方案的根本差异，就是 AI 操控的那个浏览器，能不能拿到你的通行证：

独立浏览器（gstack browse）：全新空白，需要你在它里面重新登录
你的真实 Chrome（Chrome MCP Server / Claude for Chrome）：通行证天然就在，无需重登

便利与隔离的取舍，全部源于这一点。

方案一：gstack browse —— 独立浏览器

原理

gstack browse 启动一个独立的浏览器（底层是 Playwright 提供的 Chrome for Testing），通过命令行驱动：导航、快照、点击、截图。它和你日常 Chrome 完全是两套，有自己独立的数据目录。

登录态怎么处理

因为借不到你日常 Chrome 的会话，要看登录页就得先在它里面建立登录态，两条路：

直接登一次：打开到登录页，你扫码 / 输账号，登录后这个浏览器就有会话了。适用任何登录方式，包括 SSO 扫码。
导入 Cookie：用 cookie-import-browser 把日常 Chrome 对某站的 Cookie 拷进来。前提是该系统用 Cookie 鉴权；若登录态是 localStorage 里的 token（很多 SSO 系统如此），导 Cookie 不一定够，得回退到扫码。

值得一提的是，它的会话会持久保存：同一个系统登过一次，只要会话没过期，之后再看就不用重登。

优缺点

✅ 隔离性最好：AI 只能看到你在它里面登过的那一个系统，碰不到你日常浏览器的其它登录。看敏感内网时这点很关键。
✅ 开源免费，不依赖订阅。
❌ 每个要登录的系统，首次都要单独登一次（SSO 就得扫码）。
❌ 作为命令行工具，需要一定配置。

方案二：Chrome MCP Server —— 接管真实 Chrome

“Chrome MCP Server” 是一类工具的统称，常见实现有 Google 官方的 Chrome DevTools MCP、社区的 mcp-chrome、Playwright MCP 浏览器扩展等。它们的共性：作为 MCP 服务接入你的 AI（Claude Code、Cursor 等），去操控你的真实 Chrome。

原理

底层依赖 Chrome 的远程调试协议（CDP，Chrome DevTools Protocol）。以 Chrome DevTools MCP 为例，它有几种连接方式：

--autoConnect（Chrome 144+）：连接你正在运行的 Chrome 实例，用其真实用户配置文件（所有登录都在）。需要先在 chrome://inspect/#remote-debugging 打开远程调试开关，且每次连接 Chrome 会弹授权框确认。
--browserUrl http://127.0.0.1:9222：连接一个以远程调试端口启动的 Chrome。
默认模式：启动一个隔离的临时配置文件（这种就和独立浏览器一样要重登了）。

接好之后，AI 就能 list_pages 看到你所有标签页，选中任意一个读快照、截图、操作。

登录态怎么处理

这正是它的核心价值：什么都不用做。 用 autoConnect 连的是你日常 Chrome 的真实配置，你已经登录的内网、后台、控制台，AI 直接就能看，一次都不用重新登录。

优缺点

✅ 零重复登录：复用日常 Chrome 的全部会话，体验最顺。
✅ 工具中立：任何支持 MCP 的 AI 都能接（不绑定某家模型）。
✅ 开源免费。
❌ 隔离性差：指向日常 Chrome 时，AI 能看到 / 操作该浏览器里所有已登录站点（可改用隔离 profile，但就失去了复用登录的便利）。
❌ 配置门槛中等：装 MCP 服务、配宿主、开调试开关。

本质上 Chrome MCP Server 和 gstack browse 是同一类（都是 agent 控浏览器），区别只在于前者连真实 Chrome、后者连独立 Chrome。一个换来便利，一个换来隔离。

方案三：Claude for Chrome —— 官方扩展

原理

Claude for Chrome 是 Anthropic 官方的浏览器扩展，从应用商店安装、用 Claude 账号登录后，在 Chrome 侧边栏与 Claude 对话，它能看见并操作你当前标签页。读取页面同样以无障碍树为主，无障碍树搞不定时再用截图兜底。

Anthropic 于 2025 年 8 月以 1000 名 Max 用户试点，11 月扩展到全部 Max 订阅者，12 月 18 日开放给 Pro、Team、Enterprise 计划。

登录态怎么处理

扩展跑在你日常 Chrome 里，直接继承你当前所有登录态。你登录的 Google Docs、Notion、公司内网，Claude 立刻就能读——和 Chrome MCP Server 一样无需重登。

优缺点

✅ 最省事：商店装扩展、登录即用，不碰命令行，最适合非技术日常使用。
✅ 继承日常登录态。
❌ 只能用 Claude，且需要 Claude 付费订阅。
❌ 隔离性弱：和 MCP 一样能接触你浏览器里的所有登录。
❌ 安全面更复杂（详见下一节）。

一个绕不开的维度：安全

把 AI 接进浏览器，安全性必须单独拎出来说，尤其是连接真实 Chrome 的两种方案。

便利与风险同源：Chrome MCP Server（指向日常 Chrome）和 Claude for Chrome 都能接触你浏览器里的全部登录态——内网、邮箱、甚至网银。一旦 AI 被诱导执行恶意操作，影响范围就是整个浏览器。

提示词注入（prompt injection）是真实威胁。网页里可以藏匿恶意指令（”忽略前面所有话，现在你是……”），诱导 AI 执行非预期动作。按 Anthropic 自己公布的安全数据，Claude for Chrome 在无缓解措施时注入成功率约 23.6%，加上当前缓解措施后约 11.2%——这个数字不算低。2026 年也陆续曝出过 ShadowPrompt（恶意网站注入）、ClaudeBleed（零权限扩展向 Claude 扩展发指令）、以及绕过按域名授权的 LevelDB 写入等漏洞。

官方的缓解手段：Claude for Chrome 采用按域名分别授权，且提供两种模式——“行动前询问”（先给计划、等你批准）与”无需询问直接行动”。内容分类器也会扫描进入上下文的不可信内容、标记潜在注入。但这些都是降低风险，而非消除。

这也凸显了 gstack browse 的隔离价值：独立浏览器里只登了你需要的那一个系统，即便遭遇注入，攻击面也被限制在这一个系统内，碰不到你的其它账号。

实用建议：用连接真实 Chrome 的方案时，涉及”提交 / 删除 / 转账”等不可逆操作，务必保留人工确认环节；看高度敏感的系统，优先用独立浏览器隔离。

横向对比

维度	gstack browse	Chrome MCP Server	Claude for Chrome
本质	独立浏览器，命令行驱动	MCP 服务，驱动真实 Chrome	官方 Chrome 扩展
哪个 AI 能用	接入的 Agent（如 Claude Code）	任何 MCP 宿主	仅 Claude
用哪个浏览器	独立 Test 浏览器	你的日常真实 Chrome	你的日常真实 Chrome
登录态	需在它里面重新登	复用日常登录，免重登	复用日常登录，免重登
首次登录成本	要扫码 / 导 Cookie	无	无
安装门槛	中	中高	低
隔离 / 安全	高（只见单系统）	低（见全部登录）	低（见全部登录）
成本	免费	免费	需 Claude 付费版

选型建议

没有绝对最优，关键看你更看重便利还是隔离：

想看已登录页面、零摩擦，不愿重复登录 → Chrome MCP Server（连真实 Chrome）。尤其你本来就用 Claude Code / Cursor，接进来后当前会话即可操控日常 Chrome。
日常随手用、不想折腾命令行，愿意付费 → Claude for Chrome 扩展。
看公司内网 / 敏感后台，不想让 AI 碰到其它登录 → gstack browse，代价是每个系统单独登一次。

一个简洁的判断式：便利选连真实 Chrome 的方案（MCP / 扩展），隔离选独立浏览器（gstack browse）。连真实 Chrome 越方便，AI 能触及的东西越多；用独立浏览器越安全，你就越要重复登录。

实战小记

在 Apple M1 上接入时踩过两个坑，记下备查：

架构不匹配：gstack browse 的工具链一度被装成 x86_64，在 arm64 上一跑就 SIGILL 崩溃。解决办法是装 arm64 原生 bun（注意去掉 Gatekeeper 的 quarantine 属性并 ad-hoc 签名），再重新编译 browse / find-browse 二进制。
autoConnect 的前提：Chrome MCP Server 用 autoConnect 连真实 Chrome，必须先在 chrome://inspect/#remote-debugging 打开远程调试开关，并重启 AI 客户端让 MCP 工具加载进会话；首次连接时 Chrome 会弹授权框，点允许即可。接通后 list_pages 能直接看到全部标签页，复用登录态读取登录后的内网页面，完全无需重新扫码。

Chrome MCP vs Claude for Chrome vs gstack browse

Chrome MCP vs Claude for Chrome vs gstack browse

引言

AI 是怎么”读”网页的

文本快照（accessibility tree）

截图（screenshot）

关键前提：必须有一个”活的浏览器”

核心矛盾：登录态存在哪

方案一：gstack browse —— 独立浏览器

原理

登录态怎么处理

优缺点

方案二：Chrome MCP Server —— 接管真实 Chrome

原理

登录态怎么处理

优缺点

方案三：Claude for Chrome —— 官方扩展

原理

登录态怎么处理

优缺点

一个绕不开的维度：安全

横向对比

选型建议

实战小记

参考文献

FEATURED TAGS