代理插件的崛起

梯形图转SCL | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

我写这篇文章不是因为我认为每个人都应该停止手头的工作，明天就围绕插件重建他们的架构。插件不是MCP的革命性替代品，行业绝对不需要再一个时髦的术语。我对它们感兴趣有一个更实际的原因：它们正在成为代理能力的分发层。 与其发布一个MCP服务器、一个技能、一组指令和一个解释如何组装一切的README，我们可以越来越多地将这些知识和集成打包成一个可重用的单元——而从本月开始，这个单元背后有了一个开放的、供应商中立的定义。

1、MCP回答了："代理可以连接到什么？"

当Anthropic在2024年11月引入模型上下文协议时，核心问题是碎片化。每个AI应用程序都需要为数据库、SaaS产品、内部系统、文件存储和开发者工具定制集成。MCP给了我们一个AI客户端和外部工具或数据之间的标准接口：代理与MCP客户端对话，客户端与MCP服务器对话，服务器暴露背后的东西——Salesforce、Postgres、Google Drive、内部API。

这是一个真正的改进。你不需要为每个AI应用程序构建新的集成，你可以通过MCP一次暴露一个系统，让每个兼容的客户端使用它。但连接性只是问题的一部分。给代理一个 search_documents 工具并不意味着代理理解何时应该使用它，如何将其与其他工具组合，什么序列是安全的，或者你的组织认为什么是正确的工作流程。MCP告诉代理它可以调用什么。它不教代理应该如何完成工作。

2、技能回答了："代理应该如何执行工作？"

代理技能填补了这个空白。Anthropic在2025年将它们引入为包含指令、脚本和资源的文件夹，代理可以在需要时发现和加载，该格式后来作为跨平台可移植性的开放标准发布。一个技能可以编码你如何运行架构审查，如何调查事件，部署前必须进行哪些检查，或者代理必须遵循哪些内部约定——例如：

skills/
└── architecture-review/
    ├── SKILL.md
    ├── references/
    │   └── architecture-checklist.md
    └── scripts/
        └── validate_diagram.py

skills/
└── architecture-review/
    ├── SKILL.md
    ├── references/
    │   └── architecture-checklist.md
    └── scripts/
        └── validate_diagram.py

现在代理拥有的不仅仅是工具——它拥有程序性知识，这个区别很重要。MCP服务器可能暴露 search_knowledge、get_customer、create_ticket、update_opportunity。一个技能用简单的指令解释，当准备客户研究报告时，代理应该先搜索内部知识，在Salesforce中验证数据，标记冲突信息，引用每个重要声明，在研究期间永远不要写回Salesforce，并使用批准的结构生成报告。工具保持通用。技能描述工作流程。这更接近生产代理实际需要的运作方式。

3、然后下一个问题变得显而易见

想象一下，我想让同事重用我使用的完全相同的代理能力。在实践中，这意味着给他们一个MCP服务器、另一个MCP服务器、三个技能、两个配置文件、一些环境变量、一些代理指令、也许一个钩子、也许一个专门的子代理，以及一个有二十个设置步骤的README。技术上，一切都是可重用的。操作上，它仍然很烦人——这就是插件开始解决的问题。

4、什么是代理插件？

在最简单的层面上，插件是代理能力的包，目前不同的供应商支持不同的插件功能。Anthropic将Claude插件描述为捆绑技能、连接器和子代理的包，Claude Code插件还额外支持客户端特定的机制，如钩子和MCP配置。OpenAI在ChatGPT和Codex中以相同的方式使用插件，作为包含可重用指令和连接应用程序的打包工作流程。

更重要的进展发生在2026年8月6日，当时代理插件1.0规范公开发布：一个由Vercel发起并与Amazon、Anysphere（Cursor的制造商）、Microsoft和OpenAI共同开发的开放、供应商中立的包格式，Google随后作为核心维护者加入。可移植的v1核心故意只包含两种组件类型——代理技能和MCP服务器——所以一个最小的包看起来像这样：

customer-research/
├── plugin.json
├── skills/
│   └── customer-research/
│       ├── SKILL.md
│       └── references/
│           └── report-template.md
└── mcp.json

customer-research/
├── plugin.json
├── skills/
│   └── customer-research/
│       ├── SKILL.md
│       └── references/
│           └── report-template.md
└── mcp.json

清单标识包，skills/ 携带程序性知识，mcp.json 描述能力所需的MCP服务器。任何兼容的客户端都可以从同一目录发现两者。GitHub在8月12日在VS Code、Copilot CLI和Copilot应用程序中发布了支持，到月底ChatGPT、Codex、Cursor和Kiro都在发布客户端的同一列表上。这是一个小想法，但具有重大的架构后果。

5、为什么这比"另一个插件系统"更有趣

我们在软件中有插件已经几十年了——这不是有趣的部分。有趣的是被包装的东西。代理能力越来越多地由两个维度组成：行动的能力和如何行动的知识。在当前的原语中，那就是MCP加技能。MCP提供对工具和数据的访问，技能提供操作知识，插件将两者打包成一个可重用的能力。你不是分发一个MCP服务器、另一个MCP服务器、两个技能和一堆设置指令，而是分发 customer-research-plugin。这个包代表一个实际要完成的工作，而不仅仅是一个集成。

这与我不断回到的一个更广泛模式有关：代理不应该主要基于低级命令如 salesforce.search_accounts 或 postgres.query 进行推理。它们应该基于稳定的操作（能力）进行推理——research_customer、prepare_rfi、investigate_incident——其中每个能力可能内部需要一个技能来处理流程和几个MCP服务器来获取数据，而用户不应该每次都手动组装。插件为我们提供了一个围绕这个的自然打包边界。

顺便说一下，你可以通过我的文章《AI代理应该思考操作，而不是命令》来熟悉操作的概念。

6、一个实际例子

假设我明天需要演示一个内部能力：给顾问一个可以使用内部知识和Salesforce研究客户，然后生成结构化报告的代理。对该需求的传统响应通常比需求本身增长得更大——一个新UI、身份验证、聊天历史、部署、另一个仓库、另一个服务。

但也许这些都不必要。假设公司已经使用代理环境，如Claude、Codex或Copilot。你可以打包一个插件，其技能知道要检查哪些来源、按什么顺序、需要哪些证据、哪些操作是只读的，以及最终报告应该如何结构化，而底层的MCP服务器提供对内部知识、Salesforce和文档存储的访问。安装包，要求代理"研究Acme Corp并准备我们的标准客户报告"，这可以作为第一个可用版本的足够——没有自定义聊天UI、没有专用代理应用程序、没有新的编排服务，除非工作流确实需要。

这就是我最初对MCP感兴趣的原因：当能力足够时，不要构建应用程序。插件只是将这个想法推高了一层。如果你还没读过，那就是我在"停止为每个想法构建AI应用。开始构建MCP服务器。"中探讨的线索。

我仍然相信这个论点。但在使用MCP一段时间后，另一个问题变得明显：原始MCP服务器通常太低级，无法成为最终的分发单元。它给你连接性，而不是围绕它的操作模型。一个暴露 search_expertise、get_project 和 find_case_study 的内部知识MCP服务器完全可重用——但一个预售工作流想要搜索、验证相关性、排序证据并准备面向客户的摘要，而一个RFI工作流想要搜索、将证据映射到特定问题、标记缺失覆盖范围并生成结构化答案。相同的MCP，每次不同的操作知识。这就是为什么将技能与MCP一起打包很有用：MCP成为基础设施，插件成为可分发的能力。

7、你实际上如何发布和安装一个

上面的例子跳过了一个真实问题：一旦我在我的笔记本电脑上构建了 customer-research-plugin，同事如何获得它而不需要重复我所做的一切？

在实践中，你将插件文件夹推送到Git仓库，并在旁边添加一个小市场清单——.claude-plugin/marketplace.json 用于Claude Code，.github/plugin/marketplace.json 用于GitHub Copilot，或其他客户端的等效文件。该文件只列出插件的名称、版本及其 plugin.json 的位置——在同一仓库中，或在单独的仓库中标记到标签。推送，标记发布，仓库本身就是市场；没有单独的托管或Web应用程序需要搭建。

在接收端，你的同事将他们的客户端指向该仓库一次——在Claude Code中使用 claude plugin marketplace add your-org/your-repo，在VS Code或Azure的SRE Agent中使用"添加市场"并输入仓库URL，或Copilot CLI中的等效命令——然后按名称安装插件（例如 claude plugin install customer-research@your-org）。一些客户端还允许你完全跳过市场步骤，直接从Git仓库URL安装一次性插件。无论哪种方式，客户端都会自己拉取技能文件和MCP配置。你的同事永远不会手动复制SKILL.md或手动连接MCP服务器——这个手动步骤正是包所移除的。

8、插件不是神奇地可移植的

这一部分很重要，因为"插件"很容易给人错误的印象——你构建一个Claude插件，现在就可以在Claude、Codex、Copilot和每个未来的代理中安装完全相同的包。这并非自动成立。供应商插件系统仍然具有不同的功能：钩子、自定义代理、UI表面、权限模型、命令和分发机制不会仅仅因为我们称包为插件而立即变得可移植。Anthropic自己的Claude插件格式捆绑技能、连接器和子代理，但它不在8月代理插件1.0规范的发布客户端之列——它仍然使用自己的布局。这是一个有用的现实检查：标准是真实的，但"插件"根据你所在的客户端仍然意味着略有不同的东西。

这正是代理插件1.0有趣的原因。该规范不是假装每个平台都相同，而是定义了一个小的可移植性底线——代理技能加MCP服务器配置——并将其他所有内容留给客户端，包括一个扩展命名空间，供应商可以添加专有功能而不污染可移植核心：

my-plugin/
├── plugin.json          # portable
├── skills/              # portable
├── mcp.json             # portable
└── com.vendor.client/   # vendor-specific extension
    └── hooks/

my-plugin/
├── plugin.json          # portable
├── skills/              # portable
├── mcp.json             # portable
└── com.vendor.client/   # vendor-specific extension
    └── hooks/

这比试图一次标准化每个代理功能要现实得多。

9、我在生产中会使用的模型

我不会让供应商特定的插件本身成为架构的中心。我会保持核心能力——技能加MCP——尽可能可移植，将插件包视为其上的分发层，并让供应商特定的扩展位于需要它们的任何客户端的边缘。这样，如果一个团队使用Claude Code，另一个使用Codex，我们不会从零重新创建能力；我们重用相同的核心，只调整目标客户端所需的内容。这比将整个工作流耦合到一个代理产品更健康的架构，这就是为什么我更愿意定义一次内部能力——比如 architecture-review，有其检查清单和其 mcp.json 指向架构仓库、知识库和安全发现——并让Copilot用户、Claude用户和Codex用户都能访问相同的程序性知识和相同的底层系统，即使只有运行时适配器在底层改变。

10、发现不等于授权

有一个安全原则我会在所有这些中保持非常明确：可发现的、已安装的、已授权的、已启用的和可执行的是五个不同的状态，满足其中一个的能力对其他状态没有任何说明。插件可以被安装，用户可以被授权访问底层系统，同时代理策略仍然禁用特定操作——例如，客户研究代理可能针对技术上允许删除机会的Salesforce连接运行，但仍然永远不被允许这样做。插件简化了分发。它们不能合并治理边界。

这也意味着插件应该受到你对任何其他依赖项的相同审查：谁拥有它，它连接到哪些MCP服务器，它是否执行本地代码，它需要什么权限，哪些技能可以影响行为，以及它是否可以执行写操作。GitHub已经将代理插件治理与企业插件设置和MCP允许列表联系起来，Anthropic明确警告插件可以包含以本地机器权限运行的本地MCP服务器，OpenAI将插件安装与连接应用程序的授权分开。这种分离正是正确的——方便的打包不应暗示隐式信任。

11、这让MCP和技能处于什么位置

MCP作为产品边界变得不那么重要，作为基础设施变得更加重要，我认为这是一件好事。成功的插件生态系统不会替代MCP——它使MCP更有用，因为插件现在可以携带使MCP集成立即可用的指令。你不是安装一个原始的Jira MCP服务器并弄清楚如何处理它，而是安装一个 incident-response 插件，它已经知道如何调查事件、准备事后分析并创建后续工单，连接到Jira、Datadog和你的内部运行手册。用户不是在购买集成。他们是在获取操作能力，这是一个好得多的抽象。

技能反过来保持与以前完全相同的重要性——可以说插件使它们更容易解释。技能不是"另一种类型的工具"；它是关于如何执行工作的知识。MCP说"这是一个部署工具。" 技能说"这是我们公司安全部署的方式。" 插件说"这是完整的部署能力。" 这是我找到的关于三者一起的最简单心智模型。

12、我不会做什么

我不会仅仅因为代理插件存在就重写一个成熟的生产平台，我不会强迫每个工作流都变成插件。我不会将关键业务逻辑移动到供应商特定的清单中，我不会假设安装一个包就能独立解决身份、策略、可观测性或治理——它不能。有一些工作流确实需要持久状态、复杂事件处理、事务保证、丰富UX或严格运行时隔离，插件不会让这些需求消失。有用的问题保持狭窄：这实际上是一个新应用程序，还是一个可以在我们已有的代理环境中运行的能力？如果是后者，将其打包为插件值得考虑。

13、更大的转变：从工具市场到能力市场

多年来，集成市场一直围绕产品组织——Slack、Salesforce、Jira、GitHub——MCP市场大多延续相同的模式：Slack MCP、Salesforce MCP、Jira MCP。有用，但仍然是集成中心的。代理原生市场可以围绕结果组织：调查生产事件、准备客户研究、审查架构、规划发布。每个都可以在内部依赖几个系统，这更接近人类实际委派工作的方式——我不是告诉工程师"使用Jira、Datadog和GitHub"，而是告诉他们调查事件。GitHub最近使MCP服务器、插件、技能和画布在Copilot应用程序的同一自定义界面中可发现，虽然UI本身不是有趣的部分，但下面的信号是：用户越来越不关心某些东西是作为MCP服务器、技能、插件还是工作流实现的。他们关心代理能做什么。这指向一个能力注册表，而不是每个实现原语的单独目录——注册表描述能力、其所有者、其风险级别及其批准状态，并让平台决定如何为Claude、Codex或自定义内部代理实现它，而能力本身在实现演进时保持稳定。

14、一个有用的时间线

我会这样总结演进：MCP在2024年标准化了对工具和数据的访问。代理技能在2025年打包了程序性知识。代理插件在2026年打包了可重用能力用于分发。这些都不应被解读为替代——MCP没有过时，技能没有替代MCP，插件没有替代技能。这些层是组合的：插件可以包含技能，插件可以引用MCP服务器，而这些技能可以教代理如何使用底层的MCP工具。时间线的重点不是替代。它是渐进式组合。

15、最终观点

我写这篇文章不是因为我认为每个人都需要从本周开始构建插件。我写它是因为这个抽象值得理解。我们首先标准化了代理如何连接到系统。然后我们开始标准化如何给它们程序性知识。现在我们正在标准化这些能力如何被打包和分发——如果你像我一样，宁愿不构建另一个AI应用程序，除非应用程序确实必要，那么这个演进是有用的。有时更好的解决方案真的只是MCP加技能加包，让现有的代理运行时做其余部分。重要的部分不是插件这个词——而是代理能力正在变得可组合、可版本化、可分发，并且越来越可移植。这是我在关注的方向，与许多代理炒作不同，这个已经足够具体可以使用了。

原文链接：Stop Shipping Individual MCP Servers. Start Shipping Agent Plugins

汇智网翻译整理，转载请标明出处