打包但不可移植：为什么很少遵守代理插件标准，以及为什么仅仅遵守还不够

编码代理通过插件进行扩展：可安装的捆绑包，其中包含技能、子代理、命令、挂钩和工具服务器。 2026 年 7 月 24 日，一项开放规范（代理插件 v1.0.0）标准化了此类捆绑包的布局和描述方式，以便一个插件可以在任何代理上运行。我们问从业者会问的两个问题：生态系统是否采用该标准，如果插件确实符合标准，是否足以使其与用户安装的其他插件一起工作？我们通过构建 AgentPluginZoo 来回答这两个问题，这是一个由 30,655 个存储库中的 68,072 个插件包组成的可追踪来源的语料库，并随其发现分类账、评分代码和分析一起发布。只有 6.2% 的人进行了验证，但差距很小，而不是结构性的：96.6% 的人会在添加一个缺失的样板字段后加载。真正的成本落在其他地方。 40.2% 会加载，而规范要求客户端放弃作者编写的字段，主要是插件附带内容的声明。此外，一致性并不能解决第二个问题：81% 的功能导出包与另一个插件共享一个名称，没有命名空间或优先规则来决定哪个插件会回答。本文认为，当组合需要模型时，社区标准化了打包格式，命名了此类模型必须添加的四个概念 - 合格的功能标识、声明的功能表面、优先规则和插件间关系 - 并表明它们适合相同规范的附加 v1.1 配置文件，而不是竞争标准。为当今打包扩展的从业者和制定标准的人们提供了建议，其中最主要的是，在其变得普遍之前必须使一致性变得可观察。语料库和代码可在此 https URL 获取