作者：Christopher Harrison

排版：Alan Wang

使用 Playwright MCP 服务器和 GitHub Copilot，轻松复现并调试 Web 应用问题。

我知道这听起来像是在做梦，但实际上，大多数错误报告确实包含了复现错误的步骤（也就是“复现步骤”）。虽然拥有这些步骤非常有用，但逐一执行并验证它们的过程依然很繁琐。理想情况下，我们会有端到端测试或验收测试来自动化这个流程，可惜许多项目都缺乏健全的测试机制。

幸运的是，借助 Playwright 模型上下文协议（MCP）服务器，GitHub Copilot 可以将整个流程实现自动化。

接下来，我们来探讨如何将复现步骤传递给 Copilot 的 Agent 模式，让它借助 Playwright MCP 服务器逐步执行这些步骤并验证问题。随后，它还会进一步追踪并修复这个错误。

什么是 Playwright 和 MCP？快速概览

Playwright 是一个面向 Web 应用的端到端测试框架。你可以用它编写脚本来模拟用户操作，验证应用的功能，并确保质量。

例如，如果你正在开发一个购物应用，你可以创建一系列脚本来完整演示从搜索商品、加入购物车到完成购买的流程。这些脚本是自动化的，可以在几秒钟内验证整个过程。

MCP（最初由 Anthropic 开发）是一个开放（且开源）的协议，用于向 AI Agent 暴露工具。这些工具可以提供额外的上下文和信息，或者让 AI Agent 执行某些操作。

把这两者结合起来：有一个 Playwright MCP 服务器，它将 Playwright 的工具提供给 AI Agent（在这里是 GitHub Copilot），用于同时创建这些脚本并直接执行操作。这让 Copilot 可以真正替我们完成复现步骤！

如何在 VS Code 中为 GitHub Copilot 配置 Playwright MCP 服务器

要使用 Playwright MCP 服务器，它需要在你的 IDE 中可用。在 VS Code 中，你可以选择：

• 安装 Playwright MCP 服务器，使其对所有项目可用；

• 或者在项目的 .vscode 文件夹中创建一个名为 mcp.json 的文件，并添加以下内容：

{
  "servers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest"
      ]
    }
  }
}

完成后，你会注意到在 playwright 上方出现一个小小的 play 按钮。点击该按钮即可启动服务器，这样你就能在 Copilot 的 Agent 模式中使用它了！（可以参考 Copilot agent 模式的使用指南）
你很可能需要对 Playwright 进行一些配置，尤其是当你的网站有比较复杂的启动流程时。我的项目基于 Agents in SDLC 工作坊中的示例网站（可以在 GitHub samples 找到），它的前端是用 Astro & Svelte 编写的，后端使用 Flask。通过这样的配置，Playwright 才能正确启动应用。有趣的是：这个配置文件其实是 Copilot 自动生成的！

我在 Copilot agent 模式下用了下面这个 prompt 来完成，你也可以根据自己的需求进行修改：

Add Playwright to this project. When configuring Playwright, note the startup script for the site. 
Ensure the configuration uses this startup script, and reuses the server if one is already launched.

场景说明

假设我们有一个专门为 DevOps 主题桌游打造的众筹网站（真是个蓬勃发展的产业）。用户可以通过发行商和类别来筛选搜索。

在发现发行商筛选器无法使用后，有位用户在 GitHub 上提交了如下 issue：

## Error
The publisher filter doesn't actually filter the games by publisher.
## Repro steps
1. Go to the homepage.
2. Select a publisher from the dropdown list; the page updates.
3. Review the updated list, noting no change in the games listed.
## Expected behavior
The only games displayed are ones published by the selected publisher.
## Actual behavior
All games are still displayed.

Copilot Agent 模式如何结合 Playwright 自动化复现 Bug

Copilot agent 模式的设计初衷是作为一名“结对程序员”，这意味着我们可以把任务交给它，然后再对它的工作进行审查。换句话说，我们只需要描述当前所看到的情况、需要解决的问题，以及我们期望 Copilot 完成的事情，然后就可以交由 Copilot 来处理！

如果你跟随操作，会注意到我把用户提交的 issue 用自己的话重新表述了一遍。我经常这么做，因为这样不仅能帮助我更好地理解需求，也便于在需要时回头向最初提交 issue 的用户确认更多细节。

在实际操作中，我最终将以下提示词发送给了 Copilot agent 模式：

A user is reporting the publisher filter doesn't do anything. Can you please use Playwright to confirm this is an issue, and if so track it down? Start by going to the landing page, using the dropdown for publisher, and seeing what happens. Thanks!

💡 专业提示：如果你想更“炫”一点，还可以把 GitHub MCP 服务器集成到流程中，让 Copilot 直接去追踪 issue 并读取文本。不过为了让这篇博客更简洁，我这里只演示 Playwright MCP 服务器（你可以在我们的指南中了解更多关于 GitHub MCP 服务器及其使用方法）。

接下来，Copilot 开始工作了。它利用 Playwright MCP 服务器启动了网站并执行了复现步骤。随后确认了用户的反馈：发行商筛选器确实没有任何作用。

在掌握了这个信息后，Copilot 开始探索项目来追踪 bug。它先查看了前端代码，看起来一切正常。借助 Playwright MCP 服务器，它还验证了 API 调用确实在发生。然后它检查了后端，发现了一个（其实很简单的）问题：拼写错误。

让我非常欣赏的一点是：在提出修复方案后，它又回到 Playwright 去验证修复是否真的有效。

完成这一切后，我可以确定：Copilot 已经确认了 bug，生成了修复方案，并验证修复确实解决了问题。接下来，我就可以专注于代码审查、运行额外测试，并最终创建我的 Pull Request。

为什么在调试 Web 应用时要结合使用 Playwright MCP 和 GitHub Copilot

当然，这次的 bug 本身比较简单，因为我希望把演示重点放在 Copilot Agent 模式和 Playwright 上。但根据我的经验可以确认：当面对更复杂的 bug 时，Copilot 的价值会更加突出（这是亲身实践得出的结论）。

关键在于：让 Copilot Agent 模式具备使用 Playwright 的能力，能让它“看到”自己所做修改对网站产生的影响，并且可以更全面地与网站交互。你可以在 Copilot 的帮助下，快速为项目配置 Playwright，充分利用这一功能。

如果你还没有这样做，还可以更进一步，把 Playwright 的端到端测试直接集成到你的项目中。

阅读文档，开始在 GitHub Copilot 中使用 Agent 模式 >