Anthropic定义了Agent Plugins内部标准，为何未能助力格式治理？
内容提要
Vercel等公司发布Agent Plugins 1.0.0，统一插件格式，但仅标准化组件位置，不规定行为。技能和MCP规范由Anthropic制定，治理分散。插件兼容性依赖客户端能力矩阵，非统一标准。未知字段可忽略，但schema与规范冲突。Claude Code通过CLI转换支持，非原生。扩展和认证等关键功能留待客户端定义，未来需完善权限、签名和测试套件。
延伸解读
兼容性声明的实际含义
Agent Plugins 1.0.0 的兼容性声明并不保证跨客户端互操作。规范允许客户端仅支持技能或 MCP 之一，且传输方式可选。因此，两个客户端可能都符合规范，但无法运行同一个插件。实际兼容性取决于各客户端的支持矩阵，而非统一标准。开发者应查阅具体客户端的能力列表，而非仅依赖“兼容”标签。
未知字段的规范与 schema 冲突
规范第 5.2 节规定，未知的顶层字段应被忽略且插件继续加载，但发布的 JSON Schema 却设置 additionalProperties 为 false，导致标准校验器会拒绝此类插件。规范文本优先于 schema，但 CI 工具通常基于 schema 校验，这会造成实际开发中的困惑。插件开发者需注意，不要仅依赖 schema 生成校验逻辑。
扩展命名空间与行为碎片化
规范第 8 节允许客户端通过扩展命名空间（如 com.vendor.client）添加自定义行为，但明确不提供可移植的发现、验证或加载语义。这意味着命令、钩子等常用功能仍由各客户端自行定义，可能导致标准表面统一，但实际行为碎片化。若插件核心价值依赖钩子，可移植性可能仅限于包装层。
认证与凭据处理留白
v1 规范不定义 OAuth 配置或凭据引用字段，且禁止在头部或环境变量中嵌入凭据。因此，涉及认证服务的插件在打包上可移植，但设置过程因客户端而异，用户容易在此受阻。此外，stdio 服务器的命令解析依赖客户端定义的 PATH 行为，插件应使用相对路径并避免依赖环境变量，以确保跨客户端一致性。
Q&A
Agent Plugins 1.0.0 是由哪些公司共同发布的？
Agent Plugins 1.0.0 由 Vercel 发布，核心维护者来自 AWS、Cursor、Microsoft 和 OpenAI，Google 也在同一天宣布加入。
Agent Plugins 规范中，技能和 MCP 服务器的格式分别由谁定义？
技能格式由 Agent Skills 规范定义，MCP 服务器的行为和生命周期由 MCP 规范定义。这两个规范都出自 Anthropic，但 Anthropic 并未参与 Agent Plugins 的指导委员会。
Agent Plugins 的兼容性如何保证？
Agent Plugins 的兼容性并不由统一标准保证，而是依赖于每个客户端的兼容性矩阵。规范允许客户端只支持技能或 MCP 中的一种，且传输方式也有多种选择，因此两个客户端可能都符合规范但互不兼容。
在 Agent Plugins 中，未知的顶层字段会导致插件加载失败吗？
不会。规范规定，如果插件清单包含未知的顶层字段，客户端必须报告并忽略这些字段，并继续加载插件。但需要注意的是，发布的 JSON Schema 设置了 additionalProperties: false，因此标准 JSON Schema 验证器会失败，而符合规范的客户端会加载成功。
Claude Code 是否原生支持 Agent Plugins？
Claude Code 并不原生支持 Agent Plugins，但可以通过 npx plugins add CLI 将插件安装到 Claude Code 中，该 CLI 会将可移植的插件转换为 Claude 的原生插件系统。
Agent Plugins 规范中，客户端扩展（client extensions）的作用是什么？
客户端扩展是用于存放非可移植核心内容的命名空间，例如命令、钩子、代理、规则和 LSP 服务器等。规范不赋予这些扩展任何可移植的发现、验证、加载或失败语义，每个客户端自行定义其内容的行为。
Agent Plugins 规范如何处理认证和凭据？
规范规定，插件不得在请求头或环境变量中嵌入凭据，且 v1 不定义 OAuth 配置或可移植的凭据引用字段。授权发现、用户交互和凭据存储由客户端管理，因此插件在认证方面是客户端特定的。
Agent Plugins 未来计划完善哪些功能？
未来计划包括权限声明、加密签名验证、认证链、秘密机制、组织允许列表、审计事件模式、依赖解析和一致性测试套件。其中，一致性测试套件和机器可读的能力配置文件是重点。
