Agent Plugins 1.0怎么把一套技能同时带进VS Code和Copilot CLI？
Agent Plugins 1.0把Agent Skills与MCP服务器收进同一个可安装目录，并用客户端命名空间隔离Copilot专属的Agent、命令、规则与Hooks。本文用一个最小目录讲清
plugin.json、skills/、mcp.json和com.github.copilot/各自负责什么，以及旧插件怎样渐进迁移、怎样验证跨端兼容。
过去给AI编程工具做扩展，最麻烦的往往不是把功能写出来，而是同一套能力要为不同客户端重复组织：技能放一处，MCP配置放另一处，命令、Agent和Hooks又有各自的目录。
Agent Plugins 1.0解决的正是“能力如何打包”这个问题。
它不是让所有客户端突然拥有完全相同的功能，而是规定一个可移植核心：把Agent Skills和MCP服务器放进固定位置，再把某个客户端独有的能力放入它自己的命名空间。支持这项标准的客户端读取自己认识的部分，忽略不支持的扩展。
所以，所谓“一套技能同时带进VS Code和Copilot CLI”，更准确的理解是：
维护一个插件包，共享可移植的Skills与MCP配置；VS Code、Copilot CLI等兼容客户端各自加载其支持的组件，Copilot专属能力继续留在独立命名空间中。
GitHub在2026年8月12日宣布Agent Plugins 1.0已用于VS Code、GitHub Copilot CLI、Copilot SDK和Copilot app。下面不讲概念口号，直接拆目录。
一、最小插件其实只需要两个文件
一个能被识别、同时真正提供技能的最小插件，可以是这样：
hello-plugin/
├── plugin.json
└── skills/
└── greet/
└── SKILL.md
根目录的plugin.json负责声明“我是谁、遵循哪个版本的规范”；skills/下面的每个直接子目录代表一个技能。
最小plugin.json如下：
{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "hello-plugin"
}
这里有两个必填字段：
$schema：告诉客户端按Agent Plugins 1.0的规则解释这个目录；name：插件名称，只能使用小写字母、数字、连字符和点，长度为1—64个字符。
然后在skills/greet/SKILL.md中定义技能：
---
name: greet
description: Greet the user and offer help.
---
Greet the user and offer help.
支持Agent Skills的客户端会读取skills/的直接子目录，并检查其中是否存在SKILL.md。它不会为了找技能而无限向下递归，所以不要写成skills/team/greet/SKILL.md后还期待greet被自动发现。
二、plugin.json不要变成“万能配置仓库”
这是迁移时最容易踩的坑。
Agent Plugins 1.0的根清单是封闭结构。可以添加version、description、author、homepage、repository、license、keywords和extensions等规范允许的字段，但不能随意把下面这些内容塞到顶层：
hooksagentscommandsmcpServerslspServers- 某个客户端自定义的任意字段
例如，一个较完整但仍然清晰的清单可以写成：
{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "team-review-tools",
"version": "1.0.0",
"description": "Reusable code review skills for the team",
"license": "MIT",
"keywords": ["code-review", "agent-skills"]
}
技能不需要在清单里重复登记路径，客户端会从固定的skills/位置发现它们；MCP服务器也不写进plugin.json顶层，而是放到根目录mcp.json。
这套规则看似严格，实际是在减少客户端之间的猜测：目录本身就是约定，清单只负责身份和元数据。
三、四个目录分别负责什么？
实际项目通常比最小示例多一些组件：
team-review-tools/
├── plugin.json
├── skills/
│ ├── review-api/
│ │ ├── SKILL.md
│ │ ├── scripts/
│ │ └── references/
│ └── review-tests/
│ └── SKILL.md
├── mcp.json
└── com.github.copilot/
├── agents/
├── commands/
├── rules/
└── hooks/
└── hooks.json
1. plugin.json：插件身份
它声明规范版本、名称和元数据。客户端先验证它；如果必填字段缺失、类型错误或版本不受支持，整个插件应被拒绝加载。
2. skills/：可移植的通用技能
每个直接子目录是一项技能，核心入口是SKILL.md。脚本、参考资料和素材可以继续放在该技能自己的scripts/、references/和assets/中。
适合放这里的内容包括：
- 团队代码审查流程；
- API设计检查清单；
- 测试失败排查步骤；
- 发布前核对规则；
- 调用配套脚本时需要遵循的说明。
判断标准很简单：如果这项能力不依赖某个客户端的专属界面或生命周期，它就更适合做成通用Skill。
3. mcp.json：可移植的MCP服务器配置
当技能需要访问外部工具或数据源时，可在根目录加入mcp.json。规范把MCP服务器定义为第二类可移植组件，与Skills并列。
这里要注意三点：
mcp.json是可选文件，没有MCP服务器不算错误；- 文件存在时必须是合法的普通JSON文件，并符合相同版本的MCP配置规范；
- 插件被安装不代表服务器天然安全，安装前仍要检查命令、参数、环境变量、远程地址和发布者。
不要为了“看起来完整”而给插件硬塞一个MCP服务器。仅靠说明和本地脚本能完成的任务，保持Skill就够了。
4. com.github.copilot/：Copilot专属扩展
Agent Plugins 1.0只把Skills和MCP服务器定义为可移植组件。自定义Agent、斜杠命令、规则和Hooks仍可能是客户端专属能力。
在Copilot生态里，这些内容可以放入com.github.copilot/。VS Code和Copilot客户端读取自己支持的内容；其他客户端如果不实现这个命名空间，就忽略它，但仍可继续使用通用Skills和MCP配置。
这就是跨工具复用的关键：不是强迫所有能力完全一致，而是把“通用能力”和“客户端专属能力”隔离开。
四、怎样设计一套真正可跨端的技能？
目录合规只是第一步，真正决定复用效果的是Skill本身有没有把客户端假设写死。
以“代码审查”为例，不建议在通用SKILL.md中写：
点击VS Code右侧某按钮，然后执行某个专属命令。
更稳妥的写法是描述目标、输入、判断标准和输出：
---
name: review-api
description: Review API changes for compatibility, security, and test coverage.
---
When reviewing an API change:
1. Identify changed endpoints and schemas.
2. Check backward compatibility.
3. Check authentication and authorization boundaries.
4. Verify error handling and test coverage.
5. Return findings by severity with file references.
这样写，编辑器里的Agent可以用，终端里的Agent也能理解。若某一步确实依赖Copilot Hook或专属Agent，再把那部分放到com.github.copilot/，不要污染可移植核心。
可以用三个问题检查一项能力是否写死：
- 是否依赖某个固定按钮、视图或聊天命令？
- 是否把客户端特有的工具名称当成唯一实现？
- 换到纯终端环境后，任务目标和验收标准是否仍然成立？
只要其中一项答案为“是”，就应该把通用规则与客户端实现拆开。
五、旧Copilot插件怎么迁移才不容易中断？
官方参考项目建议采用增量迁移，而不是先删除旧结构再重做。
第一步：先补根清单
在不破坏现有文件的前提下新增或调整根目录plugin.json，加入Agent Plugins 1.0的$schema，先通过清单校验。
第二步：抽出可复用技能
把真正通用的指令、脚本和参考资料移动或复制到：
skills/<skill-name>/SKILL.md
迁移阶段可以先复制，不必马上删除旧文件。等支持的客户端都验证通过后，再清理重复内容。
第三步：分离MCP配置
将可移植的MCP服务器定义迁到根目录mcp.json，明确传输方式和运行参数。不要把mcpServers继续放在plugin.json顶层。
第四步：保留客户端专属能力
Hooks、Agents、Commands、LSP、UI或市场元数据不属于1.0可移植核心。它们应留在目标客户端规定的扩展命名空间，或者暂时保留为兼容包。
第五步：最后才删除遗留文件
先测试可移植核心，再分别测试VS Code、Copilot CLI和其他计划支持的客户端。只有确认安装、发现、调用和禁用都正常，才考虑移除旧格式。
GitHub明确说明，原有未声明1.0规范的Copilot插件仍受支持，并不存在必须立即迁移的要求。对生产团队来说，“先并存、再验证、后清理”比一次性切换更稳。
六、跨端验证不能只看“安装成功”
建议至少做下面五组检查。
1. 清单验证
$schema是否完全匹配1.0.0地址；name是否只使用允许的字符；- 是否误加规范不允许的顶层字段；
- 所有插件内相对路径是否仍位于插件根目录内。
2. Skill发现
- 每项技能是否位于
skills/的直接子目录； - 文件名是否准确为
SKILL.md； - frontmatter是否符合Agent Skills规范；
- 一个坏Skill是否会被跳过，而不影响其他有效Skill。
3. MCP运行
- 本地命令、参数和工作目录能否正确解析；
- 远程服务器地址是否符合预期；
- 密钥是否通过安全的环境配置提供，而非硬编码进仓库；
- 禁用插件后，对应MCP服务器是否停止、工具是否消失。
4. 客户端差异
分别在VS Code和Copilot CLI中确认：
- 通用Skill是否都能被发现；
- MCP服务器是否都能列出并调用；
com.github.copilot/中的专属能力是否只在支持它的客户端生效；- 不支持的命名空间是否被安全忽略，而不是让整个插件失败。
5. 生命周期
不要只测首次安装，还要测：
- 更新后技能是否仍可用；
- 禁用后Skills、MCP与Hooks是否停止生效；
- 重新启用后是否恢复；
- 卸载后是否残留运行中的进程或敏感状态。
七、三个常见误区
误区一：一个插件包等于所有客户端行为完全一致
不等于。标准化的是打包与发现方式，客户端仍可以只实现自己支持的组件。最稳妥的承诺应是“共享可移植核心”，而不是“每个端上所有功能一模一样”。
误区二：装了插件就可以跳过MCP安全检查
不可以。MCP服务器和Hooks都可能在本机执行命令。安装社区插件前，应审查发布者、仓库内容、启动命令、网络访问和环境变量。企业环境还要同时使用插件市场治理与MCP允许列表；允许安装某插件，不等于自动放行其中每一个MCP服务器。
误区三：把所有内容都塞进plugin.json
1.0的根清单不是旧配置的垃圾桶。Skills靠固定目录发现，MCP放在mcp.json，客户端专属字段放在extensions及相应命名空间。随意增加顶层字段，可能直接导致清单无效。
八、FAQ
Agent Plugins 1.0和VS Code扩展是一回事吗？
不是。VS Code扩展可以扩展编辑器本身；Agent Plugin主要打包Agent Skills、MCP服务器及客户端专属的Agent定制能力。两者适用范围和运行模型不同。
只有Skill，没有MCP服务器，可以做插件吗？
可以。最小有效插件只需要plugin.json；若想提供实际技能，再加入skills/<name>/SKILL.md即可。mcp.json是可选项。
plugin.json里需要列出所有Skill路径吗？
不需要。客户端从固定的skills/目录发现技能，从根目录mcp.json发现MCP配置。
Copilot专属Hooks能被其他客户端执行吗？
只有实现对应com.github.copilot扩展命名空间的客户端才会读取。其他客户端应忽略不支持的命名空间，继续处理可移植核心。
旧Copilot插件必须马上迁移吗？
不用。现有未声明Agent Plugins 1.0规范的Copilot格式仍受支持。建议在需要跨工具复用、统一维护或建立团队插件市场时，再采用增量方式迁移。
结语
Agent Plugins 1.0最有价值的地方，不是又增加一种插件格式，而是把过去散落在不同工具里的能力划出一条清晰边界：
plugin.json定义身份；skills/承载可移植知识和流程；mcp.json承载可移植工具连接；- 客户端命名空间隔离专属能力。
如果团队已经积累了代码审查、测试、发布或排障技能，可以先挑一项最通用的流程做最小插件，在VS Code和Copilot CLI分别验证。不要从迁移所有Hooks和命令开始，先证明可移植核心真的能减少重复维护，再逐步扩展。
官方资料
一站式 AI 云服务平台
更多推荐
1
0- 0
已为社区贡献1条内容
所有评论(0)