拓冰网站定制 
文章目录
- Agent Plugins 1.0.0技术解析：用plugin.json统一打包Skills与MCP服务器
- 一、引言
- 二、统一的是打包，不是所有能力
- 三、plugin.json与版本选择
- 四、MCP配置与安全边界
- 五、与现有插件体系对比
- 六、落地与迁移建议
- 七、总结
Agent Plugins 1.0.0技术解析：用plugin.json统一打包Skills与MCP服务器
一、引言
亲爱的朋友们，创作不容易，若对您有帮助的话，请点赞收藏加关注哦，您的关注是我持续创作的动力，谢谢大家！有问题请私信或联系邮箱：jasonai.fn@gmail.com
Agent Skills 解决“教 Agent 怎么做”，MCP 解决“让 Agent 能调用什么”，但开发者仍要为不同 IDE 和编码智能体维护不同目录、清单与安装说明。Agent Plugins 1.0.0 提出一个很小但关键的互操作底座：用根目录plugin.json声明插件身份，在固定位置放置 Skills 与mcp.json，让兼容客户端按同一规则发现和加载。
它是开放、厂商中立的目录规范，不是新的通信协议，也不替代 MCP 或 Agent Skills。官网当前列出的首届技术指导委员会核心维护者来自 Amazon、Cursor、Microsoft、OpenAI 和 Vercel；部分简讯所称 Google 已加入核心维护者，截至 2026 年 8 月 7 日尚未在治理页得到确认。Google 的 Agents CLI、Data Agent Kit 等产品已体现插件化路线，但应与规范治理成员资格分开表述。
二、统一的是打包，不是所有能力
my-plugin/ ├── plugin.json ├── skills/ │ └── summarize/ │ ├── SKILL.md │ ├── scripts/ │ └── references/ ├── mcp.json └── com.example.client/ └── hooks/| 组件 | 标准职责 | 是否必需 |
|---|---|---|
| plugin.json | 名称、版本、作者、仓库与目标规范 | 必需 |
| skills/ | 按 Agent Skills 规范组织的知识与流程 | 可选 |
| mcp.json | stdio、Streamable HTTP 或 SSE 服务器 | 可选 |
| 反向域名目录 | 客户端私有扩展，如 hooks | 可选 |
规范故意把安装、市场、权限界面、更新策略和客户端专有功能留给各家实现。它定义的是“最小可移植核心”，避免为了追求大一统而把所有宿主差异塞进清单。
三、plugin.json与版本选择
一个最小 1.0.0 清单只有两个字段：
{"$schema":"https://agent-plugins.org/schemas/1.0.0/plugin.schema.json","name":"hello-plugin"}规范要求客户端先验证根清单，再发现组件。顶层字段是封闭集合：未知字段会被报告和忽略，客户端私有元数据必须放进extensions，并使用反向域名命名空间。
| 设计选择 | 解决的问题 |
|---|---|
| 规范版本写入$schema | 客户端明确按哪套规则解释整个包 |
| 固定目录 | 无需每个宿主重新声明Skills位置 |
| 闭合顶层字段 | 防止不同客户端争抢同名字段语义 |
| extensions命名空间 | 允许创新而不污染可移植核心 |
| 组件失败非致命 | 一个MCP启动失败时Skills仍可加载 |
四、MCP配置与安全边界
mcp.json可声明本地 stdio 或远程 Streamable HTTP 服务。${PLUGIN_ROOT}指向只读包内容，${PLUGIN_DATA}指向客户端管理的可写持久数据。插件相对路径必须以./开头且不能逃逸根目录。
{"$schema":"https://agent-plugins.org/schemas/1.0.0/mcp.schema.json","mcpServers":{"validator":{"type":"stdio","command":"./bin/validator","args":["--data","${PLUGIN_DATA}/validator"],"cwd":"${PLUGIN_ROOT}"}}}路径约束只保证包内文件不通过配置逃逸，不等于沙箱。启动后的进程拥有什么系统权限，仍由客户端和操作系统决定。规范也没有定义可移植 OAuth 或秘密引用；Header 是可见包数据，不得内嵌凭据。
| 风险 | 规范提供的防线 | 宿主仍需负责 |
|---|---|---|
| 目录逃逸 | 路径包含性检查 | 文件系统沙箱 |
| 未知字段 | 报告并忽略 | 用户可理解的诊断 |
| 秘密泄露 | 禁止把Header当秘密机制 | 凭据存储与授权交互 |
| 远程重定向 | 禁止未授权跨源转发Header | 网络策略与域名信任 |
| 恶意进程 | 无完整解决 | 安装审查、签名与运行隔离 |
五、与现有插件体系对比
| 方案 | 主要对象 | 优势 | 局限 |
|---|---|---|---|
| Agent Plugins 1.0 | Skills+MCP可移植包 | 小、明确、跨客户端 | 不统一市场、权限与hooks |
| Claude/Copilot插件 | 单一宿主完整扩展 | 功能丰富、体验深 | 跨宿主需适配 |
| Gemini/Antigravity插件 | Google Agent工具链 | 与Google开发生态结合 | 私有能力不自动可移植 |
| APM等包管理器 | 安装、依赖与导出 | 解决版本与分发 | 需要额外工具链 |
| 裸MCP配置 | 单个工具服务器 | 简单直接 | 缺少配套技能和包元数据 |
Agent Plugins 最适合同时包含知识流程和工具连接的能力包，例如“云数据库运维”可包含诊断 Skill、只读审查规则和监控 MCP。只有一个远程 MCP 地址时，直接配置可能更简单。
六、落地与迁移建议
第一步先抽出真正可移植的 Skills 与 MCP，宿主专有 hooks 放入反向域名扩展。第二步用官方 JSON Schema 做 CI 校验，并测试组件单独失败时的降级行为。第三步建立来源、版本、哈希、权限和更新记录；目录格式统一不代表插件天然可信。
面向多个 IDE 时，不要立刻删除旧封装。可先以 Agent Plugins 为源格式，在发布流程中生成各宿主兼容层；等目标客户端完成 1.0.0 一致性验证后，再减少重复目录。
七、总结
| 维度 | 核心结论 |
|---|---|
| 定位 | 面向AI Agent扩展组件的开放可移植包格式 |
| 核心 | 根plugin.json、skills/与mcp.json固定布局 |
| 兼容 | 用最小核心承载Skills和MCP，私有能力走命名空间 |
| 安全 | 有路径和配置规则，但不替代进程沙箱与供应链审查 |
| 治理 | 官网当前列出Amazon、Cursor、Microsoft、OpenAI、Vercel核心维护者 |
Agent Plugins 1.0.0 的价值类似早期软件包清单：它没有替开发者解决所有运行时问题，却让“同一份 Agent 能力到处打包”第一次拥有可检查的共同合同。真正决定它能否成为标准的，不是plugin.json有多少字段，而是各家客户端是否愿意对同一个小核心做一致实现。
参考资料：
- Agent Plugins 官方网站
- Agent Plugins Specification 1.0.0
- Build an Agent Plugin
- Agent plugins in VS Code — Microsoft
- Agent Plugins for AWS — GitHub
- Agents CLI in Agent Platform — Google Developers Blog