Pluginy agentów AI: Claude, ChatGPT, Codex i Copilot
Temat: AI SDLC
Plugin agenta AI jest paczką rozszerzeń, którą można zainstalować i udostępnić innym użytkownikom. Może zawierać instrukcję działania, połączenie z narzędziem, własnego agenta lub kod uruchamiany w określonym momencie pracy. Nie ma jednak jednego zestawu funkcji wspólnego dla wszystkich produktów. We wrześniu 2026 r. otwarty standard Agent Plugins 1.0 definiuje przenośny rdzeń: manifest plugin.json, umiejętności w skills/ i konfigurację serwerów MCP w mcp.json. Instalacja, uprawnienia, interfejs użytkownika, hooki i dodatkowe typy komponentów nadal zależą od klienta.
Dla zespołu pracującego z agentami kodującymi jest to ważniejsze niż liczba pozycji w katalogu. Dobrze zaprojektowany plugin potrafi przenieść procedurę testowania i dostęp do tych samych narzędzi między agentami. Źle zaprojektowany może uruchamiać obcy kod z uprawnieniami programisty lub kierować dane do niekontrolowanej usługi. Ten artykuł dotyczy tworzenia oprogramowania z pomocą AI, jednego z dwóch nurtów AI SDLC.
Plugin, skill, MCP i wtyczka edytora: co jest czym?
| Element | Co wnosi | Kiedy go wybrać? |
|---|---|---|
Skill SKILL.md | Opis powtarzalnej metody pracy, opcjonalnie ze skryptami i materiałami | Agent ma już narzędzia, ale potrzebuje procedury, np. przeglądu migracji. |
| Serwer MCP | Zewnętrzne funkcje i dane udostępniane agentowi | Agent musi odczytać issue, schemat bazy lub wynik testu z innego systemu. |
| Plugin agenta | Jedną instalowalną paczkę zawierającą kilka komponentów | Zespół chce rozprowadzać i wersjonować wspólny zestaw umiejętności oraz integracji. |
| Hook | Kod wykonywany przy zdarzeniu, np. przed użyciem narzędzia | Potrzebna jest kontrola techniczna, której sam opis tekstowy nie wymusi. |
| Rozszerzenie IDE | Funkcje samego edytora, np. panel lub podświetlanie | Potrzebna jest zmiana interfejsu edytora, a nie zachowania agenta. |
Sam plugin nie jest modelem językowym. Nie zastępuje też instrukcji repozytorium AGENTS.md: te opisują lokalne zasady projektu, a plugin dostarcza zdolności, które można powtórnie wykorzystać. MCP określa sposób udostępniania narzędzi; nie nadaje agentowi automatycznie prawa do każdej operacji. Specyfikacja Agent Plugins ujednolica opakowanie umiejętności i MCP, lecz nie gwarantuje identycznego działania całej paczki w każdym kliencie.
Claude: jeden plugin, kilka powierzchni pracy
Claude pozwala odkrywać pluginy jako pakiety umiejętności, połączeń i wyspecjalizowanych agentów. W Claude Code plugin może obejmować również komendy i hooki. To użyteczne, gdy zespół chce połączyć np. zasady przeglądu Pull Requesta, narzędzie do odczytu zgłoszeń i agenta do sprawdzenia testów w jedną instalację. Dostępność komponentów różni się między zwykłym czatem, Cowork i Claude Code: nie należy zakładać, że hook działający przy kodowaniu zadziała w rozmowie webowej. Dokumentacja Claude opisuje te granice.
Własny plugin Claude jest dobrym wyborem, gdy organizacja przyjęła Claude jako główne środowisko pracy i chce korzystać z jego funkcji specyficznych dla produktu. Gdy ten sam proces ma działać także w innych agentach, warto trzymać wspólną procedurę jako SKILL.md, a połączenie z systemem jako MCP. Część kliencką, np. hook Claude Code, utrzymywać osobno i testować w Claude. Sama obecność pluginu w katalogu nie dowodzi, że otrzyma on właściwy zakres uprawnień lub że kod nie opuści organizacji.
ChatGPT i Codex: wspólna paczka, odmienne środowiska wykonania
W aktualnej architekturze OpenAI plugin jest paczką odkrywaną, instalowaną i udostępnianą w ChatGPT i Codex. Może zawierać skille, serwer MCP lub oba elementy; integracja może też udostępniać interfejs użytkownika. Instrukcja pakowania opisuje manifest plugin.json i pliki paczki. To inna architektura niż historyczne „ChatGPT Plugins” z początkowego okresu rozwoju ChatGPT — przy czytaniu starszych poradników trzeba sprawdzić datę i format.
W Codex dodatkowe mechanizmy środowiska kodującego, takie jak hooki i uprawnienia wykonania, wymagają osobnego sprawdzenia. Skill może podpowiedzieć, jak przygotować test regresyjny; MCP może umożliwić odczyt issue; hook może technicznie zatrzymać niepożądane polecenie, jeśli dany klient go obsługuje. Ten sam pakiet nie oznacza tej samej możliwości uruchamiania kodu w czacie i w lokalnym checkoutcie. W firmie trzeba osobno ocenić, gdzie wykonuje się narzędzie, gdzie trafia kontekst modelu i jakie dane pobiera integracja.
Pozostali agenci kodujący: mapa rozszerzeń
| Narzędzie | Potwierdzony mechanizm | Co sprawdzić przed przeniesieniem pluginu? |
|---|---|---|
| GitHub Copilot | Pluginy z umiejętnościami, agentami, hookami i konfiguracją MCP; obsługa Agent Plugins 1.0 | Które komponenty są przenośne, a które mieszczą się w przestrzeni com.github.copilot. |
| Visual Studio Code | Agent Plugins w interfejsie agenta; osobno klasyczne rozszerzenia VS Code | Czy chodzi o zachowanie agenta, czy o funkcję edytora; czy hook lub MCP uruchamia lokalny kod. |
| Visual Studio | Integracje Copilota z serwerami MCP | Nie utożsamiać obsługi MCP z pełną obsługą paczki Agent Plugins w tym samym formacie. |
| Cursor | Agent Plugins 1.0 oraz własne Cursor Plugins z regułami, agentami, komendami i hookami | Cursor ma własne zachowanie dla zmiennych katalogu pluginu w mcp.json; sprawdzić ścieżki i uruchomienie. |
| Amazon Kiro | Powers zgodne z Agent Plugins, z SKILL.md i opcjonalnym mcp.json | Czy dana zdolność jest przenośnym skillem/MCP, czy funkcją specyficzną dla Kiro. |
| OpenCode | Lokalne lub npm-owe pluginy JavaScript/TypeScript oparte na zdarzeniach; osobno skille, MCP i własne narzędzia | Własny moduł OpenCode wymaga kodu i przeglądu zależności; nie jest automatycznie paczką Agent Plugins. |
| Hermes Agent | Natywne pluginy z narzędziami, hookami i skillami; obsługa przenośnych paczek opisana w przewodniku | Rozróżnić wykonywalny plugin Hermes od skilla i serwera MCP. |
| DeepSeek Harness | Kompozycja pluginów oparta na Cordis | Własne API i cykl życia pluginu wymagają adaptera; sama zgodność nazw komponentów nie daje przenośności. |
| OpenClaw | Natywne pluginy oraz kompatybilne paczki z innych ekosystemów | Kompatybilność jest selektywna: sprawdzić listę faktycznie mapowanych komponentów. |
| NemoClaw | Pluginy OpenClaw instalowane wewnątrz sandboxu NemoClaw | Politykę dostępu do sieci i możliwość instalacji zależności w sandboxie. |
| Google Antigravity | Agent Skills, MCP i instalacja pluginów według otwartego formatu | Zgodność konkretnego komponentu w aktualnej wersji narzędzia. |
| Grok Build | Skille, pluginy, hooki i MCP w agencie terminalowym | Dokumentację wybranego pluginu oraz rozdział między Grok Build a usługą modelową Grok. |
| Grok Bot | Własne skille, rutyny, konektory i pakowane umiejętności w chmurowym środowisku Bota | Nie zakładać zgodności jego biblioteki skilli i marketplace z pluginem terminalowego Grok Build. |
To mapa sposobów rozszerzania, a nie ranking agentów. W szczególności plugin w Copilot CLI, rozszerzenie VS Code i integracja MCP w pełnym Visual Studio mogą służyć temu samemu procesowi, lecz mają różne formaty, uprawnienia i miejsca wykonania. Tak samo nie należy nazywać dowolnego skilla „pluginem”: specyfikacja Agent Skills opisuje plik umiejętności, a Agent Plugins — paczkę, która może taki plik zawierać.
Przykład: paczka do obsługi błędu w AI SDLC
Załóżmy, że zespół chce zlecać różnym agentom tę samą pracę: odczytać zgłoszenie, odtworzyć błąd, dodać test regresyjny, poprawić kod i przedstawić diff do review. Przenośny rdzeń paczki może wyglądać tak:
naprawa-bledu/
├── plugin.json
├── skills/
│ └── test-regresyjny/
│ └── SKILL.md
└── mcp.jsonSKILL.md opisuje kolejność pracy i kryteria odbioru. mcp.json wskazuje zatwierdzony serwer do odczytu zgłoszeń, a jeżeli potrzeba — także do ich aktualizacji. Manifest nadaje paczce tożsamość i wersję. Repozytorium nadal zawiera własny AGENTS.md z poleceniami testów i granicami zmiany. Jeżeli firma chce zatrzymać git push bez review albo automatycznie uruchamiać linter po edycji, dodaje kontrolę właściwą dla konkretnego klienta; nie zakłada, że hook jest przenośną częścią standardu.
Taki podział jest korzystny dla suwerennego procesu: źródło instrukcji i konfiguracji można trzymać we własnym repozytorium, przeglądać w Pull Requestach i wersjonować. Suwerenność nie wynika jednak z samego formatu plików. Zależy również od miejsca pracy modelu, pochodzenia serwera MCP, zakresu tokenów dostępu oraz logowania działań. Nawet lokalny plugin może łączyć się z zewnętrznym API.
Jak wybrać i dopuścić plugin do pracy zespołu?
- Zacznij od zadania. Jeśli wystarczy procedura, napisz skill. Jeśli brakuje dostępu do danych, dodaj MCP. Pakuj je w plugin, gdy instalacja i dystrybucja jako jednej jednostki rzeczywiście upraszcza utrzymanie.
- Sprawdź kod i pochodzenie. Ustal autora, repozytorium, licencję, zależności, wykonywane komendy, adresy sieciowe i sposób aktualizacji. Opis w marketplace nie zastępuje przeglądu plików.
- Ogranicz uprawnienia. Rozdziel odczyt od zapisu, test od produkcji i dane publiczne od poufnych. Token do issue nie musi pozwalać na administrowanie repozytorium. Sprawdź, gdzie przechowywane są sekrety.
- Przetestuj dwie granice. Najpierw czy agent prawidłowo używa skilla i narzędzia na zadaniu kontrolnym. Potem czy próba polecenia spoza zakresu zostaje zatrzymana przez uprawnienia lub hook, zamiast tylko przez tekstową prośbę.
- Zapisz macierz zgodności. Dla każdego klienta oznacz osobno: skill, MCP, hook, agent podrzędny, UI i ścieżki do zasobów. Zmieniaj wersję pluginu dopiero po wykonaniu próby w docelowym środowisku.
Najlepszy plugin dla AI SDLC to ten, który daje zespołowi mierzalnie bardziej powtarzalny wynik przy akceptowalnych uprawnieniach i kosztach utrzymania. Liczba zainstalowanych paczek niczego tu nie dowodzi. Pierwszym praktycznym krokiem może być jeden wewnętrzny skill do przygotowania testu regresyjnego, a dopiero po jego sprawdzeniu paczka z zatwierdzonym serwerem MCP. Dalszy kontekst dla tego wyboru dają artykuły o Spec Kit, AGENTS.md i kontroli dostępu agentów.
- Agenci AI
