GitHub Copilot Agent Plugins 1.0 管理清单：市场、MCP 技能、CLI 和企业策略怎么配

Agent Plugins 1.0 把 skills 和 MCP 服务器打包成可跨客户端安装的插件，从 8 月 12 日起在 VS Code、Copilot CLI 和应用中普遍可用。

Agent Plugins 1.0 把 skills 和 MCP 服务器打包成可跨客户端安装的插件，从 8 月 12 日起在 VS Code、Copilot CLI 和应用中普遍可用。

  1. 01先读摘要，判断是否与你的场景相关。
  2. 02再看来源，保留继续查证的路径。
  3. 03最后看步骤、风险和可复用动作。

Agent Plugins 1.0 是一个把 AI agent skills 和 MCP 服务器打包成可安装插件的开放标准。GitHub 在 2026-08-12 宣布该标准在 VS Code、Copilot CLI、GitHub Copilot SDK 和 GitHub Copilot app 中普遍可用，国内开发者可以从默认市场安装社区插件，也可以用 declarative 配置让团队统一启用。这份清单按个人试用、团队声明式安装和企业策略三个阶段整理，避免只会在交互界面点安装却无法审计版本和来源。

适用场景

  • 你希望让 Copilot CLI 访问项目数据库、云服务或团队内部工具，又不手动维护 MCP 配置。
  • 你在 VS Code、Copilot CLI 和 Copilot app 之间切换，想用同一个插件包保持一致能力。
  • 团队需要统一启用某个内部工具插件，同时又限制开发者安装未知市场。
  • 你维护 Copilot 插件，想把 skills 和 MCP 服务器放进一个可发布包。

不适用场景

  • 你只需要一次性的代码补全，不需要新增工具或技能。
  • 你的客户端版本还不支持 Agent Plugins 1.0，应该先升级或检查当前市场入口。
  • 你的工作流要求不在仓库中写任何插件配置，声明式安装不一定适合。
  • 你想用一个插件绕过 MCP 服务的权限审批，插件标准和客户端审批不会替你承担安全责任。

准备材料

  • GitHub Copilot 账号，以及可用的 VS Code、Copilot CLI 或 Copilot app。
  • GitHub Docs 的插件说明、CLI 插件安装文档和 Agent Plugins changelog。
  • 一个插件市场的仓库地址，例如 Awesome Copilot 或其他注册市场。
  • 团队场景需要仓库访问权或 managed-settings.json 管理权限。
  • 记录插件名称、来源市场、版本和用途的审计表。

步骤一：先确认客户端版本和市场入口

Agent Plugins 1.0 的可用范围从 VS Code、Copilot CLI 和 Copilot app 开始。安装前先确认客户端的插件市场入口存在，避免按旧版本的路径反复查找。

  1. 打开 VS Code 的 Copilot 设置或 Customize 区域，查看 Plugins 列表。
  2. 在 Copilot CLI 终端输入 `copilot plugin list`，确认命令可用。
  3. 确认默认市场是否包含 `awesome-copilot`。
  4. 如果入口缺失，先更新 Copilot 客户端，再重新检查。

步骤二：从市场安装插件

官方 CLI 文档说明，可以从已注册市场安装插件，命令格式是 `copilot plugin install PLUGIN-NAME@MARKETPLACE-NAME`。交互会话里也可以使用 `/plugin install`。默认市场中加入的插件不一定都来自官方，安装前先看名称、仓库和描述。

copilot plugin install database-data-management@awesome-copilot
  • 安装前记录插件名称、市场和版本。
  • 查看 README 和插件清单，确认它包含哪些 skills 或 MCP 服务器。
  • 优先选择可审计源码的插件，不只看下载量。
  • 安装后立即测试一次最小调用，确认工具路径和参数符合预期。

步骤三：注册额外市场

团队内部插件通常不会在公共市场里。可以用 `copilot plugin marketplace add OWNER/REPO` 注册自己的市场。注册后市场名称会来自 marketplace.json，而不是你随意指定。

  1. 创建或查看团队市场仓库中的 marketplace.json。
  2. 运行 `copilot plugin marketplace add OWNER/REPO`。
  3. 运行 `copilot plugin marketplace browse NAME` 查看可用插件。
  4. 记录市场 URL 和版本，方便更新。

理解插件包里的组件和 manifest

Agent Plugins 1.0 将组件限定为 skills 和 MCP servers 两类。插件根目录的 `plugin.json` 是客户端读取的入口，客户端需要识别标准声明的 `$schema`，不支持版本时应拒绝插件而不是沉默忽略。审查插件时不要只看 `SKILL.md`，还要看它声明的 MCP 服务器、工具名称、凭证来源和网络访问范围。

  • 打开插件根目录的 `plugin.json`，确认 `$schema`、name、version 和 author 等字段完整。
  • 看 `extensions` 中声明了哪些 skills 和 MCP 服务器。
  • 对 MCP 服务器，确认是否包含网络服务地址、项目路径或长期 token。
  • 不要接受把 secret 写进插件包的分发方式，凭证应通过客户端安全机制注入。
  • 对团队内部插件，要求发布者提交测试说明和变更记录。

步骤四：用声明式配置让团队统一安装

如果团队需要在 Copilot CLI 或云 agent 中默认启用插件，可以在用户级 `~/.copilot/settings.json` 或仓库级 `.github/copilot/settings.json` 中使用 `enabledPlugins` 声明。`extraKnownMarketplaces` 用来添加允许的市场，`strictKnownMarketplaces` 可以限制只能使用受管市场。

{
  "enabledPlugins": [
    "team-internal-docs@acme-marketplace"
  ],
  "extraKnownMarketplaces": [
    "acme/copilot-marketplace"
  ],
  "strictKnownMarketplaces": true
}
  • 先在小范围仓库测试，再推广到整个组织。
  • 声明式配置不会替用户读取所有市场，插件市场仍要单独注册。
  • 严格模式先把已知团队市场加入名单，再开启，否则开发者可能全部被阻断。
  • 对插件版本变化保留变更记录，不要把隐私工具混在通用列表里。

严格市场模式的价值是缩小安装来源，但它不是权限审批。即使在 `strictKnownMarketplaces` 下安装插件，插件声明的 MCP 工具仍可能读取文件或访问网络。团队要额外配置工具权限、环境变量和会话审批，不能因为来自受管市场就自动放行所有能力。

步骤五：管理版本、禁用和卸载

Copilot CLI 提供 `copilot plugin list`、`copilot plugin update NAME –all`、`copilot plugin disable NAME` 和 `copilot plugin uninstall NAME` 等命令。版本管理不是只在安装后确认一次，插件更新可能改变 MCP 工具参数或技能名称。

  1. 定期运行 `copilot plugin list`，核对安装版本。
  2. 更新前查看插件 changelog，确认没有破坏性变更。
  3. 如发现问题，先 disable 而不是立刻 uninstall，方便保留配置信息。
  4. 卸载后检查 settings.json 是否还残留过时条目。

企业 managed settings 与回滚

GitHub Changelog 提到，企业可以用 `managed-settings.json` 中的 `enabledPlugins` 自动安装或阻止插件，用 `extraKnownMarketplaces` 添加市场，用 `strictKnownMarketplaces` 限制来源。发放前先在试点团队跑一轮，避免一个错误的插件列表把所有人的 Copilot 都阻断。回滚时把旧配置重新发布，而不是逐个用户手动卸载。

  • 建立基线配置 JSON，并把插件版本的哈希或来源记录在评审文档里。
  • 试点团队测试后再分阶段推广。
  • 每个配置更改保存前后版本，回滚可以直接恢复上一份。
  • 为插件故障准备备用路径，例如临时禁用插件而不是删除整个配置。
  • 如果市场源不可达，检查网络策略和 gh auth，而不是反复改 strict 列表。

检查清单

  • 客户端已支持 Agent Plugins 1.0。
  • 插件来源、市场、版本和用途已记录。
  • 安装后最小调用能拿到预期结果。
  • 团队市场已注册，且 `enabledPlugins` 语法正确。
  • 严格市场模式开启前已加入所有合法市场。
  • 插件更新有变更记录和回归测试。
  • 未使用的插件已禁用或卸载。
  • 插件 manifest 中的组件和 MCP 工具权限已审查。
  • 企业配置有基线、试点、分阶段和回滚版本。

实际例子

一个后端团队在 Copilot CLI 中接入内部数据库元数据服务。插件包在 acme/copilot-marketplace 仓库里，marketplace.json 名称是 acme-marketplace。负责人先在自己的电脑上运行 `copilot plugin marketplace add acme/copilot-marketplace`，再用 `copilot plugin install db-metadata@acme-marketplace` 验证工具能返回表结构。测试通过后，团队在仓库级 settings.json 中加入 `enabledPlugins`、`extraKnownMarketplaces` 和 `strictKnownMarketplaces: true`。一周后新版本更新了工具参数，团队先在一个临时目录升级测试，确认兼容后再统一更新。

一个企业团队上线内部文档技能时，先读取 plugin.json，确认它除了 SKILL.md 还声明了一个指向内网服务的 MCP 服务器。安全负责人看到工具参数允许任意 URL，要求插件发布者把网络访问限制到指定内网域名，并在客户端关闭无关权限。团队随后在 two 个试点仓库启用插件，验证三天后才进入 managed settings 分阶段推送。推送后第二天有成员报告市场更新失败，管理员直接回滚到上一版 JSON，再检查网络白名单。

常见坑

  • 安装公共市场插件前不看仓库来源，导致工具权限范围不明。
  • 只使用交互式 `/plugin install`，没有把团队需要的插件写进声明式配置。
  • 开启 `strictKnownMarketplaces` 前忘记加入内部市场，结果全团队无法安装。
  • 更新插件后不重新测试 MCP 调用，线上任务突然失败。
  • 把多个插件放进同一个市场，却没有统一的版本和权限文档。
  • 只看 `strictKnownMarketplaces`，忽略插件自身声明的文件或网络能力。
  • 把市场更新失败当作插件损坏，在没检查网络和 manifest 前反复卸载重装。
  • 企业配置没有版本管理，回滚时只能靠记忆恢复。

排错路径

  • 如果 `copilot plugin install` 找不到插件，先确认市场和名称拼写，再 `marketplace browse`。
  • 如果声明式配置不生效，检查文件路径是否正确，以及 JSON 中是否缺少 `enabledPlugins`。
  • 如果市场注册被拒绝，确认仓库是公开可访问或已配置 auth。
  • 如果插件中的 MCP 工具不可用，检查客户端是否允许该工具权限，并查看插件错误日志。
  • 如果企业 strict 模式阻断正常插件，先在 managed settings 中加入受管市场，再重试。
  • 如果插件被拒绝并报告 unsupported version，检查客户端版本和 `plugin.json` 的 `$schema`。
  • 如果 MCP 服务器无法连接，检查网络白名单、授权方式和服务器日志，而不是换插件重试。

可复制模板：Agent Plugins 审计表

  • 插件名称：。
  • 市场：。
  • 来源仓库：。
  • 版本：。
  • 包含组件：skills / MCP servers。
  • 工具权限：。
  • 安装方式：交互式 / 声明式 / managed settings。
  • 测试场景：。
  • 更新策略：。
  • 安全审查结果：。
  • 试点范围：。
  • 配置版本：。
  • 更新日期：2026-08-23。

更新日期与维护建议

本文基于 GitHub 官方 changelog 和 GitHub Docs 整理，更新日期为 2026-08-23。Agent Plugins 标准仍在快速演进，插件市场、规格路径和客户端支持范围都可能变化。每次升级 VS Code 或 Copilot CLI 后，至少检查一次插件列表和默认市场，并在团队文档里更新来源与版本。

公开来源

继续阅读

从这篇文章继续追踪

按主题、标签和相邻文章继续走，不必回到首页重新找入口。

继续看「AI 开发」 查看资源清单

订阅更新

输入邮箱，订阅站点更新。

参与讨论

你的邮箱不会公开。 标有 * 的为必填项。