想象你是一家日渐火爆的餐厅老板。你有着天马行空的创意菜想法（AI 决策），却没有两只手去切菜、颠勺、摆盘。于是你请来了一位“跑腿帮厨”——Playwright MCP Server。这位帮厨有两双灵巧的手（Chromium、Firefox、WebKit），能进出任何厨房（浏览器页面），帮你把想法变成端上桌的菜。但问题来了：你和帮厨之间怎么沟通？总不能每次都用不同方言喊话吧？于是你们约定了一份通用的点菜单——这就是 MCP（Model Context Protocol，模型上下文协议）。老板只需写清“要什么菜、用什么料、上到哪桌”，帮厨照单执行，再把成品端回来给你验收。整篇文章，我们就围绕这位“跑腿帮厨”展开，看看他的上岗流程、拿手绝活、以及如何高效管理后厨。

岗位关联

对于 AI 从业者而言，掌握 Playwright MCP 能让你构建的 AI Agent 真正“长出双手”——不再只是聊天，而是能自主操作网页、完成真实业务闭环。这是从“会说话”到“会做事”的关键一跃。

目录
  1. 可视化演示
  2. MCP基础概念
  3. Playwright能力
  4. 服务架构设计
  5. 核心工具指令
  6. AI集成应用
  7. 性能与优化
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

交互演示MCP客户端-服务端架构连接、JSON-RPC工具调用四步流程(navigate/click/screenshot)及Playwright浏览器自动化操作链，揭示MCP协议标准化工具服务机制。

本节配有交互动效（进入视口后自动加载，约 3KB）。

MCP客户端-服务端架构 LLM Host通过MCP Client连接服务端 Playwright MCP Server暴露浏览器工具 Host→Client→Server→Browser MCP协议标准化AI与外部工具的交互

MCP基础概念

餐厅老板第一次见到跑腿帮厨时，最头疼的问题就是：我们俩怎么说话？老板习惯说“把三号桌的客人哄开心”，帮厨却只听得懂“走到三号桌、拿起菜单、递给客人”。这就是 AI Agent 与外部工具之间最大的鸿沟。MCP（Model Context Protocol，模型上下文协议）正是为解决这道鸿沟而生的“标准点菜单”——它规定了一张订单上必须有哪些栏目、用什么格式书写、谁来签字确认，让任何老板和任何帮厨都能无缝配合。

从技术角度说，MCP 是由 Anthropic 于 2024 年底推出的开放标准，旨在统一 AI 应用与数据源、工具之间的连接方式。它把世界划分为三个角色：Host（宿主，也就是 AI 应用本身，相当于餐厅老板）、Client（协议客户端，相当于老板手边的点单机）、Server（工具服务器，相当于厨房里的帮厨）。三者之间通过结构化的 JSON-RPC 消息通信，不是靠默契，而是靠标准。

MCP 的消息结构看似简单，却像一张设计精良的快递面单，每个字段都承担着一个关键职责。让我们拆解这张“面单”：

有了这套统一面单，老板不需要操心帮厨的方言，帮厨也不必猜测老板的意图。MCP 让 AI 与工具的对接从“定制开发”变成了“即插即用”——这正是它作为开放标准最大的价值所在。

Message={id, role, tool, params, result}Message = \{ id,\ role,\ tool,\ params,\ result \}
这条公式描述了一条 MCP 消息的五个核心字段：编号、角色、工具、参数、结果。就像一张外卖订单有订单号、下单人、菜品名、备注和出餐状态一样。
  1. id 字段消息的唯一编号，用于关联“请求-响应”对，好比快递面单上的运单号，老板和帮厨靠它核对是哪笔订单。
    idid
  2. role 字段标识消息发送方的角色，是 Host 还是 Server，确保消息在正确方向上流转。
    rolerole
  3. tool 字段指明要调用的具体工具名称，比如“打开网页”或“点击按钮”，相当于订单上的“菜品名”。
    tooltool
  4. params 字段携带工具执行所需的参数，包括 URL、CSS 选择器、超时时间，就像订单备注“少盐多辣”。
    paramsparams
  5. result 字段承载工具执行后的返回数据，如页面标题、操作状态，相当于出餐台的“出品单”。

Playwright能力

老板有了点菜单，但还得确认这位帮厨到底有几把刷子。Playwright 就是微软开源锻造的一套“厨房工具套装”。它最初定位是浏览器自动化测试框架，但在 MCP 时代，它华丽转身成为 AI Agent 的“数字双手”。为什么偏偏是它？因为它一个人就掌握三门“厨艺”——Chromium、Firefox、WebKit 三大浏览器内核，意味着无论客人的“浏览器口味”是什么，帮厨都能应付。

Playwright 的核心能力可以归结为三点。第一，统一 API：无论底层跑的是哪个浏览器内核，暴露出来的操作语法完全一致，老板不需要为不同浏览器学两套指令。第二，自动等待：页面元素还没加载出来？帮厨会原地等着，直到元素可交互再动手，绝不空手捞鱼。第三，多语言支持：Python、Node.js、Java、.NET 都能驱动它，技术栈再杂也不怕。

从自动化原理上看，Playwright 不是简单地模拟鼠标键盘，而是通过浏览器调试协议（CDP / WebDriver BiDi）直接与浏览器内核对话，像帮厨直接接管了厨房的每个灶台。它的浏览器家族可以这样表示：

正是这“三口锅”的完整覆盖，让 Playwright 在浏览器自动化领域脱颖而出。对于 AI Agent 而言，选择 Playwright 就等于雇了一位“全能帮厨”——无论用户用哪种浏览器、访问哪种网页，他都能稳稳当当地完成任务。

Browser={chromium, firefox, webkit}Browser = \{ chromium,\ firefox,\ webkit \}
这条公式表示 Playwright 支持的三种浏览器引擎：Chromium（Chrome 同款内核）、Firefox（火狐内核）、WebKit（Safari 内核）。三者共用一套 API，但各自拥有独立的兼容性特性。
  1. chromium谷歌 Chrome 的同款内核，市场占有率最高，是自动化任务的首选引擎，相当于帮厨最常用的那口炒锅。
    chromiumchromium
  2. firefox火狐浏览器的 Gecko 内核，在处理某些隐私保护页面时更有优势，像帮厨备用的珐琅锅。
    firefoxfirefox
  3. webkit苹果 Safari 使用的渲染引擎，用于在 macOS/iOS 环境下的页面兼容验证，好比帮厨的蒸笼，专为特定菜式准备。
    webkitwebkit

服务架构设计

帮厨上岗前，老板需要为他准备一个“工作台”：工具箱挂哪、工具怎么摆、开工前要完成哪些检查。在 MCP 世界里，这个工作台就是 MCP Server 的架构设计。我们不需要从零手搓一套服务器，官方已经提供了 @playwright/mcp 这个开箱即用的“帮厨套装”，一行命令就能启动。

Server 的架构包含三个关键环节。首先是Server 配置：启动时指定端口、浏览器星型（要装几个“手”）、是否开启无头模式等。其次是工具注册：帮厨会把所有拿手绝活登记成一张“菜单”，每道菜（工具）都有名字、描述、参数表，这样老板才知道“这道菜是干嘛的”。最后是会话管理：从接单到交单的生命周期，由 Server 统一维护，确保多个订单之间互不串台。

这个生命周期可以看作一条流水线：

理解了这条生命线，你就掌握了 MCP Server 的骨架。任何复杂的自动化任务，都是在这条生命线上不断重复"Operate"这个环节——每调用一次工具，就是帮厨伸出一次手。

Lifecycle:Init→Connect→Operate→DisconnectLifecycle: Init \rightarrow Connect \rightarrow Operate \rightarrow Disconnect
这条公式展示了 MCP 会话的完整生命周期：初始化配置 → 建立连接 → 执行操作 → 断开释放。就像帮厨一天的上班流程：换工服 → 打卡 → 干活 → 下班。
  1. Init（初始化）加载 Server 配置、启动浏览器实例、准备工具列表，相当于帮厨上班先换好工服、洗好手。
    InitInit
  2. Connect（建立连接）Client 与 Server 通过 stdio 或 SSE 建立双向通信通道，好比老板和帮厨之间架起一条专用电话线。
    ConnectConnect
  3. Operate（执行操作）调用已注册的工具完成具体任务，这是整个生命周期中最核心的环节，相当于帮厨真正开始切菜炒菜。
    OperateOperate
  4. Disconnect（断开连接）任务全部完成后关闭连接、释放浏览器资源，避免内存泄漏，好比帮厨下班前收拾灶台、关煤气。
    DisconnectDisconnect

核心工具指令

帮厨的“手艺清单”是老板最关心的部分：他具体会哪些动作？Playwright MCP 的工具集像一本武林秘籍，招招有名字、有套路。我们把这些招式归为四大类：导航跳转、元素定位、交互操作、数据提取。

导航跳转（对应 browser_navigate）就像帮厨认路——输入一个 URL，他就哒哒哒跑到那个页面，还能把页面标题带回来给老板。元素定位是帮厨找料——通过 CSS 选择器或文本内容在页面里锁定目标，比如“那个写着'登录'的按钮”。交互操作是帮厨动手——点击、输入、滚动、下拉选择，每一招都带自动等待，确保元素可交互后才出手。数据提取是帮厨记录——把页面里的文本、链接、表格数据“抄”下来，还用可访问性树（Accessibility Tree）给 LLM 提供结构化的“菜色清单”。

一次完整的工具调用可以拆成三个环节：

这套“定位-交互-验证”的循环，构成了 Playwright MCP 所有高级能力的底座。无论 AI Agent 要执行的是最简单的点击，还是最复杂的跨页面爬取，底层都在反复调用这三板斧。

Action=Locate(e)→Interact(o)→Verify(r)Action = Locate(e) \rightarrow Interact(o) \rightarrow Verify(r)
这条公式表示一次浏览器操作的标准流程：先定位元素 e，再执行交互操作 o，最后验证结果 r。三个环节缺一不可，就像帮厨做一道菜：先找到食材，再下锅翻炒，最后尝一口确认味道。
  1. Locate(e)通过选择器或文本定位目标元素，返回元素的唯一标识，相当于帮厨在厨房里找到那把指定的食材。
    Locate(e)Locate(e)
  2. Interact(o)对定位到的元素执行点击、输入等操作，每次交互都会触发浏览器的真实事件，相当于帮厨下锅翻炒。
    Interact(o)Interact(o)
  3. Verify(r)验证操作后的页面状态，比如按钮是否响应、输入是否生效、页面是否跳转，相当于帮厨出锅前尝一口确认咸淡。
    Verify(r)Verify(r)

AI集成应用

现在老板要开始真正指挥帮厨做一桌大餐了。AI Agent 与 Playwright MCP 的集成，核心是“对话式编排”——老板不需要写代码，只需要用自然语言描述目标：“帮我去这个网站找到今天的头条新闻，然后总结给我。”帮厨（MCP Server）就会自动拆解出需要执行的一连串工具调用。

这个过程的背后是 ReAct（Reasoning + Acting）推理循环：大模型先思考当前情况，决定调用哪个工具，拿到工具返回的观察结果后，再次思考下一步。每次工具调用后的页面快照（可访问性树或截图）都会追加到对话上下文中，相当于老板在笔记里不断贴便利贴，记录帮厨每步干了啥。这样即便中间某个环节出了岔子，老板也能根据笔记调整下一步指令。

多步任务可以形式化为一个任务分解模型：

通过这种方式，AI Agent 把“天马行空的创意”（用户指令）翻译成“帮厨听得懂的动作序列”（工具调用），再借助 Playwright MCP 的双手在真实浏览器中执行。这就是 AI 从“光说不练”到“真刀真枪干活”的临门一脚。

Task=∑i=1nStepiTask = \sum_{i=1}^{n} Step_i
这条公式表示一个大任务可以分解为 n 个有序的小步骤，求和号表示顺序执行——先做第一步，拿到结果，再做第二步。就像做一桌年夜饭，先洗菜、再切菜、后炒菜，一步都不能乱。
  1. Task（总任务）用户最终要达成的目标，比如“在电商网站搜索并购买指定商品”，对应老板头脑中的那桌大餐。
    TaskTask
  2. Step_i（第 i 步）分解后的原子操作，比如“打开首页”、“输入搜索词”、“点击购买”，每一步都是对 MCP 工具的一次调用。
    StepiStep_i
  3. Σ（求和）表示步骤之间是顺序依赖关系，前一步的输出是后一步的输入，好比一桌菜必须按先后顺序下锅。
    ∑i=1n\sum_{i=1}^{n}

性能与优化

餐厅生意好了，订单越来越多，老板开始发愁：帮厨只有一个，忙不过来怎么办？后厨的节奏就是整个服务的性能。Playwright MCP 的优化策略，就是让“后厨”在任何负载下都游刃有余。

第一个优化点是连接复用。每次任务都重启浏览器行不行？行，但代价极高——浏览器冷启动、页面重载、资源再下载，就像帮厨每次接单都要重新买菜、重新烧火。更聪明的做法是复用浏览器实例和上下文（Context），保留登录状态和 Cookie，让帮厨始终“热手”待命。第二个优化点是并发控制。当多个 AI Agent 同时请求同一个 MCP Server 时，必须为每个任务分配独立的浏览器上下文（相当于给每位帮厨配独立的灶台），避免互相抢锅铲。第三个优化点是超时重试：网络慢、页面卡、元素消失，都是常态。合理的超时和重试策略，就像帮厨发现火候不对会及时调整，而不是傻等。

整体耗时的构成可以写成这样：

性能优化的本质，是在“更快”和“更稳”之间找平衡。就像一家成熟的餐厅，既要有速度，也不能因为赶时间砸了招牌。对 AI 工程化而言，掌握这些优化策略，才能真正把 Playwright MCP 从“能跑”推向“跑得又快又稳”。

Ttotal=Tplan+Texecute+TverifyT_{total} = T_{plan} + T_{execute} + T_{verify}
这条公式表示一次自动化任务的总耗时 = 模型推理规划耗时 + 浏览器执行耗时 + 结果验证耗时。优化任何一个环节都能缩短总时间，就像给上菜提速可以从“想菜单”、“做菜”、“尝菜”三处同时下手。
  1. T_plan（规划耗时）大模型根据上下文决定下一步工具调用的推理时间。减少上下文冗余、使用更快的模型能有效压缩此段，相当于老板看菜单下单的速度。
    TplanT_{plan}
  2. T_execute（执行耗时）Playwright 在浏览器中真正执行操作的时间。复用连接、减少重定向、使用无头模式可以优化此段，相当于帮厨手脚麻利地炒菜。
    TexecuteT_{execute}
  3. T_verify（验证耗时）检查操作是否生效、是否需要额外等待的时间。合理设置等待策略（如 waitUntil: 'domcontentloaded'）能缩短此段，相当于帮厨快速尝一口确认味道的时间。
    TverifyT_{verify}

AI 应用场景

智能网页数据采集

阶段：Agent 执行阶段（工具调用）

解决的问题：传统爬虫需要为每个网站手写解析规则，改版即失效、维护成本高。AI Agent 通过 Playwright MCP 实时理解页面结构，像老板指挥帮厨“把菜单上所有招牌菜名抄下来”一样，用自然语言描述需求即可完成结构化数据抓取。

具体案例：某市场调研公司的分析师不再手动浏览几十家竞品官网。她只需对 AI 助手说：“去这三家公司的官网，找到产品定价页，把套餐名称和价格整理成表格。”Agent 通过 Playwright MCP 逐页导航、提取、汇总，最终生成一份 Markdown 表格，整个过程 5 分钟完成。

自动化端到端网页测试

阶段：结果验证阶段

解决的问题：传统 QA 测试脚本需要维护海量选择器和等待逻辑，页面迭代频繁导致测试大面积“红屏”。利用 Playwright MCP，测试人员可以用自然语言描述测试场景，由 AI 动态生成并执行浏览器操作，无需手工编写脆弱的选择器。

具体案例：一家 SaaS 公司的 QA 团队在每次发版前，让 AI Agent 自动登录后台、创建一条新记录、上传附件、检查列表页是否出现该记录。AI Agent 调用 Playwright MCP 完成操作并返回每一步的截图，测试失败的环节自动高亮报错。

个人助理式网页任务代理

阶段：任务规划与执行（多步工具编排）

解决的问题：用户在完成“订机票 + 订酒店 + 写行程单”这类组合任务时，需要在多个网站间来回切换、手动搬运信息。AI Agent 借助 Playwright MCP 获得“跨网站连贯操作”能力，用户只需给出终极目标。

具体案例：一位用户对 AI 说：“帮我查下周五从上海到北京的航班，选价格最低的，同时订一家离机场 3 公里内的酒店。”Agent 依次打开两个旅行网站，执行搜索、筛选、对比等 20 多次工具调用，最终给出推荐方案并等待用户确认后再下单。

Python 演示

python43 行
"""演示 Playwright 浏览器自动化核心流程（模拟 MCP 工具层）"""from playwright.sync_api import sync_playwright  def mcp_tool_navigate(page, url):    """工具1：导航到指定网址"""    page.goto(url, timeout=15000)    return {"status": "ok", "title": page.title()}  def mcp_tool_extract(page, selector):    """工具2：提取页面元素信息"""    elements = page.locator(selector)    count = elements.count()    texts = [elements.nth(i).inner_text()[:20] for i in range(min(count, 3))]    return {"count": count, "samples": texts}  def mcp_tool_click(page, selector):    """工具3：点击指定元素"""    page.locator(selector).first.click(timeout=5000)    return {"status": "clicked"}  def main():    with sync_playwright() as p:        browser = p.chromium.launch(headless=True)        page = browser.new_page()         result = mcp_tool_navigate(page, "https://news.ycombinator.com")        print("导航结果:", result)         links = mcp_tool_extract(page, "span.titleline a")        print("链接统计:", links)         mcp_tool_click(page, "span.titleline a")        print("点击完成，当前页面:", page.url)         browser.close()  if __name__ == "__main__":    main()
目的：用 Python 实现一个简化版的“MCP 工具层”，展示导航、提取、点击三个核心工具如何配合，模拟 AI Agent 通过 Playwright 操控浏览器的流程。
  1. from playwright.sync_api import sync_playwright导入 Playwright 的同步 API，同步模式让代码像菜谱一样从上到下线性执行，最适合初学者快速上手
  2. with sync_playwright() as p:用上下文管理器启动 Playwright 运行时，相当于帮厨进厨房后自动完成换装和洗手，退出时自动清理
  3. p.chromium.launch(headless=True)启动 Chromium 浏览器并开启无头模式（不显示窗口），就像帮厨在后厨悄悄干活，不打扰前厅客人
  4. page.goto(url, timeout=15000)页面导航指令，相当于 MCP 工具 browser_navigate，15 秒超时防止网络卡住无限等待
  5. page.locator(selector)核心的定位器 API，通过 CSS 选择器在页面中“找食材”，返回一个可统计、可遍历的元素集合
  6. elements.nth(i).inner_text()[:20]逐个提取元素文本并截断前 20 字符，相当于帮厨把每道菜的名字抄在备忘本上，带回给老板看
  7. page.locator(selector).first.click(timeout=5000)定位到第一个匹配元素并点击，5 秒超时 + 自动等待机制确保元素可交互后才下手

常见误区

误区“MCP 不就是把 API 封装成 JSON 格式发请求吗？和我们平时调的 REST API 有什么区别？把工具地址换成 HTTP URL 不就行了？”

正解MCP 的定位不是“传输协议”，而是“工具接入标准”。它定义的是工具如何被描述、注册、发现和调用，而不是数据怎么在网络上传输。MCP 默认支持两种传输层：stdio（本地进程间通信）和 SSE（流式服务端推送），未来还可以扩展其他传输。就像老板和帮厨之间定的不是“打电话还是写信”（传输层），而是“订单上该写哪些栏目、谁来签收”（语义层）。

为何常见：因为大多数接触 MCP 的人都是从“调用一个远程工具”的视角切入的，自然把它类比成 HTTP API，忽略了它作为“协议标准”的更深层设计。

误区“AI Agent 通过 Playwright MCP 打开网页后，是不是就像人一样在浏览器里看到页面？它应该能直接理解每个像素的颜色和布局吧？”

正解多数时候，LLM 拿到的不是视觉图像，而是 Playwright 通过可访问性树（Accessibility Tree）提取的结构化文本快照——也就是页面上“有什么按钮、什么链接、什么输入框”的文字描述。只有在显式启用截图工具时，模型才拿到图片。这就像老板看的不是帮厨做菜的视频，而是他回来嘴述的“菜色描述单”。

为何常见：人类天然用视觉理解世界，容易把“浏览器自动化”直觉等同于“像人一样看屏幕”，忽略了技术实现中文本快照才是主要的信息通道。

误区“要接入 MCP，我得自己实现一套服务器端代码，包括 JSON-RPC 处理、工具注册框架、连接管理，工作量太大了。”

正解社区和官方已经提供了成熟的现成实现。以 Playwright 为例，只需执行 npx @playwright/mcp@latest 即可启动一个功能完整的 MCP Server，它自动暴露浏览器控制工具集。官方还提供了 Python/TypeScript 的 SDK 帮助快速开发自定义 Server。就像老板不需要自己砌灶台，而是直接雇一位自带全套厨具的帮厨。

为何常见：早期的 MCP 教程大量展示“从零构建 Server”的代码，让人误以为这是必经之路，其实多数场景下“用现成服务 + 少量配置”就足够了。

误区“Playwright 不是 QA 工程师用来做自动化测试的工具吗？跟我做的 AI 应用有什么关系？”

正解测试只是 Playwright 最古老的应用场景。在 MCP 时代，它已经成为 AI Agent 的“通用双手”——凡是人类能在浏览器里做的事（查资料、填表、订票、购物），AI 都能通过 Playwright MCP 代劳。它从“测试工具”升维成“数字世界的操作层”。

为何常见：Playwright 的官方文档确实从“测试框架”角度切入，大量历史教程也都在讲断言和测试报告，形成了先入为主的印象。

面试题

Q1. MCP Server 在 MCP 协议中的角色最接近什么？

单选题 · easy

  • A.终端用户的聊天界面
  • B.执行具体任务的工具端← 正确答案
  • C.负责模型训练的框架
  • D.存储网页数据的数据库

答案：B。MCP Server 相当于餐厅里的“跑腿帮厨”，负责执行具体任务（工具调用）。选项 A 是 Host 的职责，C 和 D 是无关的类比，只有 B 准确描述了 Server 的定位。

Q2. Playwright MCP 中，浏览器窗口的“地址栏”对应哪个工具指令？

单选题 · easy

  • A.点击操作指令
  • B.页面导航指令← 正确答案
  • C.数据提取指令
  • D.截图保存指令

答案：B。地址栏的功能是输入网址并跳转，这正是 browser_navigate 导航指令的职责。点击、提取、截图分别对应交互、数据采集和视觉记录，与地址导航是不同维度的操作。

Q3. MCP 协议默认支持的传输方式包括？

单选题 · easy

  • A.仅限同机进程通信
  • B.标准输入输出 stdio← 正确答案
  • C.只能无线蓝牙连接
  • D.必须用 USB 串口

答案：B。MCP 的两种标准传输层是 stdio（本地进程间）和 SSE（流式服务端事件）。选项 A 过于绝对，C 和 D 是干扰项。stdio 就像老板和帮厨在同一间厨房直接喊话，SSE 则是通过传菜电梯跨楼层沟通。

Q4. LLM 通过什么机制了解网页中有哪些可交互元素？

单选题 · mid

  • A.可访问性树快照← 正确答案
  • B.浏览器进程内存
  • C.服务器运行日志
  • D.编译后的字节码

答案：A。Playwright MCP 通过可访问性树（Accessibility Tree）提取页面上按钮、输入框、链接等元素的结构化描述，作为文本快照返回给 LLM。选项 B、C、D 分别涉及系统底层细节，LLM 无法也不需要通过这些途径理解页面。

Q5. MCP 会话生命周期的正确顺序是？

单选题 · mid

  • A.连接→初始化→操作→断开← 正确答案
  • B.操作→连接→断开→初始化
  • C.断开→操作→初始化→连接
  • D.初始化→断开→连接→操作

答案：A。正确的生命周期为 Init（初始化配置）→ Connect（建立连接）→ Operate（执行工具调用）→ Disconnect（断开释放资源）。对应帮厨上班流程：换工服 → 打卡 → 干活 → 下班。选项 B、C、D 都打乱了顺序，违背了“先准备、再连接、后执行、最后清理”的基本逻辑。

Q6. 下列哪项属于 Playwright 不支持的浏览器内核？

单选题 · mid

  • A.Chromium 浏览器内核
  • B.Firefox 浏览器内核
  • C.WebKit 浏览器内核
  • D.V8 JavaScript 内核← 正确答案

答案：D。Playwright 支持 Chromium、Firefox、WebKit 三大浏览器引擎，而 V8 只是 JavaScript 解释引擎，不是完整的浏览器内核。就像帮厨有炒锅、蒸锅、炖锅，但“火焰控制器”只是炒锅的一个零件，不能独立成为烹饪工具。

Q7. 以下哪些属于 MCP 协议的组成部分？

多选题 · mid

  • A.统一的消息格式← 正确答案
  • B.标准的工具描述← 正确答案
  • C.模型参数调整器
  • D.会话管理机制← 正确答案

答案：ABD。MCP 协议包含统一消息格式（JSON-RPC）、标准工具描述（名称/参数/说明）和会话管理机制（生命周期状态）。选项 C 的“模型参数调整器”不在 MCP 协议范围内——MCP 是连接外部工具的标准，不干预模型内部的推理参数。

Q8. 与“每次任务都新建浏览器”相比，“复用浏览器上下文”的核心收益是什么？

单选题 · hard

  • A.可以保留登录和会话状态← 正确答案
  • B.能够自动生成测试报告
  • C.会减少服务器磁盘占用
  • D.会让模型文件大小变小

答案：A。复用浏览器上下文（Browser Context）可以保留 Cookie、LocalStorage 等会话数据，避免反复登录。它还减少了浏览器启动销毁的开销，但核心场景价值是会话连续性。选项 B、C、D 与上下文复用没有直接因果关系——测试报告是测试框架的事，磁盘和模型文件与浏览器上下文无关。

Q9. AI Agent 通过 Playwright MCP 可以完成哪些操作？

多选题 · hard

  • A.点击页面上的按钮← 正确答案
  • B.表单填写与提交← 正确答案
  • C.自主训练机器学习模型
  • D.抓取并结构化页面数据← 正确答案

答案：ABD。Playwright MCP 的核心工具覆盖点击、输入、导航、提取等浏览器操作，因此 A、B、D 都在能力范围内。选项 C 的“训练机器学习模型”超出了浏览器自动化的能力边界——那是 GPU 平台或训练框架的职责，不是浏览器工具的活儿。

Q10. 多个 AI Agent 并发使用同一个 Playwright MCP Server 时，推荐的做法是？

多选题 · extreme

  • A.每个 Agent 启用独立浏览器上下文← 正确答案
  • B.所有 Agent 共享同一个页面
  • C.使用会话隔离控制资源← 正确答案
  • D.关闭所有并发限制机制

答案：AC。每个 Agent 使用独立浏览器上下文（Browser Context）实现互相隔离，配合 MCP 的会话管理机制（Session）控制资源分配，是标准实践。选项 B 让多个 Agent 共享同一页面会导致状态互相踩踏；选项 D 关闭所有并发限制会让服务在高峰期崩溃——就像后厨不排队、灶台不分工，必然天下大乱。