GitHub Copilot Agent Plugins 1.0：跨客户端插件开放标准

2026 年 8 月 12 日，GitHub 宣布 Agent Plugins 1.0 在 VS Code、Copilot CLI、GitHub Copilot SDK 和 Copilot 应用中获得正式支持。更重要的一点是，Agent Plugins 1.0 不仅仅是一个 GitHub 专属的扩展格式。它是一个开放标准，由 AWS、Anysphere、Microsoft、OpenAI 和 Vercel 共同参与开发，Google 也作为核心维护者加入。其核心思路是将技能（skill）和 MCP 服务器配置打包为一个可安装单元，兼容的 Agent 客户端可以检查并消费这个单元。本文将解释技能（skills）、MCP、插件（plugins）、可移植性、治理之间的关系，以及为什么 Agent 能力包装可能成为 AI 开发者栈的重要一层。

1. 为什么 Agent 需要又一个插件标准？

开发者日益面临一个打包问题。

试想一个部署能力。它包含一项技能，描述了发布流程、回滚规则、生产环境检查和事故策略。同时它也包含一个 MCP 服务器，对外暴露部署状态、部署、回滚、日志查询等工具。

底层能力只存在一份，但历史上支持多个 Agent 客户端往往需要不同的清单文件、目录布局、安装步骤和厂商专属的封装层。

Agent Plugins 1.0 试图减少这种重复——构建一个兼容的 Agent 客户端能够理解的包。

一个包可以包含：

plugin.json
skills/
mcp.json
vendor-specific/

标准部分可以共享，厂商专属特性则保留命名空间隔离。

对于 Copilot，包中可以包含：

com.github.copilot/

供其他客户端忽略的特性使用。

这是一种务实的折中：在不消除厂商创新的前提下标准化可移植能力。

3. 技能、MCP 和插件是不同层次

技能告诉 Agent 一个任务应该如何执行。它可以编码工作流、领域规则、运维手册、模板、示例和最佳实践。

MCP 赋予 Agent 对工具和外部系统（如 GitHub、Jira、数据库、Kubernetes、CRM、浏览器）的受控访问。

插件是打包和分发单元。

一个有用的心智模型是：

Skill = 流程和知识
MCP = 工具访问
Plugin = 打包和分发

它们互补而非相互替代。

4. 为什么将技能和工具结合很重要

一个部署 MCP 服务器可能暴露：

deploy()
rollback()
get_status()

但仅有工具并不能教 Agent 何时允许部署、哪些检查是强制的、哪些环境需要审批、以及何时需要回滚。

技能可以编码这些规则。

skill → 定义安全流程
MCP → 提供受控操作
plugin → 将它们一起分发

这类似于一个完整的 Agent 能力。

5. 当前 GitHub Copilot 支持情况

GitHub 表示 Agent Plugins 1.0 已在以下平台正式可用：

因此一个兼容包可以在多个 Copilot 界面中复用。

6. 为什么企业比个人受益更多

一个企业可能有数百名开发者、数十个内部 Agent、大量工具、多个 IDE、若干 CLI，以及不止一个 Agent 平台。

如果每次集成都需要单独的安装、授权、升级和审计，治理成本将非常高昂。

标准化插件可以支持：

企业市场
→ 已批准插件
→ 开发者安装
→ 技能 + MCP
→ 受控版本
→ 受控权限
→ 受控更新

这是一项重大的运维收益。

7. Agent Plugin 可以成为一种软件分发单元

传统企业软件以应用、包、容器和扩展的形式分发。

Agent 时代可能新增一个单元：Agent 插件。

一个组织可以维护：

company-deploy
company-database
company-security
company-support
company-finance

每个包可以包含流程、工具、规则、Agent、命令和钩子。

安装它即赋予兼容 Agent 一个受治理的企业能力。

8. 为什么可移植性很重要

该标准旨在独立于单一厂商。

GitHub 表示该规范发布时有 AWS、Anysphere、Microsoft、OpenAI 和 Vercel 参与，Google 作为核心维护者加入。

这传递了一个更广泛的方向：Agent 扩展生态系统正从孤立的格式向共享打包方式演进。

9. 可移植不等于在各处完全一致

一个插件可以包含标准部分：

skills/
mcp.json

以及厂商专属部分，例如：

com.github.copilot/

其他客户端不会自动理解 Copilot 专属的 Agent、命令、规则、钩子或画布。

共同核心可以移植，而厂商专属能力保持差异。

10. 一个最小的概念包

一个简单的包可能长这样：

company-deploy/
├── plugin.json
├── skills/
│   └── deployment/
│       └── SKILL.md
└── mcp.json

一个部署技能可以定义部署前检查、审批、数据库迁移审查、健康验证、错误率审查和回滚条件。

MCP 服务器提供实际的部署操作。

其结果是一个可复用的企业能力。

11. 企业市场需要治理

一个有用的内部市场应该包含注册表、安全扫描、基于风险的审批和受控分发。

跟踪插件版本、发布者、所有者、来源、许可证、风险、MCP 服务器和权限。

只允许从不经过任意仓库安装，而是从已批准的市场安装。

12. GitHub 托管设置

GitHub 暴露了如下托管设置：

enabledPlugins
extraKnownMarketplaces
strictKnownMarketplaces

这些设置允许组织安装或阻止插件、添加已批准的市场，以及将安装限制为仅来自托管市场。

这很重要，因为插件可以包含 MCP 服务器配置，因此携带真实的系统访问能力。

13. MCP 白名单仍然重要

批准一个插件不应自动批准每个 MCP 服务器或每次运行时调用。

插件已批准
AND
MCP 服务器已批准
AND
用户具有所需角色
AND
运行时工具策略通过

只有满足以上条件，执行才会继续。

14. 插件供应链风险

一个插件可以组合指令、工具、钩子和命令。

恶意或被入侵的包可能导致数据泄露、恶意 shell 执行、凭据窃取、MCP 重定向、提示词注入、通过钩子持久化，或供应链危害。

因此 Agent 插件应该像软件依赖一样治理，而不是当作装饰性的编辑器主题。

15. 推荐的 安全流水线

开发插件
→ 代码审查
→ 静态扫描
→ 技能内容扫描
→ MCP 白名单检查
→ 权限审查
→ 签名
→ 内部市场
→ 分阶段安装
→ 运行时审计

跟踪插件 ID、版本、发布者、哈希、MCP 服务器、技能、权限、已安装用户和最后更新时间。

16. 适合内部插件的好候选

插件对于频繁、可重复、有工具支持的工作尤其有用。

例子包括 DevOps 部署和回滚、数据查询和报告、安全调查、问题分析、支持工单查询和工单创建。

即：频繁工作流 + 稳定流程 + 工具 + 多个 Agent 客户端。

不要把每个流程都打包。

弱候选包括稀有工作流、需要大量人工判断的任务、没有可靠 API 的不稳定系统，以及授权机制不成熟的环境。

在将底层系统暴露给 Agent 之前，先治理好该系统。

18. 可能的未来层次结构

一个常见的栈可能会出现：

Agent Client
↓
Plugin
├── Skills
├── MCP Servers
├── Rules
├── Commands
├── Hooks
└── Vendor Extensions

在那个栈中，MCP 是工具连接层，技能是流程层，插件是打包层，Agent 客户端是运行时层。

这开始类似于浏览器和扩展，或 IDE 和插件市场。

19. 为什么标准可能比又一个模型基准测试更重要

模型迭代很快。

企业资产更持久：工具、工作流、策略、权限、内部系统和领域知识。

如果这些资产可以在兼容的 Agent 客户端之间迁移，组织就能减少厂商锁定，并避免在面向用户的 Agent 发生变化时重建每个集成。

20. 现有 Copilot 插件需要立即迁移吗？

GitHub 表示不针对 Agent Plugins 1.0 的现有插件仍然受支持。

一个合理的策略是：

• 最初保持稳定的生产插件不变；
• 对新的可移植包使用 Agent Plugins 1.0；
• 在多个客户端需要相同能力时优先迁移；
• 在运维收益明确时迁移 Copilot 专属包。

21. 建议的企业仓库结构

agent-plugins/
├── deployment/
│   ├── plugin.json
│   ├── skills/
│   ├── mcp.json
│   └── com.github.copilot/
├── database/
├── security/
└── support/

添加 CODEOWNERS、CI、安全扫描、版本标签和发布说明。

不要让 Agent 插件沦为个人笔记本上的不受控配置。

核对清单

• 目标客户端是否加载了插件？
• 技能是否被正确发现？
• 厂商专属扩展是否隔离？
• MCP 服务器是否在白名单中？
• 包是否可以执行 shell 命令？
• 它是否可以访问密钥？
• 它是否可以访问生产环境？
• 高风险工具是否需要审批？
• 安装的是哪个版本？
• 工具错误是否可观察？
• MCP 不可用时会发生什么？
• 如何逐步推出新版本？

GitHub 对 Agent Plugins 1.0 的支持看似是一个扩展系统更新，但它指向一个更大的转变：

Agent 能力正在成为可移植的软件包。

栈的层次正在变得清晰：

Skill → 如何执行任务
MCP → 可以调用哪些工具
Plugin → 能力如何打包和分发
Agent Client → 在哪里运行

对于个人而言，这减少了配置重复。对于企业，更大的价值在于内部市场、一致版本、集中权限、安全扫描、跨 Agent 客户端复用，以及减少厂商锁定。

如果该标准继续获得跨厂商支持，组织可能只需打包一次企业能力，然后让它安全地提供给多个兼容的 Agent。

更多关于 Agent Plugins、MCP、技能和企业 AI 治理的分析，请访问 Zyentor Picks：https://www.zyentorpicks.com/。

最初发表于 Zyentor Picks。