Google a récemment lancé un cours gratuit sur les agents.
Les cours vont de Prompt, Agent Loop à Graph Workflow, multi-agents et systèmes auto - évolutifs.À première vue, c'est comme l'introduction d'un nouvel ensemble de méthodes de développement d'agents.
Mais en regardant les documents officiels de Google ADK 2.0, les directives d'architecture de Google Cloud et plusieurs études récentes de revue d'agents, je pense que ce qui vaut vraiment la peine d'être surveillé n'est pas une API en particulier, mais un changement plus important :
Le développement d'agents passe de la phase de « modélisation » à la phase de « conception du système ».
Dans le passé, les applications d'IA étaient principalement comme suit :
Input → Prompt → Model → Output.
Traduction, résumé, classification, extraction d'informations, réécriture de contenu, ces tâches peuvent généralement être accomplies en un seul appel.
Le développement est rapide, le coût est facile à estimer, il peut être réappelé une fois si une erreur se produit.
Mais après l'apparition de l'appel d'outil, l'agent commence à entrer réellement dans le processus métier.
Il peut rechercher des données, appeler des API, exécuter du code, interroger des bases de données, puis décider de la prochaine étape en fonction des résultats renvoyés par l'outil.
Les modèles ne se limitent plus à « répondre aux questions ».
Il commence à "faire des choses".
Et une fois que le modèle est impliqué dans l'exécution, le problème est complètement différent.
Le contexte continue de croître, les résultats de l'outil continuent d'entrer dans l'historique, l'agent peut appeler l'outil à plusieurs reprises, peut s'écarter de l'objectif à mi-chemin ou même se terminer prématurément avant que la tâche ne soit terminée.
Les processus d'entreprise ajoutent des exigences supplémentaires telles que les droits, l'approbation, l'état, les réessais, la restauration et l'audit.
Le remboursement du service à la clientèle, la vérification des factures, l'intégration des employés, le traitement des commandes, ce n'est pas une simple question et réponse.
Donc, les véritables difficultés de l'agent ont été de :
« Comment faire pour que le modèle réponde correctement plusieurs fois ? »
Il devient :
« Comment faire fonctionner de manière stable un processus d'affaires impliqué par un modèle ? »
C'est aussi là que je pense que Google ADK 2.0 vaut la peine de regarder.
Premièrement, Prompt, Agent Loop, Graph, quelle est la différence ?
Beaucoup de gens parlent d'agents maintenant, il est facile de mélanger Prompt, Agent Loop et Workflow.
En fait, ils résolvent trois niveaux différents de problèmes.
Résolution rapide « Comprendre »
Prompt indique au modèle :
Ce que vous devez faire, comment vous devez le faire, quel format sortie, quelles sont les limites.
Si les tâches elles-mêmes sont relativement simples, telles que la traduction, le résumé, la classification, la réécriture, alors Prompt suffit souvent.
Agent Loop résout l'action
Une fois que le modèle a des outils, il peut :
Comprendre l'objectif → faire la prochaine étape → appeler l'outil → lire les résultats → décider de la prochaine étape.
C'est un agent typique.
Il est particulièrement adapté pour les tâches ouvertes.
Par exemple, la recherche de données, la correction de code, l'analyse de données complexes.
Comme il est difficile d'écrire chaque étape à l'avance, le modèle doit ajuster dynamiquement le plan en fonction des résultats sur le terrain.
Graph Workflow résolution de « Exécution »
Le workflow se concentre sur :
Comment tout le processus devrait fonctionner.
Quelles étapes doivent être effectuées ?
Quelles tâches peuvent être effectuées en parallèle ?
Dans quelles circonstances entrer dans une branche ?
Quand faut-il approuver manuellement ?
Où réessayer après avoir échoué ?
Quels statuts doivent être sauvegardés ?
Toutes ces questions ne peuvent pas être laissées à la décision ad hoc du modèle.
Ils sont mieux adaptés à l'écriture dans un programme.
Par conséquent, les trois peuvent être comprises simplement comme :
Prompt est responsable de la compréhension, Agent Loop est responsable de l'action et Workflow est responsable de l'exécution contrainte.
Les trois ne se substituent pas les uns aux autres, mais peuvent se superposer.
Les problèmes qui peuvent être résolus avec un appel de modèle n'ont pas besoin de créer un workflow forcé.
Un seul agent est déjà capable d'accomplir des tâches de manière stable, et il n'est pas nécessaire d'être divisé en plusieurs agents pour « Agentic ».
Quand le prompt commence-t - il à expirer ?
Le plus gros problème de Prompt n'est pas qu 'il n'est pas assez fort.
Mais lorsque les processus métier deviennent de plus en plus complexes,Le processus lui-même commence à se cacher dans le prompt.
Par exemple, un processus de remboursement :
L'utilisateur propose un remboursement → Recherche sur la commande → Déterminer la politique → Décider de rembourser ou non → Exécuter le remboursement → Envoyer un courrier de confirmation → Mise à jour de l'ordre de travail.
Si vous donnez tout cela à un agent, laissez le modèle décider de la prochaine étape par lui-même, cela semble très flexible.
Mais l'environnement de production peut rapidement être problématique.
Les développeurs ont du mal à déterminer :
Est-ce que cette étape est effectuée à chaque fois ?
Avez-vous terminé la vérification des autorisations avant de rembourser ?
Les remboursements sont-ils répétés après l'échec de l'outil ?
Où puis-je continuer après un échec de l'envoi de courrier électronique ?
Après que la mise à jour de la base de données a échoué, ne devez-vous pas revenir en arrière ?
Ce n'est plus un problème rapide.
C'est un problème d'ingénierie logicielle.
Ainsi, les systèmes vraiment fiables adopteront généralement une répartition plus réaliste du travail :
Le modèle est responsable de l'incertitude, le code est responsable de la certitude.
Par exemple :
La compréhension et l'analyse du contenu de la plainte peuvent être confiées au modèle.
Les requêtes de commande, l'exécution des remboursements, la mise à jour de la base de données, doivent être contrôlées par le programme.
Troisièmement, la boucle d'agent est flexible, mais l'environnement de production doit être « sur les rênes ».
Le charme de la boucle d'agent réside dans le fait qu 'elle n'a pas besoin de connaître tous les chemins à l'avance.
Le modèle peut ajuster continuellement le plan en fonction des résultats retournés par l'outil.
Par exemple,
« Aidez-moi à enquêter sur le financement récent de cette société. »
L'agent peut rechercher des pages Web, interroger des bases de données, organiser des données, puis continuer à rechercher lorsqu 'il trouve des informations insuffisantes.
Ce type de tâche peut être lourd si vous écrivez complètement le processus.
Mais la boucle a aussi un risque naturel :
Il ne sait pas quand il devrait s'arrêter.
Par conséquent, la boucle d'agent dans un environnement de production nécessite généralement des paramètres explicites :
- Maximum d'étapes exécutées
- Temps total de timeout
- Budget Token / API
- Condition de succès
- Condition d'échec
- Route de promotion manuelle
Sinon, une erreur de jugement, peut devenir :
Appeler l'outil → Obtenir un résultat d'erreur → Réappeler → Échouer à nouveau → Continuer à essayer.
Le résultat final était :
Les coûts augmentent, les retards augmentent, mais la tâche n'est pas terminée.
Alors :
Lorsque le chemin est incertain, laissez le modèle décider.
Lorsque le chemin est déterminé, ne laissez pas le modèle deviner.
C'est un principe très important dans l'ingénierie des agents.
Qu ' est-ce que Graph Workflow résout vraiment ?
Graph Workflow est très simple :
Le processus caché dans la décision du modèle est transformé en une structure logicielle que les développeurs peuvent voir, tester et modifier.
Par exemple, un processus de remboursement peut être conçu pour :
Enquête sur l'ordre
↓
Analyse des plaintes des utilisateurs
↓
Déterminer les conditions de remboursement
↓
- - Conditions remplies → Remboursement effectué
│
- - Insatisfait → Fermer l'ordre de travail
↓
Générer un email de confirmation
↓
Mettre à jour le statut de l'ordre
Ainsi, chaque nœud devient clair.
Quelles étapes doivent être effectuées ?
Quelles étapes peuvent être effectuées en parallèle ?
Où faut-il une confirmation manuelle ?
Où récupérer après un échec ?
Quels résultats doivent être durables ?
Tout cela peut être clairement exprimé.
C'est aussi la plus grande valeur de Workflow :
Il ne rend pas les agents plus intelligents, mais les rend plus contrôlables.
Pourquoi Google ADK 2.0 mérite-t - il d'être suivi ?
L'un des changements importants de Google ADK 2.0 est de placer officiellement Workflow Runtime au cœur du développement d'agents.
Python 2.0 est entré en GA le 19 mai 2026 et Go 2.0 le 30 juin.
De la conception officielle, les agents, les outils et les fonctions peuvent être des nœuds dans le flux de travail, puis contrôler l'ensemble du processus via des relations d'exécution.
L'exécution séquentielle, le routage conditionnel, les tâches parallèles, les boucles, les flux de travail dynamiques, les processus imbriqués et l'intervention humaine peuvent tous être incorporés dans un modèle d'exploitation unifié.
Plus important encore, il commence à se concentrer sur l'état et la récupération des longues missions.
Parce qu ' une véritable tâche d'entreprise, peut ne pas être réalisée en quelques secondes.
Il peut durer des dizaines de minutes, voire plus longtemps.
Une pause à mi-chemin peut être possible.
Peut être en attente d'approbation manuelle.
Un système externe peut être temporairement indisponible.
À ce stade, le système doit savoir :
Où était-il exécuté ?
S'il n'y a pas de point de contrôle et de récupération d'état, une fois que l'agent est arrêté, il ne peut que redémarrer.
C'est pourquoi les agents d'entreprise finiront par ressembler de plus en plus à des systèmes logiciels traditionnels.
Il nécessite :
état.
événement.
point de contrôle.
Réessayer.
autorité.
Le journal.
audit.
récupération.
Un contexte long n'est pas une mémoire fiable
Voici une autre question qui est très facile à ignorer :
Le contexte est rot.
Beaucoup de gens pensent que l'agent « se souvient de tout » en mettant tout l'historique dans son contexte.
En fait, les choses ne sont pas aussi simples.
À mesure que les entrées deviennent plus longues, la capacité du modèle à trouver avec précision les informations vraiment importantes dans le contexte peut diminuer.
Et les agents sont plus susceptibles de rencontrer ce problème que le chat ordinaire.
Parce que chaque appel d'outil peut apporter de nouvelles données.
Résultats de recherche, contenu de la page Web, enregistrements de base de données, valeurs de retour de l'API, raisonnement intermédiaire...
Si tout est continuellement ajouté au contexte, il finira par former une énorme décharge d'information.
Plus le contexte est long, il n'est pas nécessairement plus intelligent.
Parfois, il est plus facile de se tromper.
Ainsi, le workflow peut être atténué dans trois directions :
Tout d'abord, le nœud isole le contexte.
Chaque nœud ne lit que les informations dont il a vraiment besoin.
Deuxièmement, utilisez les états structurés.
Ne pas remplir le chat complet du modèle à chaque fois.
Troisièmement, la mise en place de points de contrôle.
Une fois qu 'un nœud a terminé, le résultat de la confirmation est enregistré, et le nœud suivant continue à partir de l'état confirmé.
Mais il y a une autre différence importante ici :
La sauvegarde des journaux de chat n'est pas égale à la capacité de récupération.
Les mécanismes de rétablissement réels doivent également être pris en compte :
Points de contrôle, logs d'événements, opérations idempotentes et stratégies de lecture pour les systèmes externes.
Plus les agents sont nombreux, plus les agents sont avancés.
Il y a une autre tendance qui est facilement mal comprise :
Il semble que plus il y a d'agents, plus le système est avancé.
Ce n'est pas du tout le cas.
Ce que le multi-agent est vraiment précieux, c'estUne division claire des responsabilités。
Par exemple :
Un agent est chargé de la récupération.
Un agent est chargé de l'analyse.
Un agent est chargé de l'exécution.
Cela permet à chaque agent de disposer d'outils, de privilèges et de contextes différents.
Le problème apparaît :
Plus d'appels.
plus de communication.
La synchronisation d'état est plus compliquée.
Troubleshooting est plus difficile.
La concurrence peut également entraîner des problèmes de limitation de flux, de concurrence pour les ressources et de cohérence.
L'étude MAST de NeurIPS 2025 a analysé plus de 1 600 trajectoires d'exécution multi-agents et a résumé 14 classes de défaillances.
Beaucoup de ces problèmes ne sont pas que Prompt soit mal écrit.
Mais plutôt :
La division des tâches est déraisonnable, la coopération des agents échoue, la gestion de l'état est confuse et les résultats ne peuvent pas être vérifiés.
Je suis donc très d'accord avec un principe simple :
Sans une frontière claire des responsabilités, il ne faut pas avoir plus d'agents pour « plusieurs agents ».
Les problèmes qui peuvent être résolus de manière stable avec un agent, utilisez-en un en premier.
Ce n'est que lorsque les tâches sont clairement divisées, qu ' il y a une séparation des rôles, une séparation des droits ou une collaboration complexe, que vous pouvez envisager la séparation.
L'évaluation de l'agent ne peut pas être seulement "réponse juste"
Application LLM traditionnelle, il est facile de faire un test de taux de précision.
L'agent est différent.
Parce qu ' il ne faut pas seulement « répondre correctement », mais aussi « faire les choses ».
Par exemple, un agent de remboursement du service à la clientèle.
Il répond finalement :
"Le remboursement a été effectué pour vous."
Cela n'a aucun sens, aussi beau qu ' il soit.
Ce qui doit vraiment être vérifié est :
Le remboursement a-t - il été réellement effectué ?
Le montant du remboursement, n'est-ce pas ?
Y a-t - il des remboursements dupliqués ?
Y a-t - il une opération hors autorité ?
Les ordres de travail sont-ils mis à jour ?
Les utilisateurs ont-ils été informés ?
Y a-t - il un enregistrement complet de tout le processus ?
Donc, lorsque les entreprises évaluent les agents, je suggère de comparer un lot de tâches historiques réelles et désensibilisées.
par exemple 20 à 50 tâches.
Comparer au moins trois implémentations :
- Appel unique du modèle
- Agent unique avec des outils
- Workflow graphique ou multi-agents
et utilise le même ensemble de tâches et de critères d'acceptation.
Enregistrements clés :
- Taux de réussite de la première fois
- Taux de réussite de la mission finale
- Temps de modification manuelle
- Retard de bout en bout
- Coût total du modèle et des outils
- Nombre de retentys
- À quel nœud se produit l'échec
- Nombre d'opérations non autorisées
- La source et la piste d'exécution sont complètes
Surtout pour les entreprises à haut risque, il ne faut pas seulement enregistrer le « succès / échec ».
Il convient également de conserver :
Justification de la notation, preuves brutes, trajectoires d'exécution et dossiers de révision manuelle.
Parce que vraiment en ligne, vous devez répondre à plus que :
« Est-ce qu ' il a fait ça ? »
Et répondre :
« Pourquoi le faire ? »
Le meilleur point de départ n'est pas « créer un super-agent ».
Si je devais être agent d'entreprise maintenant, je ne penserais pas d'abord :
« Faut-il un système multi-agent ? »
Je vais commencer par vous demander :
L'entreprise dispose-t - elle d'un processus manuel déjà en place avec des limites claires et des résultats vérifiables ?
Par exemple,
Vérification de la facture.
Remboursement du service à la clientèle
Contrats d'audit.
Les employés sont entrés.
Leads sortis.
Tout d'abord, faites fonctionner le processus manuel.
Combien de temps cela prendra-t - il ?
Quel est le coût ?
Quelles sont les erreurs les plus courantes ?
Quelles sont les étapes les plus gaspillées en main-d'œuvre ?
Quelles étapes font partie des règles de détermination ?
Quelles étapes nécessitent un jugement humain ?
Après avoir cette référence, décidez où utiliser le modèle.
Et puis :
Si vous pouvez résoudre cela avec un agent, ne vous précipitez pas pour en démanteler plusieurs.
Vous pouvez résoudre cela avec le code, ne laissez pas le modèle décider.
Seulement lorsque le processus apparaît explicite :
Branche, parallèle, approbation, réessai, récupération
Si nécessaire, introduisez le workflow.
S'il s'agit d'actions irréversibles telles que le paiement, l'écriture de base de données, l'envoi de courriels, la soumission d'un bon de travail, etc., il faut concevoir à l'avance :
Vérification des droits, clé idempotente, confirmation manuelle, chemin de retour.
À ce moment-là, vous découvrirez :
L'ingénierie de l'agent est de plus en plus proche de l'ingénierie logicielle traditionnelle.
Et enfin : quelle est la prochaine étape réelle de l'Agent ?
Au cours des deux dernières années, nous avons étudié :
Comment rendre le modèle plus intelligent ?
Comment rendre Prompt plus efficace ?
Comment rendre les agents plus efficaces dans l'utilisation des outils
Mais ensuite, les questions qui concernent vraiment les entreprises peuvent devenir :
Comment amener un agent à effectuer un travail de manière stable ?
Ces deux choses sont totalement différentes.
Le fait qu ' un modèle soit époustouflant de temps en temps ne signifie pas qu ' il peut entrer dans l'environnement de production.
Le fait qu ' un agent puisse accomplir une tâche ne signifie pas qu ' il peut accomplir régulièrement 10 000 tâches par jour.
Ce dont les entreprises ont vraiment besoin, c'est :
succès stable.
Coût contrôlable.
Processus traçable.
un état récupérable.
permissions minimales.
réessai fiable.
Audit complet.
Intervention manuelle.
Evaluation continue.
Je préfère donc considérer l'agent comme un nouveau système logiciel plutôt qu 'une fenêtre de chat qui invoquera des outils.
Prompt permet au modèle de comprendre les tâches.
La boucle d'agent permet au modèle d'agir en fonction des résultats.
Le flux de travail Graph contraint l'ensemble du processus d'exécution.
Les trois sont placés au bon endroit pour obtenir à la fois la flexibilité de l'IA et la certitude des logiciels traditionnels.
Et ce qui vaut vraiment la peine de regarder Google ADK 2.0 n'est peut - être pas le nombre d'API qu ' il ajoute.
Il envoie un signal très clair :
Agent est en train de passer de « chatbots qui invoquent des outils » à « systèmes logiciels qui peuvent être conçus, exploités et audités ».
Graph Workflow n'est qu ' une étape sur ce chemin.
Ce qui décide finalement si un agent peut être en ligne, ce n'est toujours pas à quel point la démo est incroyable, mais :
Taux de réussite, retravail manuel, retard, coût et dossier de sécurité.
C'est peut - être la compétitivité la plus intéressante après que l'agent entre vraiment dans l'environnement de production de l'entreprise.