Google ADK est un framework open source pour la création, l'évaluation et le déploiement d'agents IA, et il alimente de vrais agents au sein de produits Google tels qu'Agentspace. Si vous avez déjà examiné d'autres piles d'agents, comme le SDK OpenAI Agents, ADK couvre le même terrain tout en restant proche de Gemini et Vertex AI. Ce guide explique ce qu'est ADK, comment ses éléments fondamentaux s'articulent, et comment un outil comme Apidog vous aide à tester les API que votre agent finit par appeler.
Qu'est-ce que Google ADK
ADK signifie Agent Development Kit. Google l'a introduit lors de Google Cloud Next en avril 2025 comme une boîte à outils open source pour l'ensemble du cycle de vie des agents : définir un agent, lui donner des outils, composer plusieurs agents, évaluer le comportement et déployer en production.

Il a commencé avec Python, et Google a depuis ajouté Java, avec le support de Go et TypeScript à suivre. Le framework est le même que celui que Google utilise en interne pour les agents dans Agentspace et sa Customer Engagement Suite, ce n'est donc pas un SDK jouet. Il est conçu pour les charges de travail en production.
ADK est agnostique au modèle mais optimisé pour Google. Il fonctionne mieux avec Gemini et tout modèle disponible via Vertex AI Model Garden, et il s'intègre à LiteLLM pour que vous puissiez orienter un agent vers Anthropic, Meta, Mistral et d'autres fournisseurs. Vous obtenez l'intégration étroite de Gemini sans vous enfermer dans un seul modèle.
Où ADK se situe dans l'écosystème Gemini et Vertex AI
Il est utile de séparer trois couches :
- Le modèle. Gemini (ou un autre fournisseur via Vertex AI Model Garden ou LiteLLM) effectue le raisonnement.
- Le framework. ADK est la couche de code où vous définissez les agents, connectez les outils et orchestrez les flux multi-agents.
- L'environnement d'exécution. Vertex AI Agent Engine est l'hôte géré et scalable où votre agent s'exécute en production. Vous pouvez également déployer sur Cloud Run ou tout autre environnement d'exécution de conteneurs.

ADK est donc la couche orientée développeur. Gemini fournit l'intelligence sous-jacente, et Vertex AI Agent Engine offre un environnement géré au-dessus. Vous pouvez utiliser les trois ensemble, ou exécuter ADK localement et le déployer ailleurs. Rien ne vous contraint à une seule voie.
Concepts fondamentaux
Quelques blocs de construction couvrent la plupart de ce que vous écrirez.
Agents
L'unité de base est un agent basé sur un LLM. En Python, vous l'importez depuis google.adk.agents. La classe est LlmAgent, et Agent est un alias pratique pour celle-ci. Vous lui donnez un modèle, un nom, une instruction qui façonne son comportement, et une liste d'outils.
from google.adk.agents import Agent
def get_exchange_rate(base: str, target: str) -> dict:
"""Return the exchange rate between two currencies."""
# call your real FX API here
return {"base": base, "target": target, "rate": 1.08}
currency_agent = Agent(
name="currency_exchange_agent",
model="gemini-2.0-flash",
instruction="You help users convert between currencies. Stick to the facts.",
tools=[get_exchange_rate],
)
C'est un agent unique fonctionnel. L'instruction lui dit quoi faire, et la liste d'outils lui indique ce qu'il peut appeler.
Outils
Les outils sont la façon dont un agent fait quelque chose au-delà de la génération de texte. Dans ADK, une simple fonction Python est un outil. Le nom de la fonction, les indications de type et la docstring indiquent au modèle quand et comment l'appeler, donc une docstring claire est plus importante que vous ne l'imaginez.
Au-delà de vos propres fonctions, ADK fournit des outils intégrés comme google_search et l'exécution de code, et il prend en charge le Model Context Protocol (MCP) pour connecter des serveurs d'outils externes. Vous pouvez également encapsuler des bibliothèques tierces telles que LangChain ou LlamaIndex, ou utiliser un autre agent comme outil. La plupart des agents finissent par appeler des API REST externes via ces outils, ce qui est précisément là où les tests et le mocking interviennent plus tard.
Systèmes multi-agents
Un seul agent peut vous mener loin, mais ADK est conçu pour des hiérarchies. Vous composez des agents spécialisés en un système plus vaste et laissez un coordinateur acheminer le travail entre eux.

Le framework fournit des agents de workflow pour un contrôle déterministe : un SequentialAgent exécute les sous-agents dans l'ordre, un ParallelAgent les exécute simultanément, et un LoopAgent se répète jusqu'à ce qu'une condition soit remplie. Mélangez cela avec un routage piloté par LLM et vous pouvez construire un agent de recherche qui se répartit sur plusieurs sous-agents et fusionne leurs résultats.
Runners
Vous n'appelez pas directement un agent en production. Un Runner est le moteur d'exécution d'ADK. Il gère la session, pilote le flux d'événements, met à jour l'état, invoque le modèle et coordonne les appels d'outils. Pendant le développement, vous pouvez éviter le code passe-partout avec la CLI : adk run lance une session de terminal interactive, et adk web ouvre une interface utilisateur de navigateur locale pour discuter avec votre agent et inspecter chaque étape.
Évaluation et déploiement
ADK inclut un harnais d'évaluation pour que vous puissiez évaluer un agent en fonction de trajectoires et de réponses attendues, et non pas simplement jeter un coup d'œil au résultat. C'est important car le comportement de l'agent dérive lorsque vous modifiez les invites, les outils ou les modèles.
Pour le déploiement, vous avez un chemin géré et un chemin portable. Vertex AI Agent Engine vous offre un environnement d'exécution entièrement géré et scalable, avec une infrastructure prise en charge pour vous. Si vous préférez rester portable, emballez l'agent dans un conteneur et déployez-le sur Cloud Run ou toute autre plateforme de conteneurs.
Un exemple de haut niveau
Voici la forme d'une petite configuration multi-agents. Un coordinateur délègue à deux spécialistes.
from google.adk.agents import Agent
flights = Agent(
name="flight_agent",
model="gemini-2.0-flash",
instruction="Find flight options for the user's route and dates.", # Trouver des options de vol pour l'itinéraire et les dates de l'utilisateur.
tools=[search_flights], # votre fonction encapsulant une API de vols
)
hotels = Agent(
name="hotel_agent",
model="gemini-2.0-flash",
instruction="Find hotel options near the destination.", # Trouver des options d'hôtel près de la destination.
tools=[search_hotels], # votre fonction encapsulant une API d'hôtels
)
trip_planner = Agent(
name="trip_planner",
model="gemini-2.0-flash",
instruction="Planifier un voyage. Déléguer les recherches de vols et d'hôtels à vos sous-agents.",
sub_agents=[flights, hotels],
)
Le coordinateur raisonne sur la requête et la transmet au bon sous-agent. Chaque sous-agent appelle une API réelle via sa fonction d'outil. Vous exécutez le tout via un Runner, ou le testez interactivement avec adk web.
ADK vs le SDK OpenAI Agents
Les deux sont des frameworks d'agents code-first avec des outils, des transferts et du traçage. La différence réside dans la gravité de l'écosystème.
| Google ADK | SDK OpenAI Agents | |
|---|---|---|
| Modèle par défaut | Gemini (Vertex AI) | Modèles OpenAI |
| Autres modèles | Vertex AI Model Garden, LiteLLM | LiteLLM et autres |
| Langages | Python, Java, Go, TypeScript | Python, JavaScript/TypeScript |
| Multi-agents | Sous-agents plus agents de workflow Séquentiel, Parallèle, Boucle | Agents comme outils et transferts |
| Environnement d'exécution géré | Vertex AI Agent Engine | Apportez le vôtre |
| Protocole d'outils | MCP, outils intégrés, outils fonctionnels | MCP, outils fonctionnels |
Si votre pile est déjà sur Google Cloud, ADK et Vertex AI sont un choix naturel. Si vous privilégiez OpenAI, le SDK OpenAI Agents vous maintient dans cette voie. Les deux supportent le MCP, de sorte que les serveurs d'outils peuvent être partagés.
Quand utiliser ADK
Utilisez ADK lorsque :
- Vous développez sur Google Cloud et souhaitez Gemini ainsi qu'un environnement d'exécution géré dans Vertex AI Agent Engine.
- Vous avez besoin d'une orchestration multi-agents avec un contrôle séquentiel, parallèle ou en boucle explicite.
- Vous souhaitez que l'évaluation soit intégrée au framework plutôt que d'être ajoutée ultérieurement.
- Vous prévoyez de changer de modèles, et vous voulez LiteLLM et Vertex AI Model Garden comme portes de sortie.
Vous pourriez l'éviter si vous êtes fermement ancré dans un autre écosystème de modèles, ou si une seule invite avec un ou deux appels de fonction couvre l'ensemble de votre cas d'utilisation. Un framework d'agents ajoute de la structure, et la structure a un coût lorsque la tâche est petite.
Où Apidog intervient : tester et mocker les API que votre agent appelle
ADK orchestre votre agent. Il ne teste pas les API externes dont dépend cet agent, et c'est une lacune qu'il convient de combler tôt.

Chaque outil significatif de votre agent appelle quelque chose : un endpoint de LLM, une API de paiement, un microservice interne, une source de données tierce. Lorsqu'un de ceux-ci renvoie une forme inattendue, votre agent raisonne sur une mauvaise entrée et la défaillance est difficile à tracer. Apidog est l'endroit où vous définissez ce contrat avant qu'il ne vous morde. Pour être clair : Apidog n'est pas un framework d'agent et ne remplace pas ADK. Il se situe une couche en dessous, sur les API que vos outils appellent.
Quelques utilisations concrètes pendant le développement ADK :
- Mocker les endpoints que vos outils appellent. Mettez en place une API mock pour un LLM ou un endpoint REST d'un outil afin de pouvoir développer et exécuter votre agent sans brûler de tokens ou atteindre les limites de débit. Vous contrôlez les réponses, y compris les cas d'erreur que votre agent doit gérer.
- Affirmer la forme de la réponse de l'outil. Utilisez les assertions d'API pour confirmer qu'un endpoint d'outil renvoie exactement les champs que votre agent attend. Si le contrat dérive, vous le détectez dans un test, pas dans une transcription d'agent confuse.
- Gérer les clés par environnement. Conservez les clés de développement, de staging et de production dans les environnements Apidog afin que les mêmes appels d'outils s'exécutent proprement à travers les différentes étapes.
Si vous souhaitez un aperçu plus approfondi ciblé spécifiquement sur les agents, voyez comment tester les appels d'outils d'un agent IA avant qu'ils ne tombent en panne en production. Vous pouvez télécharger Apidog et mocker un seul endpoint en quelques minutes.
Foire aux questions
Google ADK est-il gratuit et open source ?
Oui. ADK est open source sous un dépôt sous licence Apache sur GitHub, et vous pouvez l'exécuter localement sans frais. Vous payez pour les modèles que vous appelez et pour tout environnement d'exécution géré sur lequel vous déployez, comme Vertex AI Agent Engine. Le framework lui-même est gratuit.
ADK fonctionne-t-il uniquement avec Gemini ?
Non. ADK est optimisé pour Gemini et Vertex AI, mais il est agnostique au modèle. Via Vertex AI Model Garden et LiteLLM, vous pouvez exécuter des agents sur Anthropic, Meta, Mistral et d'autres fournisseurs. Gemini est le modèle par défaut, pas une exigence.
Quels langages ADK supporte-t-il ?
Python a été le premier et reste le plus complet. Google a depuis ajouté Java, avec le support de Go et TypeScript à suivre. Si vous voulez la couverture fonctionnelle la plus large aujourd'hui, Python est le choix le plus sûr.
Comment tester les API dont dépend mon agent ADK ?
Testez-les séparément de l'agent. Mocker les endpoints du LLM ou des outils pour que votre agent s'exécute sans appels réels, et affirmez que chaque réponse correspond à ce que votre agent attend. Apidog couvre les deux, et le guide sur la façon de tester l'API ChatGPT montre le même modèle pour un endpoint de LLM que vos outils pourraient appeler.
Conclusion
Google ADK vous offre un moyen propre et orienté production de construire des agents et des systèmes multi-agents, avec Gemini et Vertex AI à portée de main, mais d'autres modèles à un changement de configuration. Commencez avec un agent et quelques outils, appuyez-vous sur adk web pour le regarder penser, puis évoluez vers des sous-agents et un environnement d'exécution géré à mesure que le travail l'exige. À mesure que votre agent s'appuie davantage sur des API externes, traitez ces API comme quelque chose que vous moquez et contre quoi vous affirmez. C'est la couche que Apidog gère, et c'est là que le comportement instable des agents commence généralement.
