• 人工智能
• AI Agent
• 浏览器控制
• GUI 自动化
• MCP 服务

MCP 只解决一个问题——让模型发现它本来不知道的东西——而它的代价是每个回合都要为这份"可发现性"重新付费。本文以 invisible_playwright_mcp 项目自身的实测数据为核心：16 个工具、每个回合 3,141 token 的固定开销，逐条剖析库导入、厂商原生函数调用、纯 API 与 Agent 框架这四种替代方案各自在哪里买单，并给出"下一步是否可预知"这个决定性问题，帮助你判断自己手上的任务到底该走协议，还是该走一条更便宜的路径。

MCP 解决什么问题，以及它收什么费

MCP 的独特价值只有一个：让模型从一个没有人写进 prompt 的东西身上，发现它能做什么。宿主注册一个 server，server 声明自己的工具列表，模型就能调用一个它的作者从未听说过、宿主也从未硬编码过的能力。这是协议传播开来的真正原因。

但它为这个能力收费，每一个回合、永远收费。这个费用是否值得，取决于一个答案清晰的问题：

你需要模型去"发现"这个能力，还是你本来就知道自己想做什么？

注意本文的立场边界：本文讨论的是"不使用 MCP"。如果你已经决定要用 MCP server，只是还没选好具体哪一个，浏览器场景请看 Playwright MCP 替代方案对比，其余场景请看 如何挑选 MCP server。

实测价格：每个回合 3,141 token

这个数字不是估算出来的。2026-09-15 从 invisible_playwright_mcp 自己的浏览器 server 工具注册表枚举，并用tiktoken的o200k_base编码逐字计数：16 个工具，8,040 字符的工具描述，完整定义合计 3,141 token，在每个会话的每一回合都会被重新发送。一个 40 回合的会话，在读到任何一页内容之前，光是复述"工具有哪些"就要花掉约 128,000 token。

这套测量方法本身在 如何构建一个 MCP server 中有完整的可复现代码——遍历mcp._tool_manager.list_tools()，把每个工具的 name、description、参数 JSON schema 拼起来送进 tokenizer，打印的就是每个回合的固定账单：

"""Measure your own server's tool surface, the way the model receives it.""" import json import tiktoken from invisible_playwright_mcp.mcp.server import mcp # 你自己的 FastMCP 实例 enc = tiktoken.get_encoding("o200k_base") total = 0 for tool in mcp._tool_manager.list_tools(): wire = (tool.name + "\n" + (tool.description or "") + "\n" + json.dumps(tool.parameters, separators=(",", ":"))) total += len(enc.encode(wire)) print(total, "tokens on every turn")

其中的 JSON schema 约占三分之一——这是最容易被低估的部分：很多人只量了 docstring 长度就以为测完了，而参数 schema 是随每个工具一起、每回合原样传输的。

16 个工具在 server.py 的工具注册区中逐一声明：browser_open、browser_close、browser_list、browser_status、browser_navigate、browser_read_text、browser_snapshot、browser_read_html、browser_take_screenshot、browser_watch、browser_click、browser_click_at、browser_type、browser_select_option、browser_press_key、browser_evaluate。注意这套面不是随意攒出来的：项目曾发布 24 个工具，后来删掉 9 个、新增 1 个，收敛到 16 个——被删的是会话层、标签页层等一系列"为了表达某些事而存在、结果发现那些事有更简单形状"的工具。用 server.py 模块说明 里的话说：这个 server 没有会话概念、每个浏览器只驱动一个页面、只有main和support两个固定浏览器，一切能枚举出"第二个"东西的能力都被刻意移除。

这不算是对 MCP 的批评——这正是机制在正常工作：可发现性要求描述必须在场，模型才能发现。但它是拿来进行下文所有替代方案对比的基准数字，因为下面四种替代方案每个回合的成本都是零，只是把费用挪到了别处。同一数字从 server 内部视角的完整拆解见 多少个 MCP 工具算太多。

四种替代方案：各自在哪里付费

1. 直接导入的库（a library, imported directly）

你写代码直接调用那个东西。没有协议、没有 server、没有出现在上下文里的工具描述、没有模型来决定要不要调用。

这比当前业界讨论所暗示的正确答案出现得频繁得多，也正因如此常常被跳过——因为它感觉像退步。但"退步"只在前进的方向是"发现"时才成立；在你自己写的脚本里，根本不存在"发现"这一步。

在 invisible_playwright_mcp 项目内部就能找到一个教科书式的对照：server.py里每个工具都是薄薄的一层包装，"操作"全部实现在actions.py、"浏览器"全部实现在work.py（见 mcp 包结构）。如果工作流是确定的——同样的站点、同样的步骤、每晚跑一次——直接 import 这些操作、写一个脚本，就是成本最低、且可复现的形态。

2. 厂商原生函数调用（provider-native function calling）

你手工把一份函数 schema 列表放进自己的请求里，然后调度模型挑中的那个。模型仍然在做选择——这正是 MCP 通常被称赞的部分——你放弃的是互操作性：你的定义只活在你的应用里，没有任何别的宿主能发现它们。你换来的是对"发送什么、何时发送"的完全控制。

如果你的工具列表是固定的、且是你自己的，这就是"没有注册表的 MCP"。判断它和 MCP 的取舍，用的是下文第二个问题。

3. 纯 API，模型完全出局（a plain API, with the model out of the loop）

这是最强的选项，也是最容易被忽视的。如果调用的序列是已知的，那么让模型每一次运行都重新决策一遍，是用昂贵的办法运行一个你本来就能写出来的脚本，而且更不可复现：没有任何东西保证第四千个条目上的决策和第三个条目上的一致。

这一点在浏览器领域和抓取领域的展开，正是仓库里两篇姊妹文章的主题：Playwright MCP 对比 Playwright CLI 把"谁来决定下一步动作"讲透了——CLI 执行你写好的脚本，模型不在回路里，确定性、并行性正是它的全部价值；用 MCP 做网页抓取 则覆盖"重复本身就是整个工作"的场景——当你要把同一流程跑遍一百个站点时，模型每个站点重新推导一遍步骤，正是最贵的写法。

4. Agent 框架（an agent framework）

它与其说是 MCP 的替代品，不如说是不同的层级：大多数 Agent 框架本身就能消费 MCP server。如果你真正想要的是一个会循环、会重试、会保持状态的程序，那么协议从来就不是缺失的那块拼图。

决定性的测试：下一步是否可预知

一个关于你的业务、而不是关于你的工具的问题：

在运行之前，你能否知道下一步是什么？

• 能：上面的一切都胜过 MCP，其中纯 API 胜过全部。脚本、定时任务、已知流程、批量重复——让模型每个回合重新决定一次，是又贵又不可复现的写法。
• 不能：因为页面每次都不一样，因为答案决定了下一个调用，因为一百个来源有一百种形状——那么模型在已声明的工具中做选择，就值得每回合 3,141 token，而且没有更便宜的获取方式。

第二个问题更窄，专门用来在 MCP 与原生函数调用之间做决定：

有没有"别人"需要发现这些工具？

MCP 真正卖的产品是：一个不是你写的助手，能用上不是你写的 server。如果两端都是你自己的，那你就是在为一个只有一条条目的注册表付费。

我们对自己答案的实践：把自家界面搬上 MCP

这一点值得说明，因为发表本文的团队本身就在发布一个 MCP server。

直到版本 0.9.0，invisible_playwright_mcp 的界面还住在 server 进程内部、直接触达浏览器——因为它就在同一个进程里。0.9.0 之后它被搬了出去，现在像任何其他客户端一样，通过 MCP 与 server 对话。这与本文推荐的方向相反，而理由恰恰是协议成立的那个唯一场景：

特权路径意味着工具从未被证明是足够的。

如果旗舰界面可以绕过协议触达浏览器，协议就会悄悄沦为二等公民的做法，而那些缺口只会暴露给其他人。让自己成为自己的客户端，正是工具面被"我们最在意的东西"测试的方式。Link 的模块说明 把这一点写得很直白：过去是"同一个解释器里的 Python 对象"（registry），现在是"一个通过 MCP 说话的独立程序"；server 只暴露工具、别的什么都不暴露，一切有界面的东西都是这些工具的一个客户端。

这个架构在 sessions.py 里体现为一个具体决策：一个会话 = 一个被拉起的 server 进程。MCP 不再有"会话"概念之后，会话 id 无法再作为工具参数传递，只能成为"哪条连接存在"本身——界面为每个会话 spawn 一个进程，并把INVISIBLE_MCP_SESSION_ID写进它的环境，server 端在 server.py 顶部只读一次。两个会话就是两个进程、两个互不触碰的浏览器状态。

测试端同样以真实链路验证了这个主张：test_the_interface_reaches_a_real_server.py 明确写道——界面是一个 MCP 客户端，这是架构的中心主张，所以它驱动一条 HTTP 请求 →Sessions→ 真实Link（stdio）→ 真实python -m invisible_playwright_mcp子进程 →browser_watch拒绝（因为没开浏览器）→ 错误结果回传的完整链条，除了浏览器之外每个环节都是真的；它还断言客户端确实拿到了 server 的全部工具面（len(tools) >= 16）以及 server 的 instructions。防止界面偷偷退回 import 老路的测试，正是同一个文件里的test_the_client_really_is_a_separate_process。

所以这里的结论不是"别用 MCP"。而是：协议在"发现是真的"的地方赚回它的成本；而大量被包装成"需要 MCP"的事情，不过是一个函数调用多了几步。

快速问答

MCP 的替代品是什么？库导入、厂商原生函数调用、模型不在回路里的纯 API，或 Agent 框架。选哪个取决于下一步是否可预知。

MCP 比函数调用更好吗？不同，不是更好。函数调用是你的工具放在你的应用里；MCP 是任何人的工具放在任何人的宿主里。如果两端都是你的，函数调用更便宜、更简单。

我需要 MCP 才能给模型工具吗？不需要。所有主流模型提供商都直接支持工具定义。

MCP 会消失吗？仓库里的证据没有任何一点指向这个方向，本文的目的也不是押这个注。标准很好，不代表它就是某一项具体工作的正确形状。

MCP 到底花多少钱？以本项目实测：16 个工具、每回合 3,141 token。你自己的数字随描述长度和参数 schema 扩展，而不仅仅随工具数量增长——这是 如何挑选 MCP server 中反复出现、也是 多少个 MCP 工具算太多 从内部审视的同一个数字。

延伸阅读

• 如何挑选 MCP server：面对一堆候选 server 时的选择框架
• MCP 对比 API、对比 RAG：同一问题的数据通路视角
• 如何构建一个 MCP server：含 3,141 token 的完整测量代码
• Playwright MCP 对比 Playwright CLI：纯 API 论点在浏览器上的展开
• 用 MCP 做网页抓取：重复流程场景下的选择
• 多少个 MCP 工具算太多：从 server 内部看同一笔账单

数据来源

• invisible_playwright_mcp 自带的 MCP server，2026-09-15 通过其工具注册表枚举：16 个工具、完整定义 3,141 token，使用tiktoken精确计数而非按字符数估算（测量脚本见 how-to-build-an-mcp-server.md）。
• 0.9.0 界面迁移的架构证据：server.py 模块说明、link.py 模块说明、sessions.py 与 test_the_interface_reaches_a_real_server.py。

本文由发布 MCP server、并把自家界面搬上 MCP 的团队撰写。那条最违背我们自身利益的建议是第三条，它排在第三，正因为它比前两条正确的次数更多。

• 人工智能
• AI Agent
• 浏览器控制
• GUI 自动化
• MCP 服务