Vai al contenuto

root / tags / packaging

#packaging

2 fiches

Agenti di codifica IA e Skills Traduzione verificata automaticamente

Agent Plugins package your skills, tools, and more

Annuncio di **Google** del **6 agosto 2026**: Google entra come **Core Maintainer** della specifica **Agent Plugins 1.0.0**, un formato di packaging aperto e *vendor-neutral* per distribuire insieme **Agent Skills** e server **MCP**. ⭐ **Il fatto di governance pesa più del fatto tecnico**: la specifica è stata pubblicata da un **TSC** i cui Core Maintainer provengono da **Amazon, Cursor, Microsoft, OpenAI e Vercel** — Google li raggiunge, rappresentata da **Kevin Hou** (Senior Staff Engineer, Google DeepMind). ⚠️ **Anthropic non compare in questo elenco**, sebbene i due mattoni impacchettati (**Agent Skills** e **MCP**) provengano da Anthropic: il livello di packaging per i due formati di Anthropic viene standardizzato senza che Anthropic sia nominata tra i maintainer. **La diagnosi** è espressa in una frase: *« The core problem isn't the components. It's the manifest. »* Una skill è portabile, un server MCP è portabile; **la scatola in cui vengono messi non lo è**, e ogni client ha dovuto inventarla da sé — da qui i fork, le copie di componenti identici e la loro deriva. **Il formato si riduce a un solo vincolo**: *« A plugin is a directory. That's the whole idea, and the restraint is the point. »* Un `plugin.json` con **due righe utili** (`$schema` + `name`), skill in `skills/` nel formato della specifica Agent Skills, server dichiarati in `mcp.json` **con un `type` esplicito su ciascuna voce** (stdio, Streamable HTTP, o il legacy HTTP+SSE) — niente più trasporto dedotto dalla forma dell'oggetto di configurazione. ⭐ **La forza della progettazione sta in ciò che il manifest non può fare**: **non può né spostare i componenti né dichiararli inline**, quindi non esiste un percorso di discovery da configurare né un ordine di precedenza da imparare. Corollario operativo: **i componenti falliscono in modo indipendente** — un server `mcp.json` che non si avvia non trascina con sé le skill del plugin; il client salta la voce, continua e segnala l'errore. **La via di fuga accettata** è la directory **reverse-domain** (`com.example.client/`), uno spazio di estensione appartenente interamente a un client (hook, agent, comandi) che gli altri ignorano: *« the portable core stays small because the non-portable parts have somewhere legitimate to go »*. **Una sezione rara, da segnalare** — ***« Not Every skill should be a Plugin »*** : un solo server MCP per un solo client, `mcp.json` basta; una singola skill non richiede alcun plugin. Il formato è giustificato solo per componenti **che appartengono insieme e devono viaggiare insieme**. ⚠️ **Ciò che la v1 esclude esplicitamente** — ed è il punto da ricordare prima del deployment: **nessun meccanismo di installazione, nessun protocollo di distribuzione, nessun modello di permessi, nessun requisito di sandboxing, nessuna verifica di fiducia o provenienza, nessuna UX** — elencati sotto *future considerations*, non passati sotto silenzio. L'insieme si inserisce in uno **stack a quattro livelli, adottabile in modo indipendente**: **discover** (Agentic Resource Discovery), **describe** (AI Catalog, che registrerebbe il tipo `application/agent-plugins+json`), **package** (Agent Plugins), **execute** (MCP + Agent Skills). Due prodotti Google sono già disponibili: **Agents CLI** (skill per la costruzione, valutazione, deployment, osservabilità e pubblicazione di agent — utilizzabili da Antigravity, Gemini CLI, Claude Code o Cursor) e **Data Agent Kit** (BigQuery, Spanner, Cloud SQL).

#Agent Plugins#Agent Plugins 1.0.0#specifica aperta

Trois signataires · répartis sur trois entités Google — ce qui dit déjà quelque chose de la portée interne de l'annonce :

Architettura e Costruzione Traduzione verificata automaticamente

Amazon, Microsoft, and Google are converging on the same enterprise agent architecture

Analisi di Janakiram MSV (The New Stack, 20 luglio 2026) sulla **convergenza architetturale** delle piattaforme agent enterprise dei tre hyperscaler: in nove mesi, **Amazon Bedrock AgentCore**, **Microsoft Foundry** e **Gemini Enterprise Agent Platform** sono convergenti sugli **stessi sei primitivi** — runtime, memoria, tool gateway, identità, osservabilità, governance — sotto nomi commerciali diversi. Ciò che 18 mesi fa era una collezione frammentata di librerie sta diventando un **livello di piattaforma** a sé stante. La tesi: questa convergenza ripercorre l'**inflessione PaaS 2011-2016**, in cui **Cloud Foundry** ed **Heroku** hanno unificato VM, load balancer, code e secret store attorno a un **contratto applicativo** portabile — salvo che qui **non esiste ancora un contratto equivalente**, e **nessun progetto open source lo ha rivendicato**. Conseguenza: un'impresa non può **spostare un agente da un cloud all'altro** (stato di sessione, tracce e identità finiscono tutti presso un unico fornitore; migrare significa ricostruire tutto). L'autore propone una **mappatura riga per riga** del contratto Cloud Foundry sugli agenti, definisce tre principi di design (impacchettare l'agente come **una singola unità distribuibile**, **collegare** le capacità invece di incorporare i fornitori, integrare il livello **operativo** nell'astrazione), indica ciò che i protocolli aperti (MCP, A2A, OpenTelemetry) lasciano fuori campo — il **ciclo di vita** — e formula tre domande di due diligence: **governance** (fondazione neutrale vs. fornitore), **packaging** (lo stesso artefatto su due cloud senza riscriverlo), **stato** (memoria esportabile). Verdetto: chi finirà per possedere il **control plane degli agenti** definirà *cos'è un agente*.

#Piattaforme agent enterprise#convergenza architetturale#portabilità

Janakiram MSV