Un plugin open-source facilite la création d’agents IA portables

Un plugin open-source transforme la création d’agents IA en un exercice déclaratif, exécutable et partageable comme un conteneur. Docker Agent combine support multi‑fournisseurs, orchestration d’équipes d’agents et validation de configuration contre un schéma officiel.

Configurations contrôlées par un schéma et exécution d’outils isolée

Les configurations d’agents peuvent être vérifiées contre le schéma officiel du projet, à l’aide d’un validateur construit directement sur le fichier agent-schema.json issu du dépôt docker/docker-agent. Ce validateur Python s’appuie sur yaml, json et jsonschema. Il échoue correctement face à une configuration volontairement invalide incluant un type d’outil inexistant, confirmant la robustesse du contrôle. Un exemple de configuration intégrant un serveur MCP DuckDuckGo via « ref: docker:duckduckgo » a été validé proprement contre ce schéma. L’exécution recommandée des serveurs MCP dans leur propre conteneur renforce l’isolation par défaut, avec la possibilité de les lancer localement, à distance ou en conteneur selon le besoin.

Délégation entre agents et choix du meilleur modèle par rôle

Docker Agent gère des équipes d’agents spécialisés capables de se déléguer des tâches. La directive « sub_agents » transforme des agents isolés en une équipe coordonnée et active l’outil intégré « transfer_task » sans configuration supplémentaire. Lorsqu’il est appelé, « transfer_task » lance une sous‑session dédiée pour l’agent ciblé, attend son résultat, puis le restitue au coordinateur. Cette approche se distingue de l’option « transfers », qui transfère l’intégralité de la conversation et le contrôle, davantage adaptée à des pipelines. Dans un scénario de contenu, un coordinateur délègue la recherche à un agent chercheur, transmet le résultat à un rédacteur, puis valide la sortie finale. Chaque rôle peut s’appuyer sur un modèle différent, par exemple Claude pour le coordinateur et le rédacteur, et GPT‑5 pour le chercheur. La possibilité de sélectionner le modèle le plus pertinent pour chaque fonction fait partie des objectifs de conception. Le rédacteur peut aussi disposer d’un accès fichier, et le chercheur formaliser des synthèses sourcées.

Portabilité, formats déclaratifs et compatibilité fournisseurs

Les agents s’expriment en YAML ou HCL, avec un champ model normalisé au format fournisseur/nom‑du‑modèle. Le runtime est compatible avec des services tels qu’OpenAI, Anthropic, Gemini, AWS Bedrock, Mistral, xAI, ainsi qu’avec des modèles locaux via Docker Model Runner. Les outils peuvent être intégrés ou fournis par des serveurs MCP, exécutables localement, à distance ou dans des conteneurs. Les agents publiés se distribuent via des registres OCI, comme les images Docker, ce qui facilite le partage et la réutilisation dans des environnements hétérogènes.

Le plugin s’installe via Docker Desktop ou Homebrew selon l’environnement

Pour démarrer, il faut Docker opérationnel et l’accès à au moins un modèle. Sur Docker Desktop 4.63 ou plus, le plugin est déjà disponible et s’invoque via « docker agent ». Sous Homebrew, « brew install docker-agent » installe l’exécutable, utilisable en « docker-agent » ou via un lien symbolique vers « ~/.docker/cli-plugins/docker-agent » pour l’employer comme sous‑commande. Une alternative consiste à récupérer un binaire depuis GitHub Releases et créer un lien symbolique identique. La commande « docker agent --help » doit renvoyer la liste des sous‑commandes en guise de vérification rapide.

Définir un agent minimal et l’exécuter en interactif ou script

Un agent minimal tient dans un fichier agent.yaml et doit déclarer un point d’entrée nommé exactement « root ». Le runtime s’appuie sur la description pour identifier l’agent, tandis qu’instruction définit le comportement attendu en langage naturel. La section toolsets expose les capacités, par exemple l’accès au système de fichiers ou l’exécution de commandes, et un champ think peut structurer le raisonnement avant action. Un exemple peut cibler « anthropic/claude-sonnet-4-5 » via le format fournisseur/modèle. Côté exécution, « docker agent run agent.yaml » ouvre une session interactive, tandis que « --exec » envoie une instruction unique puis quitte, une forme adaptée à l’appel depuis des scripts ou une CI.

Accès aux modèles et outillage mémoire et web

L’accès à un modèle peut passer par une clé API fournie en variable d’environnement, comme ANTHROPIC_API_KEY, OPENAI_API_KEY ou GOOGLE_API_KEY, ou par l’exécution locale d’un modèle via Docker Model Runner pour éviter toute dépendance cloud. Les agents peuvent disposer d’une mémoire persistante, par exemple un fichier « ./research.db », afin de conserver des faits au fil des échanges. Pour l’exploration web, un serveur MCP tel que DuckDuckGo peut être référencé via « docker:duckduckgo » afin d’être lancé dans un conteneur isolé. L’ensemble s’inscrit dans un écosystème d’outils intégrés ou via serveurs MCP, tout en restant compatible avec un large éventail de fournisseurs et de modèles locaux.

Genèse du projet et premiers indicateurs communautaires

Docker a préparé le terrain en 2025 en étendant Compose aux agents et modèles IA, et en lançant Model Runner pour l’exécution locale de modèles. Docker Agent réunit ces bases dans un outil dédié plutôt qu’une simple extension de Compose. Côté maturité, le module Go affiche des versions taguées depuis mars 2026, tandis que le dépôt GitHub recense plus de 3 300 étoiles et s’approche des 10 000 commits.