Agent Plugins 1.0 发布，智能体插件的「iPhone 时刻」来了吗？

发表于2026-08-08|更新于2026-09-07|视界AI研究

|浏览量:

前两天我还在折腾一个 LangGraph 项目，想把一个自己写的「查询内部知识库」的能力打包给团队里另一个用 Claude Code 的同事复用。结果聊了半天发现，我给他 SKILL.md，他不知道往哪放；我给他 MCP 配置，他客户端里的字段名和我这边对不上；最后变成我录了五分钟的 Loom 视频，手把手教他改 .cursor/mcp.json。

这种事儿你肯定也遇到过。AI 智能体火了一年多，工具链却还在「手工作坊」阶段。每个客户端都有自己的技能格式、自己的 MCP 配置方言、自己的安装路径。一个东西能不能跑起来，很大程度上取决于作者有没有在你用的 IDE 里踩过同样的坑。

所以当我看到 Agent Plugins 1.0.0 正式发布，Google、Amazon、Microsoft 一起站台，第一反应不是「又一个标准来了」，我想的是

这帮人是真的想把智能体插件做成可移植的安装包，还是只是在 MCP 之外再叠一层政治博弈？

我花了一个上午读了这份规范原文，越读越觉得，这件事可能没标题那么性感，但对做 Agent 的人来说，确实是一根能捅破窗户纸的针。

01 一个目录加一个 JSON，智能体终于有「安装包」了？

Agent Plugins 的规范非常朴素。一个合法插件就是一个目录，根目录下必须有一个 plugin.json，然后可选地放 skills/ 目录和 mcp.json。

最小示例如下

hello-plugin/
├── plugin.json
└── skills/
    └── greet/
        └── SKILL.md

plugin.json 长这样

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

没了。不需要你写一堆 vendor 特定的字段，不需要用户在每个客户端里翻译一遍配置，不需要把技能和 MCP 服务器拆成两个仓库分发。

规范把「Agent Skills」和「MCP servers」打包进同一个目录。Skills 走 skills/<name>/SKILL.md，符合 Agent Skills 规范；MCP 服务器走根目录的 mcp.json，用 stdio 或者 streamable-http 传输。客户端加载时，先读 plugin.json，再按固定路径去发现这两个组件。

这种设计让我想起 Maven 的 pom.xml 加上约定优于配置的目录结构。它没发明新轮子，只是把已经存在的两个协议装进了一个统一的容器。

但恰恰是这个「容器」，解决了过去一年最让人头大的问题

一个能力从作者手里传到用户手里，中间要经过多少次格式翻译？

02 为什么偏偏是 Agent Plugins，而不是直接 MCP？

有人会问，MCP 不是已经有统一协议了吗？再搞一个 Agent Plugins 是不是重复造轮子？

坦率的讲，我一开始也这么想。但读完规范原文后，我发现它瞄准的是一个 MCP 没打算解决的问题，包装和分发。

MCP 管的是运行时通信。它告诉你客户端怎么和服务器握手、怎么发请求、怎么返回工具列表。但它没规定这些服务器应该以什么形态被交付给用户。于是现实变成

Cursor 用一套 mcpServers 配置；
Claude Code 用另一套；
有些项目把 MCP server 二进制和 Python 包一起发；
有些项目让你手动 npx 或者 uvx；
技能文件更是各写各的，有的叫 .claude/commands/，有的叫 .github/copilot-instructions.md。

Agent Plugins 不搞新的运行时协议，而是说

「你们现有的协议我都认，但能不能约定一个统一的目录格式，让插件作者只写一次，用户只要复制一个目录就能跑？」

这就像 Docker 没有重新发明 Linux namespace，而是给 namespace、cgroup、unionfs 套了一个镜像格式。Agent Plugins 也想给 Agent Skills 和 MCP 套一个可移植的镜像格式。

这个定位其实挺聪明的。它不和 MCP 抢话语权，而是补上了 MCP 生态里缺失的那一块。

03 规范里真正值钱的三件事

我挑了三条我认为最值钱的规定，放在这里聊聊。

第一件事，路径沙箱。

规范 4.1 节明确要求，插件内所有路径解析后必须落在插件根目录内。command 和 cwd 如果是相对路径，必须以 ./ 开头，不能写 ../bin/server 这种东西。

这个要求看起来是小事，但对安全来说很关键。你想啊，MCP server 很多是本地可执行文件，如果配置里允许它引用插件目录之外的文件，一个恶意插件就能顺手读取你 ~/.ssh 里的内容。把路径锁死在插件根目录，等于给每个插件画了一个牢房。

第二件事，环境变量隔离。

规范给每个 stdio MCP server 注入两个保留变量，PLUGIN_ROOT 和 PLUGIN_DATA。前者是插件根目录的绝对路径，后者是客户端给这个插件分配的持久化数据目录。

这样一来，插件作者不用再猜自己装在哪，也不用把临时文件写到系统各个角落。用户升级插件时，客户端可以把 PLUGIN_DATA 保留下来，配置和状态不会丢。

更细节的是，mcp.json 里的 args、env、cwd 支持 ${PLUGIN_ROOT} 和 ${PLUGIN_DATA} 占位符展开，但 command 本身不被展开。规范说得很清楚，把 command 当成一个单独的可执行 token，避免用户写 shell 命令字符串带来的转义和注入问题。

第三件事，失败隔离。

规范 7.2.2 条规定，如果某个 MCP server 启动失败、握手失败、或者认证失败，客户端必须继续加载插件里的其他组件，不能一崩全崩。

这个设计太有工程味了。现实里的插件很少是单一能力，一个知识库插件可能同时提供搜索 skill、分析 skill、还有一个 MCP server 做文件读写。如果 MCP server 因为网络问题连不上，skill 部分应该还能用。这种局部可用性思维，比「要么全对要么全挂」的粗暴处理高明得多。

04 大厂站台背后的政治与治理

这条新闻里最容易被忽略、但我觉得最重要的，是治理结构。

Agent Plugins 不是 Google 一家的标准。规范放在 agentplugins GitHub 组织下，技术章程里写了一条硬规则

没有任何一家厂商可以控制 Core Maintainer 的多数席位。

所有角色都授予个人，而不是公司。TSC 选举、Lead Core Maintainer 的任免、规格变更，都要走公开投票。Google 只是核心维护者之一，而且规范明确说明

Agent Plugins 的 Google 支持体现在 Agents CLI 和 Data Agent Kit 中提供实现，而不是对规格的单方面控制。

这个表态很有意思。MCP 虽然是 Anthropic 发起的，但现在已经被广泛接受为中立协议；Agent Plugins 在成立之初就把「反单一厂商控制」写进章程，显然是想避免重蹈某些早期协议被质疑私有化的覆辙。

Amazon 和 Microsoft 的站台也很关键。这三家云厂商如果各自搞一套插件格式，开发者会比现在还痛苦。现在它们愿意坐在一起，至少说明一件事

智能体插件的市场已经大到，连云计算巨头都觉得统一格式比封闭生态更划算。

05 不是万能药，v1 故意没解决的坑

读到这儿你可能觉得我在吹。其实没有。规范的 Future Considerations 部分把 v1 没做的事列得很清楚，而且这些事个个都难。

权限模型缺失。

v1 没有定义插件能申请什么权限，也没有要求客户端在加载前向用户展示权限清单。一个插件带了 MCP server，它能不能访问网络、能不能读写文件、能不能调用系统命令，全看客户端自己的心情。未来必须补上 permissions 字段和分级信任机制，否则企业场景没法大规模用。

来源验证缺失。

现在插件就是一个目录，任何人都可以改。规范提到未来可能会做签名验证和来源证明，但 v1 没有。你从 GitHub 下一个插件，怎么知道它没被中间人替换？这个问题不解决，插件商店就不敢开。

秘密管理缺失。

MCP server 经常需要 API key。规范明确要求不能把凭证写在 mcp.json 的 headers 或 env 里，但它也没提供一个标准注入方式。每个客户端还是得自己想办法解决 secret 的读取和轮转。

依赖解析缺失。

v1 不支持插件依赖另一个插件。如果你想做一个「数据分析插件」，依赖另一个「数据库连接插件」，现在只能让用户手动装两个，然后自己配路径。长期看肯定需要类似 npm 的依赖树机制。

测试和验证缺失。

v1 没有提供标准的测试工具或者验证命令。你写了一个插件，怎么确认它符合规范？怎么在不同客户端上跑一致性测试？现在只能靠各家客户端自己去实现。对于想发布插件到公共市场的作者来说，这会增加不少调试成本，也会让用户在选择插件时更犹豫。

这些缺失不是 bug，而是 v1 的边界。规范制定者选择先把最小可用格式定下来，而不是等到所有问题都有答案才发布。这个策略我认同，不过这也说明，现在就开始「All in Agent Plugins」还太早。

06 它和 Docker、npm 有什么不一样？

聊到 Agent Plugins，很多人第一反应是，这不就是 Agent 世界的 npm 吗？

坦率的讲，这个类比有一半是对的，但另一半会误导你。

npm 解决的是「代码依赖」的可移植性。你写一个 package.json，把依赖树锁死，别人 npm install 就能跑。Agent Plugins 解决的不是代码依赖，而是「能力交付」的可移植性。一个插件里可以没有一行新代码，只有 SKILL.md 和 mcp.json，但它依然是一个完整的能力包。

Docker 更像是「运行环境」的可移植性。你把应用、系统库、配置都打进镜像，换台机器也能跑。Agent Plugins 不负责运行环境，它假设客户端已经能运行 MCP server 和 Agent Skills。它只做一件事，让能力的描述和入口在不同客户端之间保持一致。

所以 Agent Plugins 不是 npm 的替代品，也不是 Docker 的替代品。它更像是一个「能力清单 + 沙箱入口」的约定。

这个定位其实挺吃亏的。因为它不像 npm 那样能立刻让你少写代码，也不像 Docker 那样能立刻解决环境不一致。它的价值要在大规模协作里才能显现出来。

想象一个场景。你们公司有二十个内部 Agent，分别跑在 Cursor、Claude Code、Coze、Dify、LangGraph 上。每个工具都有自己的技能格式，每次有人写了一个好用的「代码审查 skill」，其他人想复用，都得手动翻译一遍。

Agent Plugins 想终结这种重复翻译。它不是说让所有工具都变成同一个运行时，而是让所有工具都能读懂同一份能力清单。

这个野心比「统一运行时」小，但可行性高得多。因为统一运行时会触碰到每个厂商的核心利益，而统一清单只触碰到交付格式。

不过这也带来一个限制。Agent Plugins 能做的，只是把「能力说明书」标准化。真正决定体验好坏的，还是各个客户端怎么去执行这份说明书。同样一个 SKILL.md，有的客户端能把它用得风生水起，有的客户端可能根本读不懂。

所以说到底，Agent Plugins 是必要但不充分的条件。没有它，生态一定会乱；有了它，生态也不一定就整齐。

07 LangGraph 和 Spring 开发者该关注什么

回到我自己的技术栈，Java / Spring、LangGraph、一些 MCP server。我读完规范后最大的感受是

Agent Plugins 不会让 LangGraph 失业，也不会让 Spring Boot 变成 legacy。但它可能会改变我们封装和交付 Agent 能力的方式。

LangGraph 擅长的是编排。状态图、节点、边、条件分支，这些是运行时的大脑。Agent Plugins 不关心大脑怎么工作，它关心的是大脑外面的手脚怎么打包。

所以未来可能的结构是

用 LangGraph 写一个工作流；
把其中可复用的能力拆成 Agent Skills，写成 SKILL.md；
如果需要用外部工具，给这个能力配一个 MCP server；
最后用 Agent Plugins 目录把它们包在一起，发布到某个仓库或者插件市场。

对 Spring 开发者来说，这件事等于说我们可以把一个 Spring Boot 应用同时暴露成 REST API 和 MCP server，然后把它作为 Agent Plugin 的一部分分发。mcp.json 里的 streamable-http 传输方式，天然适合已经跑在容器里的服务。

我甚至能想象一种 CI 流程，每次发版时，自动把 skills/、mcp.json、plugin.json 打进一个 tar 包，推到内部 registry，然后各个 IDE 和 Agent 客户端去拉取。这比现在「复制配置文件到各个仓库」的做法干净多了。

08 一个我想象中的 Spring Boot Agent Plugin

光讲规范有点抽象，我试着把脑子里的一个场景落到纸上。

假设我们公司内部有一个「订单查询 Agent」。它本身是一个 Spring Boot 应用，暴露了 /api/orders 和 /api/refunds 两个 REST 接口。以前我要让 Cursor 能调用它，得在 .cursor/mcp.json 里写一套配置；要让 Claude Code 能调用它，又得把同样的东西翻译到 claude.md 里。

如果按 Agent Plugins 的格式来打包，目录可能长这样

order-agent-plugin/
├── plugin.json
├── skills/
│   └── query-orders/
│       └── SKILL.md
└── mcp.json

plugin.json 只需要声明名称。

SKILL.md 里写清楚 skill 的用途、输入输出示例、调用时的注意事项。

mcp.json 则配置一个 streamable-http 服务器，指向已经在容器里跑起来的 Spring Boot 应用。

它可能长这样

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "order-server": {
      "type": "streamable-http",
      "url": "http://localhost:8080/mcp"
    }
  }
}