首页 / 文章 / 船舶代理插件，而非裸露的MCP服务器

船舶代理插件，而非裸露的MCP服务器

将MCP工具与技能、权限及安装元数据打包，以便主机获得实际功能而非未完成的适配器。

2488 词

代理插件，而非独立的MCP服务器

几年来，代理工具的发展路径相当清晰：先将模型与系统连接起来（MCP），再教授正确的使用方法（技能），最后将两者打包为可安装的单元。到2026年中，这种打包方式已不再只是厂商的宣传语，而是成为团队分发功能的方式。

MCP解决了什么问题

MCP回答了“代理可以连接到什么？”这一问题——它定义了工具、主机以及协议边界，使得Cursor、Claude Desktop和自定义运行时能够使用相同的适配器。

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

技能解决了什么问题

技能则回答了“代理应如何完成工作？”这一问题——通过流程、检查清单和示例，为模型提供指导，避免其在每次会话中都重新设计工作流程。

显而易见的下一个缺口

没有配套指南的工具很危险；仅有指南而没有工具则只是空谈。各团队仍习惯将它们分开管理：一个仓库用于服务器相关内容，另一个用于提示词，还有一个维基页面记录安装步骤。而代理插件则消除了这种分隔。

什么是代理插件

它是一种带版本控制的包，其中会声明：

所需的MCP服务器（或等效的工具后端）
正确使用这些工具所需的技能/系统指令
元数据：权限、必需的密钥以及主机兼容性信息
市场平台或命令行工具可自动执行的安装流程

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

为何它不只是“另一种插件系统”

浏览器扩展和IDE插件主要负责添加用户界面，而代理插件则能带来实际功能：凭证权限范围、会产生副作用的工具以及行为规范。这提升了签名审核和最小权限原则的要求。

实际形态

想象一个“支持分级处理”插件：它整合了工单管理MCP服务器、CRM查询工具，以及一种在关闭工单前必须注明工单编号的功能。安装该插件即可同时使用这三项功能，无需分别处理三份手动设置文档。

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

发布与安装

发布过程包括打包元数据及相关文件、签名处理，然后将内容推送到主机信任的注册表中。安装过程应通过一条命令自动解决依赖问题、提示输入敏感信息并完成MCP条目的注册——而非要求用户逐项复制粘贴JSON代码。

可移植性限制

插件并非能在所有主机上自动实现完美兼容。MCP在工具层面提供了帮助，但不同插件的格式与权限界面仍存在差异。设计时应以主要主机为基准，记录现有缺陷，并确保工具遵循原生协议，以便在其他主机上复用核心功能。

生产环境思维模式

应将插件视为具有运行时副作用的库：

固定版本号。
将发现功能与授权功能分开——仅列出插件并不意味着授予生产环境权限。
提供可用于写入数据或花费资金的沙箱工具。
记录包含插件编号和版本号的工具调用日志，以便审计。

发现 ≠ 授权

市场平台仅展示工具的功能特性。只有通过组织策略才能绑定密钥并允许网络访问。这种分离方式能避免“安装即获得生产环境权限”的情况。

MCP与技能的定位

MCP依然是工具间的通信协议，而技能则属于行为层。插件则是同时包含这两者及元数据的分发单元。不要放弃MCP，而应对其进行封装。

不应采取的做法

不要将无限制的命令行工具放入公共插件中。不要将客户机密信息嵌入到插件包中。也不要因为“只是提示语”就省略版本控制。

更大的变革

市场正从工具目录转变为能力市场：提供经过筛选且明确标注风险的工作流。发展时间线为：原始 API → MCP 适配器 → 技能组件 → 带有策略约束的签名插件。