评测
GitHub Copilot Agent Plugins 1.0：一次开发，多端复用，Agent 插件标准要统一了吗？
GitHub 在 2026 年 8 月 12 日宣布，Agent Plugins 1.0 已在 VS Code、Copilot CLI、GitHub Copilot SDK 和 Copilot App 中正式可用。更值得注意的是，这并不是 GitHub 单独设计的一套私有插件格式：Agent Plugins 1.0 是一个开放标准，由 AWS、Anysphere、Microsoft、OpenAI、Vercel 等共同参与，Google 也加入核心维护。它的核心思路是把 Skills 和 MCP Server 打包进一个可安装插件，使兼容的 Agent Client 可以从同一个包中发现自己支持的能力。本文分析它与 Skills、MCP、传统插件的关系，以及为什么“Agent 能力的可移植打包”可能成为下一阶段开发工具竞争的关键。
# GitHub Copilot Agent Plugins 1.0：一次开发，多端复用，Agent 插件标准要统一了吗？
## 文章摘要
GitHub 在 2026 年 8 月 12 日宣布，Agent Plugins 1.0 已在 VS Code、Copilot CLI、GitHub Copilot SDK 和 Copilot App 中正式可用。更值得注意的是，这并不是 GitHub 单独设计的一套私有插件格式：Agent Plugins 1.0 是一个开放标准，由 AWS、Anysphere、Microsoft、OpenAI、Vercel 等共同参与，Google 也加入核心维护。它的核心思路是把 Skills 和 MCP Server 打包进一个可安装插件，使兼容的 Agent Client 可以从同一个包中发现自己支持的能力。本文分析它与 Skills、MCP、传统插件的关系，以及为什么“Agent 能力的可移植打包”可能成为下一阶段开发工具竞争的关键。
---
## 一、为什么 Agent 又需要一套 Plugin 标准？
过去两年 AI Agent 快速发展以后，开发者遇到了一个非常现实的问题：
> 同一个能力，要给不同 Agent 重复打包。
例如，一个企业 DevOps Agent 需要：
### Skill
告诉 Agent：
```text
公司发布流程
回滚步骤
生产变更规则
故障处理要求
```
### MCP Server
提供工具：
```text
get_deployment_status
deploy_service
rollback_service
query_logs
```
底层能力其实只有一份。
但如果要同时支持 VS Code Agent、Copilot CLI、Cursor、Codex 或其他 Agent Client，过去往往需要不同 manifest、不同目录、不同安装方式和不同规则文件。
Agent Plugins 1.0 想解决的就是这种重复打包问题。
## 二、Agent Plugins 1.0 的核心是什么？
一句话：
> **Build once, install across compatible agent clients.**
一个插件可以同时包含：
```text
plugin.json
skills/
mcp.json
vendor-specific/
```
兼容 Client 根据自己支持的能力读取对应内容。
例如：
```text
deployment-plugin/
├── plugin.json
├── skills/
│ └── production-deploy/
│ └── SKILL.md
├── mcp.json
└── com.github.copilot/
├── agents/
├── commands/
├── rules/
└── hooks/
```
通用部分 Skills 和 MCP 可以共享，Copilot 专属能力则放在 `com.github.copilot/` 中。
这就是：
> **标准化公共能力 + 保留厂商扩展。**
## 三、Skill、MCP 和 Plugin 到底是什么关系？
### Skill
Skill 更接近：
> Agent 应该怎么做。
它可以包含：
- 操作方法；
- 工作流程；
- 领域规则；
- 最佳实践；
- 模板；
- 示例。
例如“如何发布 Java 微服务到生产环境”。
### MCP Server
MCP 更接近：
> Agent 可以调用什么。
例如：
```text
GitHub
Jira
Database
Kubernetes
CRM
Browser
```
MCP 提供实际工具接口。
### Plugin
Plugin 更接近：
> **怎么把 Skill 和工具打成一个可以安装、分发和治理的产品包。**
可以简单理解为：
```text
Skill = Knowledge / Procedure
MCP = Tool Access
Plugin = Packaging / Distribution
```
三者不是竞争关系，而是三个不同层次。
## 四、为什么把 Skill 和 MCP 放在一起很重要？
如果只有 MCP：
```text
deploy()
rollback()
get_status()
```
模型知道“能调用什么”，但不一定知道什么时候应该部署、部署前必须检查什么、哪些环境需要审批、何时必须回滚。
如果只有 Skill，Agent 知道流程，但没有真正执行工具。
组合起来：
```text
Skill
→ 告诉 Agent 正确流程
MCP
→ 提供受控工具
Plugin
→ 把两者一起安装和分发
```
这更接近一个完整的 Agent 能力模块。
## 五、Agent Plugins 1.0 当前支持哪些 GitHub Copilot 客户端？
GitHub 已宣布一般可用于：
- VS Code；
- Copilot CLI；
- GitHub Copilot SDK；
- GitHub Copilot App。
并适用于所有 Copilot Plans。
这意味着一个符合规范的 Plugin 可以在多个 Copilot 入口间复用。
## 六、为什么这件事对企业比个人更重要？
个人开发者安装几个 MCP Server，重复配置还能忍受。
企业场景不同。
一家企业可能有：
```text
200 个开发者
30 个内部 Agent
50 个工具
10 个业务系统
多个 IDE
多个 CLI
多个 Agent 平台
```
如果每个工具都要分别安装、授权、升级和审计，治理成本会迅速失控。
Plugin 标准化后，可以形成：
```text
企业插件市场
↓
审批后的 Plugin
↓
开发者安装
↓
自动获得 Skill + MCP
↓
统一版本
↓
统一权限
↓
统一升级
```
这才是它真正的企业价值。
## 七、Agent Plugin 可能成为新的“内部软件分发单位”
传统企业软件分发单位是：
```text
Application
Package
Container
Extension
```
Agent 时代可能增加：
> **Agent Plugin**
例如公司可以维护：
```text
company-deploy
company-database
company-security
company-customer-support
company-finance
company-data-analysis
```
每个 Plugin 包含流程、工具、规则、Agent、命令和 Hook。
员工安装后，就获得一个符合公司标准的 AI 能力。
## 八、GitHub 为什么强调“Portable”？
如果 Plugin 只支持 Copilot，它的价值有限。
Agent Plugins 1.0 的真正方向是：
> **独立于单一厂商。**
GitHub 表示标准发布时有 AWS、Anysphere、Microsoft、OpenAI 和 Vercel 参与，Google 也加入核心维护。
这释放了明显信号：
> Agent 扩展生态正在尝试从“每家一套格式”向“共享打包标准”演进。
## 九、开放标准不等于所有 Agent 已经完全兼容
一个 Plugin 可能包含：
### 标准部分
```text
skills/
mcp.json
```
### 厂商扩展
例如：
```text
com.github.copilot/
```
其中可能包含 Custom Agents、Commands、Rules、Hooks 和 Canvas 扩展。
其他 Client 不会自动理解 Copilot 专属内容。
正确理解是：
> 通用核心可移植，厂商差异仍然存在。
## 十、一个最小 Agent Plugin 长什么样？
简单示意：
```json
{
"$schema": "https://example.com/agent-plugin.schema.json",
"name": "company-deploy",
"version": "1.0.0",
"description": "Company deployment tools and runbooks"
}
```
目录：
```text
company-deploy/
├── plugin.json
├── skills/
│ └── deployment/
│ └── SKILL.md
└── mcp.json
```
Skill 可以定义：
```text
发布前：
1. 检查 CI
2. 检查变更窗口
3. 检查审批
4. 检查数据库迁移
发布后：
1. 验证健康检查
2. 检查错误率
3. 检查延迟
4. 必要时回滚
```
这已经是一个完整的 Agent Deployment Capability。
## 十一、企业插件市场会怎么设计？
建议分成四层。
### 1. Registry
保存 Plugin、Version、Owner、Source、Risk 和 License。
### 2. Security Scan
检查 Manifest、Skill、MCP、外部 URL、Shell、Hook、依赖和恶意内容。
### 3. Approval
根据风险分成：
```text
Read-only
Write
Production
Financial
Admin
```
不同级别使用不同审批。
### 4. Distribution
只允许从企业批准 Marketplace 安装，而不是开发者随意从任意仓库拉取。
## 十二、GitHub 已经加入了哪些治理能力？
GitHub 当前提供 Managed Settings，例如：
```text
enabledPlugins
extraKnownMarketplaces
strictKnownMarketplaces
```
`enabledPlugins` 可以自动安装或阻止某些插件。
`extraKnownMarketplaces` 可以增加企业允许的 Marketplace。
`strictKnownMarketplaces` 可以限制只能使用批准的 Marketplace。
这非常重要，因为 Plugin 可以携带 MCP Server，它不是简单 UI 插件，而可能拥有真实系统访问能力。
## 十三、为什么还需要 MCP Allowlist？
假设 Plugin 中声明一个 MCP Server，企业还需要验证 URL、Command、Server Name、Owner、Scope 和证书。
因此推荐：
```text
Plugin approved
AND
MCP Server approved
AND
User has required role
AND
Tool call passes runtime policy
```
才执行。
不能因为 Plugin 已批准，就默认所有工具调用都批准。
## 十四、Plugin 会不会让 Agent 安全风险更大？
会。
一个 Plugin 可能同时拥有：
```text
Instructions
+
Tools
+
Hooks
+
Commands
```
恶意 Plugin 可能带来：
- Prompt Injection；
- 数据外泄；
- 恶意 Shell；
- 凭证窃取；
- MCP Server 劫持；
- Hook 持久化；
- 供应链攻击。
因此企业 Agent Plugin 必须像软件供应链一样管理。
## 十五、推荐的安全流程
```text
开发 Plugin
↓
代码审查
↓
静态扫描
↓
Skill 内容扫描
↓
MCP URL Allowlist
↓
权限评估
↓
签名
↓
内部 Marketplace
↓
灰度安装
↓
运行时审计
```
每个 Plugin 至少记录：
```text
plugin_id
version
publisher
hash
mcp_servers
skills
permissions
install_user
last_update
```
## 十六、企业应该自己做 Plugin 吗？
如果存在以下重复任务，非常适合。
### DevOps
部署、回滚、日志和健康检查。
### 数据团队
查询数据、生成报表和质量检查。
### 安全
扫描代码、查 CVE 和调查告警。
### 产品
读取 Issue、分析用户反馈和生成需求。
### 客服
查订单、查政策和创建工单。
当一个能力满足：
> 高频 + 有固定流程 + 有工具 + 多个 Agent 都要用
就适合封装成 Plugin。
## 十七、哪些东西不应该直接做成 Plugin？
### 极低频流程
维护成本可能高于收益。
### 高度人工判断流程
例如重大财务审批。Plugin 可以辅助，但不应全自动。
### 没有稳定 API 的系统
如果工具不可靠，Plugin 只会放大不稳定。
### 权限模型不成熟的系统
先治理权限，再接 Agent。
## 十八、Plugin、MCP、Skills 未来会如何分工？
很可能形成：
```text
Agent Client
↓
Plugin
├── Skills
├── MCP Servers
├── Rules
├── Commands
├── Hooks
└── Vendor Extensions
```
也就是说：
- MCP 成为工具连接层；
- Skills 成为可复用知识和工作方法层；
- Plugin 成为分发和安装层；
- Agent Client 成为运行和交互层。
这个分层一旦成熟，Agent 生态会更像“浏览器 + Extension”或“IDE + Plugin Marketplace”。
## 十九、为什么 Agent 插件标准可能比“模型大战”更重要？
模型会快速变化。
企业真正沉淀的是：
- 工具；
- 流程；
- 权限；
- 规则；
- 知识；
- 内部系统。
如果这些能力可以跨 Agent Client 复用，企业就不会因为更换 AI 产品而重新建设所有 Integration。
这会降低 Vendor Lock-in。
## 二十、团队现在需要立刻迁移旧 Plugin 吗？
不一定。
GitHub 明确表示现有不针对 Agent Plugins 1.0 的 Copilot Plugins 会继续支持，不要求立即迁移。
更合理的策略是：
- 已稳定生产：暂不强制迁移；
- 正在开发新 Plugin：优先 Agent Plugins 1.0；
- 多客户端需求：优先迁移；
- 只有 Copilot 专属功能：评估收益后再迁移。
## 二十一、建议的企业目录规范
```text
agent-plugins/
├── deployment/
│ ├── plugin.json
│ ├── skills/
│ ├── mcp.json
│ └── com.github.copilot/
├── database/
├── security/
└── support/
```
配合：
```text
CODEOWNERS
CI
Security Scan
Version Tag
Release Notes
```
不要让 Plugin 成为员工电脑里无法追踪的散装配置。
## 二十二、上线前检查表
### 功能
- Plugin 能否在目标 Client 加载？
- Skill 是否正确发现？
- MCP 是否连接成功？
- 厂商专属扩展是否正确隔离？
### 安全
- MCP Server 是否 Allowlist？
- 是否包含 Shell？
- 是否可能读取 Secret？
- 是否能访问生产系统？
- 高风险 Tool 是否审批？
### 治理
- Owner 是谁？
- 版本是多少？
- 谁能安装？
- 如何撤回？
- 如何升级？
### 运维
- Plugin 调用是否可追踪？
- Tool Error 是否告警？
- MCP Server 不可用时如何降级？
- 新版本如何灰度？
## 总结
GitHub Copilot 对 Agent Plugins 1.0 的支持看似只是一个开发者插件更新，但背后代表的方向更值得关注：
> **Agent 能力正在从“某个平台的配置”变成“可移植的软件包”。**
新的分层越来越清晰：
```text
Skill → 如何做
MCP → 能调用什么
Plugin → 如何打包和分发
Agent Client → 在哪里运行
```
Agent Plugins 1.0 当前已经支持在 VS Code、Copilot CLI、Copilot SDK 和 Copilot App 中复用一个插件包，并允许通过标准部分共享 Skills 和 MCP Server，同时保留厂商专属扩展。
对于个人开发者，它减少重复配置。
对于企业，它更重要的价值是内部 Plugin Marketplace、统一版本、统一权限、统一安全扫描、多 Agent 复用和降低 Vendor Lock-in。
如果这一开放标准继续获得更多 Agent 厂商支持，未来企业建设的重点可能不再是“给每个 AI 工具重新接一次公司系统”，而是一次封装企业能力，让不同 Agent 都能安全使用。
想继续了解 Agent Plugins、MCP、Skills 和企业 AI 工具治理，可以访问 **智元选**：https://www.zyentorpicks.com/。我们会持续跟踪 Agent 生态从模型竞争走向工程标准化的变化。