Agent Plugins 1.0 怎么统一 VS Code、Copilot CLI 与 Copilot App：迁移和治理边界

同一个部署技能如果同时服务 VS Code、Copilot CLI 和 Copilot App，最容易失控的不是技能本身，而是每个客户端各维护一套清单、文件夹结构和安装说明。GitHub 在 2026 年 8 月发布 Agent Plugins 1.0 后，插件可以把 skills 与 MCP server 放进一个可安装包，再由兼容客户端读取自己支持的部分。对团队来说，真正值得关注的是：哪些文件可以共用，哪些行为仍然属于 Copilot 专属，以及企业管理员怎样把安装范围锁住。

Agent Plugins 1.0 解决的到底是哪一层重复

过去可以为多个 agent client 发布插件，但同一套 skill 和 MCP server 往往要配多份 manifest 与文件夹布局。代码逻辑没有变，包装方式却变了，维护者需要同步版本号、安装说明和能力声明。Agent Plugins 1.0 把这层包装标准化：一个插件包可以被多个兼容客户端发现，各客户端只加载自己支持的 skills、MCP 配置或扩展。

这不是把客户端差异抹平。VS Code、Copilot CLI、GitHub Copilot SDK 和 Copilot App 已获得兼容支持，但每个客户端仍可能只识别部分扩展。因此，迁移时要把“包能被发现”和“功能在本客户端可用”分开验收。

一套可移植包应该怎样分层

可以先把文件夹结构理解成两条线：公共能力线负责跨客户端复用，客户端扩展线负责保留差异。一个最小的迁移草图如下，名称可以按团队仓库调整：

my-deploy-plugin/
├── plugin.json
├── skills/
│   └── deploy-runbook/SKILL.md
├── mcp.json
└── com.github.copilot/
    ├── agents/
    ├── commands/
    └── hooks/

plugin.json 是包的入口描述，skills/ 放跨客户端都能理解的工作知识，mcp.json 描述工具服务。Copilot 的 custom agents、commands、rules、hooks 等扩展则放进 com.github.copilot/，其他客户端可以忽略这部分而继续读取公共内容。

从旧插件迁移时，先做兼容矩阵再改 manifest

迁移旧包时，我更建议先画一张四列矩阵：客户端、会读取的文件夹、需要的工具权限、验收动作。这样可以提前发现“公共 skill 写得很完整，但 CLI 缺少某个 MCP server”这类半成功状态。

1. 把原有 skill、MCP 配置和 Copilot 私有文件分别列出，不要一上来重命名全部文件夹。
2. 给 plugin.json 加上 $schema，再确认 skills/ 与 mcp.json 的最小包能被客户端发现。
3. 把仅供 Copilot 使用的 agents、commands、rules、hooks 移入 com.github.copilot/。
4. 在 VS Code、Copilot CLI 和 Copilot App 各做一次“发现插件—调用 skill—访问 MCP”的验收，记录缺失能力。

旧 GitHub Copilot 插件如果没有针对 Agent Plugins 1.0，不需要为了版本号而立即重做；官方说明是这类旧插件仍受支持。真正需要迁移的信号，是同一能力已经出现多份 manifest，或者企业需要统一 marketplace 和权限策略。

企业治理要锁住来源、安装和工具三件事

插件可移植之后，治理范围反而更清晰了。Copilot Business 和 Enterprise 可以沿用现有的 managed settings，在 managed-settings.json 中配置 enabledPlugins，自动安装或阻止指定插件；用 extraKnownMarketplaces 增加团队允许的市场；用 strictKnownMarketplaces 限制只能从受管市场安装。

这三项控制的是“插件能不能进入工作区”，不是 MCP 服务内部能做什么。插件带有 MCP 配置时，还要继续使用 MCP allowlist，按 URL、命令或名称批准或阻止具体 server。治理验收至少看四个结果：

• 未批准的 marketplace 不出现在可安装入口。
• 被阻止的插件不会被自动装入客户端。
• 已批准插件能被发现，但其 MCP server 仍受独立 allowlist 约束。
• 团队覆盖设置与企业基线叠加后的结果符合预期，而不是绕过基线。

几个容易误判的边界

统一包不等于统一体验。同一个 skill 可以跨客户端复用，但客户端支持的扩展、审批交互和工具权限可能不同。发布说明里“兼容”更接近可发现、可安装和读取标准部分，不代表所有按钮、命令和 hook 都同名。

市场限制不等于服务安全。strictKnownMarketplaces 能限制插件来源，但不能替代 MCP allowlist，也不能替代对 server 命令和网络目标的审查。

迁移 manifest 不等于迁移运行手册。如果 skill 文档里写着某个 Copilot 专属 command，搬到公共 skills/ 后可能让其他客户端得到无法完成的步骤。公共 skill 应写能力和结果，专属文件夹再写客户端操作。

发布前的四项检查清单

1. 包结构：plugin.json、skills/ 和 mcp.json 能被目标客户端发现，私有扩展只放在对应命名空间。
2. 客户端结果：至少在一个编辑器、一个 CLI 和一个 Copilot App 场景完成安装、skill 调用和工具权限核对。
3. 治理结果：验证 enabledPlugins、extraKnownMarketplaces、strictKnownMarketplaces 和 MCP allowlist 的组合效果。
4. 回退方案：保留旧插件包和原 marketplace 配置，先让一个团队灰度，再扩大范围。

相关问题

Agent Plugins 1.0 是否要求立刻迁移所有旧插件？

不要求。没有采用新规范的旧 GitHub Copilot 插件仍可继续使用；当重复维护成本或企业治理需求出现时，再按兼容矩阵迁移更稳妥。

一个插件能否把 skill 和 MCP server 一起分发？

可以，这正是规范强调的组合方式。但 server 的 URL、命令和权限仍要单独审核，不能因为它位于同一个包里就跳过 allowlist。

其他客户端会读取 com.github.copilot/ 吗？

这部分用于 Copilot 专属文件，其他兼容客户端应忽略它；公共能力应放在标准文件夹中，避免把关键步骤只写在专属扩展里。

企业最先应该配置哪一项？

先明确允许的 marketplace，再配置插件启用范围，最后逐个核对 MCP server。顺序反过来，容易出现插件来源没有锁住、工具权限却已经放开的情况。

Agent Plugins 1.0 的价值不在于再增加一个插件文件夹，而在于把“复用”和“治理”拆成了可检查的两层：公共包负责跨客户端传播能力，客户端命名空间保留差异，企业设置负责来源与安装范围，MCP allowlist负责工具边界。按这个层次迁移，团队才有机会真正做到一份包、多端复用、权限可追踪。