Opérations d'agents multi-canaux
La passerelle ADK connecte les canaux de messagerie, les applications web et d'autres agents à une équipe d'agents ADK-Rust. Elle route chaque requête, restaure le contexte approprié, applique la politique d'exploitation et offre aux développeurs un point unique pour voir et contrôler le système.
Personnes et systèmes
Identité · Routeur · Exécuteur
Équipe d'agents
Pourquoi une passerelle ?
Un agent ADK-Rust peut raisonner, appeler des outils et diffuser des événements. Un déploiement réel doit aussi répondre à des questions pratiques : Où arrivent les demandes ? Quel agent doit les recevoir ? Quelle session doit être restaurée ? Que cet agent est-il autorisé à faire ?
La passerelle ADK fournit cette couche d'exploitation partagée. Telegram, Slack, WhatsApp, Discord, Matrix, webhooks et requêtes web orientées agent entrent via des adaptateurs. La passerelle les transforme en un format de message unique, applique les règles d'accès, les route vers un agent système ou spécialiste, et renvoie la progression via le canal d'origine.
La passerelle ne fusionne pas tous les agents en un seul assistant. Les développeurs peuvent garder agents de recherche, support, opérations et codage séparés — avec différents modèles, outils, espaces de travail, permissions et liaisons de canaux — tout en les pilotant via une surface de contrôle unique.
Architecture
Lire l’architecture de gauche à droite. Les requêtes entrent par canaux humains ou agents. Identité et routage décident de leur destination. ADK-Rust exécute l’agent sélectionné avec son propre état et capacités. Le plan de contrôle observe chaque couche sans s’intégrer à la conversation.
Points d’entrée
Edge de confiance
Exécution Gateway
Équipe d'agents
principales
Plan de contrôle opérateur
Configurer, approuver, observer, récupérer et auditer le chemin complet de la requête.
Suivre une demande
Le même flux s'applique à chaque canal supporté. Seuls l'adaptateur et le format de livraison changent ; routage, sessions, exécution des agents, politique et preuves restent partagés.
Telegram, Slack, WhatsApp, Discord, Matrix et les webhooks arrivent sous différents formats. Chaque adaptateur les convertit en un même contrat de message entrant.
Les règles d’appairage, listes blanches, politique de mention de groupe, identité multi-utilisateur, limites de débit et vérifications JWT optionnelles s’exécutent avant que la requête n’atteigne un agent.
Le routage vérifie le canal, le compte et la personne ou le groupe. La correspondance la plus spécifique l'emporte ; l'agent système est le dernier recours.
Le Runner attache la session correcte, le contexte utilisateur, la mémoire, l'état d'annulation et la chaîne de secours du modèle avant le début de l'exécution de l'agent.
L'agent sélectionné peut utiliser ses outils Rust, serveurs MCP, connaissances, workflows ou un agent de codage ACP approuvé. La politique de rôle limite ce qu'il peut appeler.
Les événements typés deviennent des indicateurs de saisie, messages de progression, images ou une réponse finale. Les métriques, journaux, historique des tâches et événements d’audit expliquent ce qui s’est passé.
Routage en Rust
Un développeur peut lier un agent à un canal entier, un compte sur ce canal, ou une personne ou un groupe spécifique. Le routeur vérifie d'abord la règle la plus spécifique et retombe de manière prévisible.
L'exemple condense l'implémentation source pour plus de lisibilité. Le dépôt teste les comportements exacts, au niveau compte, canal, legacy et routage par défaut.
/// Most-specific binding wins.
pub fn resolve_agent(&self, message: &InboundMessage) -> &str {
// 1. channel + account + person or group
if let Some(agent) = self.exact_binding(message) {
return agent;
}
// 2. channel + account, then channel-only
if let Some(agent) = self.account_binding(message)
.or_else(|| self.channel_binding(message))
{
return agent;
}
// 3. configured legacy rules, then the system agent
self.legacy_binding(message)
.unwrap_or(&self.default_agent_id)
}{
"agent": {
"model": {
"primary": "openai/gpt-5.4-mini",
"fallbacks": ["openai/gpt-5.4-nano"]
}
},
"channels": {
"telegram": {
"enabled": true,
"botToken": "${TELEGRAM_BOT_TOKEN}",
"dmPolicy": "pairing"
}
},
"user_agents": [{
"id": "support",
"name": "Customer support",
"tools": ["order_lookup", "refund_request"],
"channel_bindings": [{ "channel_type": "telegram" }],
"role": {
"allow": ["order_lookup", "refund_request"],
"deny": ["refund_issue"]
},
"auto_start": true
}]
}Panneau de contrôle intégré
Le panneau de contrôle React est compilé dans le binaire Rust et servi à /ui. It is the operator interface for configuration, agent lifecycle, approvals, sessions, memory, scheduled work, logs, and health.
Choisissez les fournisseurs de modèles, stockez les identifiants, connectez les comptes de canal, et validez la passerelle avant de l'ouvrir aux utilisateurs.
Créer des spécialistes, assigner des outils et des canaux, démarrer ou arrêter leurs processus, et définir quels agents peuvent déléguer du travail.
Examiner les appels d'outils sensibles, jumeler les utilisateurs, terminer les sessions, inspecter le consentement et intervenir lorsqu'une tâche ne doit pas continuer.
Surveiller les canaux et agents en temps réel, inspecter les erreurs, rechercher dans la mémoire et suivre la santé de la passerelle en fonctionnement.
Ouvrir les frontières du protocole
Les canaux connectent la passerelle aux personnes. Les protocoles la connectent aux capacités et autres logiciels. Chaque frontière a un rôle distinct, permettant aux développeurs d'ajouter un élément sans repenser tout le runtime.
MCP
Connecter des serveurs de capacités pour navigateurs, ordinateurs, médias, données et systèmes métier. La passerelle peut ajouter, lister et supprimer des serveurs MCP configurés sans intégrer chaque intégration dans son binaire.
ACP
Exécuter les processus d'agent de codage supportés derrière une frontière supervisée. La politique d'espace de travail, les demandes d'autorisation, les progrès, les coûts, l'état de la file d'attente et l'historique des tâches restent visibles pour la passerelle.
AWP
Publier découverte, capacités, état, consentement, abonnements et point de message agent pour que d’autres logiciels comprennent comment interagir avec la passerelle.
HTTP + WebSocket
Les webhooks entrants apportent du travail depuis d'autres applications. Les API HTTP et les événements WebSocket en direct alimentent le panneau de contrôle intégré et les outils d'opérations externes.
Frontière actuelle : la source expose sa route agent-message sous la surface AWP. La page ne revendique pas une surface serveur A2A vérifiée séparément, complète, ni une implémentation commerciale AWP en production.
Gouvernance
L'autonomie de l'agent doit être une décision d'exploitation configurée. La passerelle ADK place identité, autorité, limites et preuves autour du même chemin d'exécution qui transporte la requête.
L’appairage, listes blanches, sessions multi-utilisateurs, JWT/JWKS et mappage des rôles déterminent qui fait la requête.
Les règles d’autorisation et de refus par agent ainsi que l’approbation des outils déterminent les capacités accessibles à une personne ou un agent.
Limitation de débit, délais de requête, annulation, boucles d’outils bornées et politique de santé limitent la durée du travail.
Les événements d'audit, journaux, métriques, historique des tâches, résultats d'outils et historique de santé fournissent un enregistrement opérationnel.
Déploiement
Un poste de travail développeur, un serveur interne ou un conteneur peut exécuter la même forme de passerelle. Le stockage de session peut rester en mémoire pour une expérience locale ou passer à SQLite, PostgreSQL, Redis ou Firestore pour un système déployé.
Le service Rust intègre le panneau de contrôle React compilé. Installez ou copiez un exécutable et conservez la configuration à côté.
Le dépôt inclut un Dockerfile et des contrats documentés de volumes et ports pour le déploiement en conteneur.
Une unité systemd prend en charge le démarrage au boot, la politique de redémarrage, la disponibilité, les logs et les fichiers d'environnement gérés par l'opérateur.
Une définition launchd exécute une passerelle locale persistante pour les agents développeur et poste de travail.
Migration et vérification
Les capacités produit sur cette page proviennent de la source locale Gateway, configuration, documentation et suites de tests. La migration ADK-Rust v2 valide désormais sa bibliothèque, propriété, intégration, agent généré et panneau de contrôle.
Adaptateurs de canal, routage des messages, registre des agents, cycle de vie des processus, sessions, mémoire, RAG, tâches planifiées, approbation des outils, contrôle d'accès, routes du panneau de contrôle, intégration AWP, MCP, ACP, ressources de déploiement et tests présents dans le dépôt examiné.
Chaque dépendance ADK se résout vers l'espace de travail local 2.0. Rust 2024 et Rust 1.95 compilent sur toutes les cibles et fonctionnalités. Tous les 845 tests de bibliothèque, 276 tests autonomes de propriétés et d'intégration, et 81 tests du panneau de contrôle réussissent.
L'état v2 vérifié est actuellement une migration locale de source, pas une crate adk-gateway v2 publiée. Les instructions d'installation doivent continuer à distinguer un checkout source de la version v1 sur crates.io.
Chaque fournisseur de messagerie, fournisseur de modèle, serveur MCP externe, backend persistant, fournisseur d'identité et déploiement en production nécessite encore des identifiants, une infrastructure et une revue de sécurité par son opérateur.
La génération de code multi-agent documente encore des points de terminaison A2A fictifs, et le commerce AWP est déclaré mais non implémenté comme un système transactionnel complet. Aucun n'est présenté ici comme prêt pour la production.
Revue de la source : Toutes les dépendances ADK se résolvent vers l'espace de travail local v2.0.0, le projet cible Rust 2024 avec MSRV 1.94, et la compilation avec toutes cibles et toutes fonctionnalités réussit. La vérification passe 845 tests de bibliothèque, 276 tests autonomes de propriétés et d'intégration, et 81 tests du panneau de contrôle ; crates.io continue de publier la version 1.
ADK Gateway est présenté comme un logiciel basé sur une source, et non comme un service hébergé sur un site web. La migration locale vers la version 2 est vérifiée, tandis que crates.io reste sur la version 1. Les canaux de messagerie, les fournisseurs de modèles, les outils MCP externes, les backends persistants et la sécurité en production dépendent des identifiants de l'opérateur et de la configuration du déploiement ; la génération de code expérimentale et le commerce AWP restent explicitement limités dans la documentation source.
Construire la couche opérationnelle
Commencez à partir de la source v2 vérifiée. Le dépôt contient la passerelle, le panneau de contrôle intégré, la référence de configuration, les guides de canal, les ressources de déploiement et les suites de tests nécessaires pour comprendre et exploiter le système complet.