Les agents sur Google AI : l'Agent Development Kit

L'Agent Development Kit (ADK) de Google permet de construire des agents qui appellent des tools en boucle jusqu'à ce qu'une tâche soit réellement terminée, au lieu de renvoyer une seule réponse au jugé en espérant que ça passe. Vous connaissez déjà le concept d'agent : un modèle qui peut décider d'agir, observer les résultats, et agir de nouveau. Cette leçon porte sur la façon dont Google industrialise ce pattern, sur les cas où sa complexité est justifiée, et sur la manière d'en livrer un vrai.

Ce qu'est réellement ADK

ADK est un framework Python open source (avec un support Java également) pour définir des agents en code. C'est le framework que Google utilise en interne pour des produits comme Agentspace. Vous définissez un agent, vous lui donnez des tools, vous choisissez un modèle Gemini, et ADK exécute la boucle raisonner-agir-observer à votre place.

Les objets clés :

• Agent : un modèle, des instructions et un ensemble de tools.
• Tool : une fonction Python (ou un tool intégré comme Google Search) que l'agent peut appeler.
• Runner : ce qui exécute la boucle et gère les sessions et l'état.

ADK accepte différents modèles mais est réglé pour Gemini. Vous développez en local, testez dans une web UI intégrée, puis déployez sur Vertex AI Agent Engine, le runtime managé de Google Cloud pour les agents. Le passage du local à la production utilise le même code.

Où se situe ADK par rapport au reste

Vous avez plusieurs façons de « faire des agents » sur Google AI, et ce sont moins des concurrents que des altitudes différentes :

• Gems dans l'app Gemini : personas et instructions enregistrés. Zéro code, pas de boucle de tools.
• Function calling de l'API Gemini : vous câblez la boucle vous-même.
• ADK : la boucle, l'état, l'orchestration multi-agents et le déploiement sont pris en charge.
• Vertex AI Agent Engine : là où les agents ADK tournent en production.

Si vous avez seulement besoin que le modèle appelle une fonction une fois, vous n'avez pas besoin d'ADK. Sortez-le quand la tâche est multi-étapes.

Quand un agent bat un appel unique

Un appel Gemini unique (même avec function calling) est le bon outil quand le travail tient en une étape : classer cet email, extraire ces champs, rédiger cette réponse. Le contexte long de Gemini et sa multimodalité native permettent déjà à un seul appel de faire beaucoup.

Un agent se justifie quand le nombre d'étapes est inconnu à l'avance et dépend des résultats intermédiaires qui remontent. Les signes que vous avez franchi la ligne :

• Le modèle doit chercher, lire ce qu'il a trouvé, puis décider s'il faut chercher encore.
• L'entrée de chaque étape dépend de la sortie de l'étape précédente.
• La tâche traverse plusieurs tools (recherche, puis calculatrice, puis écriture en base).
• Vous voulez que l'agent réessaie ou change de stratégie quand un tool échoue.

Une tâche « rechercher et résumer ce sujet » est l'exemple canonique. Vous ne pouvez pas savoir d'avance combien de recherches il faudra pour bien couvrir un sujet. L'agent le décide à l'exécution. Ce bouclage dynamique, dépendant des données, est ce qu'un appel unique ne peut pas faire et ce qu'ADK existe pour gérer.

Le coût est réel : plus de latence, plus de tokenstokensUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète →, plus de façons d'échouer. Utilisez Flash pour la boucle quand c'est possible (c'est rapide et pas cher), réservez Pro pour les étapes qui demandent un raisonnement profond, et n'allez jamais chercher un agent quand un seul appel structuré ferait l'affaire.

Un agent research-and-summarize concret

Construisons-en un. L'agent prend un sujet, utilise le grounding Google Search pour rassembler des informations à jour, boucle jusqu'à en avoir assez, puis rédige un résumé structuré.

D'abord, préparez l'environnement. Il vous faut le SDK et une clé API Gemini depuis Google AI Studio (ou des identifiants Vertex AI si vous déployez sur Cloud).

pip install google-adk
export GOOGLE_API_KEY="your-key-here"
export GOOGLE_GENAI_USE_VERTEXAI=FALSE

Maintenant l'agent. ADK fournit un tool intégré google_search qui ancre les réponses dans des résultats Google Search en direct, vous n'écrivez donc pas la plomberie de recherche vous-même.

from google.adk.agents import Agent
from google.adk.tools import google_search

root_agent = Agent(
    name="research_summarizer",
    model="gemini-2.5-flash",
    description="Researches a topic and writes a sourced summary.",
    instruction=(
        "You are a research assistant. Given a topic, search for "
        "current, credible information. Run multiple searches if the "
        "first results are thin or one-sided. Stop when you can cover "
        "the topic accurately. Then write a summary with: a two-line "
        "overview, 3 to 5 key findings as bullets, and a 'Sources' "
        "list. Never state a fact you did not find in results."
    ),
    tools=[google_search],
)

Cette instruction fait le gros du travail. Remarquez qu'elle indique à l'agent *quand boucler* (« run multiple searches if the first results are thin ») et *quand s'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êter* (« when you can cover the topic accurately »). Les conditions d'arrêt floues sont la première cause d'agents qui bouclent indéfiniment ou s'arrêtent trop tôt.

L'exécuter en local

ADK vous donne une dev UI pour observer la boucle, y compris chaque appel de tool et le raisonnement du modèle entre les étapes. Depuis le dossier contenant votre agent :

adk web

Cela ouvre une UI locale dans le navigateur où vous saisissez un sujet et regardez l'agent chercher, observer, chercher encore, puis rédiger. Voir les étapes intermédiaires, c'est ainsi qu'on débogue les instructions. Si l'agent cherche une fois et s'arrête, votre condition d'arrêt est trop lâche. S'il cherche huit fois pour un sujet simple, resserrez-la.

Pour une exécution headless, ADK expose un `Runner` que vous pouvez appeler depuis votre propre code ou encapsuler dans une API.

Pourquoi le grounding compte ici

Le tool google_search est plus qu'une simple recherche. C'est le grounding avec Google Search, qui injecte de vrais résultats dans le modèle et renvoie les métadonnées de sources. Pour un agent de recherche, c'est la différence entre un résumé assuré et un résumé *correct*. Sans grounding, le modèle écrit à partir de données d'entraînement avec une date de coupure. Avec, l'agent lit le web du jour. Ancrez toujours les agents qui émettent des affirmations factuelles sur le monde actuel.

Ajouter un tool personnalisé

La recherche intégrée fait le job, mais les vrais agents ont besoin de *vos* tools : une fonction qui interroge votre base, poste sur Slack ou écrit dans un Google Sheet. Dans ADK, un tool est une fonction Python typée avec une docstring claire. La docstring n'est pas de la documentation pour vous, c'est la description que le modèle lit pour décider quand l'appeler.

def save_summary(topic: str, summary: str) -> dict:
    """Saves a finished research summary to the team archive.

    Args:
        topic: The researched topic, used as the record title.
        summary: The full formatted summary text to store.

    Returns:
        A dict with 'status' and the saved record 'id'.
    """
    record_id = _write_to_store(topic, summary)
    return {"status": "ok", "id": record_id}

Ajoutez-la à la liste tools de l'agent, à côté de google_search. L'agent peut maintenant rechercher *et* archiver dans une même boucle. Écrivez les docstrings de tools comme si vous expliquiez la fonction à une nouvelle recrue brillante : ce qu'elle fait, ce que signifie chaque argument, ce qu'elle renvoie. Des docstrings bâclées amènent le modèle à appeler les tools au mauvais moment ou à passer des arguments absurdes.

Une contrainte à surveiller : les tools intégrés d'ADK comme google_search ont des règles de combinaison avec les tools personnalisés selon le modèle. Dans le doute, répartissez les responsabilités sur plusieurs agents.

Multi-agents : quand une seule boucle ne suffit pas

La vraie puissance d'ADK apparaît avec les systèmes multi-agents : un agent coordinateur qui délègue à des sous-agents spécialisés. Pour notre exemple, vous pourriez avoir un agent researcher (recherche uniquement) et un agent writer (mise en forme et archivage), avec un coordinator qui route entre les deux.

C'est important parce que chaque agent reste focalisé. Un agent focalisé avec trois tools se comporte bien plus fiablement qu'un agent qui jongle avec dix. Vous définissez les sous-agents et les confiez à un parent via le paramètre sub_agents ; le parent décide qui traite quoi. Commencez avec un seul agent, et ne découpez que lorsque ses instructions deviennent longues et conditionnelles.

Passer en production sur Vertex AI

adk web en local sert à construire. La production, c'est Vertex AI Agent Engine, un service managé qui héberge votre agent, gère les sessions, scale et s'intègre au reste de Vertex AI. Le même code d'agent se déploie avec des changements minimes ; vous basculez surtout de l'auth par clé APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → à l'auth Vertex AI et pointez ADK vers votre projet Google Cloud.

Ce que vous gagnez à déployer sur Agent Engine plutôt qu'à faire tourner votre propre serveur :

• Sessions et état managés : la mémoire conversationnelle persiste sans que vous construisiez une base pour ça.
• Scaling et monitoring : ça tourne comme un endpoint managé avec observabilité intégrée.
• Contrôles entreprise : ça vit dans votre projet Google Cloud, sous vos règles IAM et VPC, ce qui compte quand l'agent touche à des données internes.

Pour des agents qui agissent sur les données de l'entreprise, ce dernier point est toute la raison d'être sur Vertex plutôt que d'appeler l'API Gemini brute depuis un script.

L'évaluation : l'étape que tout le monde saute

Un agent qui marche en démo et un agent qui marche sur des entrées réelles sont deux choses différentes. ADK inclut une capacité d'évaluation : vous définissez des cas de test (entrée plus comportement attendu ou trajectoire de tools attendue), et ADK exécute l'agent dessus en notant à la fois la réponse finale et *quels tools il a appelés, dans quel ordre*.

Ce contrôle de trajectoire est spécifique aux agents et compte beaucoup. Un appel unique, vous l'évaluez sur la seule sortie. Un agent, vous l'évaluez aussi sur son *chemin*, parce qu'un agent qui trouve la bonne réponse par accident (ou qui brbrLe pourcentage de visiteurs qui repartent après avoir vu une seule page, souvent le signe d'une pertinence insuffisante, d'un décalage d'intention ou d'une expérience utilisateur faible.Voir la définition complète →ûle vingt appels de tools pour y arriver) n'est pas prêt pour la production. Construisez une poignée de cas d'éval avant de déployer, et rejouez-les à chaque modification d'instruction.

Un modèle mental réaliste

Voyez ADK comme la couche qui transforme Gemini de « un modèle qui peut suggérer un appel de tool » en « un processus qui mène une tâche à son terme ». Le modèle reste le cerveau. ADK est la boucle, la mémoire, le routage, le déploiement et le harnais de test autour. Vous apportez trois choses : des instructions nettes (surtout les conditions d'arrêt), des tools bien décrits, et des cas d'éval. ADK et Vertex s'occupent du reste.

Points clés

• Ne sortez un agent que lorsque les étapes sont dynamiques. Si le travail tient en une étape, utilisez un appel Gemini unique avec grounding. Les agents ajoutent de la latence, du coût et des modes de défaillance ; faites-les mériter leur place.
• Les conditions d'arrêt vivent dans l'instruction. La plupart des agents qui s'emballent ou qui sont paresseux se corrigent en disant explicitement au modèle quand continuer et quand terminer, pas en changeant de modèle.
• Les docstrings de tools sont des prompts. Le modèle choisit les tools et les arguments à partir de la docstring. Écrivez chacune clairement, avec des arguments typés et une valeur de retour décrite.
• Ancrez tout ce qui est factuel avec le tool intégré google_search pour que les résumés reflètent le web en direct, pas la date de coupure de l'entraînement.
• Développez avec `adk web`, déployez sur Vertex AI Agent Engine, et conditionnez les déploiements à des évals ADK qui vérifient la trajectoire des tools, pas seulement la réponse finale.