Agent Plugins 1.0 im Detail: Der portable Standard für Fähigkeiten und MCP-Server über KI-Agenten hinweg

Name: Begrüßung
Beschreibung: Begrüßt den Benutzer und bietet Hilfe an.

Begrüßt den Benutzer kurz und fragt, wie geholfen werden kann.

### Schritt 4: MCP nur bei Bedarf hinzufügen

Wenn das Plugin Werkzeuge benötigt, fügen Sie Folgendes hinzu:

```Plaintext
mcp.json

Ein Plugin muss kein leeres MCP konfigurieren, um gültig zu sein.

Fehlende optionale Komponentenpositionen werden nicht als Fehler betrachtet.

Schritt 5: In kompatiblen Clients testen

Testen Sie den tragbaren Kern in jedem Client, den Sie unterstützen möchten.

Gehen Sie nicht davon aus, dass „Agent-Plugin-kompatibel“ bedeutet, dass jede Komponente und jeder Transport implementiert ist.

Clients können Komponenten schrittweise übernehmen.

Ein nützlicheres Paket könnte wie folgt aussehen:

reporting-plugin/
├── plugin.json
├── skills/
│   └── weekly-report/
│       └── SKILL.md
├── mcp.json
└── bin/
└── reporting-server

Manifest:

{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "reporting-plugin",
"version": "1.0.0",
"description": "Tragbare Berichts-Workflows und Werkzeuge."
}

MCP-Konfiguration:

{
"$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
"mcpServers": {
"reporting": {
"type": "stdio",
"command": "./bin/reporting-server",
"cwd": "${PLUGIN_ROOT}"
}
}
}

Ein konformer Client kann Folgendes erkennen:

• Plugin-Identität
• Wochenberichts-Fähigkeit
• Berichts-MCP-Server

Ohne dass der Autor diese tragbaren Komponenten für jeden Client in völlig unterschiedliche Strukturen platzieren muss.

Fehlerisolierung macht Plugins widerstandsfähiger

Ein durchdachter Teil der Spezifikation ist, dass viele Komponentenfehler lokal und nicht katastrophal sind.

Zum Beispiel:

• Eine ungültige Fähigkeit kann übersprungen werden, während andere Fähigkeiten weiterhin geladen werden.
• Ein ungültiger MCP-Servereintrag muss nicht alle Server deaktivieren.
• Eine fehlgeschlagene MCP-Verbindung sollte das unabhängige Laden von Fähigkeiten nicht blockieren.
• Clients können nicht unterstützte Komponententypen ignorieren.

Dies ist in einem realen Ökosystem mit mehreren Clients entscheidend.

Ein Plugin kann Folgendes bereitstellen:

Fähigkeit A
Fähigkeit B
MCP-Server A
MCP-Server B
Client-Erweiterung

Wenn ein bestimmter Client einen bestimmten Transport nicht unterstützt, sollte der nützliche tragbare Rest, soweit möglich, weiterhin funktionieren.

Andernfalls wird die Interoperabilität fragil: Eine nicht unterstützte optionale Funktion würde das gesamte Plugin deaktivieren.

Konforme Clients können den Standard schrittweise übernehmen

Clients müssen nicht jede Funktion in v1 implementieren.

Ein Client, der nur Fähigkeiten unterstützt, kann dennoch konform sein, wenn er das Manifest korrekt lädt und das relevante Fähigkeitsverhalten implementiert.

Clients, die MCP unterstützen, müssen die geltenden Transportregeln erfüllen.

Dieses inkrementelle Modell senkt die Einstiegshürde.

Kleinere Clients können mit Folgendem beginnen:

plugin.json
+
skills/

und später MCP hinzufügen.

Größere Clients können den vollständigen tragbaren Kern sowie eigene Erweiterungs-Namespaces implementieren.

Das Projekt wird von der Community gesteuert, nicht von einem einzelnen Anbieter

Der Titel von AIBase beschreibt, dass OpenAI Agent-Plugins eingeführt hat.

OpenAI ist offensichtlich ein wichtiger Akteur.

Die offiziellen Governance-Dokumente machen das Eigentumsmodell breiter.

Agent-Plugins bezeichnen sich selbst als

ein von der Community gesteuertes, anbieterneutrales Projekt.

Sein technisches Lenkungsgremium besteht aus unabhängigen Kernbetreuern, nicht aus reservierten Unternehmenssitzen.

Die Satzung legt fest:

• Kein einzelner Anbieter darf die Mehrheit der Kernbetreuersitze kontrollieren.
• Technische Vorschläge und Diskussionen sind öffentlich.
• Die Projektteilnahme ist nach klaren Regeln offen.
• Spezifikations- und Dokumentationsmaterial ist standardmäßig unter CC BY 4.0 lizenziert.
• Schemata, Code und Softwarematerial sind standardmäßig unter Apache 2.0 lizenziert.

Die Projektseite listet derzeit die folgenden anfänglichen Kernbetreuer aus:

• Amazon
• Cursor
• Microsoft
• OpenAI
• Vercel

Diese Multianbieterstruktur ist wichtig, weil Interoperabilitätsstandards glaubwürdiger sind, wenn konkurrierende Clients einen Beteiligungsweg haben.

Der Standard hat bereits mehrere kompatible Clients

Die offizielle Kompatibilitätsseite listet derzeit auf:

• VS Code
• Cursor
• GitHub Copilot
• ChatGPT mit Codex
• Kiro

Das ist ein stärkerer Ausgangspunkt als ein Standard, der nur von seinem ursprünglichen Autor unterstützt wird.

Die Unterstützungsmatrix ist noch nicht vollständig identisch.

Zum Beispiel unterstützen mehrere der aktuell aufgeführten Clients traditionelles SSE, während ChatGPT mit Codex derzeit stdio und Streamable HTTP auflistet.

Das wichtige Ergebnis ist, dass das Paketformat bereits Anbietergrenzen überschreitet.

Plugin-Autoren können jetzt auf einen gemeinsamen Kern abzielen, ohne anzunehmen, dass jede Agentenumgebung ein völlig separates Ökosystem ist.

Warum dies wichtiger wird, wenn Agenten zu langlaufenden Systemen werden

Wenn Agenten tatsächliche Arbeit verrichten, wird die Plugin-Fragmentierung deutlicher.

Ein einfacher Chatbot kann mit einer kleinen festen Werkzeugliste laufen.

Ein ernsthafter Agent könnte benötigen:

• Unternehmensspezifische Prozesse
• Datenbankzugriff
• Browserautomatisierung
• Bereitstellungswerkzeuge
• Sicherheitsprüfungen
• Dokumentations-Workflows
• Wiederverwendbare Domänenanweisungen
• Spezialskripte
• Mehrere MCP-Dienste

Wenn diese Komponenten exponentiell wachsen, wird Portabilität zur Infrastruktur.

Ohne einen gemeinsamen Paketmechanismus riskiert jedes Unternehmen die Pflege einer solchen Matrix:

Fähigkeit × Agent-Client × Version × Plattform

Ein tragbares Paketformat reduziert eine Dimension dieser Matrix.

Es beseitigt nicht die clientspezifische Arbeit.

Aber es kann den Umfang der Duplikationsarbeit reduzieren, die erforderlich ist, um einen wiederverwendbaren Kern konsistent zu halten.

Agent-Plugins, MCP und Agent-Fähigkeiten lösen unterschiedliche Probleme

Diese drei Konzepte sind verwandt, sollten aber nicht vermischt werden.

Ein nützliches mentales Modell ist:

Fähigkeiten
= Was ein Agent wissen oder wie er arbeiten sollte

MCP
= Wie ein Agent sich mit externen Fähigkeiten verbindet

Agent-Plugins
= Wie diese wiederverwendbaren Teile gebündelt werden, um in kompatible Clients zu passen

Agent-Plugins sind also eine Ebene über den bestehenden Komponentenstandards, kein Ersatz für sie.

Was Agent-Plugins nicht lösen

Der Umfang des Standards ist bewusst eng gehalten.

Er löst nicht alle problems der Interoperabilität zwischen Agenten.

Es standardisiert keine

Modelle

Dasselbe Plugin kann sich bei verschiedenen Modellen unterschiedlich verhalten.

Es vereinheitlicht keine Berechtigungsoberflächen

Ein Client verlangt möglicherweise eine Bestätigung vor der Ausführung, während ein anderer eine Richtlinie auf Workspace-Ebene verwendet.

Es vereinheitlicht keine Authentifizierung

OAuth und Anmeldedatenspeicher bleiben in der Verantwortung des Clients.

Es garantiert keine Unterstützung aller MCP-Transporte

Clients können unterschiedliche Teilmengen implementieren.

Es vereinheitlicht in v1 keine Hooks oder Befehle

Diese bleiben vom Client selbst definiert.

Es schafft keinen einheitlichen App-Marktplatz

Die Verteilung bleibt außerhalb des Kernumfangs der Spezifikation.

Es sandboxt keine MCP-Prozesse

Die Aufnahme von Paketpfaden ist keine Laufzeitisolierung.

Es garantiert kein vollständig identisches Verhalten

Portabilität bedeutet, dass Clients Komponenten gemäß einem gemeinsamen Vertrag erkennen und laden können. Es bedeutet nicht, dass jede Agentenlaufzeit auf genau dieselbe Weise über die Komponente nachdenkt oder sie aufruft.

Sicherheitshinweise für Plugin-Autoren

Tragbare Plugins können die Verbreitung erweitern.

Dies erhöht auch die Bedeutung sicherer Standardkonfigurationen.

Vertrauliche Informationen nicht einbetten

Vermeiden Sie es, Anmeldedaten an folgenden Orten zu speichern:

plugin.json
mcp.json Kopfbereich
mcp.json Umgebungsvariablenwerte
Paketdateien

Bitte verwenden Sie die vom Client verwaltete Authentifizierung.

Paketpfade eingeschränkt halten

Verlassen Sie sich nicht darauf, das Plugin-Root-Verzeichnis zu verlassen, um auf beliebige Host-Dateien zuzugreifen.

Lokale MCP-Server als ausführbaren Code betrachten

stdio-Server können Prozesse starten.

Benutzer und Unternehmensadministratoren sollten sich darüber im Klaren sein, was sie installieren.

Erforderliche Berechtigungen minimieren

Plugins, die nur Leserechte benötigen, sollten keine Schreibvorgänge anfordern.

Externe Dienste dokumentieren

Remote-MCP-Server sollten klare Richtlinien für Eigentum, Datenschutz und Datennutzung haben.

Bei Versionsverwaltung vorsichtig sein

Selbst wenn die Verzeichnisstruktur weiterhin gültig ist, können Änderungen am Serververhalten einen Breaking Change darstellen.

Was Entwickler jetzt tun sollten

Schritt 1: Tragbare und client-spezifische Teile unterscheiden

Bestimmen Sie, welche Teile Ihres aktuellen Plugins wirklich wiederverwendbar sind:

Skills
MCP-Server
Gemeinsame Metadaten

Migrieren Sie nur client-spezifisches Verhalten in die entsprechenden erweiterten Namespaces.

Schritt 2: Versioniertes Schema hinzufügen

Deklarieren Sie Agent Plugins 1.0.0 explizit in plugin.json.

Schritt 3: Skill-Platzierung standardisieren

Platzieren Sie tragbare Agent-Skills in:

skills//SKILL.md

Schritt 4: MCP-Konfiguration standardisieren

Verwenden Sie eine Root-Level-Datei:

mcp.json

Statt sich ausschließlich auf native Konfigurationsdateien des Clients zu verlassen.

Schritt 5: Tragbare vertrauliche Informationen entfernen

Migrieren Sie Anmeldedaten in das Authentifizierungssystem jedes Clients.

Schritt 6: Pakete in mehreren Clients testen

Interoperabilität sollte durch tatsächliche Demonstrationen verifiziert werden, nicht durch Annahmen.

Schritt 7: Spezifikations-Updates verfolgen

Da die aktuelle Spezifikation weiterhin als Arbeitsentwurf gekennzeichnet ist, beachten Sie Änderungen im Projekt-Repository, in Diskussionen, Schemata und auf der Kompatibilitätsseite.

Bestätigte Inhalte und Punkte, die weiterer Klärung bedürfen

Häufig gestellte Fragen

Was ist Agent Plugins 1.0?

Agent Plugins 1.0 ist ein offenes, anbieterneutrales Paketformat für wiederverwendbare KI-Agenten-Erweiterungen. Es standardisiert, wie Agent Skills und MCP-Serverkonfigurationen in einem portablen Plugin-Verzeichnis platziert werden.

Ist Agent Plugins ein Standard, der nur für OpenAI gilt?

Nein. OpenAI ist an dem Projekt beteiligt und unterstützt das Format in ChatGPT und Codex, aber das offizielle Projekt wird von der Community verwaltet und ist anbieterneutral. Das anfängliche Kernteam der Maintainer umfasst Personen, die mit Amazon, Cursor, Microsoft, OpenAI und Vercel verbunden sind.

Welche Dateien benötigt ein Agent Plugin?

Jedes Plugin benötigt ein Root-plugin.json. Skills können unter skills/ gespeichert werden, während MCP-Server im Root-mcp.json beschrieben werden können; client-spezifische Funktionen können Namespace-Erweiterungen verwenden.

Ersetzt Agent Plugins MCP?

Nein. MCP definiert weiterhin das Protokoll, das zwischen Clients und MCP-Servern verwendet wird. Agent Plugins definiert eine portable Möglichkeit, MCP-Serverkonfigurationen sowie andere wiederverwendbare Agentenkomponenten zu verpacken.

Sind Hooks Teil von Agent Plugins 1.0?

Nein, nicht als portable Kernkomponente. Version 1 standardisiert Skills und MCP-Server; Hooks können über client-spezifische Erweiterungs-Namespaces implementiert werden, wo dies unterstützt wird.

Welche Clients unterstützen Agent Plugins?

Die offizielle Kompatibilitätsseite listet derzeit VS Code, Cursor, GitHub Copilot, ChatGPT mit Codex sowie Kiro auf. Sie unterstützen unterschiedliche MCP-Transports, daher sollten Autoren die Live-Matrix einsehen.

Verhält sich ein Agent Plugin in jedem Client gleich?

Nein. Der Standard umfasst Paketerkennung und portable Komponenten, nicht Modelle, Berechtigungsoberflächen, Authentifizierungsabläufe, Marktplätze oder client-spezifisches Laufzeitverhalten. Plugins können portabel sein, führen aber nicht unbedingt zu identischem Ausführungsverhalten.

Wird Agent Plugins 1.0 als endgültige Version betrachtet?

1.0.0 ist die aktuell veröffentlichte Version und bietet das Standard-Schema. Die Spezifikationsseite kennzeichnet den Projektstatus derzeit als „Arbeitsentwurf“, daher sollten Entwickler die öffentlichen Governance- und Versionsprozesse weiterhin verfolgen.

Verwandte Tools

• Agent Plugins: Offizielle Dokumentationswebsite für portable Agent-Plugins-Pakete.
• Agent Skills: Offene Spezifikation für wiederverwendbare Skill-Komponenten in Agent-Plugins.
• Model Context Protocol: Protokoll, das von MCP-Clients und -Servern verwendet wird, die über mcp.json gepackt werden.
• ChatGPT-Plugins: Das aktuelle Plugin-System von OpenAI für ChatGPT- und Codex-Workflows.
• VS Code Agent-Plugins: Microsoft-Dokumentation zum Laden von Agent-Plugins in VS Code.
• GitHub Copilot-Plugins: GitHub-Dokumentation zur Unterstützung von Plugin-Paketen und der offenen Plugin-Spezifikation.

Verwandte Links

• Agent-Plugins-Spezifikation 1.0.0: Vollständige normative Anforderungen für das aktuelle portable Format.
• Agent-Plugins erstellen: Offizielles Minimal-Plugin-Tutorial und Paketlayout-Richtlinien.
• [Kompatible Clients](https://agent-plugins.

org/compatible-clients): Die aktuelle Support-Matrix für VS Code, Cursor, GitHub Copilot, ChatGPT und Codex sowie Kiro.

• Agent-Plugins-Spezifikations-Repository: Öffentliche Muster, Governance, Issues, Diskussionen und Spezifikationsquellcode.
• Agent-Plugins-Governance: Gemeinschafts-Governance-Charta und anbieterneutrale Regeln.
• Agent-Plugins-Lizenz: Lizenzbedingungen für Spezifikation, Dokumentation, Muster und Code.
• OpenAI-Plugins in ChatGPT und Codex: Produktbezogene Dokumentation von OpenAI zu Plugins, Apps, Skills und Arbeitsbereichssteuerung.

Zusammenfassung

Agent-Plugins 1.0 löst ein reales Problem im wachsenden Agenten-Ökosystem: Entwickler packen dieselben Skills und MCP-Integrationen für jeden Client auf unterschiedliche Weise immer wieder neu.

Die Spezifikation definiert einen kompakten, portablen Kern – die erforderliche plugin.json, Skills im skills/-Verzeichnis, MCP-Konfiguration in mcp.json, Paketverpackungsregeln, versionierte Schemata sowie Client-Erweiterungen mit Namensraum. Verteilung, Marktplatz, Berechtigungen, Authentifizierung und Benutzeroberfläche bleiben weiterhin in der Hand des Clients.

Das Projekt listet Unterstützung für mehrere führende Agent-Clients auf, darunter VS Code, Cursor, GitHub Copilot, ChatGPT und Codex sowie Kiro. Damit ist es mehr als nur ein OpenAI-spezifisches Plugin-Format, auch wenn OpenAI einer der beteiligten Maintainer ist.

Version 1.0.0 ist der aktuell veröffentlichte Vertrag, während die Spezifikationsseite weiterhin als Entwurf markiert ist. Entwickler können es jetzt bereits übernehmen, sollten jedoch die öffentlichen Governance- und Versionskontrollprozesse im Blick behalten.

Der zentrale Wandel ist einfach: Statt dieselben Agent-Erweiterungen für jede Plattform neu zu schreiben, können Entwickler Skills und MCP-Integrationen als portable Komponenten mit einheitlicher Paketstruktur behandeln.