Saltar al contenido

root / tags / packaging

#packaging

2 fiches

Agentes de codificación IA y Skills Traducción verificada automáticamente

Agent Plugins package your skills, tools, and more

Anuncio de **Google** del **6 de agosto de 2026**: Google se incorpora como **Core Maintainer** de la especificación **Agent Plugins 1.0.0**, un formato de empaquetado abierto y *neutral respecto al proveedor* para distribuir juntos **Agent Skills** y **servidores MCP**. ⭐ **El hecho de gobernanza pesa más que el hecho técnico**: la especificación fue publicada por un **TSC** cuyos Core Maintainers provienen de **Amazon, Cursor, Microsoft, OpenAI y Vercel** — Google se une a ellos, representado por **Kevin Hou** (Senior Staff Engineer, Google DeepMind). ⚠️ **Anthropic no figura en esta lista**, aunque los dos bloques empaquetados (**Agent Skills** y **MCP**) provienen de Anthropic: la capa de empaquetado de los dos formatos de Anthropic se está estandarizando sin que Anthropic figure entre los maintainers. **El diagnóstico** se enuncia en una frase: *« El problema central no son los componentes. Es el manifiesto. »* Una skill es portable, un servidor MCP es portable; **la caja en la que se colocan no lo es**, y cada cliente tuvo que inventarla por su cuenta — de ahí los forks, las copias de componentes idénticos y su deriva. **El formato se reduce a una restricción**: *« Un plugin es un directorio. Esa es toda la idea, y la contención es lo esencial. »* Un `plugin.json` con **dos líneas útiles** (`$schema` + `name`), skills en `skills/` en el formato de la especificación Agent Skills, servidores declarados en `mcp.json` **con un `type` explícito en cada entrada** (stdio, Streamable HTTP, o HTTP+SSE heredado) — ya no se infiere el transporte a partir de la forma del objeto de configuración. ⭐ **La fuerza del diseño reside en lo que el manifiesto no puede hacer**: **no puede ni reubicar componentes ni declararlos en línea**, por lo que no hay ninguna vía de descubrimiento que configurar ni orden de precedencia que aprender. Corolario operativo: **los componentes fallan de forma independiente** — un servidor de `mcp.json` que no arranca no arrastra consigo las skills del plugin; el cliente omite la entrada, continúa y reporta el fallo. **La vía de escape aceptada** es el directorio en **dominio inverso** (`com.example.client/`), un espacio de extensión que pertenece por completo a un cliente (hooks, agentes, comandos) y que los demás ignoran: *« el núcleo portable se mantiene pequeño porque las partes no portables tienen a dónde ir legítimamente »*. **Una sección poco frecuente que merece destacarse** — ***« No toda skill debería ser un Plugin »*** : un solo servidor MCP para un solo cliente, `mcp.json` basta; una sola skill no necesita ningún plugin. El formato solo se justifica para componentes **que pertenecen juntos y deben viajar juntos**. ⚠️ **Lo que v1 excluye explícitamente** — y este es el punto que hay que recordar antes del despliegue: **ningún mecanismo de instalación, ningún protocolo de distribución, ningún modelo de permisos, ningún requisito de sandboxing, ninguna verificación de confianza o procedencia, ninguna UX** — listado bajo *future considerations*, no pasado por alto en silencio. El conjunto encaja en una **pila de cuatro capas, adoptable de forma independiente**: **descubrir** (Agentic Resource Discovery), **describir** (AI Catalog, que registraría el tipo `application/agent-plugins+json`), **empaquetar** (Agent Plugins), **ejecutar** (MCP + Agent Skills). Dos productos de Google ya lo implementan: **Agents CLI** (skills para construcción, evaluación, despliegue, observabilidad y publicación de agentes — utilizable desde Antigravity, Gemini CLI, Claude Code o Cursor) y **Data Agent Kit** (BigQuery, Spanner, Cloud SQL).

#Agent Plugins#Agent Plugins 1.0.0#especificación abierta

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

Arquitectura y Construcción Traducción verificada automáticamente

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

Análisis de Janakiram MSV (The New Stack, 20 de julio de 2026) sobre la **convergencia arquitectónica** de las plataformas de agentes empresariales de los tres hyperscalers: en nueve meses, **Amazon Bedrock AgentCore**, **Microsoft Foundry** y **Gemini Enterprise Agent Platform** han convergido en las **mismas seis primitivas** — runtime, memoria, tool gateway, identidad, observabilidad, gobernanza — bajo nombres de marca distintos. Lo que hace 18 meses era una colección fragmentada de librerías se está convirtiendo en una **capa de plataforma** diferenciada. La tesis: esta convergencia repite la **inflexión PaaS de 2011-2016**, en la que **Cloud Foundry** y **Heroku** unificaron VMs, balanceadores de carga, colas y almacenes de secretos en torno a un **contrato de aplicación** portable — salvo que aquí **todavía no existe un contrato equivalente**, y **ningún proyecto de código abierto lo ha reclamado**. Consecuencia: una empresa no puede **mover un agente de una nube a otra** (el estado de sesión, las trazas y la identidad terminan todos en manos de un único proveedor; migrar implica reconstruirlo todo). El autor propone un **mapeo línea por línea** del contrato de Cloud Foundry sobre los agentes, plantea tres principios de diseño (empaquetar el agente como **una única unidad desplegable**, **adjuntar** capacidades en lugar de incrustar proveedores, integrar la capa **operativa** en la abstracción), señala lo que los protocolos abiertos (MCP, A2A, OpenTelemetry) dejan fuera de alcance — el **ciclo de vida** — y plantea tres preguntas de due diligence: **gobernanza** (fundación neutral frente a proveedor), **empaquetado** (el mismo artefacto en dos nubes sin reescribirlo), **estado** (memoria exportable). Veredicto: quien termine poseyendo el **plano de control del agente** definirá *qué es un agente*.

#Plataformas de agentes empresariales#convergencia arquitectónica#portabilidad

Janakiram MSV