Aller au contenu

root / tags / packaging

#packaging

2 fiches

Agent Plugins package your skills, tools, and more

Annonce **Google** du **6 août 2026** : Google rejoint comme **Core Maintainer** la spécification **Agent Plugins 1.0.0**, format d'empaquetage ouvert et *vendor-neutral* pour distribuer ensemble des **Agent Skills** et des **serveurs MCP**. ⭐ **Le fait de gouvernance prime sur le fait technique** : la spécification a été publiée par un **TSC** dont les Core Maintainers viennent d'**Amazon, Cursor, Microsoft, OpenAI et Vercel** — Google s'y ajoute, représenté par **Kevin Hou** (Senior Staff Engineer, Google DeepMind). ⚠️ **Anthropic ne figure pas dans cette liste**, alors que les deux briques empaquetées (**Agent Skills** et **MCP**) sont d'origine Anthropic : la couche d'emballage des deux formats d'Anthropic se normalise sans qu'Anthropic soit nommée parmi les mainteneurs. **Le diagnostic** est posé en une phrase : *« The core problem isn't the components. It's the manifest. »* Une skill est portable, un serveur MCP est portable ; **la boîte dans laquelle on les met ne l'est pas**, et chaque client a dû l'inventer pour lui-même — d'où les forks, les copies de composants identiques et leur dérive. **Le format tient en une contrainte** : *« A plugin is a directory. That's the whole idea, and the restraint is the point. »* Un `plugin.json` à **deux lignes utiles** (`$schema` + `name`), des skills dans `skills/` au format de la spécification Agent Skills, des serveurs déclarés dans `mcp.json` **avec un `type` explicite sur chaque entrée** (stdio, Streamable HTTP, ou HTTP+SSE historique) — plus de transport deviné à la forme de l'objet de configuration. ⭐ **La force du design est dans ce que le manifeste ne peut pas faire** : il **ne peut ni déplacer les composants ni les déclarer en ligne**, donc aucun chemin de découverte à configurer et aucun ordre de précédence à apprendre. Corollaire opérationnel : **les composants échouent indépendamment** — un serveur `mcp.json` qui ne démarre pas n'emporte pas les skills du plugin, le client saute l'entrée, continue et signale l'échec. **L'échappatoire assumée** est le répertoire en **domaine inversé** (`com.example.client/`), espace d'extension appartenant entièrement à un client (hooks, agents, commandes) que les autres ignorent : *« le cœur portable reste petit parce que les parties non portables ont un endroit légitime où aller »*. **Section rare et à saluer** — ***« Not Every skill should be a Plugin »*** : un seul serveur MCP vers un seul client, `mcp.json` suffit ; une seule skill, pas besoin de plugin. Le format ne se justifie que pour des composants **qui vont ensemble et doivent voyager ensemble**. ⚠️ **Ce que la v1 exclut explicitement**, et c'est le point à retenir avant déploiement : **aucun mécanisme d'installation, aucun protocole de distribution, aucun modèle de permissions, aucune exigence de bac à sable, aucune vérification de confiance ou de provenance, aucune UX** — listés dans les *future considerations*, pas passés sous silence. Le tout s'insère dans une **pile à quatre couches indépendamment adoptables** : **trouver** (Agentic Resource Discovery), **décrire** (AI Catalog, qui enregistrerait le type `application/agent-plugins+json`), **empaqueter** (Agent Plugins), **exécuter** (MCP + Agent Skills). Deux produits Google livrent déjà : **Agents CLI** (skills d'agent building, évaluation, déploiement, observabilité, publication — utilisable depuis Antigravity, Gemini CLI, Claude Code ou Cursor) et **Data Agent Kit** (BigQuery, Spanner, Cloud SQL).

#Agent Plugins#Agent Plugins 1.0.0#spécification ouverte

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

Architecture & Construction

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

Analyse de Janakiram MSV (The New Stack, 20 juillet 2026) sur la **convergence architecturale** des plateformes d'agents d'entreprise des trois hyperscalers : en neuf mois, **Amazon Bedrock AgentCore**, **Microsoft Foundry** et **Gemini Enterprise Agent Platform** ont fait émerger les **mêmes six primitives** — runtime, mémoire, tool gateway, identité, observabilité, gouvernance — sous des noms de marque différents. Ce qui était il y a 18 mois une collection fragmentée de librairies devient une **couche plateforme** distincte. La thèse : cette convergence rejoue l'inflexion **PaaS de 2011-2016**, où **Cloud Foundry** et **Heroku** ont unifié VM, load balancers, files et secret stores autour d'un **contrat applicatif** portable — sauf qu'ici **aucun contrat équivalent n'existe encore**, et **aucun projet open source ne l'a revendiqué**. Conséquence : une entreprise ne peut pas **déplacer un agent d'un cloud à l'autre** (état de session, traces, identité terminent tous chez un seul fournisseur ; migrer = tout reconstruire). L'auteur propose un **mapping ligne à ligne** du contrat Cloud Foundry vers les agents, décline trois principes de conception (packager l'agent en **une unité déployable**, **attacher** les capacités plutôt qu'embarquer les fournisseurs, intégrer l'**opérationnel** à l'abstraction), pointe ce que les protocoles ouverts (MCP, A2A, OpenTelemetry) laissent hors champ — le **cycle de vie** —, et livre trois questions de due diligence : **gouvernance** (fondation neutre vs vendor), **packaging** (même artefact sur deux clouds sans réécriture), **état** (mémoire exportable). Verdict : celui qui possèdera le **control plane agent** définira *ce qu'est un agent*.

#Plateformes d'agents d'entreprise#convergence architecturale#portabilité

Janakiram MSV