Agent Plugins 1.0：可移植 Coding Agent 插件详解
Agent Plugins 1.0 详解：GitHub Copilot 插件结构、VS Code 与 CLI 的可移植性、MCP/Skills 区别及测试边界。
Agent Plugins 1.0：Coding Agent 终于有可移植插件了吗？
官方确认了 Copilot 各端支持，行为与权限仍需跨端验证。
把一份 Markdown 复制到另一个工具并不难。真正困难的是让命令、工具、权限、配置和生命周期在不同客户端保持一致。GitHub 将 Agent Plugins 1.0 推向 GA 的价值正在这里：同一插件可进入 VS Code、Copilot CLI、Copilot SDK 与 Copilot App。
先说结论
- GitHub 宣布 Agent Plugins 1.0 已在四个 Copilot 入口 GA。
- Plugin 打包可复用 Agent 行为，但它不是模型或 Sandbox。
- MCP 连接工具与数据，Plugin 则把能力与使用方式组合成可安装产品。
- “可以安装”不代表权限、UI 和执行环境中的行为完全一致。
- 先用只读工作流做兼容测试，再开放写入和外部变更。
发布了什么
官方结构将 Manifest、Agent、Skill、Hook、MCP 和 LSP 配置明确分开。
GitHub 的官方周更新表示，开发者可以构建一次并在兼容 Agent 工具中使用。这减少了 Copilot 生态内部的重复打包，但还不能自动等同于全行业通用标准。
不同层的职责应分开：模型负责推理，Skill 保存领域流程，MCP Server 提供外部工具，Plugin 负责安装与组合，Host 则掌握权限、UI、Sandbox、秘密和生命周期。Plugin 可以包含 Skill 或 MCP 配置，但三者不是同义词。
可移植性有三层
第一层是同一个包能安装；第二层是调用与事件协议一致；第三层才是行为和安全控制相近。多数发布只证明第一层，生产团队必须验证后两层。
读取仓库的 Plugin 通常容易迁移。部署型 Plugin 则可能在一个 Host 中获得细粒度审批，在另一个 Host 中只弹出一次宽泛确认。差异会直接改变 Agent 权限，不是 UI 小问题。
应该测试什么
在每个支持入口运行同一组 Fixture：
- 是否加载相同命令与指令；
- 缺少配置时是否一致拒绝；
- Tool Schema、超时和错误是否保真；
- 外部变更是否获得等价审批；
- 中断后是否留下孤儿进程；
- Patch 与产物是否可恢复；
- 凭证是否泄露到 Prompt 或日志。
每次结果都记录 Host 和 Plugin 版本。“在 Copilot 能用”不是可复现实验。
MCP 在哪里
MCP 擅长能力边界：列出工具、读取资源、调用 Server。Plugin 更像一个可安装工作流，告诉 Host 如何组合这些能力。Host 仍负责同意机制和进程隔离。
分层还让维护更清楚：轮换工具凭证不必重写编辑规则，修改 Skill 不必改变 Server 协议，Host 强化 Sandbox 也不必重新打包业务流程。
发布 Plugin 时应附带什么
- 支持的 Host 与最低版本；
- 外部系统和可能产生的变更；
- 权限、秘密需求；
- 固定校验和或签名包；
- 兼容 Fixture 与期望输出；
- 升级、回滚和负责人。
如果安装后还会下载可执行代码，用户批准的包与最终运行的包可能根本不是同一个。
结论
能力边界可以继续参考生产级 Agent 的 MCP 执行边界；Host SDK 如何进入更大的控制平面，可阅读Copilot SDK 的 Agent Harness。
Agent Plugins 1.0 是 GitHub Agent 入口间的重要打包里程碑。真正的进步不在“Prompt 可以复制”，而在依赖、权限和兼容性是否能被明确审查。
把可移植性当成需要验证的声明：先安装，再跑统一只读测试，最后比较不同 Host 下的实际权限。只在文件格式层面可移植，意义有限。
FAQ
Agent Plugins 1.0 会替代 MCP 吗？
不会。Plugin 面向工作流打包，MCP 面向工具与资源协议，二者可以组合。
GA 是否代表所有 Coding Agent 都支持？
不是。官方只确认了兼容的 Copilot 入口，其他 Host 需分别核实。
第一个 Plugin 应做什么？
从仓库理解、部署诊断等有边界的只读任务开始，验证审批后再加入写操作。
