Spiegazione di Agent Plugins 1.0: lo standard portabile per le abilità e i server MCP tra agenti AI

Nome: greet Descrizione: saluta l'utente e offre aiuto. --- Saluta brevemente l'utente e chiede come può aiutare. Se il plugin richiede strumenti, aggiungi: mcp.json in testo semplice richiesto dal plugin

发布于 2026年8月7日generalGEO 评分: 03 次阅读
L'immagine è il materiale promozionale di 'Agent Plugins 1.0 Explained', con sfondo scuro. In alto c'è il logo 'AGENT PLUGINS'. A sinistra ci sono 'AI AGENTS' con ChatGPT, Claude, Gemini, ecc. A destra ci sono 'MCP SERVERS' con opzioni come Files, Database, ecc. Al centro spicca 'AGENT PLUGINS 1.0', con il testo sottostante 'A Portable Standard for Skills and MCP Servers Across AI Agents'. In basso c'è l'etichetta 'Skills (Plugins)' con icone di competenze come Search, Code Runner, Data Analysis, Web Scraper, ecc. L'immagine è in linea con il contenuto di Agent Plugins 1.0 descritto nel documento e ne presenta visivamente il concetto e l'applicazione.

Nome: Saluto
Descrizione: Saluta l'utente e offri assistenza.

Saluta brevemente l'utente e chiedi come puoi aiutare.


### Passaggio 4: Aggiungi MCP solo quando necessario

Se il plugin richiede strumenti, aggiungi:

```Plaintext
mcp.json

Non è necessario configurare un MCP vuoto affinché un plugin sia valido.

La mancanza di componenti opzionali in determinate posizioni non viene considerata un errore.

Passaggio 5: Testa nei client compatibili

Testa il nucleo portabile in ogni client che intendi supportare.

Non dare per scontato che "compatibile con plugin per agenti" significhi che ogni componente e trasporto sia implementato.

I client possono adottare i componenti gradualmente.

Esempio di plugin con server MCP locale

Un pacchetto più utile potrebbe essere strutturato come segue:

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

Manifesto:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "reporting-plugin",
  "version": "1.0.0",
  "description": "Flussi di lavoro e strumenti di reporting portabili."
}

Configurazione MCP:

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

Un client conforme può rilevare:

  • L'identità del plugin
  • La competenza per il report settimanale
  • Il server MCP di reporting

Senza che l'autore debba riorganizzare questi componenti portabili in strutture completamente diverse per ciascun client.

L'isolamento degli errori rende i plugin più resilienti

Una parte ben progettata della specifica è che molti guasti ai componenti sono localizzati, non catastrofici.

Ad esempio:

  • Una competenza non valida può essere saltata mentre le altre continuano a caricarsi.
  • Una voce di server MCP non valida non deve necessariamente disabilitare tutti i server.
  • Una connessione MCP fallita non deve impedire il caricamento di competenze indipendenti.
  • I client possono ignorare tipi di componenti non supportati.

Questo è fondamentale in un vero ecosistema multi-client.

Un plugin può offrire:

Competenza A
Competenza B
Server MCP A
Server MCP B
Estensione client

Se un client non supporta un determinato trasporto, la parte portabile utile dovrebbe comunque funzionare, quando possibile.

In caso contrario, l'interoperabilità diventa fragile: una funzionalità opzionale non supportata disabiliterebbe l'intero plugin.

I client conformi possono adottare lo standard gradualmente

I client non devono implementare ogni funzionalità della v1.

Un client che supporta solo le competenze può comunque essere conforme se carica correttamente il manifesto e implementa i comportamenti delle competenze pertinenti.

Un client che supporta MCP deve soddisfare le regole di trasporto applicabili.

Questo modello incrementale riduce le barriere all'adozione.

I client più piccoli possono iniziare con:

plugin.json
+
skills/

E aggiungere MCP in seguito.

I client più grandi possono implementare il nucleo portabile completo insieme al proprio namespace di estensioni.

Il progetto è governato dalla comunità, non da un singolo fornitore

Il titolo di AIBase descrive l'introduzione dei plugin per agenti da parte di OpenAI.

OpenAI è chiaramente un attore importante.

I documenti ufficiali di governance rendono il modello di proprietà più ampio.

I plugin per agenti si presentano come

un progetto guidato dalla comunità e neutrale rispetto ai fornitori.

Il suo comitato direttivo tecnico è composto da maintainer principali indipendenti, senza seggi aziendali riservati.

Lo statuto stabilisce:

  • Nessun singolo fornitore può controllare la maggioranza dei seggi dei maintainer principali.
  • Le proposte tecniche e le discussioni sono pubbliche.
  • La partecipazione al progetto è aperta secondo regole chiaramente definite.
  • I materiali di specifica e documentazione sono rilasciati con licenza CC BY 4.0.
  • I materiali relativi a schemi, codice e software sono rilasciati con licenza Apache 2.0.

La pagina del progetto elenca attualmente i seguenti maintainer principali iniziali, che rappresentano:

  • Amazon
  • Cursor
  • Microsoft
  • OpenAI
  • Vercel

Questa struttura multi-fornitore è importante perché gli standard di interoperabilità hanno maggiore credibilità quando i client concorrenti hanno un percorso di partecipazione.

Lo standard ha già diversi client compatibili

La pagina ufficiale di compatibilità elenca attualmente:

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

Questo è un punto di partenza più solido rispetto a uno standard supportato solo dal suo creatore.

La matrice di supporto non è ancora completamente uniforme.

Ad esempio, diversi client elencati attualmente supportano SSE tradizionale, mentre ChatGPT con Codex elenca attualmente stdio e Streamable HTTP.

Il risultato importante è che il formato del pacchetto ha già superato i confini tra fornitori.

Gli autori di plugin possono ora puntare a un nucleo condiviso senza dover presumere che ogni ambiente agente sia un ecosistema completamente separato.

Perché questo diventa più importante man mano che gli agenti diventano sistemi a lungo termine

Quando gli agenti svolgono lavoro reale, il problema della frammentazione dei plugin diventa più evidente.

Un semplice chatbot può funzionare con un piccolo elenco fisso di strumenti.

Un agente serio può richiedere:

  • Processi specifici dell'azienda
  • Accesso ai database
  • Automazione del browser
  • Strumenti di distribuzione
  • Controlli di sicurezza
  • Flussi di lavoro documentali
  • Istruzioni di dominio riutilizzabili
  • Script dedicati
  • Più servizi MCP

Man mano che questi componenti si moltiplicano, la portabilità diventa infrastruttura.

Senza un meccanismo di packaging condiviso, ogni azienda rischia di dover gestire una matrice del tipo:

Capacità × Client agente × Versioni × Piattaforme

Un formato di pacchetto portabile riduce una dimensione di questa matrice.

Non elimina il lavoro specifico per singolo client.

Ma può ridurre la duplicazione necessaria per mantenere coerente il nucleo riutilizzabile.

Plugin per agenti, MCP e competenze per agenti risolvono problemi diversi

Questi tre concetti sono correlati ma non devono essere confusi.

Standard Ruolo principale
Competenze per agenti Definiscono risorse riutilizzabili di istruzioni/flussi di lavoro per gli agenti
MCP Definisce la comunicazione tra client AI e server esterni di strumenti/dati
Plugin per agenti Definisce come competenze e configurazioni MCP vengono impacchettate in modo portabile

Un modello mentale utile è:

Competenze
= cosa dovrebbe sapere un agente o come dovrebbe lavorare

MCP
= come un agente si connette a capacità esterne

Plugin per agenti
= come queste parti riutilizzabili vengono impacchettate per adattarsi a client compatibili

Pertanto, i plugin per agenti sono un livello sopra gli standard dei componenti esistenti, non un loro sostituto.

Cosa non risolvono i plugin per agenti

L'ambito dello standard è volutamente ristretto.

Non risolve tutti i problemi di compatibilità tra agenti.

Non standardizza

i modelli

Lo stesso plugin può comportarsi in modo diverso con modelli diversi.

Non unifica le interfacce di autorizzazione

Un client può richiedere conferma prima di eseguire un'azione, mentre un altro utilizza policy a livello di workspace.

Non uniforma l'autenticazione

OAuth e l'archiviazione delle credenziali rimangono gestiti dal client.

Non garantisce il supporto di tutti i trasporti MCP

I client possono implementare sottoinsiemi diversi.

Non uniforma hook o comandi nella v1

Questi rimangono definiti dal singolo client.

Non crea un app store unificato

La distribuzione resta al di fuori dell'ambito della specifica principale.

Non mette in sandbox i processi MCP

L'inclusione del percorso del pacchetto non equivale all'isolamento in runtime.

Non garantisce un comportamento completamente identico

La portabilità significa che i client possono scoprire e caricare componenti in base a un contratto condiviso. Non significa che ogni runtime agente ragionerà o invocherà il componente esattamente allo stesso modo.

Considerazioni di sicurezza per gli autori di plugin

I plugin portabili possono ampliare la distribuzione.

Questo aumenta anche l'importanza di configurazioni sicure di default.

Non incorporare informazioni riservate

Evita di conservare credenziali nelle seguenti posizioni:

plugin.json
intestazione di mcp.json
valori delle variabili d'ambiente in mcp.json
file impacchettati

Utilizza invece l'autenticazione gestita dal client.

Mantieni limitato il percorso del pacchetto

Non fare affidamento sull'uscita dalla directory principale del plugin per accedere a file arbitrari dell'host.

Tratta i server MCP locali come codice eseguibile

I server stdio possono avviare processi.

Gli utenti e gli amministratori aziendali dovrebbero essere consapevoli di ciò che stanno installando.

Riduci al minimo i permessi richiesti

Un plugin che necessita solo di permessi di lettura non dovrebbe richiedere operazioni di scrittura.

Documenta i servizi esterni

I server MCP remoti dovrebbero avere chiare politiche di proprietà, privacy e utilizzo dei dati.

Presta attenzione al versionamento

Anche se la struttura delle directory rimane valida, i cambiamenti nel comportamento del server possono costituire modifiche sostanziali.

Cosa dovrebbero fare ora gli sviluppatori

Passo 1: Distingui le parti portabili dalle specifiche del client

Identifica quali parti del tuo plugin attuale sono realmente riutilizzabili:

Skill
Server MCP
Metadati condivisi

Migra i comportamenti specifici del client negli appositi namespace di estensione.

Passo 2: Aggiungi uno schema con numero di versione

Dichiara esplicitamente Agent Plugins 1.0.0 in plugin.json.

Passo 3: Standardizza la posizione delle skill

Posiziona le skill agente portabili in:

skills/<nome-skill>/SKILL.md

Passo 4: Standardizza la configurazione MCP

Utilizza il file a livello di root:

mcp.json

Invece di fare affidamento solo sui file di configurazione nativi del client.

Passo 5: Rimuovi le informazioni riservate portabili

Migra le credenziali nei sistemi di autenticazione di ciascun client.

Passo 6: Testa il pacchetto su più client

L'interoperabilità deve essere verificata con dimostrazioni pratiche, non data per scontata.

Passo 7: Segui gli aggiornamenti della specifica

Poiché la specifica attuale è ancora contrassegnata come bozza di lavoro, tieni d'occhio i cambiamenti nel repository del progetto, nelle discussioni, nello schema e nelle pagine di compatibilità.

Contenuti confermati e punti da chiarire

Dichiarazione Stato
La specifica Agent Plugins 1.0.0 è stata pubblicata Confermato
La specifica definisce il confezionamento portabile di skill e server MCP Confermato
Il file plugin.json nella root è obbligatorio Confermato
skills/ è la posizione fissa per le skill Confermato
mcp.json nella root è la posizione per la configurazione MCP Confermato
stdio e Streamable HTTP sono i tipi di trasporto MCP standard Confermato
Il vecchio SSE è riconosciuto ma opzionale per i client Confermato
Le estensioni specifiche del client usano namespace con dominio inverso Confermato
Distribuzione, installazione, permessi ed esperienza utente sono standardizzati No; volutamente fuori ambito
Gli hook sono componenti portabili di Agent Plugins v1 No; possono essere estensioni del client
OpenAI possiede o gestisce esclusivamente Agent Plugins No
Il progetto è neutrale rispetto ai fornitori e governato dalla comunità Confermato tramite la governance ufficiale
La versione 1.0.0 è uno standard finale completamente congelato No; la pagina della specifica è attualmente una bozza di lavoro
Ogni client compatibile supporta tutti i componenti e i trasporti MCP No
ChatGPT, Codex, VS Code, Cursor, GitHub Copilot e Kiro sono elencati come compatibili Confermato nella pagina di compatibilità attuale

Domande frequenti

Cos'è Agent Plugins 1.0?

Agent Plugins 1.0 è un formato di pacchetto aperto e neutrale rispetto ai fornitori per estensioni riutilizzabili di agenti AI. Standardizza il modo in cui le Agent Skills e le configurazioni dei server MCP vengono posizionate in una directory di plugin portabile.

Agent Plugins è uno standard esclusivo di OpenAI?

No. OpenAI partecipa al progetto e supporta il formato in ChatGPT e Codex, ma il progetto ufficiale è governato dalla comunità ed è neutrale rispetto ai fornitori. Il suo team iniziale di manutentori principali include persone associate ad Amazon, Cursor, Microsoft, OpenAI e Vercel.

Quali file sono necessari per un Agent Plugin?

Ogni plugin richiede un plugin.json nella directory principale. Le skill possono essere memorizzate in skills/, mentre i server MCP possono essere descritti in mcp.json nella root; le funzionalità specifiche del client possono utilizzare estensioni con namespace.

Agent Plugins sostituirà MCP?

No. MCP definisce ancora il protocollo utilizzato tra client e server MCP. Agent Plugins definisce un modo portabile per confezionare la configurazione dei server MCP e altri componenti agente riutilizzabili.

Gli hook fanno parte di Agent Plugins 1.0?

No, non come componenti portabili di base. La versione 1 standardizza skill e server MCP; gli hook possono essere implementati tramite namespace di estensione specifici del client dove supportati.

Quali client supportano Agent Plugins?

La pagina di compatibilità ufficiale elenca attualmente VS Code, Cursor, GitHub Copilot, ChatGPT e Codex, e Kiro. I trasporti MCP supportati differiscono, quindi gli autori dovrebbero consultare la matrice aggiornata.

Un Agent Plugin si comporterà allo stesso modo in ogni client?

No. Lo standard riguarda il rilevamento dei pacchetti e i componenti portabili, non i modelli, le interfacce dei permessi, i flussi di autenticazione, i marketplace o i comportamenti di runtime specifici del client. I plugin possono essere portabili, ma non produrranno necessariamente lo stesso comportamento di esecuzione.

Agent Plugins 1.0 è considerato definitivo?

1.0.0 è la versione attualmente pubblicata che fornisce lo schema standard. La pagina della specifica contrassegna attualmente lo stato del progetto come "bozza di lavoro", quindi gli sviluppatori dovrebbero continuare a seguire i processi pubblici di governance e versionamento.

Strumenti correlati

  • Agent Plugins: Sito ufficiale di documentazione per i pacchetti portabili Agent Plugins.
  • Agent Skills: Specifica aperta per i componenti di skill riutilizzabili negli Agent Plugins.
  • Model Context Protocol: Protocollo utilizzato dai client e dai server MCP confezionati tramite mcp.json.
  • Plugin ChatGPT: Sistema di plugin attuale di OpenAI per i flussi di lavoro in ChatGPT e Codex.
  • Plugin agente VS Code: Documentazione Microsoft sul caricamento di plugin agente in VS Code.
  • Plugin GitHub Copilot: Documentazione GitHub sui pacchetti di plugin e sul supporto della specifica dei plugin aperti.

Collegamenti correlati

org/compatible-clients): matrice di supporto attuale per VS Code, Cursor, GitHub Copilot, ChatGPT e Codex, e Kiro.

Riepilogo

Agent Plugins 1.0 risolve un problema reale nell'ecosistema crescente degli agenti: gli sviluppatori ripetono la stessa skill e le stesse integrazioni MCP in modi diversi per ciascun client.

La specifica definisce un nucleo portabile e compatto: il file plugin.json obbligatorio, le skill nella directory skills/, la configurazione MCP in mcp.json, regole di impacchettamento, pattern versionati ed estensioni client con namespace. Distribuzione, marketplace, permessi, autenticazione e interfaccia utente restano sotto il controllo del client.

Il progetto elenca il supporto di diversi client principali per agenti, tra cui VS Code, Cursor, GitHub Copilot, ChatGPT e Codex, e Kiro. Questo lo rende più di un semplice formato di plugin specifico di OpenAI, sebbene OpenAI sia uno dei manutentori partecipanti.

La versione 1.0.0 è il contratto attualmente pubblicato, mentre la pagina della specifica la indica ancora come bozza di lavoro. Gli sviluppatori possono adottarla fin da ora, ma dovrebbero seguire i processi pubblici di governance e versionamento.

Il cambiamento principale è semplice: gli sviluppatori non devono più riscrivere le stesse estensioni per agente su ogni piattaforma; possono invece trattare skill e integrazioni MCP come componenti portabili con una struttura di pacchetto unificata.