Agent Plugins 1.0 拆解：统一的扩展包格式，和它故意留下的信任缺口
原创 · 约 16 分钟阅读 · 阅读 --

Agent Plugins 1.0 拆解：统一的扩展包格式，和它故意留下的信任缺口

作者: Alex Xiang

人工智能行业观察

古董级程序员，大厂出来后一直在创业公司，现在仍在一线做 AI 相关开发。这个站写过 MCP 无状态化、写过 ARD 资源发现，这篇把 Agent 生态里最新拼上的那块——插件打包规范——拆开看。

2026 年 8 月 5 日到 7 日，Agent Plugins 1.0.0 正式上线：一个开放、厂商中立的规范，把 Agent Skills 和 MCP 服务器打包成可移植插件，让同一个扩展能在不同 Agent 客户端里被一致地发现和加载。Vercel 发起提案，AWS、Anysphere、GitHub、Microsoft、OpenAI 一起把它打磨成 1.0.0；发布当天，ChatGPT 与 Codex、Cursor、GitHub Copilot、Kiro、VS Code 五个客户端同时表态支持。OpenAI 在 GPT-5 上线一周年的节点上做了官宣，时间点选得很有仪式感。

先说我的结论：这是 Agent 生态的“zip 时刻”——把分发层标准化了，而且刻意做得很小。但规范自己也很诚实：它解决分发，不解决信任；权限、沙箱、签名、凭证、审计全都不在 1.0 里，留给客户端和下一版。 这既是它聪明的地方，也是它最需要被盯住的地方。

一个目录格式，五家客户端同时接住

Agent Plugins 要解决的问题非常朴素：每个 Agent 客户端都长了各自的插件格式，即使插件里装的是同一个东西。作者要为 ChatGPT 写一份、为 Cursor 写一份、为 VS Code 再写一份；同一个 SKILL.md 要维护在四个仓库布局里。做过这事的人都懂这种痛苦，它和当年 ChatGPT plugins / GPTs / Actions 各自为政是同一种碎片化，只是现在客户端更多了。

Agent Plugins 的解法是把“能跨客户端移植的部分”定义成一个小型互操作地板：一个目录，一个 plugin.json，固定的组件位置。分发、安装、权限、用户体验、客户端特有能力，全部继续归客户端自己管。

deployment-assistant/
├── plugin.json
├── skills/
│   └── deploy-service/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.example.client/
    └── hooks/

最小清单只有两个必填字段：

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "deployment-assistant"
}

规范到底写了什么：小，但边界很清楚

读完整份规范，我的印象是“写得比宣传稿硬”。几个关键设计值得单独说。

只有两个组件类型，且不改它们的原生格式。 v1 只标准化 Agent Skills 和 MCP 服务器。Skill 的格式完全交给 Agent Skills 规范（frontmatter、scripts/、references/、assets/ 都是那边的规则），MCP 的连线行为也完全交给 MCP 规范；Agent Plugins 只负责告诉客户端“去哪找”。客户端可以只支持其中一种，也可以都支持。命令、hooks、子 Agent、LSP、设置这些概念，语义和安全模型还没跨厂商收敛，所以 v1 干脆不收，放进各客户端的反向域名命名空间里（com.example.client/），其他客户端必须无视它们、连验证都不做。

失败隔离写得很细。 一个 MCP 条目坏了，只禁用那个服务器；一个 SKILL.md 不合规，只跳过那个 Skill；但 plugin.json 清单整体不合规，整个插件直接拒绝、一个组件都不执行。写过集成的人会明白这种精度有多重要——最怕的就是“半加载”的 MCP 集成，症状像幽灵一样难查。

安全规则全是“包层面”的。 路径必须待在插件根目录内：../bin/server 非法，cwd 必须是 ./ 开头的插件相对路径；stdio 子进程会拿到 PLUGIN_ROOT 和 PLUGIN_DATA 环境变量，占位符只能在 args/env/cwd 里展开；非回环地址的 MCP 远端必须 HTTPS；跨 origin 重定向时不转发配置的 header；客户端加载插件时禁止联网取 schema。

注意最后一句：这些规则管的是“包里的文件别乱跑”，不限制插件进程本身能干什么。MCP 服务器里放一段 subprocess.run(os.environ)，规范一个字都管不了——它本来也没打算管。

生态分层：它补的是“打包”这一层

把 Agent 可扩展性的全栈摊开看，每一层都有对应的规范或责任方：

关注点主要问题负责方
可复用指令Agent 能复用哪些过程知识Agent Skills（Anthropic 2025 年 10 月提出，12 月开放为 agentskills.io 标准）
运行时连接Agent 怎么连到工具和上下文MCP
打包可复用组件怎么装进一个包Agent Plugins
跨生态发现客户端和用户怎么找到包Catalog / Registry（ARD、AI Catalog 这类努力）
信任与执行什么可以被信任并运行发布者、来源验证、客户端策略

这套分层是我在这篇文章里最认同的部分：Agent 互操作不是一个问题，任何单一规范想通吃都会失败。 Agent Plugins 只碰“打包”这一层，MCP 只管“连”，ARD/AI Catalog 管“找”，信任留给“装的人和运行的客户端”。每个环节都能独立演进。

Agent 可扩展性的五层分工

治理比多数第一版标准认真

标准能不能活，治理比技术细节更重要。Agent Plugins 的 Technical Steering Committee 是五个具名个人：Amazon 的 Clare Liguori、Cursor 的 Roshan Sadanani、Microsoft 的 Harald Kirschner、OpenAI 的 Gav Verma，以及 Vercel 的 Jonathan Hefner（Lead）。章程里三条值得读两遍：

  • 没有任何一家厂商能占 Core Maintainer 多数席位；
  • 治理角色由个人担任，不为公司保留席位；
  • 项目名、logo、域名和 GitHub 组织由委员会指定的中立实体托管，任何厂商不得独占。

仓库最初孵化在 vercel-labs/open-plugin-spec，后来迁到独立的 agentplugins 组织；规范文本 CC-BY-4.0、代码 Apache-2.0。这意味着即使中立性承诺哪天失效，整个项目也是可 fork 的，而不是被某个厂商锁死。这比“联盟新闻稿 + 空仓库”的剧本强得多。

三个必须正视的洞

第一，信任：解决分发，不解决“能不能信”。 v1 明确不定义：信任模型、权限系统、沙箱；来源验证（没有签名、没有 attestation）；凭证处理（规范禁止在 env 和 header 里放凭据，但也没给可移植的替代方案）；企业控制（allowlist/blocklist/组织级 registry/集中策略）；审计日志；插件间依赖。规范里有的安全规则都是关于“包本身”，而不是“包被允许做什么”。

对一个写代码的人来说，这意味着：装一个 Agent Plugin 等于运行一段没有权限声明的代码，是否安全完全取决于你装在哪个客户端、那个客户端碰巧给了什么权限控制。 企业买 Agent 产品时，最该问的三个问题仍然是：能不能把我教它的东西导出；谁决定它能碰什么（v1 没有权限模型，答案在客户端）；能不能用我自己的历史数据先测一遍。可移植的包解决不了“不可移植的后果”。

第二，Anthropic 缺席：差两个文件路径。 Claude Code 是当前真实世界里插件创作最活跃的地方，Agent Skills 这个概念本身就是 Anthropic 提出来的，但 Anthropic 不在发布名单里，Claude Code 也不在 launch 客户端里。两边的格式接近但不兼容：

Agent Plugins 1.0Claude Code 插件
清单路径plugin.json.claude-plugin/plugin.json
MCP 配置mcp.json.mcp.json
Skillsskills/skills/
子 Agent未覆盖agents/
Hooks未覆盖hooks/hooks.json
LSP / 设置未覆盖.lsp.json / settings.json

这些是文件路径差异——最可修复的不兼容。一个插件可以同时带两份 manifest 而不算太折腾，但在有人做这件事之前，同时面向两个生态的作者仍然要维护两套布局，而这恰恰是这套标准想要消灭的问题。我不把缺席理解为拒绝，更接近“未完成”。值得盯的是 Claude Code 什么时候把 plugin.json 和 mcp.json 的位置对上，以及 v1.1 会不会把 agents/、hooks/ 收进可移植组件。

第三，分发不等于效果。 一个 SKILL.md 在两个客户端之间搬家很干净，不代表 Agent 在两个客户端里表现一致——工具权限不同、模型不同、系统提示不同，结果就不同。可移植的包降低的是组装成本，不是拥有成本；它不解决“这个技能在我的环境里到底好不好用”。

我的判断：该有的都有，最难的都留给了下一版

Agent Plugins 1.0 是一个“对的小事”：先统一打包边界，再谈组件类型扩展；先让标准落地，再让语义收敛。相比一份什么都想定义、吵三年出不来的宏大纲，这份“small on purpose”的规范更可能被生态真正接住。发布当天五家客户端接住、GitHub 仓库公开、章程把中立性写死，这些都是好信号。

接下来真正决定它价值的，是三件事：

  1. v1.1 会不会补权限/信任模型。 如果下一版带着能力声明、签名和沙箱边界来，Agent Plugins 就从“分发格式”升级成“分发 + 信任协议”；如果一直拖着，它就只能停在“zip 格式”，安全故事完全靠各家客户端各讲各的。
  2. Anthropic 是否收敛。 两个文件路径的差距加上 Claude Code 的生态体量，决定了这个格式是“事实上的统一”还是“又一次 A/B 分裂”。
  3. 谁能成为“插件界的 npm”。 规范明确不做 registry，市场层留给第三方——Smithery、微软的 Agent Governance Toolkit Plugin Marketplace 都在抢这个位置。打包格式统一了，分发渠道的战争才刚开始。

对我们这些写插件、选 Agent 工具的人来说，我的建议很直接：新写扩展时按 Agent Plugins 的目录结构打包，客户端特有部分放进反向域名命名空间；选工具时把“是否支持 Agent Plugins”当一个小加分项，然后照旧去问那个真正的问题——你让它装的东西，到底能碰什么。

打开原图 ↗