使用 MCP 增强 GitHub Copilot 代理模式

了解如何使用模型上下文协议（Model Context Protocol，MCP）来扩展 Copilot Chat 的代理能力。

本文内容

注意

MCP 服务器在 Copilot 中的企业和组织策略，默认禁用，用于控制 MCP 的使用。

关于 Copilot 的代理能力和 MCP

Copilot 的代理能力指的是它能够独立工作——在不需要持续指导的情况下执行多步骤工作流；做出决策——根据上下文选择合适的工具和方法；以及迭代和适应——依据反馈和结果调整自己的做法。您可以通过使用代理模式来访问这些能力。

当与模型上下文协议（MCP）服务器结合使用时，代理模式的威力会显著提升，使 Copilot 能够在不切换上下文的情况下访问外部资源。这让 Copilot 能够完成代理“循环”，即通过自主检索相关信息、分析反馈并做出明智决策来动态调整方案。借助 MCP，Copilot 能在最小的人为干预下完成任务，并根据发现不断优化策略。

将 MCP 与代理模式结合的好处

使用 MCP 服务器配合代理模式时，您将解锁以下关键收益

  • 扩展的上下文：MCP 服务器为 Copilot 提供对外部数据源、 API 和工具的访问。
  • 降低手动工作量：Copilot 能完成创建议题、运行工作流等任务，让您专注于更高价值的工作。
  • 无缝集成：Copilot 能在涉及多个工具和平台的任务中保持同一上下文，无需自定义集成。

使用 MCP 与代理模式的最佳实践

遵循以下最佳实践，充分发挥 MCP 服务器与代理模式的组合效益。

提示策略

  • 明确目标：在提示中清晰说明您想要完成的任务以及期望的输出。
  • 提供上下文：包含项目背景、需求以及 Copilot 可访问的外部资源链接等相关信息。
  • 设定边界：指明任务的约束或限制。例如，如果您希望 Copilot 仅规划新功能而不进行实际更改，请明确说明；也可以限制启用的 MCP 工具。
  • 请求确认：让 Copilot 在进行重大更改前先确认其理解是否正确。
  • 使用提示文件或自定义指令：您可以创建提示文件或自定义指令文件，为不同的 MCP 服务器定义 Copilot 的行为方式。参见 关于自定义 GitHub Copilot 响应。

MCP 服务器使用

  • 选择相关服务器：挑选并启用与您具体工作流需求相匹配的 MCP 服务器。
  • 从简开始：先使用少数成熟的 MCP 服务器，随后再逐步加入更复杂的集成。
  • 测试连通性：确保所有 MCP 服务器已正确配置且可访问后，再启动代理模式任务。

安全考虑因素

  • 优先使用 OAuth：对于 GitHub MCP 等服务器，建议使用 OAuth 认证而非个人访问令牌。参见 在 IDE 中使用 GitHub MCP 服务器。
  • 限制权限：仅授予 MCP 服务器完成任务所需的最小权限。
  • 审查连接：定期审计哪些 MCP 服务器能够访问您的开发环境。
  • 监控活动：追踪 Copilot 通过 MCP 服务器执行的各项操作。
  • 防止机密泄漏：Push Protection 可阻止机密被包含在 AI 生成的响应中，并防止您通过 GitHub MCP 服务器执行的操作泄露机密。目前仅在公共仓库中可用。详见 关于 Push Protection。

示例场景：实现可访问性合规

注意

以下情景仅用于演示如何使用代理模式和 MCP 服务器从头到尾完成任务的模式与策略；情景、提示和响应均为示例。

假设您的团队收到反馈，客户门户需要更新以符合最新的可访问性标准。您被指派在以下指引下改进整个应用的可访问性：

  • 设计团队定义的一系列规范。
  • 可访问性审计后在项目仓库中创建的议题。

您可以使用 Copilot 代理模式配合多个 MCP 服务器，高效实现可访问性改进。

下面的情景展示了如何在不同阶段（研究、规划、实现、验证）使用独立提示，形成多个与软件开发生命周期阶段 loosely 对齐的代理“循环”。这种方式提供了自然的检查点，您可以在每个阶段审阅进度、提供反馈并在 Copilot 进入下一阶段前调整需求。

先决条件

在使用 MCP 的代理模式之前，请确保您已具备以下条件：

  • 已安装带有 Copilot 集成和 MCP 支持的 IDE（如 Visual Studio Code）
  • 已启用代理模式
  • 能够访问您计划使用的 MCP 服务器

配置 MCP 服务器

首先，需要配置您预期 Copilot 将使用的 MCP 服务器。针对本示例情景，我们将使用：

  • GitHub MCP 服务器：配置 GitHub MCP 服务器，使 Copilot 能访问您的仓库、检查代码库、检索现有议题、创建分支并管理 Pull Request。参见 在 IDE 中使用 GitHub MCP 服务器。

  • Figma MCP 服务器：配置 Figma MCP 服务器，以便 Copilot 访问包含可访问性规范的设计文件，例如颜色对比要求、焦点状态和交互模式。参见 Figma-Context-MCP 或尝试 Dev Mode MCP 服务器。

  • Playwright MCP 服务器：搭建 Playwright MCP 服务器，使 Copilot 能编写并运行自动化可访问性测试，包括屏幕阅读器兼容性和键盘导航测试。参见 mcp-playwright。

步骤 1：研究循环——分析可访问性需求

提示 Copilot 分析项目中的可访问性需求以及已有的与可访问性相关的 GitHub 议题。

在提示中包含指向 Figma 文件的链接。为确保 Copilot 能成功读取并分析设计规范，请在 URL 中加入具体节点或图层的 ID（即选中该节点后复制的链接）。

示例提示 1

Copilot 提示
I need to make our customer portal WCAG 2.1 AA compliant. Use the Figma MCP to analyze our design specifications at https://figma.com/design/DESIGN-FILE-FOR-ACCESSIBILITY-SPECS?node-id=NODE_ID for accessibility requirements. Also use the GitHub MCP to find open GitHub issues with the labels accessibility or WCAG in the customer-portal repository. Then sort them into categories and list each issue that falls under the category with the issue title and number.

示例响应 1

Copilot 首先会请求使用 Figma 和 GitHub MCP 服务器的工具。获得授权后，Copilot 将分析 Figma 设计规范并检索、整理 GitHub 议题并进行分类。

例如，Copilot 可能会基于多条相关议题将“颜色对比”归为一类。

  • 颜色对比议题
    • 议题 #134：仪表盘文本对比度低于 4.5:1
    • 议题 #156：表单错误状态未满足对比度要求

这样您即可得到关于可访问性需求的完整概览，随后让 Copilot 按优先级排序并制定计划。

步骤 2：规划循环——制定可访问性实现策略

接下来，请求 Copilot 编写详细的实现计划。

示例提示 2

Copilot 提示
Based on your accessibility analysis of our Figma designs and GitHub issues, create a focused implementation plan for an immediate pull request addressing the highest priority accessibility issues. Don't make any changes yet. Also suggest follow-up issues we should create for the remaining Figma specifications.

示例响应 2

Copilot 将返回一个聚焦高影响力可访问性议题的优先级实现计划，并在同一 Pull Request 中给出立即可交付的改动，同时为剩余工作建议后续议题。

例如，Copilot 可能会列出解决颜色对比类议题的具体措施。

  • 1. 颜色对比修复
    • 将 variables.scss 中的文本颜色变量更新，以确保所有普通文本的对比度达到 4.5:1
    • 在 DashboardCard.vue 以及其他核心组件中修改 UI 颜色，使其在浅色背景上达到 3:1 对比度
    • 优先处理议题 #134（仪表盘文本对比）和议题 #156（表单错误状态）

您可以根据关注点让 Copilot 调整计划。最终得到一个您满意的计划，然后让 Copilot 着手实现。

步骤 3：实现循环——进行可访问性改进

审阅计划后，提示 Copilot 开始执行可访问性修复。

示例提示 3

Copilot 提示
Create a new branch and implement the critical accessibility fixes according to your proposed implementation plan. Focus on the top three categories that you identified as highest priority. Create a pull request with proper references to the issues being fixed.

示例响应 3

Copilot 将依据实现计划执行，有针对性地修改代码以解决已识别的可访问性问题，并创建 Pull Request。

例如，Copilot 可能会新建名为 fix/critical-accessibility-issues 的分支，并针对颜色对比问题进行更改。

  • 已修复仪表盘文本对比问题（议题 #134）
    • 在 src/styles/variables.scss 中将文本颜色从 #767676 更新为 #595959
    • 在 DashboardCard.vue 中修改深色文本在浅灰背景上的显示，以确保 4.5:1 对比度

已打开 Pull Request #213，包含上述更改。

步骤 4：测试循环——使用 Playwright 验证可访问性

提示 Copilot 使用 Playwright MCP 创建并运行可访问性测试。

示例提示 4

Copilot 提示
Create focused accessibility tests for the components we've updated in the pull request. Use the Playwright MCP.

示例响应 4

Copilot 将编写可访问性测试，并在必要时创建 Playwright 配置文件。

例如，Copilot 可能会生成针对文本对比度的测试文件。

测试实现

  • 在 tests/accessibility/ 目录下创建了针对性的测试文件
    • contrast.spec.ts – 校验文本对比度比例

创建完测试后，Copilot 会请求使用 Playwright MCP 的各种工具来运行这些测试。请注意，Copilot 有时会执行您未明确要求的额外测试；若想避免，可在提示中更严格地限定范围。

步骤 5：更新 GitHub 议题

最后，提示 Copilot 更新已在 Pull Request 中解决的 GitHub 议题，并创建后续议题。

示例提示 5

Copilot 提示
Update the GitHub issues we've fixed in the pull request with comments summarizing the changes. Create the follow-up issues you suggested for the remaining accessibility work.

示例响应 5

Copilot 将请求使用 GitHub MCP 服务器的相应工具，并在议题中添加详尽的评论，同时为剩余工作创建结构化的后续议题。

例如，Copilot 会在研究步骤中首次标识的颜色对比议题中添加评论。

已更新议题的评论

  • 议题 #134：“仪表盘文本对比度低于 4.5:1”
    • 评论：“已在 PR #213 中通过更新 variables.scss 中的文本颜色变量以及 DashboardCard 组件修复。所有仪表盘文本现已满足 4.5:1 对比度，且已通过自动化测试验证。”

现在您可以审阅该 Pull Request 并进行必要的调整。确认修改有效后，即可像处理其他 Pull Request 那样合并。

实战练习

在 Integrate MCP with GitHub Copilot 练习中实践将 MCP 与 GitHub Copilot 集成。

在此练习中，你将学习如何

  • 设置并将 GitHub MCP 服务器连接至 GitHub Copilot。
  • 在代理模式下使用自然语言通过 MCP 工具与外部服务交互。
  • 使用 MCP 搜索并分析相似项目。
  • 对 GitHub 议题进行分流、创建与管理，然后使用 GitHub Copilot 实施更改。

延伸阅读

© . This site is unofficial and not affiliated with GitHub, Inc.