Agent Plugins 1.0: Ein Paketformat für jeden KI-Agenten

Was sind Agent Plugins? Agent Plugins 1.0 ist ein offener, herstellerneutraler Paketstandard – veröffentlicht am 6. August 2026 –, der Agent Skills und MCP-Serverkonfigurationen in einem portablen Verzeichnis bündelt, das jeder kompatible Agenten-Client laden kann. Ein Plugin ist ein Ordner mit einem verpflichtenden plugin.json-Manifest, einem optionalen skills/-Ordner für Agent Skills und einer optionalen mcp.json, die MCP-Server deklariert. ChatGPT, Codex, Cursor, GitHub Copilot, Kiro und VS Code unterstützen das Format zum Start.¹²

Sechs Unternehmen, die täglich miteinander konkurrieren, haben eine gemeinsame Antwort auf ein Problem geliefert, das jeder Agentennutzer kennt: Die Erweiterung, die Sie für einen Agenten-Client gebaut haben, funktioniert im nächsten nicht. Vercel hat den Vorschlag angestoßen und die Spezifikation gemeinsam mit Amazon, Anysphere (dem Hersteller von Cursor), GitHub, Microsoft und OpenAI entwickelt;² Google kündigte am selben Tag an, in den Kreis der Core-Maintainer einzutreten und die Unterstützung in die eigenen Produkte einzubauen.⁶ Die Zusammenfassung der offiziellen Website in einem Satz: „Ein portables Paketformat für wiederverwendbare Komponenten, die KI-Agenten erweitern.”¹

Der Name des Unternehmens, das beide verpackten Schichten selbst geschaffen hat, steht nicht auf der Maintainer-Liste. Diese Abwesenheit ist die halbe Geschichte – und die zweite Hälfte dieses Beitrags.

Kurz gefasst: Agent Plugins 1.0 standardisiert die Verpackungsschicht um zwei bestehende Spezifikationen herum – Agent Skills und das Model Context Protocol – und ersetzt keine von beiden: Der Standard legt lediglich fest, wo beide innerhalb eines teilbaren Verzeichnisses liegen.¹ Ein Plugin ist ein Ordner: plugin.json für die Identität, skills/ für Skills, mcp.json für Server, dazu Namespace-Ordner in umgekehrter Domainnotation für clientspezifische Zusätze. Version 1 ist bewusst nur eine Interoperabilitätsgrundlage – die Spezifikation definiert keinerlei portable Semantik für Installation, Registries, Berechtigungen, Herkunftsnachweise, Secrets oder OAuth; all das bleibt Sache des jeweiligen Clients.¹² Codex hat die Unterstützung über v0.146.0 und v0.147.0 ausgeliefert.⁴ Anthropic, Urheber von Agent Skills und MCP, gehört nicht zu den Maintainern – Claude Code behält sein eigenes Plugin-Format.³⁷⁸

Die wichtigsten Erkenntnisse

• Einzelentwickler: Schreiben Sie Ihre Skills als gewöhnliche Agent Skills (ein Ordner mit einer SKILL.md), dann sind sie bereits das portable Fundament – bis zum fertigen Plugin fehlt nur ein Manifest. Hören Sie auf, pro Client eine eigene Kopie zu pflegen.
• Teamleitungen: Der Standard deckt die Verpackung ab, nicht die Distribution und nicht die Richtlinien. Registry, Aktualisierungsmechanismus und Freigabeliste bleiben clientspezifische Entscheidungen – kalkulieren Sie diesen Aufwand ein, bevor Sie intern „einmal schreiben, überall ausführen” versprechen.
• Sicherheitsverantwortliche: Version 1 definiert weder eine Herkunfts- noch eine Berechtigungsschicht und ebenso wenig eine Signaturschicht – die Vertrauensentscheidung verlagert sich vollständig in Ihre Prüfung zum Installationszeitpunkt. Portabilität vergrößert den Wirkungsradius vergifteter Skills.

Was ausgeliefert wurde

Am 6. August 2026 veröffentlichte Vercel Agent Plugins 1.0.0 – eine offene Spezifikation, die das Unternehmen angestoßen und gemeinsam mit Amazon, Anysphere, GitHub, Microsoft und OpenAI entwickelt hat.² Die normative Spezifikation liegt in einem öffentlichen Repository, dessen Maintainer-Liste Amazon, Cursor, Microsoft, OpenAI und Vercel umfasst,³ und Google gab am Starttag bekannt, dieser Gruppe als Core-Maintainer beizutreten; die Unterstützung fließt bereits in das eigene Agenten-Tooling ein.⁶

Die Client-Liste zum Start deckt die größten Oberflächen des Ökosystems ab: VS Code, Cursor, GitHub Copilot, ChatGPT und Codex sowie Kiro.¹² Die CLI-Unterstützung von Codex kam der öffentlichen Ankündigung sogar zuvor – v0.146.0 (29. Juli) brachte Agent-Plugins-Manifeste und das Veröffentlichen von Plugins im Workspace, v0.147.0 (7. August) schloss den Kreis mit portabler Plugin-Installation und einer Suche über lokale, persönliche, Workspace- und Remote-Kataloge hinweg.⁴

Den Geltungsbereich benennt die Spezifikation gleich im ersten Satz: Sie „definiert die kanonische Agent Plugins Specification v1.0.0 für das Verpacken wiederverwendbarer Komponenten, die KI-Agenten erweitern, in verteilbare Plugins”.¹ Verpackung also – keine neue Skill-Sprache, kein Ersatz für MCP. Beide zugrunde liegenden Formate behalten ihre eigenen Spezifikationen; dieser Standard legt fest, wo sie innerhalb eines Verzeichnisses liegen, das ein Client finden kann.

Der Aufbau eines Plugins

Ein Plugin ist ein Verzeichnis mit einer Pflichtdatei und drei optionalen Bestandteilen:¹

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 ist ein Manifest mit geschlossenem Schema. Zulässig sind auf oberster Ebene exakt zehn Felder: $schema, name, version, description, author, homepage, repository, license, keywords und extensions – und bei allem anderen wird die Spezifikation deutlich: „Clients MÜSSEN jedes unbekannte Feld melden und ignorieren und MÜSSEN das Plugin weiterhin laden, sofern das Manifest im Übrigen diesen Abschnitt erfüllt.”¹ Das Feld name erlaubt alphanumerische Kleinbuchstaben, Bindestriche und Punkte, wobei erstes und letztes Zeichen alphanumerisch sein müssen und weder Bindestriche noch Punkte aufeinanderfolgen dürfen.¹

skills/ nimmt Agent Skills genau so auf, wie es sie ohnehin gibt: „Jedes unmittelbare Unterverzeichnis, das einen Pfad mit dem exakten Namen SKILL.md enthält, der auf eine reguläre Datei verweist, gilt als ein Skill.”¹ Die mcp.json deklariert MCP-Server; ein Client, der Plugin-MCP-Server unterstützt, „MUSS mindestens stdio oder streamable-http unterstützen” und SOLLTE beides beherrschen, sse bleibt optional – und ausdrücklich erlaubt die Spezifikation einem Client, der nur Skills kennt, konform zu sein, ohne MCP-Server überhaupt zu unterstützen.¹

Verzeichnisse in umgekehrter Domainnotation wie com.example.client/ nehmen clientspezifisches Verhalten auf; die Portabilitätsregel steht in normativer Sprache da: „Ein Client MUSS Manifesteinträge für Namespaces, die er nicht implementiert, ignorieren, ohne den Inhalt ihrer Werte zu validieren.”¹

Dieser letzte Mechanismus wiegt schwerer, als er aussieht. Ausgerechnet die Komponenten, die sich zwischen Clients am stärksten unterscheiden, sind aus dem portablen Kern ausgesperrt: Commands, Hooks, Agenten, Rules und LSP-Server sind die eigenen Beispiele der Spezifikation für Komponententypen, die „für einen stabilen portablen Vertrag zu clientspezifisch bleiben” und außerhalb des v1-Formats liegen, bis ihre Formate konvergieren.¹ Der portable Kern besteht aus Skills plus MCP-Konfigurationen, mehr nicht.

Was Version 1 bewusst auslässt

Die Spezifikation standardisiert das kleinstmögliche Funktionierende. Sie definiert keine portable Semantik für Installation, Registries, Berechtigungen, Herkunftsnachweise, Secrets oder OAuth – all das bleibt clientverwaltet¹² – und ebenso wenig eine Signaturschicht. Der Erweiterungspfad der Maintainer ist bewusst konservativ: Komponententypen rücken erst dann in den portablen Kern auf, wenn die Implementierungen weit genug konvergiert sind, um sie präzise zu definieren.¹

Lesen Sie das als Physik einer Koalition, nicht als Zaghaftigkeit. Sechs Unternehmen – fünf davon liefern Agenten-Clients mit zueinander inkompatiblen Plugin-Formaten aus – konnten sich darauf einigen, wo Dateien liegen; worauf sie sich bislang nicht einigen konnten, ist, wie Hooks ausgelöst werden, wie Commands sich registrieren und wessen Berechtigungsmodell gewinnt. Also fror der Standard die Schicht ein, in der das Verhalten bereits konvergiert war (Skills sind Markdown-Ordner, MCP ist ein Wire-Protokoll), und schob alles Umstrittene in Namespaces ab. Es ist eine Interoperabilitätsgrundlage – und Grundlagen sind gerade deshalb nützlich, weil alle darauf stehen können.

Der Preis dieser Grundlage: „einmal bauen, überall ausführen” gilt für das Paket, nicht für das Erlebnis. Ein Plugin lässt sich überall installieren; was es leisten kann, variiert weiterhin je nach Client, und wie es installiert, aktualisiert und als vertrauenswürdig eingestuft wird, liegt vollständig beim Client.

Die Lücke in Anthropic-Form

Hier wird es merkwürdig. Agent Skills – jenes Format aus Anweisungsordnern, das der Standard verpackt – stammt von Anthropic und wurde im Oktober 2025 vorgestellt.⁸ Gleiches gilt für das Model Context Protocol, das Anthropic im November 2024 als Open Source veröffentlichte.⁷ Beide Schichten unter diesem Paketstandard kommen also von genau dem großen Agenten-Toolanbieter, dessen Name in der Maintainer-Liste nirgends auftaucht.³

Claude Code behält sein eigenes Plugin-Format – eigenes Manifest, eigene Marketplace-Quellen, eigene Verpackung von Hooks und Commands – und daran ändert nichts, was am 6. August angekündigt wurde. Die Brücke verläuft vorerst in eine Richtung: Codex liefert eine Claude-Code-Marketplace-Quelle mit (v0.146.0), und sein Befehl /import überführt Claude-Code-Einstellungen, MCP-Server, Plugins, Sitzungen, Commands und projektbezogene Memories nach Codex.⁴

Praktisch ist die Naht schmaler, als das Organigramm vermuten lässt, und der Grund liegt im Substrat: Ein Skill ist in jedem Ökosystem ein Ordner mit einer SKILL.md. Skills, die Sie für Claude Code schreiben, sind dasselbe Artefakt, das ein Agent Plugin transportiert. Was nicht mitreist, ist die Hülle – auf der einen Seite das Plugin-Manifest von Claude Code, auf der anderen plugin.json – sowie die clientspezifischen Komponenten (allen voran Hooks), die jedes Ökosystem nativ behält. Wer heute Skills pflegt, schreibt bereits die portable Schicht; die Divergenz steckt in der Verpackung, nicht im Inhalt.

Ob Anthropic das Format irgendwann übernimmt, ein Äquivalent veröffentlicht oder die Brücke einseitig bleiben lässt, ist die offene Frage, die dieser Start aufwirft. Die Zusammensetzung der Koalition – jeder große Anbieter von Agenten-Clients bis auf einen – macht die Entwicklung des Paketstandards weniger von seinen technischen Vorzügen abhängig als davon, ob der abwesende Urheber seiner beiden Basisschichten die Grundlage für tragfähig hält.

Die Lieferkettenfrage, die niemand standardisiert hat

Ein portables Paketformat ohne Herkunftsschicht ist zugleich ein portables Angriffsformat. Version 1 überlässt Herkunft und Berechtigungen dem Client und definiert kein Signatur- oder Validierungswerkzeug,¹ womit die Vertrauensentscheidung vollständig zum Installationszeitpunkt liegt, pro Client und pro Nutzer.

Das wiegt in diesem Monat schwerer als im letzten. Aktuelle Forschung zu Angriffen auf Skill-Ebene – ElasticBack ist das schärfste Beispiel – demonstriert bedingte Backdoors, die in einem einzigen Skill-Dokument versteckt sind, und beschreibt Agent Skills als „eine entstehende Lieferkette, in der ein einziger vergifteter Skill jeden Agenten, der ihn installiert, dauerhaft kompromittieren kann”.⁵ Portabilität vervielfacht das: Dasselbe vergiftete Plugin landet nun in sechs Clients statt in einem, und der Geltungsbereich des Standards überlässt die Erkennung derjenigen Prüfung, die jeder Client (oder jeder Nutzer) eben durchführt.

Das ausführlichere Argument habe ich formuliert, bevor es diesen Standard gab, nämlich in Agent Skills brauchen Paketmanager: Agentenkontext ist längst eine Software-Lieferkette, und ihn sicher zu installieren erfordert genau die Maschinerie, die Paketökosysteme bereits aufzubauen gelernt haben – Manifeste, Lockfiles, gescopte Installationen, Prüfschritte, Rollback. Agent Plugins 1.0 liefert das Manifest und hört dort auf; der Rest dieser Liste ist exakt das, was v1 den Clients überlässt. Prüfen Sie, was Sie installieren; das Format nimmt Ihnen das nicht ab. (Ein angrenzender Stolperstein aus Skills, die mein Agent nicht sehen konnte: Agenten laden Skill-Beschreibungen unter einem harten Kontextbudget, und per Plugin gelieferte Skills reihen sich in denselben Katalog ein – Portabilität füllt eine Warteschlange auf, die ohnehin still abgeschnitten wird.)

Was heute zu tun ist

Wenn Sie Codex nutzen: Sie haben den Standard bereits. codex plugin bringt die portable Installation von Agent Plugins, und die Plugin-Suche erstreckt sich seit v0.147.0 über lokale, persönliche, Workspace- und Remote-Kataloge.⁴ Teams können Plugins im eigenen Workspace veröffentlichen, statt einen öffentlichen Marketplace aufzubauen.

Wenn Sie Claude Code nutzen: An Ihrem Plugin-Format ändert sich nichts. Schreiben Sie Skills weiterhin als gewöhnliche Skill-Ordner – das ist die portable Schicht – und betrachten Sie die Hülle als Wegwerfware. Wenn Sie zusätzlich Codex einsetzen, tragen dessen Claude-Code-Marketplace-Quelle und /import Ihr bestehendes Setup hinüber.⁴

Wenn Sie VS Code, Cursor, Copilot, ChatGPT oder Kiro nutzen: Sie stehen auf der Startliste der Clients; wie Plugins installiert werden, ist die Sache Ihres Clients, denn der Standard schreibt es bewusst nicht vor.¹

Wenn Sie Entwicklerwerkzeuge bauen: Das Manifest ist klein genug, um es an einem Nachmittag zu übernehmen, und das Repository der Spezifikation ist öffentlich.³ Die interessante Entscheidung ist nicht, ob Sie plugin.json lesen – sondern welche Ihrer Komponenten Sie in Ihren eigenen Namespace in umgekehrter Domainnotation abschieben, denn diese Grenze ist faktisch Ihre Erklärung darüber, was Sie für portabel halten.

Häufige Fragen

Ersetzen Agent Plugins MCP oder Agent Skills?

Nein. Die erklärte Aufgabe der Spezifikation lautet „das Verpacken wiederverwendbarer Komponenten, die KI-Agenten erweitern, in verteilbare Plugins”¹ – Skills behalten ihr SKILL.md-Format, MCP-Server behalten ihr Protokoll, und der Standard legt fest, wo beide innerhalb eines teilbaren Verzeichnisses liegen.

Kann ein Plugin Hooks, Slash-Commands oder eigene Agenten mitliefern?

Portabel nicht, jedenfalls nicht in v1. Die Spezifikation nennt Commands, Hooks, Agenten, Rules und LSP-Server als Beispiele für Komponententypen, die „für einen stabilen portablen Vertrag zu clientspezifisch bleiben” – sie liegen außerhalb des portablen Formats, bis ihre Gestalt konvergiert. Ein Client darf sie im Verzeichnis seines eigenen Namespace in umgekehrter Domainnotation mitführen, und Clients MÜSSEN Namespaces ignorieren, die sie nicht implementieren.¹ Der portable Kern besteht aus Skills plus MCP-Konfigurationen.

Warum ist Anthropic nicht Teil des Standards?

Weder die Spezifikation noch die Koalition hat sich dazu geäußert. Öffentlich bekannt ist: Die Maintainer-Liste umfasst Amazon, Cursor, Microsoft, OpenAI und Vercel, dazu Google seit dem Start,³⁶ während Anthropic – Urheber sowohl von Agent Skills als auch von MCP⁷⁸ – fehlt und Claude Code sein eigenes Plugin-Format behält. Die praktische Brücke verläuft heute über Codex: dessen Claude-Code-Marketplace-Quelle und die Migration per /import.⁴

Ist es sicher, Agent Plugins von Dritten zu installieren?

Das Format hilft Ihnen bei dieser Entscheidung nicht: Version 1 überlässt Berechtigungen und Herkunft dem Client und definiert kein Signatur- oder Validierungswerkzeug.¹ Behandeln Sie ein Plugin wie jeden anderen Code, dem Sie Ihre Rechte übertragen. Die Forschung zu Backdoors auf Skill-Ebene (ElasticBack) zeigt, dass ein einziges vergiftetes Skill-Dokument jeden Agenten, der es installiert, bedingt kompromittieren kann – und Portabilität vervielfacht die installierte Basis.⁵

Quellen