ADK-Rust v2 : du framework d'agent au runtime de production.
L'histoire de la façon dont les outils, les workflows, l'état, les médias en temps réel, les agents de codage, les protocoles ouverts et les contrôles opérationnels sont devenus un système Rust composable.
En mars, nous avons publié l'histoire d'ADK-Rust v0.5. Cette version a rendu le framework capable de plus : récupération, exécution de code, fournisseurs de modèles supplémentaires, graphes durables, sessions chiffrées et une CLI capable de créer un projet de démarrage utile.
La question suivante était plus difficile. Ces capacités pourraient-elles devenir un système de production unique qu'un développeur pourrait composer, observer, sécuriser, déployer et maintenir en fonctionnement ? Le parcours vers v2 est la réponse. Il a transformé ADK-Rust d'une boîte à outils d'agents en pleine croissance en un runtime Rust pour des produits dont les agents parlent, utilisent des outils, coordonnent le travail, créent des artefacts et collaborent via des protocoles ouverts.
Lire le chapitre précédent : ADK-Rust v0.5La route vers v2
Six mois pour transformer les fonctionnalités d'agent en un système.
Chaque version a résolu une partie différente du problème de production. Ensemble, elles ont changé ce que les développeurs peuvent raisonnablement construire autour d'un runtime Rust.
Le framework a appris de nouveaux types de travail
RAG, l'exécution de code, les améliorations des fournisseurs, les graphes durables, les sessions chiffrées et cargo-adk ont étendu les capacités d'un agent Rust.
Les agents ont franchi de véritables frontières système
A2A a atteint des flux de tâches distantes complets. AWP a doté les sites web d'une interface d'agent. Les serveurs MCP ont acquis des cycles de vie gérés, tandis que la mémoire et l'état partagé sont devenus plus sûrs pour les produits plus importants.
La composition est devenue une expérience développeur
Les niveaux de fonctionnalités ont réduit la surface de dépendance par défaut. ACP est arrivé, les schémas se sont adaptés à chaque fournisseur de modèle, et les modèles ainsi que les add-ons ont fait de l'architecture un choix plutôt qu'un exercice de copie.
La fondation est devenue stable
Trente-neuf crates ont atteint le niveau stable avec des engagements de version sémantique, des contrôles de documentation plus stricts, des travaux de sécurité, l'évaluation, des runtimes gérés et des API de déploiement d'entreprise.
Le runtime est devenu l'épine dorsale du produit
CodingAgent et CodeAct ont rejoint la famille des agents. Les appels d'outils, la progression, les résultats, l'annulation, les médias en temps réel, la mémoire de graphe de connaissances et les protocoles ouverts transitent désormais par des contrats de runtime explicites.
Le tournant
Un agent de production est bien plus qu'un appel de modèle.
Les premiers exemples d'agents étaient naturellement centrés sur une invite, un modèle et une réponse. Les produits réels ont rapidement exposé le reste du travail : décider qui peut appeler un outil, préserver l'état, afficher la progression, reprendre après une approbation, déplacer un fichier généré, tracer un échec et communiquer avec des services appartenant à une autre équipe.
v2 traite ces responsabilités comme des préoccupations du framework avec des contrats Rust. Le modèle reste important, mais il s'exécute au sein d'une invocation avec des outils, des sessions, des événements, des callbacks, des limites et une politique opérationnelle. Vous pouvez remplacer le modèle sans redessiner le produit autour de lui.
C'est le changement architectural derrière la version majeure : le comportement de l'agent et l'infrastructure du produit se rencontrent désormais dans le même runtime, tout en restant suffisamment séparés pour être composés et testés.
L'architecture v2
Suivez un élément de travail à travers tout le produit.
Une requête peut arriver via une interface humaine ou un protocole d'agent. Le Runner lui donne du contexte, invoque la forme d'agent appropriée et diffuse des événements typés tandis que les outils, l'état et les contrôles opérationnels supportent le travail.
Personnes et systèmes
Surfaces produit
Un contrat d'exécution
Runner et flux d'événements typés
Choisissez la forme du travail
Agents composables
Donnez aux agents une portée utile
Outils, connaissances et état
Maintenir la production compréhensible
Contrôles opérationnels
À l'intérieur du processus
Les agents, outils, sessions, callbacks, événements et l'annulation partagent des traits et des types Rust.
À travers une frontière
MCP, A2A, ACP, AWP, HTTP et les transports en temps réel connectent des systèmes avec différents propriétaires.
Visible pour le produit
Le même flux d'événements peut piloter une CLI, une UI web, un client API, un visualiseur de traces ou un agent distant.
Voir comment ça marche
Le parcours d'exécution est une interface produit.
Un agent utile doit montrer plus que sa phrase finale. v2 donne à chaque étape significative une place dans le flux d'événements, afin que les développeurs puissent construire des interfaces autour du travail au fur et à mesure qu'il se déroule.
Requête
Une personne, un service ou un agent démarre le travail.
Décider
Un agent ou un workflow choisit la prochaine action significative.
Agir
Un outil, un spécialiste, un modèle ou un système distant exécute l'étape.
Diffuser
Les événements typés transportent les appels, la progression, les résultats et les changements d'état.
Continuer
Le runtime répond, met en pause pour une entrée, réessaie ou reprend plus tard.
Imaginez un agent de codage exécutant une suite de tests. L'UI reçoit l'appel d'outil, la sortie standard et l'erreur standard ligne par ligne, le résultat typé, toute modification d'état ou d'artefact, et la prochaine décision de l'agent via un flux corrélé unique. Si la tâche nécessite une approbation ou si le processus est interrompu, la session et le point de contrôle offrent un endroit clair pour continuer.
Ce que v2 offre à un développeur
Un framework unique pour le cycle de vie de l'agent.
Vous pouvez commencer avec un agent conversationnel et n'ajouter de la structure que lorsque le produit en a besoin. Les mêmes contrats de base restent en place à mesure que le système évolue.
Les agents peuvent travailler de différentes manières
Utilisez un agent LLM pour un raisonnement flexible, des agents de workflow déterministes pour des séquences connues, des graphes pour le travail ramifié et durable, des agents en temps réel pour la voix et la vidéo, CodingAgent pour le travail de dépôt, ou CodeAct lorsqu'un modèle doit exprimer une action en plusieurs étapes sous forme de code exécutable.
La progression fait partie de l'API
Les appels et les résultats d'outils sont des événements typés. Les outils de longue durée peuvent émettre leur progression dans le même flux que la réponse de l'agent, avec des ID d'appel liant la requête, la sortie en direct et le résultat final. Une UI peut afficher le travail sans avoir à analyser les logs.
L'état peut survivre à un tour de modèle
Les sessions préservent la conversation, les artefacts conservent les fichiers générés, les points de contrôle de graphe reprennent les workflows, et la mémoire de graphe de connaissances sémantique ou bi-temporelle donne aux agents un contexte qui reste utile lors des sessions ultérieures.
Les protocoles ouverts ont des rôles clairs
MCP connecte les outils et les ressources, A2A connecte les agents déployés indépendamment, ACP connecte les clients et serveurs d'agents de codage, et AWP donne à un site web une interface structurée pour les agents à côté de son interface humaine.
L'autonomie a des limites opérationnelles
Les callbacks d'autorisation, les outils à portée limitée, les garde-fous, les approbations, les politiques de sandbox, l'annulation, la télémétrie, l'évaluation et les preuves d'audit permettent à une équipe de décider ce qu'un agent peut faire et d'inspecter ce qui s'est passé par la suite.
Vous compilez le produit dont vous avez besoin
Le niveau minimal maintient un premier agent petit. Standard ajoute la pile de production courante ; enterprise ajoute le temps réel, le navigateur, RAG, les paiements et AWP ; full ajoute les capacités audio et d'exécution les plus lourdes. Les fonctionnalités individuelles restent disponibles lorsqu'un préréglage est trop large.
L'expérience de démarrage
Choisissez une forme de travail, puis personnalisez-la.
La CLI v2 peut échafauder la forme d'exécution et ajouter les capacités environnantes. Le projet généré ressemble toujours au code Rust que vous écririez et réviseriez vous-même.
Créer et vérifier
cargo install cargo-adk
cargo adk new support-agent \
--template tools \
--addon sessions \
--addon telemetry \
--addon guardrails
cd support-agent
cargo adk build
cargo runComposer l'agent
let agent = LlmAgentBuilder::new("support")
.description("Resolves customer issues")
.instruction("Use the reviewed tools and cite evidence.")
.model(Arc::new(model))
.tool(Arc::new(LookUpOrder))
.before_tool(approval_gate)
.build()?;
Launcher::new(Arc::new(agent))
.run()
.await?;Douze modèles couvrent les architectures de démarrage courantes. Neuf add-ons composent des capacités telles que les sessions, la télémétrie, MCP, l'authentification, les outils de navigateur et les garde-fous. Cinq modèles d'entreprise offrent des formes de déploiement plus grandes. cargo adk build vérifie le projet généré avant le déploiement.
Vérifié par rapport à la source v2
Les détails derrière l'histoire.
Le prochain chapitre commence avec un véritable agent
Construisez le premier workflow. Gardez le chemin vers la production ouvert.
Commencez avec une requête, un appel d'outil visible et une session que vous comprenez. ADK-Rust v2 offre à ce petit agent un chemin direct vers les workflows, la mémoire, les protocoles ouverts, les interfaces en temps réel, la sécurité et le déploiement lorsque le produit est prêt.