如何使用 GitHub Copilot CLI 以及 MCP 服务器来构建一个高效、自动化的终端工作流程

大多数开发者都是通过终端来开展工作的。他们通过shell提示符来运行命令、调试代码流程、管理基础设施以及浏览代码库。

然而，尽管终端在开发者的工作流程中占据着核心地位，但AI在这方面的辅助功能仍然较为有限：要么只是自动完成某些命令的输入，要么仅仅解释出现的错误。

但是，当将GitHub Copilot CLI与MCP（模型上下文协议）服务器结合使用时，情况就会发生改变。此时，你得到的不再是一个只会对孤立指令做出反应的AI系统，而是一个能够理解你的项目背景、查询实时数据源，并能自主执行一系列工具操作的终端——业界开始将这种工作方式称为“智能型工作流程”。

在本教程中，你会逐步了解如何将这两个系统连接在一起。完成学习后，你的终端将能够理解你的Git历史记录，然后在建议修复方案之前先进行相关查询；在编写Docker配置文件之前，它会先检查当前正在运行的容器状态；在生成请求之前，它还会获取实时的API接口信息。

目录

• 先决条件

• 什么是GitHub Copilot CLI？

• 什么是模型上下文协议？

• MCP服务器在终端环境中的工作原理

• 步骤1——安装并配置GitHub Copilot CLI

• 步骤2——设置你的第一个MCP服务器

• 步骤3——将Copilot CLI与MCP服务器连接起来

• 步骤4——构建真正的智能型工作流程

• 步骤5——使用多个MCP服务器进行扩展

• 调试常见问题

• 总结

先决条件

在开始之前，请确保你具备以下条件：

• Node.js v18或更高版本（运行`node –version`可查看版本）

• npm v9或更高版本

• 拥有已启用Copilot功能的GitHub账户。对于所有GitHub用户来说，免费账户就足以完成本教程的学习。Pro、Business和Enterprise套餐虽然能提供更高的使用权限，但并不是必需的。

• 已安装GitHub CLI（运行`gh`可查看是否已安装）。我们将使用它来进行身份验证。

• 需要对终端以及JSON配置文件有基本的了解

• （可选）如果你想按照步骤5中的示例来操作Docker，那么需要先安装Docker

您不需要具备关于MCP或智能代理AI系统的先验经验，因为本指南会从基础开始帮助您掌握这些知识。

什么是GitHub Copilot CLI？

GitHub Copilot CLI是专为Shell工作流程设计的终端原生接口，用于连接GitHub的Copilot AI服务。与那些辅助代码补全的IDE插件不同，Copilot CLI专门针对Shell环境而设计，提供了以下三个主要命令：

• gh copilot suggest：根据自然语言描述生成相应的Shell命令

• gh copilot explain：解释特定命令的功能

• gh copilot alias：为Copilot的子命令创建Shell别名

下面是一个suggest命令的实际使用示例：

gh copilot suggest "查找过去24小时内被修改且大小超过1MB的所有文件"

Copilot会返回如下命令：

find . -mtime -1 -size +1M

系统还会询问您是想要复制该命令、直接执行它，还是修改请求内容。这种交互式机制已经非常实用了——但仅靠Copilot CLI本身，它并不了解您的项目环境：它不知道您的仓库结构、正在运行的服务，也不知道您的部署环境。这时，MCP就派上了用场。

什么是模型上下文协议？

模型上下文协议（MCP）是Anthropic在2024年底推出的一项开放标准。它的目标非常明确：为AI模型提供一种标准化的方式，以便它们能够与外部工具、数据源和服务进行交互。

可以把MCP看作是AI模型与现实世界之间的通用适配层。如果没有MCP，每次AI系统的集成都需要单独开发：一个插件用于GitHub，另一个用于Postgres，还有一个用于Slack，而这些插件的接口往往不兼容。MCP定义了一种统一的协议，任何工具都可以实现这种协议，而任何兼容的AI客户端也可以使用它。

MCP服务器会提供工具（AI可以调用的功能）、资源（AI可以读取的数据）以及提示模板。在我们的例子中，由Copilot支持的终端会在运行时发现这些功能，并自主使用它们来完成任务。

目前已经有几款成熟的MCP服务器可供实际使用：

MCP服务器	提供的功能
@modelcontextprotocol/server-filesystem	对本地文件的读写操作
@modelcontextprotocol/server-git	Git日志、差异对比、代码归属分析以及分支操作功能
@modelcontextprotocol/server-github	通过API访问GitHub的Issues、PRs和仓库信息
@modelcontextprotocol/server-postgres	在Postgres数据库上执行实时查询操作
@modelcontextprotocol/server-docker	容器检查、日志查看及统计分析功能

完整的注册信息托管在github.com/modelcontextprotocol/servers地址上。

MCP服务器在终端环境中的工作原理

在开始实际操作之前，了解其通信机制是很有必要的。

MCP服务器以本地进程的形式运行。它们通过标准输入/输出或HTTP/SSE传输协议与AI客户端进行通信。客户端会向服务器发送JSON-RPC格式的消息，而服务器则会返回结构化的数据作为响应。

以下是简化的工作流程：

这里的关键概念是基于实际代码数据的处理。如果没有MCP，Copilot只会根据自身的训练数据以及用户的指令来做出响应；而有了MCP之后，它就可以在执行命令之前先调用git log --oneline -20这样的命令，从而让其回答关于最近代码变更的问题时能够基于用户真实的代码历史记录，而不是基于一些泛化的假设。

步骤1 – 安装并配置GitHub Copilot CLI

如果还没有安装的话，请先安装GitHub CLI：

# 在macOS系统中
brew install gh

# 在Ubuntu/Debian系统中
sudo apt install gh

# 在Windows系统中（使用winget）
winget install --id GitHub.cli

接下来进行身份验证：

gh auth login

按照提示操作，选择GitHub.com，然后选择HTTPS，并按照浏览器提示完成身份验证。

现在安装Copilot CLI扩展程序：

gh extension install github/gh-copilot

检查安装是否成功：

gh copilot --version

你应该会看到类似gh-copilot version 1.x.x这样的输出结果。

推荐但非强制：设置Shell别名。这样可以让使用流程更加便捷。对于bash或zsh来说，可以执行以下命令：

# 将别名添加到~/.bashrc或~/.zshrc文件中
eval "$(gh copilot alias -- bash)"   # 用于bash
eval "$(gh copilot alias -- zsh)"    # 用于zsh

重新加载Shell环境后（执行source ~/.bashrc），你就可以使用ghcs代替gh copilot suggest，用ghce代替gh copilot explain了。

步骤2 – 设置你的第一个MCP服务器

我们先从server-git开始。对于开发工作流程来说，它是最实用的工具，而且完全不需要任何外部依赖。

通过npm全局安装它：

npm install -g @modelcontextprotocol/server-git

测试一下它是否能够正常运行：

mcp-server-git --version

这个服务器为任何兼容的MCP客户端提供了以下工具：

• git_log：可利用过滤器检索提交历史记录

• git_diff：用于比较分支或提交之间的差异

• git_status：显示当前工作区的状态

• git_show：详细查看某个特定的提交内容

• git_blame：在文件各行中标注对应的提交信息

• git_branch：列出或切换分支

现在创建一个配置文件。MCP客户端会查找名为mcp.json的文件来获取可用的服务器信息。你可以将这个文件放在项目根目录中，或者放在全局配置目录里：

mkdir -p ~/.config/mcp
touch ~/.config/mcp/mcp.json

在文件中添加以下内容：

{
  "mcpServers": {
    "git": {
      "command": "mcp-server-git",
      "args": ["--repository", "."],
      "transport": "stdio"
    }
  }
}

关于这个配置文件，有几点需要注意：

• command参数指定了要运行的二进制文件。请确保该文件位于你的$PATH环境变量中。

• args参数中包含了--repository .，这样服务器就会将当前工作目录作为处理范围。

• transport: "stdio"表示通信是通过标准输入/输出进行的。对于本地服务器来说，这是最简单且最稳定的连接方式。

步骤3 – 将Copilot CLI连接到你的MCP服务器

这就是两个系统相互连接的环节。GitHub Copilot CLI通过--mcp-config参数支持MCP功能（从1.3版本开始支持）。你只需要将这个参数指向你的mcp.json文件，Copilot就会在处理你的请求之前自动初始化配置好的服务器。

基本的使用方法如下：

gh copilot suggest --mcp-config ~/.config/mcp/mcp.json "为什么在上一次提交后构建会失败？"

当你在Git仓库中运行这个命令时，Copilot CLI会依次执行以下操作：

1. 启动mcp-server-git进程

2. 调用git_log获取最近的提交记录

3. 对最新的提交记录使用git_diff进行对比分析

4. 根据分析结果生成相应的建议或解释

你可以在一个最近有失败提交的仓库上亲自试试。与直接使用gh copilot suggest相比，Copilot提供的帮助质量会有明显的提升。

提示：避免每次都重新输入这个参数。你可以在.bashrc/.zshrc文件中添加一个shell函数来简化这一过程。

function aterm() {
  gh copilot suggest --mcp-config ~/.config/mcp/mcp.json "$@"
}

现在你只需输入以下命令：

aterm "main分支和feature/auth分支之间发生了哪些变化？"

通过这个简短的命令，你就可以执行一个完全基于上下文、由MCP支持的查询操作。这个函数的名字aterm，代表“智能终端”，在接下来的教程中我们将会一直使用这个名称。

步骤4 – 构建真正的智能工作流程

让我们不再仅仅执行单个查询操作，而是构建一个能够串联多个工具命令、从而完成特定开发任务的工作流程：具体来说，就是诊断代码回归问题。

假设你推送了一个功能分支，但你的持续集成管道失败了，而你并不知道究竟是哪个变更导致了这个问题。那么，智能终端会如何处理这种情况呢？

查询1：了解具体发生了哪些变化

aterm "列出所有在feature/auth分支中存在、但在main分支中还不存在的提交记录"

Copilot会使用分支过滤条件调用git_log命令，然后返回一个包含你所在分支中所有独特提交记录的结构化摘要。这样你就无需手动复制SHA值了。

查询2：找出具体差异内容

aterm "显示main分支和feature/auth分支之间，在auth中间件中发生的所有变化"

这个命令会触发针对包含该中间件的代码路径的git_diff操作，Copilot会返回差异内容，并解释每一处变更的具体作用。

查询3：确定可能的问题根源

aterm "哪些变更可能会导致JWT验证失败？"

此时，Copilot已经掌握了之前那些操作所产生的差异信息。它会根据这些具体的代码变化来进行分析，而不是依靠关于JWT的通用知识来推测问题所在。

查询4：生成修复方案

aterm "编写那个验证函数的修正版本"

Copilot会根据通过MCP获取到的具体代码信息，生成针对性的修复方案。你得到的会是一个可以直接应用的补丁文件，而不是一个通用的代码模板。

这个由四个步骤组成的流程——了解问题、找出差异、分析原因、生成修复方案——构成了一个完整的智能工作流程循环。每一个步骤都是基于通过MCP工具获取到的实时仓库数据来进行的。人工智能并不是在凭空构建上下文信息，而是真正地在读取你的代码库。

步骤5：扩展使用多台MCP服务器

虽然一台MCP服务器已经非常有用，但当多台MCP服务器协同工作时，工作流程的效果就会真正得到提升。让我们再添加两台服务器：server-filesystem和server-docker。

请安装这些额外的服务器：

npm install -g @modelcontextprotocol/server-filesystem  
npm install -g @modelcontextprotocol/server-docker

请更新您的 `mcp.json` 文件：

{
  "mcpServers": {
    "git": {
      "command": "mcp-server-git",
      "args": ["--repository", "."],
      "transport": "stdio"
    },
    "filesystem": {
      "command": "mcp-server-filesystem",
      "args": ["--root", "."],
      "transport": "stdio"
    },
    "docker": {
      "command": "mcp-server-docker",
      "transport": "stdio"
    }
  }
}

当这三台服务器都处于活跃状态时，您的终端就可以用来解决跨域相关的问题了：

aterm "我的 Express 应用容器不断重启，请查看日志，并将其与 Dockerfile 中定义的健康检查逻辑进行对比"

为了回答这个问题，Copilot 会执行以下操作：

1. 调用 `docker_logs`（服务器-docker模块）来获取容器的最近输出日志

2. 调用 `read_file`（服务器-filesystem模块）来读取您的 `Dockerfile` 文件

3. 解析 `HEALTHCHECK` 指令的内容

4. 将日志中的错误信息与健康检查端点的路径进行关联分析

5. 最终生成一份诊断报告，说明存在的问题并提出相应的解决方法

这就是所谓的 智能工作流程：模型会自主决定需要调用哪些工具、以何种顺序执行这些操作，并将最终结果整合成一条连贯的答案。您并没有明确要求它去读取 Dockerfile，但它是根据您提出的问题推断出这一操作是必要的。

关于安全性的注意事项： 在运行 `server-filesystem` 时，请务必使用 `--root` 参数将其作用范围限定在特定的目录内；切勿让它指向 `/` 目录或您的个人主目录。同样地，`server-docker` 模块也只有在使用于受信任的环境中时才能访问 Docker 套接字。

常见问题的排查与解决

mcp-server-git: 命令未找到

如果 npm 的全局二进制目录没有被添加到您的 `$PATH` 环境变量中，请进行相应的设置：

export PATH="\(PATH:\)(npm bin -g)"
# 或者对于较新版本的 npm：
export PATH="\(PATH:\)(npm prefix -g)/bin"

将这条命令添加到您的 `.bashrc` 或 `.zshrc 文件中，以便让设置长期生效。

Copilot CLI 似乎没有使用 MCP 工具

请检查您的 Copilot CLI 版本：

gh copilot --version

要使用 MCP 功能，必须确保 Copilot 的版本在 1.3 或以上。可以使用以下命令进行升级：

gh extension upgrade copilot

同时，请确认您的 `mcp.json` 文件格式是否正确——文件末尾如果有多余的逗号或缺少括号，都会导致服务器无法正常启动。

MCP 服务器已启动但未返回任何数据

您可以手动运行服务器来检查是否存在错误：

mcp-server-git --repository .

如果服务器立即退出，请确认您是在有效的 Git 仓库中执行该命令的。对于 `server-docker` 模块，需要确保 Docker 守护进程正在运行，并且您的用户具有访问 Docker 套接字的权限。

sudo usermod -aG docker $USER
# 然后退出系统再重新登录

# 项目A（后端） aterm --mcp-config ./mcp-backend.json "..." # 项目B（基础设施） aterm --mcp-config ./mcp-infra.json "..."

Related Posts:

• 面向开发者的AI工具：OpenClaw、GitHub Copilot、Claude…
• GitHub-Copilot-SDK使开发人员能够将Copilot CLI引擎集成到各类应用程序中
• 如何使用 GitHub Actions 构建一套可用于生产环境的 Flutter CI/CD…
• 如何使用 GitHub Actions、持续集成与持续部署功能，在 Cloudflare Workers…
• 当我用“Claude Code”替代了“Copilot”，持续使用了两周之后，发生了什么……
• 谷歌在Gemini CLI Conductor中推出了自动化审核功能