人工智能AI Agent浏览器控制GUI 自动化MCP 服务【免费下载链接】invisible_playwright_mcpPlaywright MCP server undetected by anti-bots and captchas: AI agent browses the web on anti-detect stealth Firefox, Python, undetected browser automation, scraping, computer use.项目地址https://gitcode.com/GitHub_Trending/jo/invisible_playwright_mcp点击查看免费下载MCP 只解决一个问题——让模型发现它本来不知道的东西——而它的代价是每个回合都要为这份可发现性重新付费。本文以 invisible_playwright_mcp 项目自身的实测数据为核心16 个工具、每个回合 3,141 token 的固定开销逐条剖析库导入、厂商原生函数调用、纯 API 与 Agent 框架这四种替代方案各自在哪里买单并给出下一步是否可预知这个决定性问题帮助你判断自己手上的任务到底该走协议还是该走一条更便宜的路径。MCP 解决什么问题以及它收什么费MCP 的独特价值只有一个让模型从一个没有人写进 prompt 的东西身上发现它能做什么。宿主注册一个 serverserver 声明自己的工具列表模型就能调用一个它的作者从未听说过、宿主也从未硬编码过的能力。这是协议传播开来的真正原因。但它为这个能力收费每一个回合、永远收费。这个费用是否值得取决于一个答案清晰的问题你需要模型去发现这个能力还是你本来就知道自己想做什么注意本文的立场边界本文讨论的是不使用 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 servers 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.0invisible_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→ 真实Linkstdio→ 真实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 server2026-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 服务【免费下载链接】invisible_playwright_mcpPlaywright MCP server undetected by anti-bots and captchas: AI agent browses the web on anti-detect stealth Firefox, Python, undetected browser automation, scraping, computer use.项目地址https://gitcode.com/GitHub_Trending/jo/invisible_playwright_mcp点击查看免费下载相关推荐为什么IEC104协议成为工业通信不可替代的技术选择为什么IEC104协议成为工业通信不可替代的技术选择 在电力系统自动化和工业控制领域设备间的稳定通信始终是系统可靠运行的核心基础。随着分布式能源监控和工厂设uWebSockets网络协议版本选择性能与兼容性权衡uWebSockets网络协议版本选择性能与兼容性权衡 你是否还在为服务端协议选择而纠结面对用户激增导致的连接延迟、高并发下的吞吐量瓶颈以及老旧设备兼容性后端网络消息路由WebSocketReact Native Paper Dates 未来路线图即将推出的7大新特性React Native Paper Dates 未来路线图即将推出的7大新特性 React Native Paper Dates 是 React Nativ上一篇BFS-Prover-V295%准确率的AI数学证明利器下一篇Port Kill根因分析智能诊断开发环境问题的终极工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考