Agent Plugins v1.0 und die Illusion der Portabilität

Am 24. Juli 2026 erreichte das Ökosystem für agentenbasierte Softwareentwicklung einen scheinbar wegweisenden Meilenstein: die Veröffentlichung der Agent Plugins v1.0.0 Spezifikation durch die Agent Plugins Working Group. Über Coding-Agenten wie GitHub Copilot, Claude Code, OpenAI Codex und Cursor hinweg hatte sich die Erweiterungseinheit bereits zuvor auf eine erkennbare Grundform zubewegt: ein Verzeichnis mit einem Manifest sowie einer Kombination aus Skills (Markdown-Instruktionsdateien, die der Agent bei passenden Aufgaben lädt), Sub-Agenten, Slash-Befehlen, Lifecycle-Hooks und Model Context Protocol (MCP)-Servern zur Bereitstellung von Werkzeugen. Bis Juli 2026 definierte jedoch jeder Anbieter ein eigenes herstellerspezifisches Verzeichnislayout, sodass Entwickler ihre Bundles für jeden Ziel-Client umstrukturieren oder duplizieren mussten.

Das Versprechen von Agent Plugins v1.0.0 klang bestechend einfach: Eine einzige plugin.json-Manifestdatei im Wurzelverzeichnis des Bundles ablegen, feste Pfadkonventionen für die Komponenten einhalten, und jeder standardkonforme Agent kann das Paket ohne Zusatzinstruktionen laden.

Zwei Monate später zeichnet die empirische Vermessung des Open-Source-Ökosystems ein deutlich nüchterneres Bild. In einem groß angelegten Zensus von 68.072 Plugin-Bundles aus 30.655 öffentlichen GitHub-Repositories (AgentPluginZoo, Tezan Sahu, arXiv:2609.23809, September 2026), ergänzt um 157.062 eigenständige Skills und 1.379 eigenständige MCP-Konfigurationen, treten zwei strukturelle Befunde zutage. Erstens ist strikte Schemakonformität im Feld bislang selten (6,2 %), auch wenn die Hürde meist nur oberflächlich ist (96,6 % aller parsbaren Manifeste laden, sobald eine einzige fehlende $schema-Pflichtzeile ergänzt wird). Zweitens – und weitaus schwerwiegender – würde selbst eine hundertprozentige Schemakonformität nicht dazu führen, dass mehrere Plugins verlässlich zusammenarbeiten: Bei 40,2 % der ladbaren Manifeste verwerfen standardkonforme Clients stillschweigend vom Autor geschriebene Top-Level-Felder, 95,6 % mehrfach gepflegter Hersteller-Manifeste driften inhaltlich auseinander, und 81 % aller Bundles, die benannte Fähigkeiten exportieren, kollidieren mit dem Namen eines anderen Plugins.

Die Standardisierung eines einzelnen Paketlayouts ohne ein formales Modell für Multi-Plugin-Komposition und Laufzeitisolation verwandelt Fragmentierung lediglich in paketiertes Chaos.

---

Die Anatomie eines Agent Plugins v1.0.0-Bundles

Um zu verstehen, warum selbst regelkonforme Plugins im Zusammenspiel scheitern, muss man betrachten, was Agent Plugins v1.0.0 tatsächlich standardisiert – und was die Spezifikation bewusst ausklammert. Standardisiert wird ein Paketformat, keine Laufzeit-API und kein Kompositionsmodell. Das Portabilitätsversprechen ruht auf zwei Designentscheidungen:

1. Ein einzelnes, geschlossenes Wurzel-Manifest (plugin.json): Genau eine plugin.json-Datei liegt im Wurzelverzeichnis des Pakets und enthält ausschließlich Identitäts- und Herkunftsmetadaten ($schema, name, version, description, author, license, repository).
2. Konventionsbasierte Komponenten-Erkennung: Ein standardkonformer Client fragt nicht das Manifest, welche Fähigkeiten ein Plugin mitbringt. Stattdessen durchsucht er feste Verzeichnispfade auf der Festplatte, konkret skills/*/SKILL.md für Skills sowie mcp.json (bzw. .mcp.json) für MCP-Tool-Server.

my-plugin/
├── plugin.json               # Geschlossenes Identitäts-Manifest ($schema, name, version, ...)
├── skills/                   # Über Pfadkonvention erkannte Skills
│   └── code-review/
│       └── SKILL.md
├── mcp.json                  # Über Pfadkonvention erkannte MCP-Server-Definitionen
└── com.example.client/       # Reverse-Domain-Verzeichnis für herstellerspezifische Dateien

Ein strikt konformes plugin.json-Manifest nach v1.0.0 sieht wie folgt aus:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "my-plugin",
  "version": "1.0.0",
  "description": "Automatisiertes Architekturkonformitäts- und Sicherheitsreview-Plugin.",
  "author": {
    "name": "Example Maintainer"
  },
  "license": "MIT",
  "extensions": {
    "com.example.client": {
      "customSetting": true
    }
  }
}

Version 1.0.0 standardisiert genau zwei Komponententypen: Skills und MCP-Server. Slash-Befehle (commands), Lifecycle-Hooks (hooks), Sub-Agenten (agents), Regeln und Language-Server wurden als zu client-spezifisch eingestuft und aus dem v1.0.0-Format ausgeklammert. Für herstellerspezifische Erweiterungen erlaubt die Spezifikation zwar ein Top-Level-Verzeichnis in Reverse-Domain-Notation (com.example.client/) sowie ein korrespondierendes extensions-Objekt innerhalb von plugin.json, weist beiden jedoch ausdrücklich keinerlei portable Erkennungs-, Validierungs-, Lade- oder Fehlersemantik zu.

Entscheidend für die in der Praxis beobachteten Fehlermuster sind drei asymmetrische Regeln des zugrundeliegenden JSON-Schemas (Draft 2020-12):

• Das Schema ist geschlossen (additionalProperties: false): Jedes Top-Level-Feld, das nicht explizit im Schema benannt ist, gilt als Schemaverstoß.
• $schema ist neben name ein Pflichtfeld: Fehlt $schema, liegt ein fataler Fehler vor; ein standardkonformer Client muss das Plugin vollständig ablehnen und darf keine seiner Komponenten laden oder ausführen.
• Unbekannte Top-Level-Felder sind nicht-fatal, werden aber stillschweigend verworfen: Enthält ein Manifest ein unbekanntes Top-Level-Feld (etwa skills, commands, hooks oder agents), muss ein konformer Client dieses Feld melden, ignorieren und den Ladevorgang fortsetzen.

---

Was 68.072 Plugins offenbaren: Fünf empirische Fehlermuster

Durch die Überprüfung aller 68.072 Bundles im AgentPluginZoo (aus 30.655 Repositories von 22.901 verschiedenen Eigentümern) gegen das offizielle v1.0.0-Schema und die normativen Laderegeln konnte Sahu (2026) die Probleme des Ökosystems präzise quantifizieren:

AgentPluginZoo Konformitäts- & Kompositionsbilanz (68.072 Bundles)
┌────────────────────────────────────────────────────────────────────────┐
│ Strikte Validierung gegen das v1.0.0 JSON-Schema    4.237   (6,2 %)    │
│ Direkt ladbar durch konformen v1.0.0-Client         4.357   (6,4 %)    │
│ Manifest liegt im portablen Wurzelverzeichnis      13.417  (19,7 %)    │
│ Ladbar nach Ergänzung der fehlenden $schema-Zeile  65.729  (96,6 %)    │
├────────────────────────────────────────────────────────────────────────┤
│ Stiller Feldverlust (Client verwirft Top-Felder)   27.291  (40,2 %*)   │
│ Multi-Manifest-Bundles mit semantischem Drift       3.822  (95,6 %**)  │
│ Bundles mit Namenskollisionen bei Fähigkeiten      25.840  (81,0 %***) │
└────────────────────────────────────────────────────────────────────────┘
 *   Unter den Manifesten, die nach Ergänzung von $schema laden.
 **  In einer Zufallsstichprobe von 3.998 Multi-Manifest-Bundles (aus 9.857 gesamt).
 *** Unter den 31.901 Bundles, die mindestens eine benannte Fähigkeit exportieren.

1. Die $schema-Klippe und der stille Verlust von Autorenfeldern

Auf den ersten Blick wirkt die strikte Schemavalidierung verheerend: Nur 4.237 Bundles (6,2 %) bestehen die Prüfung vollständig, und ein normkonformer Client würde lediglich 6,4 % unverändert laden, während 93,6 % komplett abgewiesen würden. Ergänzt man jedoch in jedem parsbaren Manifest einzig die fehlende $schema-Deklaration, laden 96,6 %. Lediglich 2.343 Bundles (3,4 %) scheitern aus tieferliegenden strukturellen Gründen – zu zwei Dritteln an Namenskonventionen (das Feld name erlaubt nur 1 bis 64 Kleinbuchstaben, Ziffern und Bindestriche).

Das eigentliche Problem zeigt sich erst nach dem Laden dieser 96,6 %: Unter den Manifesten, die nach Ergänzung von $schema laden, besitzen 40,2 % (27.291 Bundles) mindestens ein Top-Level-Feld, das ein konformer Client laut Spezifikation zwingend verwerfen muss. Besonders aufschlussreich: 32 % aller Bundles tragen explizit Felder wie skills, mcpServers, commands, hooks oder agents auf oberster Ebene in plugin.json ein, weil Entwickler in der zentralen Manifestdatei deklarieren wollen, welche Komponenten ihr Plugin bereitstellt. Weitere Autoren ergänzen Felder wie dependencies (Abhängigkeiten zu anderen Plugins) oder userConfig (konfigurierbare Parameter vor der Aktivierung).

Obwohl die Spezifikation für nicht-standardisierte Daten das extensions-Objekt vorsieht, nutzen es nur 1,9 % der Manifeste (über 129 Reverse-Domain-Namensräume hinweg), während 43 % stattdessen ein verbotenes Top-Level-Feld anlegen. Da unbekannte Top-Level-Felder als nicht-fatal gelten, lädt das Plugin scheinbar fehlerfrei, während der Host die vom Autor hinterlegten Komponenten-, Abhängigkeits- und Konfigurationsangaben stillschweigend ignoriert.

2. Die Portabilitätssteuer und der Drift duplizierter Manifeste

Wenn ein herstellerneutrales Format existiert, sollte eine einzige plugin.json im Wurzelverzeichnis des Bundles liegen. Tatsächlich tun dies nur 19,7 % (13.417 Bundles); die übrigen 80,3 % legen ihr Manifest weiterhin in einem herstellerspezifischen Unterordner ab (etwa .claude-plugin/ oder .cursor/). Eine Kontrollberechnung auf dem Teilkorpus von 36.157 Bundles, die ohne herstellerspezifische Pfadsuchen gefunden wurden, bestätigt diesen Befund.

Die Bindung an einzelne Hersteller korreliert massiv mit der Nichtbeachtung des Standards:

• Bundles ohne Herstellerverzeichnis sind zu 23,2 % standardkonform ($n = 10.511$).
• Bundles in genau einem Herstellerverzeichnis (Lock-in-Fall) erreichen nur 2,0 % Konformität ($n = 49.309$).
• Bundles mit zwei oder mehr Herstellerverzeichnissen steigen wieder auf 9,7 % ($n = 8.252$).

Um $k$ verschiedene Coding-Agenten zu unterstützen, zahlen viele Entwickler heute eine Portabilitätssteuer, indem sie $k$ Kopien ihres Manifests in verschiedenen Client-Verzeichnissen pflegen. Im AgentPluginZoo liefern 9.857 Bundles (14,5 %) zwei oder mehr Manifestdateien aus. In einer Zufallsstichprobe von 3.998 dieser Multi-Manifest-Bundles waren 95,6 % der Kopien semantisch nicht mehr identisch, und 7,3 % widersprachen sich sogar beim eigenen Plugin-Namen (name). Je nachdem, welcher Agent das Repository lädt, meldet sich dasselbe Plugin unter anderem Namen oder mit abweichendem Funktionsumfang.

3. Zeitliche Adoption: Wachstum auf niedrigem Niveau

Anhand der Commit-Historie des Spezifikations-Repositories (maßgeblich ist der signierte Commit „Publish Agent Plugins Specification 1.0.0" vom 24. Juli 2026) lässt sich die Konvergenz über die Zeit messen. Teilt man den Korpus nach dem Erstellungsdatum des jeweiligen Repositories, steigt die Konformitätsrate um mehr als das Sechsfache von 3,2 % vor dem 24. Juli 2026 ($n = 55.881$) auf 19,9 % danach ($n = 12.191$). Betrachtet man alle 45.796 Bundles in Repositories mit Commits nach Veröffentlichung des Standards, liegt die Rate bei 9,3 % und erreicht 10,4 % (bzw. 15,5 % mit $schema-Deklaration) unter den 38.331 Bundles, die in den letzten 30 Tagen vor Erhebungsende aktiv bearbeitet wurden.

Die Adoption des Paketformats nimmt also messbar zu – doch knapp neun von zehn aktiv gepflegten Bundles fallen weiterhin durch die strikte Prüfung, und für das Zusammenspiel mehrerer Plugins hat sich nichts bewegt.

4. Die Kollisionskrise bei Fähigkeitsnamen

In der Praxis installieren Nutzer zahlreiche Plugins gleichzeitig, was Host-Runtimes bereits heute an harte Grenzen bringt: Visual Studio Code begrenzt den Agent-Modus hart auf 128 Tools (was schon mit wenigen aktiven MCP-Servern erreicht wird), OpenAI Codex budgetiert die Liste verfügbarer Skills auf 2 % des Kontextfensters und lässt weitere Skills danach kommentarlos weg, und kontrollierte Messungen von Repantis et al. (2026, arXiv:2605.24660) zeigen, dass die Treffsicherheit von Sprachmodellen bei der Werkzeugauswahl mit wachsender Tool-Liste von 93,1 % auf 87,1 % sinkt.

Die Extraktion sämtlicher exportierter Fähigkeiten im AgentPluginZoo (Skills, Sub-Agenten, Commands und Hooks) ergab 409.935 Einträge mit 94.837 unterschiedlichen Skill-Namen:

Kollisionsmetriken im AgentPluginZoo (409.935 exportierte Fähigkeiten)
  • Unterschiedliche Skill-Namen mit Mehrfachbeanspruchung: 28,0 % (von 94.837 Namen)
  • Einzelne Skill-Instanzen mit umkämpftem Namen:          78,0 %
  • Fähigkeiten exportierende Bundles mit ≥1 Kollision:     81,0 % (von 31.901 Bundles)
  • Kollisionsrate über unabhängige Repository-Owner:       74,0 %

Am häufigsten kollidierende Fähigkeitsnamen (nach unabhängigen Repository-Ownern):
  1. code-reviewer          (beansprucht von 300 verschiedenen Repository-Ownern)
  2. systematic-debugging   (beansprucht von 221 verschiedenen Repository-Ownern)

Da sich Entwickler für gängige Aufgaben auf naheliegende Bezeichnungen konzentrieren, tragen 78 % aller einzelnen Skills einen Namen, den auch ein anderes Plugin beansprucht. Über alle Komponententypen hinweg teilen 81 % der 31.901 Fähigkeiten exportierenden Bundles (74 % nach Bereinigung um Organisations-Forks) mindestens einen Namen mit einem fremden Plugin.

Installiert ein Entwickler zwei Plugins, die beide code-reviewer oder systematic-debugging bereitstellen, kennt Agent Plugins v1.0.0 weder Namensräume noch Vorrangregeln. Die Auflösung bleibt dem Zufall des jeweiligen Clients überlassen: Claude Code erzwingt ein herstellerspezifisches Präfix, GitLab Duo dokumentiert als Tie-Break schlicht „das erste Element, auf das der Client beim Durchlaufen stößt", und andere Runtimes überschreiben frühere Registrierungen kommentarlos.

5. Ungekapselte Ausführung und Sicherheitsrisiken

Hinzu kommen gravierende Sicherheitsbefunde auf Komponentenebene, die zeigen, warum ein reines Dateilayout ohne Laufzeit-Sandboxing gefährlich ist:

• Sicherheitslücken in Skills: Liu et al. (2026, arXiv:2601.10338) untersuchten 42.447 Agent-Skills im Feld und wiesen großflächige Prompt-Injection-Vektoren, ungeprüfte Shell-Aufrufe und den Abfluss von Zugangsdaten nach.
• Drift und Wartungsmängel bei MCP-Servern: Hasan et al. (2025, arXiv:2506.13538) dokumentierten verbreitete Sicherheits- und Wartbarkeitsmängel in öffentlichen MCP-Servern, während Kraishan (2026, arXiv:2609.14119) unter dem Titel „Same Name, Different Server" stillen Verhaltens- und Sicherheitsdrift namensgleicher MCP-Server über Versionen und Registries hinweg nachwies.

---

Architektonische Muster für echte Interoperabilität

Wie Sahu (2026) herausarbeitet, hat die Community ein Paketformat standardisiert (prüfbar an einem einzelnen Verzeichnis auf der Festplatte), während reale Multi-Plugin-Installationen ein Kompositionsmodell erfordern (Regeln für das Zusammenspiel mehrerer Plugins untereinander und mit der Host-Runtime). Um echte Portabilität und Ausführungssicherheit zu erreichen, sind vier architektonische Erweiterungen erforderlich, die sich als additives v1.1-Profil mit sauberem Host-Sandboxing verbinden lassen:

Ungebundenes v1.0.0-Laden (Flacher Namensraum & stiller Feldverlust):
┌────────────────────── Agent Host ───────────────────────┐
│  Plugin A (code-reviewer) ──┐                           │
│                             ├──> Traversal-Kollision    │
│  Plugin B (code-reviewer) ──┘    (Gewinner je nach Host)│
│  plugin.json ("dependencies", "hooks") ──> Stillschwei- │
│                                            gend gelöscht│
└─────────────────────────────────────────────────────────┘

v1.1-Kompositionsmodell + Gekapselte Host-Runtime:
┌────────────────────── Agent Host ───────────────────────┐
│  1. Deklarierte Oberfläche & Dependency-Check (Vorab)   │
│  2. Qualifizierter Identity-Router:                     │
│       plugin_a:code-reviewer  vs. plugin_b:code-reviewer│
│  3. Deterministische Vorrang- / Konfliktregel           │
│  4. Container- / Wasm-Sandbox für MCP- & Hook-Prozesse  │
└─────────────────────────────────────────────────────────┘

Muster 1: Qualifizierte Fähigkeits-Identität (plugin:capability)

Keine Fähigkeit darf ausschließlich in einem flachen globalen Namensraum existieren. Jeder Skill, Befehl, Sub-Agent und jedes Tool benötigt eine kanonische qualifizierte Adresse der Form plugin_name:capability_name, während der Kurznamen (code-reviewer) nur als Alias dient, solange keine Mehrdeutigkeit besteht:

from typing import Any, Callable


class QualifiedPluginRegistry:
    """Erzwingt qualifizierte plugin:capability-Identitäten und explizite Konfliktregeln."""

    def __init__(self) -> None:
        self._capabilities: dict[str, Callable[..., Any]] = {}
        self._aliases: dict[str, list[str]] = {}

    def register(
        self,
        plugin_name: str,
        capability_name: str,
        handler: Callable[..., Any],
    ) -> str:
        qualified_id = f"{plugin_name}:{capability_name}"
        if qualified_id in self._capabilities:
            raise ValueError(f"Doppelte Fähigkeit innerhalb desselben Plugins: {qualified_id}")

        self._capabilities[qualified_id] = handler
        self._aliases.setdefault(capability_name, []).append(qualified_id)
        return qualified_id

    def resolve(self, identifier: str) -> Callable[..., Any]:
        # 1. Exakter qualifizierter Aufruf ("sentinel:code-reviewer")
        if identifier in self._capabilities:
            return self._capabilities[identifier]

        # 2. Kurzname ("code-reviewer") mit deterministischer Konfliktprüfung
        matches = self._aliases.get(identifier, [])
        if len(matches) == 1:
            return self._capabilities[matches[0]]
        if len(matches) > 1:
            raise RuntimeError(
                f"Mehrdeutiger Fähigkeitsname '{identifier}' wird von mehreren Plugins "
                f"beansprucht: {matches}. Bitte 'plugin:capability' verwenden."
            )
        raise KeyError(f"Unbekannte Fähigkeit: '{identifier}'")

Muster 2: Deklarierte Fähigkeitsoberfläche und Abhängigkeiten im Manifest

Statt zuzulassen, dass 32 % der Autoren Top-Level-Felder schreiben, die standardkonforme Clients lautlos verwerfen, muss das Manifest-Schema eine optionale deklarierte Fähigkeitsoberfläche sowie Kompositionsbeziehungen (dependencies, conflicts und userConfig) aufnehmen. Nur wenn plugin.json selbst benennt, welche Fähigkeiten das Paket exportiert und welche Abhängigkeiten es voraussetzt, können Registries, CI-Pipelines und Paketmanager Kollisionen und Abhängigkeitsgraphen (deren Auflösung in nicht-trivialen Komponentenmodellen NP-vollständig ist; Abate et al., 2020) bereits vor dem Herunterladen und Entpacken prüfen.

Solange v1.0.0-Clients im Einsatz sind, sollten Entwickler nicht-standardisierte Metadaten konsequent im dafür vorgesehenen extensions-Objekt unter ihrem Reverse-Domain-Namensraum ablegen und etwaige herstellerspezifische Zweitmanifeste automatisiert in der CI-Pipeline aus einer einzigen Quelle generieren, um den 95,6-%-Drift bei Mehrfachmanifesten auszuschließen.

Muster 3: Containerisierte MCP- und Hook-Ausführung mit Fail-Closed-Garantie

Selbst ein konfliktfreies Kompositionsmodell muss schließlich begrenzen, welche Operationen ein Plugin auf dem Host ausführen darf. Statt MCP-Server oder Hook-Skripte als ungeschützte Host-Prozesse mit vollem Dateisystem- und Umgebungsvariablen-Zugriff zu starten, sollten Agent-Runtimes Tool-Server in deklarativen Container- oder WebAssembly-Sandboxes mit expliziten Variablen-Freigaben und strikten Fail-Closed-Regeln für Sicherheits-Hooks kapseln:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "isolated-code-reviewer",
  "version": "1.0.0",
  "description": "Gekapseltes Statikanalyse-Plugin mit explizitem Capability-Scoping.",
  "author": { "name": "Arne Burk" },
  "license": "Apache-2.0",
  "extensions": {
    "io.agentruntime.sandbox": {
      "engine": "oci-container",
      "image": "ghcr.io/org/agent-linter:1.0.0",
      "read_only_rootfs": true,
      "required_env": ["LINTER_TOKEN"],
      "hook_policy": "fail_closed"
    }
  }
}

---

Fazit: Vom Paketformat zum Kompositionsmodell

Die Spezifikation Agent Plugins v1.0.0 hat einen wichtigen ersten Schritt getan, indem sie dem einzelnen Plugin-Bundle ein einheitliches Dateilayout gegeben hat. Doch die empirische Analyse von 68.072 Bundles im AgentPluginZoo zeigt unmissverständlich: Ein Format standardisiert, wie eine einzelne Erweiterung ausgeliefert wird – ein Modell standardisiert, was geschieht, wenn mehrere gleichzeitig laufen.

Um aus portabler Paketierung verlässliche Interoperabilität zu machen, sind beide Seiten gefragt:

1. Für Plugin-Autoren heute: plugin.json immer im Wurzelverzeichnis ablegen und $schema explizit deklarieren (wodurch 93,6 % der heutigen Ladeablehnungen entfallen), Fähigkeitsnamen mit einem Präfix versehen statt generische Namen wie code-reviewer zu vergeben, Zusatzmetadaten im extensions-Objekt unterbringen (damit nicht 40,2 % der Manifeste stillschweigend beschnitten werden) und herstellerspezifische Zweitmanifeste ausschließlich automatisiert generieren.
2. Für Spezifikation und Host-Runtimes: Weiterentwicklung von v1.1 zu einem echten Kompositionsmodell mit qualifizierten plugin:capability-Identitäten, einer im Manifest deklarierten Fähigkeitsoberfläche, deterministischen Vorrang- und Konfliktregeln sowie isolierten Sandbox-Ausführungsgrenzen.