Modèles de projet composables

cargo adk new crée un projet Rust fonctionnel à partir de trois choix :

un modèle définit la structure de l’agent ou du workflow ;
des modules complémentaires ajoutent des fonctionnalités telles que les sessions, MCP ou la télémétrie ; et
un modèle d’entreprise sélectionne un modèle et un groupe vérifié de modules complémentaires pour une structure de produit courante.

Le CLI installé fait autorité, car les répertoires de modèles personnalisés peuvent étendre ou remplacer le registre intégré.

cargo adk templates
cargo adk addons
cargo adk new --help

Créer un projet

# One LLM agent
cargo adk new support-agent --template llm

# A tool-using agent with operating capabilities
cargo adk new support-agent \
  --template tools \
  --addon sessions \
  --addon telemetry \
  --addon guardrails

# Preview generated files without writing them
cargo adk new support-agent --template graph --dry-run

basic reste un alias de llm. Utilisez le nom explicite llm dans la nouvelle documentation et l’automatisation.

Modèles intégrés

Le registre intégré contient actuellement 13 modèles.

Modèle	Ce qu’il crée	Choisissez-le lorsque
`llm`	Un `LlmAgent` conversationnel	Un agent peut gérer la demande et appeler les outils nécessaires
`tools`	Un agent LLM ainsi que des exemples `#[tool]` typés	Le premier jalon utile est un appel d’outil Rust visible
`rag`	Un agent doté d’un parcours de connaissances avec recherche vectorielle	Les réponses doivent utiliser un document privé ou une collection de connaissances
`api`	Un agent exposé via HTTP API	Une autre application appellera l’agent sur le réseau
`openai`	Un agent LLM configuré pour OpenAI	OpenAI est le fournisseur de démarrage prévu
`sequential`	Plusieurs agents exécutés dans un ordre fixe	Chaque étape dépend du travail de l’étape précédente
`parallel`	Spécialistes concurrents avec résultats agrégés	Un travail indépendant peut s’exécuter simultanément
`loop`	Exécution répétée jusqu’à ce qu’une condition soit remplie	Un cycle de révision, de réparation ou de perfectionnement nécessite une boucle bornée
`conditional`	Routage entre agents fondé sur des décisions	Les différentes requêtes nécessitent différents spécialistes ou chemins
`graph`	Flux de travail ramifié avec points de contrôle	Le travail doit reprendre, se ramifier, se rejoindre ou survivre à une défaillance du processus
`realtime`	Gestion bidirectionnelle de l’audio et de la vidéo	Le produit nécessite une conversation vocale ou multimodale en direct
`custom`	Une implémentation manuelle du trait `Agent`	Le contrat d’exécution ne peut pas être exprimé par un agent intégré
`agent-engine`	Un conteneur BYOC Gemini Enterprise Agent Engine avec `Dockerfile` et `deploy/terraform/`	L’agent est déployé sur Agent Runtime en tant que conteneur prédéfini

Choisissez d’abord la structure d’exécution. Ajoutez ensuite les sessions, MCP, la télémétrie ou d’autres fonctionnalités du produit, plutôt que de les utiliser pour décider du workflow.

Extensions de capacités

Répétez --addon pour composer les capacités. Le générateur résout leurs indicateurs de fonctionnalité, leurs imports, leurs fragments d’initialisation, leurs exemples d’environnement et leurs fichiers générés selon un ordre de priorité stable.

Extension	Ce qu’elle ajoute	Raison courante de l’utiliser
`telemetry`	Configuration du traçage OpenTelemetry	Suivre les requêtes entre les limites du modèle, de l’agent et de l’outil
`auth`	Infrastructure d’authentification pour la clé API et JWT	Protéger un point de terminaison d’agent déployé
`sessions`	Configuration du service d’état de session	Poursuivre une conversation ou un workflow avec un état enregistré
`memory`	Mémoire sémantique et intégration de RAG	Récupérer des connaissances pertinentes au-delà de la conversation actuelle
`mcp`	Connexion des fonctionnalités de MCP et point de départ du client	Connecter des capacités gérées par un autre processus ou service
`guardrails`	Points d’extension de validation des entrées et des sorties	Faire respecter les règles du produit avant et après l’exécution de l’agent
`eval`	Structure de l’environnement d’évaluation	Mesurer le comportement par rapport à des cas reproductibles avant la mise en production
`browser`	Intégration de l’automatisation du navigateur	Permettre à un agent approuvé d’utiliser une interface web
`server`	Configuration du serveur Axum HTTP et A2A	Publier l’agent pour les appelants distants
`docker`	Fichiers de build de conteneur en plusieurs étapes (`Dockerfile`, `Dockerfile.static`, `.dockerignore`)	Empaqueter l’agent sous forme d’image de conteneur minimale

Exemple :

cargo adk new order-agent \
  --template tools \
  --addon mcp \
  --addon sessions \
  --addon server \
  --addon auth \
  --addon telemetry

Le code de capacité généré constitue un point de départ. Remplacez les points de terminaison fictifs, les identifiants, les stratégies et les services en mémoire par des choix gérés par le déploiement avant la mise en production.

Modèles d’entreprise composés

Les modèles apparaissent dans le même espace de noms --template que les modèles ordinaires. Il n’existe pas d’indicateur --pattern distinct.

Modèle	Composition	Point de départ du produit
`multi-agent`	`sequential` + télémétrie	Un flux de travail visible en plusieurs étapes
`production`	`llm` + serveur + authentification + sessions + télémétrie	Un service d’agent authentifié et observable
`pipeline`	`sequential` + sessions + télémétrie	Un pipeline de traitement avec état
`chatbot`	`llm` + sessions + mémoire + serveur	Un produit HTTP conversationnel avec rappel
`a2a-server`	`llm` + serveur + sessions	Un agent A2A déployé indépendamment

a2a reste un alias de a2a-server.

cargo adk new operations-agent --template production
cargo adk new research-team --template multi-agent --addon eval
cargo adk new public-specialist --template a2a-server --addon auth

Sélection du fournisseur et du modèle

Les modèles disposent d’un fournisseur par défaut, mais CLI peut le remplacer sans modifier la structure d’exécution.

cargo adk new support-agent \
  --template tools \
  --provider openai \
  --model company-approved-model

Utilisez --non-interactive dans CI afin que les choix manquants provoquent un échec au lieu d’ouvrir une invite. Utilisez --json-output lorsqu’un autre programme a besoin du résultat de la génération.

Modèles personnalisés

Fournissez un répertoire de manifestes TOML lorsqu’une organisation a besoin d’un point de départ réutilisable allant au-delà du registre intégré.

cargo adk new finance-agent \
  --template company-finance \
  --template-dir ./agent-templates

Un modèle personnalisé portant le même nom qu’un modèle intégré le remplace pour cette invocation de CLI. Conservez les manifestes dans le contrôle de version et testez les projets générés dans CI.

name = "company-finance"
description = "Company finance agent with approved defaults"
provider = "openai"
features = ["minimal", "tools"]
imports = ["use std::sync::Arc;"]

Vérifier le projet généré

cd support-agent
cargo adk build
cargo run

cargo adk build compile et valide le projet généré sans le déployer. Validez le code source généré, examinez ses fonctionnalités activées et ses exigences environnementales, et conservez la même commande comme étape de contrôle dans CI.

Maintenir l’automatisation à jour

Le contenu du registre peut changer entre les versions. Avant de mettre à niveau la génération automatisée de projets :

cargo adk templates
cargo adk addons
cargo adk new smoke-agent --template tools --addon mcp --dry-run

Cela vérifie les noms et la compatibilité avec le binaire exact de cargo-adk installé dans l’environnement de compilation.