有了统一标准的AI插件露面了, 8月6日, 正式公开了Agent 1.0.0 的开放规范, 解决了让开发者感到最为头疼的重复打包问题, 这份规范是由AWS、微软、谷歌等六家巨头一起构建的, 谷歌在发布当天还追加成为核心维护者。

统一插件打包格式

过去之时, 开发者要是想要制作一个插件, 那就务必要针对每一个客户端再次进行打包操作。而如今的情况却是, 仅仅需要打好一份包, 所有能够兼容的智能体客户端全部都能够实现识别。这所呈现出来的状态的, 类似于是给插件设定了统一的包装盒, 从此以后凭借一份包便可以通行于天下。

微软官方账号发布文章声称, 仅需一次打包, 便能够在全部具备兼容性的客户端当中实现通用, 并且还@了一连串的共建方。如此一来, 开发者往后无需再针对每家客户端来回重复进行劳动, 从而极大程度地提高了开发效率为。

规范核心结构设计

一份.json清单放置于规范根目录，所有技能皆被丢入/skills目录, MCP配置写入mcp.json。清单之中仅有$id与name这两个字段为必填项, 其余的需依靠固定位置去寻找。客户端无需猜测, 甚至连版本号皆可不写。

各类想要夹带进入的秘密条款, 像特别的诱导手段或指令, 全部遗弃纳入反向域名所命名的文件夹。此外的客户端并不知晓这个文件夹, 扫描到了也径直忽略而过。所以公共层面变得愈加纯净, 达成起来也并不繁杂。

只统一包装盒

管指令的Agent规范, 管连工具的MCP, 那把有关这二者所属的管指令的Agent规范跟管连工具的MCP装进一个同样模样从而统一的包装盒里头, 不过统一的仅仅是包装盒而已, 其中原原本本的智能体并没有变动。关于安装、分发、权限、沙箱、认证、信任验证以及用户体验，没有任何一项处在被管的范畴之内。

每家对于stdio传输方式, 以及HTTP传输方式, 再者旧版HTTP加上SSE这种类型的传输方式的支持情况并非完全相同。同一插件在更换客户端之后, 能否顺利运行起来, 还得取决于概率。即便进行了统一打包, 也不意味着运行情况就会保持一致。

安全风险提示

微软特地嘱咐安全事项, 插件当中的MCP以及hooks, 将会在本机运行代码, 安装之前务必要看清来源以及作者, 社区市场里的 stuff 特别要留意, 别随意安装来路不明的插件。

工作草案被标在了规范正文里, 距离行业盖章认可的成熟标准仍有着一定差距。各家用来打包文档所采用的结构并非一致, 真正运行起来认证方式以及运行环境依旧有可能各不相同。

微软Code先跑通

微软所拥有的VS Code早就已然完成了一整套的插件系统, 在根目录存在的其中一批清单, 它们对应着、关联着技能、MCP、钩子、子智能体、所涉及的斜杠命令。「插件等同于与关联着技能以及MCP还有清单」这样的打包思路, 是在较早就已经实现并运行完好的思路当中的其中一条思路之一句号。

此次采用的新标准, 仅仅收纳了具备通用性的那两块, 其他更为花哨繁复的部分并未纳入。然而, 格式方面几乎是依照 VS Code 的样式来呈现, 就连变量都原封不动地照搬过来, 仅仅替换了一个名称而已。

谷歌缺席标准制定

微软VS Code官方文档里, 默认插件市场存在vscode这一项, 它一方面对新型格式予以支持, 另一方面持续认可旧有的结构。Codex更为干脆, 就连原来的那个变量名都特意留存着, 用于实现对已有的插件进行兼容。

谷歌新推出的两套工具, 都将VS Code列入适配对象范畴, 其自身另有两个官方插件市场。此次它未参与到统一标准的相关事宜中, 而是持续经营自身从格式直至市场的闭环体系。一旦底层标准达成一致, 竞争便会在更高层面, 围绕插件生态展开比拼。

在你看来, 当AI插件达成统一标准之后, 它会促使智能体应用的普及进程加快吗? 欢迎留下话语来分享你所抱持的观点, 为点赞并进行转发以便让更多的人能够看到！