Agent Plugins 1.0: jeden format pakietu dla każdego agenta AI

Czym jest Agent Plugins? Agent Plugins 1.0 to otwarty, niezależny od dostawcy standard pakowania — opublikowany 6 sierpnia 2026 roku — który łączy Agent Skills oraz konfiguracje serwerów MCP w przenośny katalog możliwy do wczytania przez dowolnego zgodnego klienta agenta. Plugin to folder z wymaganym manifestem plugin.json, opcjonalnym folderem skills/ zawierającym Agent Skills oraz opcjonalnym plikiem mcp.json deklarującym serwery MCP. ChatGPT, Codex, Cursor, GitHub Copilot, Kiro i VS Code obsługują go od premiery.¹²

Sześć firm, które konkurują ze sobą każdego dnia, dostarczyło wspólną odpowiedź na problem odczuwany przez każdego użytkownika agentów: rozszerzenie zbudowane dla jednego klienta agenta nie działa w kolejnym. Vercel zainicjował propozycję i opracował specyfikację wspólnie z Amazon, Anysphere (twórcą Cursora), GitHub, Microsoft i OpenAI;² tego samego dnia Google ogłosiło, że dołącza do grona głównych opiekunów i wbudowuje obsługę we własne produkty.⁶ Jednozdaniowe podsumowanie z oficjalnej strony: „przenośny format pakietu dla komponentów wielokrotnego użytku, które rozszerzają agentów AI”.¹

Nazwa firmy, która stworzyła obie pakowane warstwy, nie figuruje na liście opiekunów. Ta nieobecność to połowa całej historii — i druga połowa tego artykułu.

TL;DR: Agent Plugins 1.0 standaryzuje warstwę pakowania wokół dwóch istniejących specyfikacji — Agent Skills oraz Model Context Protocol — i nie zastępuje żadnej z nich: ustala jedynie, gdzie obie znajdują się wewnątrz katalogu nadającego się do udostępniania.¹ Plugin to folder: plugin.json dla tożsamości, skills/ dla umiejętności, mcp.json dla serwerów, a do tego foldery przestrzeni nazw w odwróconej domenie na dodatki właściwe dla konkretnego klienta. Wersja 1 jest celowo minimalnym fundamentem interoperacyjności — specyfikacja nie definiuje przenośnej semantyki instalacji, rejestrów, uprawnień, pochodzenia, sekretów ani OAuth; wszystko to pozostaje po stronie klienta.¹² Codex dostarczył obsługę w wersjach v0.146.0 i v0.147.0.⁴ Anthropic, twórca Agent Skills i MCP, nie znalazł się wśród opiekunów — Claude Code zachowuje własny format pluginów.³⁷⁸

Najważniejsze wnioski

• Dla samodzielnych programistów: warto pisać umiejętności jako standardowe Agent Skills (folder z plikiem SKILL.md) — one już są przenośnym podłożem, a opakowanie ich w plugin to kwestia jednego manifestu. Nie ma potrzeby utrzymywać osobnych kopii dla każdego klienta.
• Dla liderów zespołów: standard obejmuje pakowanie, a nie dystrybucję czy politykę. Rejestr, mechanizm aktualizacji i lista dozwolonych źródeł nadal pozostają decyzjami każdego klienta z osobna — należy to uwzględnić, zanim padnie wewnętrzna obietnica „napisz raz, uruchamiaj wszędzie”.
• Dla inżynierów bezpieczeństwa: wersja 1 nie definiuje warstwy pochodzenia ani uprawnień, nie definiuje też warstwy podpisu — decyzja o zaufaniu przenosi się w całości na przegląd wykonywany w momencie instalacji. Przenośność poszerza zasięg rażenia ataków z użyciem zatrutej umiejętności.

Co zostało wydane

6 sierpnia 2026 roku Vercel opublikował Agent Plugins 1.0.0 — otwartą specyfikację, którą zainicjował i rozwinął wspólnie z Amazon, Anysphere, GitHub, Microsoft i OpenAI.² Normatywna specyfikacja znajduje się w publicznym repozytorium, którego lista opiekunów obejmuje Amazon, Cursor, Microsoft, OpenAI i Vercel,³ a Google ogłosiło w dniu premiery, że dołącza do tej grupy jako główny opiekun, przy czym obsługa trafia już do jego własnych narzędzi agentowych.⁶

Lista klientów dostępnych od pierwszego dnia obejmuje największe powierzchnie ekosystemu: VS Code, Cursor, GitHub Copilot, ChatGPT i Codex oraz Kiro.¹² Obsługa w Codex CLI wyprzedziła publiczne ogłoszenie: wersja v0.146.0 (29 lipca) dodała manifesty Agent Plugins i publikowanie pluginów w obszarze roboczym, a v0.147.0 (7 sierpnia) domknęła całość przenośną instalacją pluginów oraz wyszukiwaniem w katalogach lokalnych, osobistych, roboczych i zdalnych.⁴

Zakres wyraża pierwsze zdanie samej specyfikacji: „definiuje kanoniczną specyfikację Agent Plugins v1.0.0 służącą do pakowania komponentów wielokrotnego użytku rozszerzających agentów AI w pluginy nadające się do dystrybucji”.¹ Pakowanie — nie nowy język umiejętności, nie zamiennik MCP. Oba leżące u podstaw formaty zachowują własne specyfikacje; ten standard ustala jedynie, gdzie znajdują się one w katalogu, który klient potrafi wykryć.

Anatomia pluginu

Plugin to katalog z jednym wymaganym plikiem i trzema opcjonalnymi powierzchniami:¹

my-plugin/
├── plugin.json              # required: identity + metadata
├── skills/                  # optional: Agent Skills
│   └── release-notes/
│       └── SKILL.md         # one immediate subdirectory = one skill
├── mcp.json                 # optional: MCP server configs
└── com.example.client/      # optional: client-namespace directory

plugin.json to manifest o zamkniętym schemacie. Dozwolonych pól najwyższego poziomu jest dokładnie dziesięć: $schema, name, version, description, author, homepage, repository, license, keywords oraz extensions — a wobec wszystkiego innego specyfikacja jest stanowcza: „Klienci MUSZĄ zgłosić i zignorować każde nieznane pole oraz MUSZĄ kontynuować wczytywanie pluginu, jeżeli manifest w pozostałym zakresie spełnia wymagania tej sekcji”.¹ Pole name dopuszcza małe litery i cyfry, myślniki oraz kropki, przy czym pierwszy i ostatni znak musi być alfanumeryczny, a myślniki i kropki nie mogą występować bezpośrednio po sobie.¹

skills/ przechowuje Agent Skills dokładnie w takiej postaci, w jakiej już istnieją: „Każdy bezpośredni katalog podrzędny zawierający ścieżkę o nazwie dokładnie SKILL.md, która wskazuje zwykły plik, jest traktowany jako jedna umiejętność”.¹ mcp.json deklaruje serwery MCP; klient obsługujący serwery MCP z pluginów „MUSI obsługiwać co najmniej jeden z transportów stdio lub streamable-http” i POWINIEN obsługiwać oba, przy czym sse pozostaje opcjonalne — specyfikacja wprost dopuszcza też, by klient obsługujący wyłącznie umiejętności był zgodny, nie obsługując w ogóle serwerów MCP.¹

Katalogi w odwróconej domenie, takie jak com.example.client/, mieszczą zachowania właściwe dla konkretnego klienta, a reguła przenośności została zapisana językiem normatywnym: „Klient MUSI zignorować wpisy manifestu dotyczące przestrzeni nazw, których nie implementuje, bez walidowania zawartości ich wartości”.¹

Ten ostatni mechanizm waży więcej, niż się wydaje. Komponenty najbardziej różniące się między klientami zostały odgrodzone od przenośnego rdzenia: polecenia, hooki, agenci, reguły i serwery LSP to podane w samej specyfikacji przykłady typów komponentów, które „pozostają zbyt specyficzne dla poszczególnych klientów, by dało się dla nich ustalić stabilny przenośny kontrakt”, i znajdują się poza formatem v1, dopóki ich formaty się nie zbiegną.¹ Przenośny rdzeń to umiejętności plus konfiguracje MCP — i nic więcej.

Czego wersja 1 świadomie nie obejmuje

Specyfikacja standaryzuje najmniejszą rzecz, która mogłaby zadziałać. Nie definiuje przenośnej semantyki instalacji, rejestrów, uprawnień, pochodzenia, sekretów ani OAuth — każdy z tych obszarów pozostaje po stronie klienta¹² — nie definiuje również warstwy podpisu. Ścieżka rozwoju przyjęta przez opiekunów jest z założenia zachowawcza: typ komponentu awansuje do przenośnego rdzenia dopiero wtedy, gdy implementacje zbiegną się na tyle, by dało się go precyzyjnie zdefiniować.¹

Należy w tym widzieć fizykę koalicji, a nie nieśmiałość. Sześć firm — z czego pięć dostarcza klientów agentowych o niekompatybilnych formatach pluginów — potrafiło uzgodnić, gdzie leżą pliki; nie potrafiło jeszcze uzgodnić, jak wyzwalają się hooki, jak rejestrują się polecenia ani czyj model uprawnień wygrywa. Standard zamroził więc warstwę, w której zachowania już się zbiegły (umiejętność to folder z plikami markdown, MCP to protokół komunikacyjny), a wszystko sporne odgrodził przestrzeniami nazw. To fundament interoperacyjności, a fundamenty są użyteczne właśnie dlatego, że każdy może na nich stanąć.

Cena tego fundamentu: „zbuduj raz, uruchamiaj wszędzie” odnosi się do pakietu, a nie do doświadczenia. Plugin instaluje się wszędzie; to, co potrafi, wciąż różni się między klientami, a sposób instalacji, aktualizacji i obdarzania zaufaniem zależy wyłącznie od klienta.

Dziura w kształcie Anthropic

Tu zaczyna się dziwna część. Agent Skills — format folderów z instrukcjami, który ten standard pakuje — to dzieło Anthropic, ogłoszone w październiku 2025 roku.⁸ Podobnie Model Context Protocol, który Anthropic udostępnił jako otwarte oprogramowanie w listopadzie 2024 roku.⁷ Obie warstwy leżące pod tym standardem pakowania pochodzą od jedynego dużego dostawcy narzędzi agentowych, którego nazwa nie pojawia się nigdzie na liście opiekunów.³

Claude Code zachowuje własny format pluginów — własny manifest, własne źródła marketplace, własne pakowanie hooków i poleceń — i nic z ogłoszonego 6 sierpnia tego nie zmienia. Pomost prowadzi na razie w jedną stronę: Codex dostarcza źródło marketplace Claude Code (v0.146.0), a jego polecenie /import przenosi do narzędzia Codex ustawienia Claude Code, serwery MCP, pluginy, sesje, polecenia oraz pamięci przypisane do projektu.⁴

W praktyce szew jest węższy, niż sugeruje schemat organizacyjny, a powodem jest podłoże: umiejętność to folder z plikiem SKILL.md — w każdym ekosystemie. Umiejętności pisane dla Claude Code to dokładnie ten sam artefakt, który przenosi Agent Plugin. Nie podróżuje natomiast opakowanie — manifest pluginu Claude Code po jednej stronie, plugin.json po drugiej — oraz komponenty właściwe dla konkretnego klienta (przede wszystkim hooki), które każdy ekosystem trzyma u siebie. Kto dziś utrzymuje umiejętności, ten już pisze warstwę przenośną; rozbieżność dotyczy pakowania, a nie treści.

Czy Anthropic ostatecznie przyjmie ten format, opublikuje odpowiednik, czy pozwoli, by pomost pozostał jednokierunkowy — to otwarte pytanie postawione przez tę premierę. Skład koalicji — wszyscy najwięksi dostawcy klientów agentowych z wyjątkiem jednego — sprawia, że trajektoria tego standardu pakowania zależy mniej od jego zalet technicznych, a bardziej od tego, czy nieobecny autor obu leżących u jego podstaw warstw uzna, że warto stanąć na tym fundamencie.

Pytanie o łańcuch dostaw, którego nikt nie ustandaryzował

Przenośny format pakietu bez warstwy pochodzenia jest zarazem przenośnym formatem ataku. Wersja 1 pozostawia pochodzenie i uprawnienia po stronie klienta i nie definiuje narzędzi do podpisywania ani walidacji,¹ co oznacza, że decyzja o zaufaniu zapada w całości w momencie instalacji — u każdego klienta i u każdego użytkownika z osobna.

W tym miesiącu waży to więcej niż w poprzednim. Najnowsze badania nad atakami na poziomie umiejętności — ElasticBack jest tu najostrzejszym przykładem — pokazują warunkowe backdoory zaszyte w pojedynczym dokumencie umiejętności i opisują umiejętności agentów jako „powstający łańcuch dostaw, w którym jedna zatruta umiejętność może trwale skompromitować każdego agenta, który ją zainstaluje”.⁵ Przenośność to zwielokrotnia: ten sam zatruty plugin instaluje się teraz w sześciu klientach zamiast w jednym, a zakres standardu pozostawia wykrywanie takiemu przeglądowi, jaki przeprowadzi konkretny klient (lub konkretny użytkownik).

Pełniejszy wywód powstał, zanim ten standard zaistniał, w tekście Umiejętności agentów potrzebują menedżerów pakietów: kontekst agenta stał się programowym łańcuchem dostaw, a jego bezpieczna instalacja wymaga maszynerii, którą ekosystemy pakietów zdążyły już zbudować — manifestów, plików blokad, instalacji o ograniczonym zasięgu, bramek przeglądu i wycofywania zmian. Agent Plugins 1.0 dostarcza manifest i na tym poprzestaje; reszta tej listy to dokładnie to, co wersja 1 zostawia klientom. Trzeba sprawdzać to, co się instaluje; format nie zrobi tego za nikogo. (Pokrewna pułapka opisana w tekście Umiejętności, których mój agent nie widział: agenci wczytują opisy umiejętności w ramach sztywnego budżetu kontekstu, a umiejętności dostarczane w pluginach dołączają do tego samego katalogu — przenośność dokłada umiejętności do kolejki, która już teraz po cichu się skraca.)

Co robić dzisiaj

Dla użytkowników Codex: standard jest już na miejscu. codex plugin udostępnia przenośną instalację Agent Plugins, a wyszukiwanie pluginów obejmuje katalogi lokalne, osobiste, robocze i zdalne od wersji v0.147.0.⁴ Zespoły mogą publikować pluginy we własnym obszarze roboczym, zamiast stawiać publiczny marketplace.

Dla użytkowników Claude Code: w formacie pluginów nic się nie zmienia. Warto dalej pisać umiejętności jako standardowe foldery umiejętności — to właśnie jest warstwa przenośna — a opakowanie traktować jako jednorazowe. Kto korzysta również z Codex, ten przeniesie istniejącą konfigurację dzięki źródłu marketplace Claude Code oraz poleceniu /import.⁴

Dla użytkowników VS Code, Cursor, Copilot, ChatGPT lub Kiro: te programy znalazły się na liście premierowej; sposób instalowania pluginów to kwestia interfejsu konkretnego klienta, ponieważ standard świadomie tego nie określa.¹

Dla twórców narzędzi programistycznych: manifest jest na tyle mały, że można go wdrożyć w jedno popołudnie, a repozytorium specyfikacji jest publiczne.³ Ciekawa decyzja nie polega na tym, czy czytać plugin.json — polega na tym, które komponenty odgrodzić we własnej przestrzeni nazw w odwróconej domenie, bo ta granica jest faktyczną deklaracją tego, co uznaje się za przenośne.

Często zadawane pytania

Czy Agent Plugins zastępuje MCP albo Agent Skills?

Nie. Deklarowanym zadaniem specyfikacji jest „pakowanie komponentów wielokrotnego użytku rozszerzających agentów AI w pluginy nadające się do dystrybucji”¹ — umiejętności zachowują format SKILL.md, serwery MCP zachowują swój protokół, a standard ustala jedynie, gdzie obie warstwy znajdują się w katalogu nadającym się do udostępniania.

Czy plugin może dostarczać hooki, polecenia slash albo własnych agentów?

Nie w sposób przenośny i nie w wersji 1. Specyfikacja wymienia polecenia, hooki, agentów, reguły i serwery LSP jako przykłady typów komponentów, które „pozostają zbyt specyficzne dla poszczególnych klientów, by dało się dla nich ustalić stabilny przenośny kontrakt” — pozostają więc poza formatem przenośnym, dopóki ich kształty się nie zbiegną. Klient może je przenosić w katalogu własnej przestrzeni nazw w odwróconej domenie, a klienci MUSZĄ ignorować przestrzenie nazw, których nie implementują.¹ Przenośny rdzeń to umiejętności plus konfiguracje MCP.

Dlaczego Anthropic nie należy do standardu?

Ani specyfikacja, ani koalicja tego nie wyjaśniły. Publicznie wiadomo tyle: lista opiekunów obejmuje Amazon, Cursor, Microsoft, OpenAI i Vercel, a w dniu premiery dołączyło Google,³⁶ podczas gdy Anthropic — twórca zarówno Agent Skills, jak i MCP⁷⁸ — jest nieobecny, a Claude Code zachowuje własny format pluginów. Praktyczny pomost istnieje dziś po stronie Codex: źródło marketplace Claude Code oraz migracja przez /import.⁴

Czy instalowanie pluginów Agent Plugins od podmiotów trzecich jest bezpieczne?

Format nie pomaga w tej ocenie: wersja 1 pozostawia uprawnienia i pochodzenie po stronie klienta i nie definiuje narzędzi do podpisywania ani walidacji.¹ Plugin należy traktować jak każdy inny kod, któremu powierza się własne uprawnienia. Badania nad backdoorami na poziomie umiejętności (ElasticBack) pokazują, że jeden zatruty dokument umiejętności może warunkowo skompromitować każdego agenta, który go zainstaluje, a przenośność zwielokrotnia bazę instalacji.⁵

Źródła