(01) Agent 插件的零件统一了,安装包却没有

你给团队攒了一套 Agent 工作流，三样东西：一份项目指令（AGENTS.md），告诉 agent 这个仓库怎么提交、怎么跑测试；一个 code review 的技能（SKILL.md），让它按团队标准审 PR；一个 MCP server，连公司内部的缺陷库。

分享给同事时，你发现这三样东西命运完全不同。项目指令最简单——AGENTS.md 提交到仓库，同事拉下来，agent 自动读，完事。MCP server 也不难——配一下连接，哪家 agent 都能连。

唯独那个 code review 技能，你想把它打包成「插件」让同事一键装，卡住了：Claude Code 的插件是一套目录结构和 manifest，Cursor 是另一套，Codex 又不一样。你写一次技能，想在三个工具都装上，得改三遍包。

零件统一了，安装包却没有。

这是 2026 年中，Agent 生态最真实、也最容易被忽略的现状。

先把话挑明：截至 2026 年 7 月，不存在一个被 Claude Code、Codex、Cursor、OpenCode 共同采用的「完整 Agent 插件规范」。

如果你听说过那个号称要做跨厂商插件标准的 open-plugin-spec（在 Vercel labs 名下），可以去翻翻它的 GitHub——仓库刚经历了一次迁移，热度跟同生态的其他标准完全不在一个量级（MCP 的 servers 仓库近 9 万 star，这个规范连零头都不到） [来源：GitHub API，2026-07-25]。它想做 Agent 圈的 npm，但远没成气候。这一点 S03 会用数据细说。

但这不等于行业没在标准化。恰恰相反——标准化正在轰轰烈烈地发生，只是不在「安装包」这一层，而在它底下的「零件」层。

所以真正的问题不是「Agent 插件标准来了没有」，而是「它统一到哪一层了」。答案是：统一了一半。

先划清边界：什么算「插件零件」

拆开一个插件之前，得先把一件事说清楚，否则后面全乱：不是所有「跨工具标准化的东西」都算插件。

一个 Agent 插件，指的是「能打包、能安装、能分发」的那个单元——它有一份 manifest，能从一个市场装到你的 agent 里。打开这个安装包，里面装的才是「零件」：skills（SKILL.md）、MCP servers、hooks、commands、agents、LSP servers、monitors 等等。这些才是插件内部的组件。

而 agent 生态里还有两类跨工具的标准化，常被混进来讲，但它们不是插件：

• • AGENTS.md：项目指令文件，放项目根目录，agent 启动自动读。它不在任何一家的插件 manifest 里，不进市场，是独立的项目级配置——开头那个场景里，它「提交到仓库就完事」，正是因为它根本不走插件。
• • ACP（Agent Client Protocol）：编辑器（Zed、JetBrains）连接 agent 进程的协议，类比「LSP for AI Coding」。它在编辑器层，也不进插件。

这两样是 agent 生态「更广的标准化」，但和「插件」是两个分发维度。本文聚焦真正的插件——插件里的零件，和把这些零件打包的安装包。

拆开一个插件：零件层 vs 安装包层

划清边界后，插件的结构其实就两层：

裂缝就在这两层之间。零件的格式在收敛（尤其 SKILL.md 和 MCP），但把它们「打包成可安装单元」的那层，各家各干各的。

这也解释了开头那个场景：你分享一套工作流时卡在最后一步，不是因为技能和 MCP 不通用，而是因为「打包」这一步过不去。零件能跨工具流通，安装包不能。

为什么零件能统一，安装包却卡住了

同样是「标准化」，为什么零件层在收敛，安装包层偏偏卡住？

看看那些正在统一的零件，它们有个共同点：都有明确的主导方，而且解决的都是「最小可统一单元」。

MCP 只管一件事——agent 怎么调用一个外部工具。Anthropic 把协议定下来，其他工具照着接就行。SKILL.md 只管描述一个可复用技能，一个 markdown 目录，格式简单到谁都能复刻。它们的共同特征是单一职责、边界清晰、接入成本低——一个主导方把标准定好，其他人照着做几乎没负担，共识自然形成。

但「安装包」这层不是这样。一个插件要做的事太多了：装到哪里、怎么命名空间隔离防止打架、怎么管权限（一个插件能读哪些文件、能不能联网）、怎么版本升级、从哪个市场分发、谁来做安全审核……每一项都和具体工具的架构深度绑定。 Claude Code 的安装机制和 Cursor 不一样，权限模型不一样，背后的市场也不一样。这些不是定一个 manifest 文件格式就能抹平的。

打个比方。USB-C 统一了充电口的「形状」（零件层），但各家手机的「快充协议」和「配件生态」（安装包层）还在各玩各的——你拿一根 USB-C 线能插进任何手机，但未必能快充。Agent 插件卡在同一个位置：零件的接口统一了，打包成「产品」的标准还没出现。

那「Agent 的 npm」什么时候来

很多人在等一个「Agent 的 npm 时刻」——某个统一插件模型横空出世，从此插件一键跨工具安装，生态爆发。

我的判断是：它不会从天而降，也不会一次性到来。

看看 npm 自己的历史就明白。npm 不是一上来就统一了 JavaScript 的包管理。在它之前，JS 库靠各种土办法分发：直接拷贝文件、靠 CDN、用 Bower……直到 npm 提供了「一个够好的 registry + 一个够简单的 manifest（package.json）」，才慢慢把生态收敛过来。

Agent 的 npm 大概率走同样的路：先在某个子问题突破，再慢慢往完整插件模型收敛。 如果让我押注，我会押在「市场 registry + 权限治理」这一块先突破——因为「从哪装」和「装完安不安全」是分发最硬的两个刚需，连那个还没成气候的 open-plugin-spec，也把权限模型、签名验证、企业管控列进了未来待办。

在那一天到来之前，与其干等一个还没影的完整标准，不如先把零件层做厚：把能力沉淀在 SKILL.md、MCP 这些已经统一的标准上。至于最上面「打包安装」那层，先用薄适配器对付着——每个工具留一点差异适配，核心共享。

这样做有个实在的好处：无论上层的标准最终怎么收敛，你的核心能力都不用重写，迁移成本永远最低。这不是理论，是我在多个 agent 之间管插件的真实做法，S04 会展开讲。

结尾

Agent 插件的标准之争，远没到终局。但有一件事已经清楚：零件统一了，安装包没有，而且短期内不会统一。

对从业者来说，认清这个「半统一」的现状，比追某一个还没站稳的标准更重要。接下来三篇，我会把插件零件的标准化光谱拆透（S02）、横评各家安装包层为什么统一不起来（S03）、最后讲我在这个过渡期怎么活下来的（S04）。

关注「言午 AI 进化论」，下篇拆零件。