68 次实测比较两种浏览器 MCP 成本

接上浏览器 MCP，AI 每看一眼网页就要烧掉几万 token？作者用 68 次运行测试了 Playwright MCP 和 Chrome DevTools MCP，发现日常任务的开销主要来自反复携带的上下文和操作步数，整页快照才可能造成单次暴涨。

更有意思的是，作者做的压缩代理虽然最高能减少 96% 的快照 token，在 Claude Code 的长页面测试里却反而增加了费用。看懂这个反差，比直接装一个省钱工具更有用。

浏览器账单为什么不只取决于网页大小

测试环境是 Claude Code 2.1.295、Opus 5.5、effort medium、Windows 11，记录日期为 2026-10-22。两个浏览器服务分别是 Playwright MCP 0.0.83 和 Chrome DevTools MCP 1.11.0，均以 headless 模式运行。

每次只启用一个 MCP server，禁用网页搜索、网页抓取、文件工具和 shell，确保任务只能通过浏览器工具完成。共测 7 类任务，日常任务各跑 2 次，快照任务各跑 5 次，完整快照探测各跑 3 次，总计 68 次。token 来自 Claude Code 日志中的逐请求 usage，包含未缓存输入、缓存读取和缓存写入。

日常任务的 16 次运行全部答对，最大的单次工具返回只有 6,012 个字符。模型通常执行短脚本提取目标信息，或者使用 Playwright 的 find 工具，并没有习惯性地读完整页。

真正反复出现的是每次请求约 23,000 token 的固定内容，主要由 Claude Code 自身指令和工具定义构成。点击、输入、观察结果，每多走一步，就可能再携带一次。

待办事项任务最贵，原因也是点击和键盘操作最多。

在这组测试里，日常浏览器任务的主要成本来自操作步数。

不过，这里的输入 token 包含缓存部分，不能把约 23,000 token 全部按未缓存输入价格计算。

真正要防的是完整快照和中等页面

作者随后强制读取英文 Wikipedia 的「Python (programming language)」完整无障碍快照，也就是供模型理解页面结构、定位控件的文本表示。

Playwright MCP 返回 504,168 个字符，Chrome DevTools MCP 返回 427,400 个字符。交给 Opus 5.5 计数后，分别达到 205,642 和 208,926 token，按其 API 标价，单份快照约需 $1.65。

字符更少，token 却可能更多。同样两份文本，OpenAI 的 o200k tokenizer 只计出 133,668 和 138,745 token；Claude 的结果高出超过 50%。作者认为，链接目标、元素 ID 这类内容对 Claude 的分词尤其不友好。

但这笔巨额输入并没有实际进入 Claude Code 的模型上下文。客户端每次都拦截了超大结果，将其保存到文件，并提示分段读取。

更容易漏过防线的是中等页面。Hacker News 首页快照直接通过，让下一次请求分别增加 18,407 和 14,115 token，其中包含大量链接 URL、「clickable」标记、空布局单元、竖线分隔符和深层缩进。

因此，不能把「浏览器生成了多少文本」直接等同于「模型实际收到了多少文本」。客户端有没有拦截，决定了成本落在哪里。

压缩代理为什么有时省钱，有时更贵

作者开发的 tokensave-mcp-diet 放在客户端与浏览器 MCP 之间，按三个层次处理快照。

先做 Compact：快照较大时，去掉链接目标、光标标记、分隔符和空包装，压缩缩进，同时保留元素 ref，供后续点击和输入使用。

仍然太大，再做 Outline：只保留标题、表单字段、按钮和链接，折叠参考文献一类连续链接。完整快照留在内存，需要正文时通过新增的 snapshot_detail 工具，按 ref 或文本查取。

下面的配置把代理接在 Playwright MCP 前面，不需要 npm 账号或 API key：

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "github:johnisking/tokensave-mcp-diet", "--", "npx", "-y", "@playwright/mcp@latest"]
    }
  }
}

要看的是 args 中的 --：后面才是代理实际启动的浏览器服务命令。另外，示例使用 @latest，复现实验时需要留意它与测试版本 0.0.83 的差异。

Hacker News 的结果比较扎实：快照 token 减少 43% 至 63%，任务费用下降 18% 至 31%，5 次运行答案均一致；费用波动在一美分以内，快照 token 波动最多 4%。

Wikipedia 则反过来。Claude Code 原本只把简短的超限提示交给模型，代理却送入约 9,000 token 的提纲，最终任务费用增加 3% 至 44%。

标题中的 96%，来自把超过 200,000 token 的完整快照缩到约 9,000 token。这个收益以客户端直接放行大结果为前提，作者没有实测其他客户端的端到端费用。

压缩结果更小，不保证整项任务更便宜。

我的判断

我认可作者把成本拆成固定上下文、操作步数和快照体积。这比笼统讨论「浏览器 MCP 很费 token」更能指导优化。

但这仍是一组有限实验：一个模型、一台机器，日常任务每项仅 2 次；Hacker News 又是实时页面，分数会变化。原文也没有给出跨模型、跨客户端的对照，不能据此判定 Playwright MCP 或 Chrome DevTools MCP 谁始终更省钱，更不能推断 Claude Desktop、Cursor、Codex 会直接吞下超大结果。

代理适合处理中等快照里的结构噪声。与保留完整快照、让模型自行筛选相比，它减少了输入；与直接用短脚本提取信息相比，它又可能多出请求细节的步骤。Outline 会丢掉正文，阅读型任务尤其可能因此增加往返。

此外，快照格式会随服务版本变化，Playwright MCP 在导航时已经会把快照保存到文件。是否值得加代理，要看实际调用路径，不能只凭最大压缩比例判断。

能拿来做什么

• 用 AI 检查前端页面时，把「看看整个页面」改成明确目标，例如定位登录按钮、读取指定表格或检查某个表单，让模型优先使用查找或短脚本提取信息。
• 排查浏览器自动化费用时，同时看请求次数、工具返回大小和缓存 usage。若主要开销来自多次点击与重复观察，应先减少操作往返。
• 遇到 Hacker News 这类中等大小页面，可以对照测试代理前后的任务总费用与答案正确性；遇到长文阅读，则额外检查是否因缺少正文而频繁调用 snapshot_detail。
• 给自己的客户端接浏览器 MCP 前，确认大结果是否会被拦截或保存到文件。已有保护时，先验证代理是否增加了模型实际接收的内容。