ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

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

Agent Plugins 1.0 拆解:统一的扩展包格式,和它故意留下的信任缺口 古董级程序员大厂出来后一直在创业公司现在仍在一线做 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 SkillsAnthropic 2025 年 10 月提出12 月开放为 agentskills.io 标准运行时连接Agent 怎么连到工具和上下文MCP打包可复用组件怎么装进一个包Agent Plugins跨生态发现客户端和用户怎么找到包Catalog / RegistryARD、AI Catalog 这类努力信任与执行什么可以被信任并运行发布者、来源验证、客户端策略这套分层是我在这篇文章里最认同的部分Agent 互操作不是一个问题任何单一规范想通吃都会失败。Agent Plugins 只碰“打包”这一层MCP 只管“连”ARD/AI Catalog 管“找”信任留给“装的人和运行的客户端”。每个环节都能独立演进。治理比多数第一版标准认真标准能不能活治理比技术细节更重要。Agent Plugins 的 Technical Steering Committee 是五个具名个人Amazon 的 Clare Liguori、Cursor 的 Roshan Sadanani、Microsoft 的 Harald Kirschner、OpenAI 的 Gav Verma以及 Vercel 的 Jonathan HefnerLead。章程里三条值得读两遍没有任何一家厂商能占 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.jsonMCP 配置mcp.json.mcp.jsonSkillsskills/skills/子 Agent未覆盖agents/Hooks未覆盖hooks/hooks.jsonLSP / 设置未覆盖.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 仓库公开、章程把中立性写死这些都是好信号。接下来真正决定它价值的是三件事v1.1 会不会补权限/信任模型。如果下一版带着能力声明、签名和沙箱边界来Agent Plugins 就从“分发格式”升级成“分发 信任协议”如果一直拖着它就只能停在“zip 格式”安全故事完全靠各家客户端各讲各的。Anthropic 是否收敛。两个文件路径的差距加上 Claude Code 的生态体量决定了这个格式是“事实上的统一”还是“又一次 A/B 分裂”。谁能成为“插件界的 npm”。规范明确不做 registry市场层留给第三方——Smithery、微软的 Agent Governance Toolkit Plugin Marketplace 都在抢这个位置。打包格式统一了分发渠道的战争才刚开始。对我们这些写插件、选 Agent 工具的人来说我的建议很直接新写扩展时按 Agent Plugins 的目录结构打包客户端特有部分放进反向域名命名空间选工具时把“是否支持 Agent Plugins”当一个小加分项然后照旧去问那个真正的问题——你让它装的东西到底能碰什么。
返回列表