1 个插件包跨 4 大客户端,Copilot 新标准免去重复打包

Agent Plugins 1.0 正式发布，将 agent skills 和 MCP servers 打包成独立于单一供应商的可安装插件。AWS、Anysphere、Microsoft、OpenAI、Vercel 联合发布，Google 作为核心维护者加入。

这解决了以前为多个 agent 客户端发布插件需要重复维护 manifest 和目录布局的痛点。你下半年在多客户端环境部署 agent 工具，不用再为每个客户端写一套配置，开发效率直接翻倍。

目录结构与 Manifest 配置解析

以前打包是重复劳动，现在通过标准化 manifest 工作流解决。在 plugin.json 添加 $schema。将技能放在 skills/ 目录，MCP 配置放在 mcp.json。最关键的改动是将 Copilot 特定文件移入 com.github.copilot/ 目录。其他客户端会直接忽略这个目录，从而保证插件的可移植性，同时不丢失 Copilot 的 custom agents、commands、rules、hooks 以及 canvases 等扩展行为。

这种目录隔离设计有明确的适用边界。如果你的插件深度依赖 Copilot 独有的 UI 扩展（例如 canvases），在 VS Code 或 Copilot CLI 中这些功能会静默失效。开发者在迁移时必须明确区分通用 MCP 能力和 Copilot 专属能力，避免在非 Copilot 客户端中触发未捕获异常或功能缺失。建议在 plugin.json 中增加环境检测逻辑，在加载 com.github.copilot/ 资源前先校验当前客户端类型。

企业级管控与 MCP 安全策略

Copilot Business 和 Enterprise 客户可以直接复用现有的企业托管设置。在 managed-settings.json 中，通过以下参数实现细粒度控制：

• enabledPlugins：自动安装或阻止特定插件。
• extraKnownMarketplaces：添加开发者可用的市场。
• strictKnownMarketplaces：限制安装到受管市场。

企业级设定建立基线，插件和市场设置会与团队特定覆盖 additive 结合。现有设置直接适用于 Agent Plugins 1.0，无需单独制定策略。同时，由于插件可携带 MCP 服务器配置，需结合 MCP allowlists 通过 URL、command 或 name 批准或阻止单个服务器。

针对企业级落地，这里提供一份可执行的排查清单。第一步，梳理现有插件清单，标记哪些包含 MCP server 配置。第二步，在 managed-settings.json 中将 strictKnownMarketplaces 设为 true，阻断未授权市场的插件安装。第三步，针对包含敏感数据访问权限的 MCP server，在 MCP allowlists 中通过 URL 或 command 进行白名单拦截。第四步，验证现有 Copilot 客户端策略是否平滑过渡，确认无需新建独立策略后再向全公司推开。

获取渠道与迁移指南

你可以在 Awesome Copilot marketplace 中找到这些插件，该市场默认集成在 VS Code、Copilot CLI 和 Copilot app 中。现有的不针对 Agent Plugins 1.0 的 GitHub Copilot 插件继续受支持，无需迁移。如果需要构建新插件或迁移旧插件，参考以下官方资源：

插件市场：
构建指南：
示例与迁移：
企业设置覆盖：

Agent Plugins 1.0 的核心价值在于将 MCP 服务器配置与 agent 技能解耦并统一打包。对于技术决策者而言，内部工具链的标准化成本大幅降低。但需要注意，Google 作为核心维护者加入，暗示未来该标准可能会深度整合特定生态需求。在评估是否全面迁移时，建议先在非核心业务线的小规模团队中试点 com.github.copilot/ 目录的隔离效果，确认跨客户端兼容性后再全量推开。

留言聊聊
你主力用哪个客户端？插件迁移到 1.0 标准遇到兼容问题了吗？

往期推荐

• ·5000亿美元融资，Nvidia将旧GPU重估为长期资产
• ·5000亿美元砸向算力基建，交付才是真门槛
• ·智能手表CPU跑HiMAE，推理不到1毫秒

点击公众号头像 → 历史消息，可翻阅以上文章