OpenClaw et A2A

L’agent à agent est un canal dans OpenClaw : l’extension A2A connecte la passerelle à d’autres agents par le protocole Agent2Agent de la Linux Foundation. Les agents externes découvrent la passerelle par une carte d’agent publique et soumettent des tâches texte authentifiées par la liaison JSON-RPC A2A 1.0, et OpenClaw peut en retour envoyer des messages à des agents pairs configurés. Voici la configuration, les appels, le modèle d’isolation, les règles de sécurité que la documentation détaille, et les fonctions du protocole que l’extension actuelle ne prend pas en charge.

Configuration et découverte

• Activez l’extension intégrée, réglez l’URL annoncée sur votre origine HTTPS joignable de l’extérieur quand la passerelle est derrière un proxy inverse, et définissez un jeton porteur distinct pour chaque pair de confiance par une variable d’environnement, puis redémarrez.
• La carte d’agent se récupère sans authentification au chemin bien connu de carte d’agent ; elle annonce le point d’accès JSON-RPC, l’entrée et la sortie texte, et une compétence par agent OpenClaw exposé, avec une liste d’exposition pour limiter les agents affichés et un chemin hérité pour les anciens clients.
• Une tâche est une requête JSON-RPC d’envoi de message authentifiée vers le point d’accès A2A ; par défaut elle attend la réponse et renvoie une tâche terminée avec la réponse dans un artefact, un identifiant de contexte poursuit la même conversation, une option de retour immédiat rend une tâche en cours à la place, et une requête au-delà du délai de réponse renvoie aussi la tâche en cours plutôt que de l’annuler.
• Une tâche en cours s’interroge avec l’appel de lecture de tâche jusqu’à ce qu’elle termine, échoue ou soit rejetée ; l’annulation est refusée avec une erreur JSON-RPC plutôt qu’acquittée, parce qu’une exécution lancée n’a pas de point d’interruption et que rapporter un état annulé dirait au pair que le travail s’est arrêté alors que l’exécution continuait d’utiliser des outils.

Les pairs A2A envoient des tâches, pas des commandes d’utilisateur.

Pairs sortants et isolation

Pour envoyer des messages à un autre agent, donnez au pair une URL et, s’il en a besoin, un jeton sortant ; les messages sortants s’adressent au nom du pair sous le préfixe a2a, vont directement à l’URL configurée sans découverte de carte, et réutilisent un contexte de conversation stable par pair. Chaque paire de pair authentifié et de contexte reçoit sa propre session d’agent, épinglée à la portée de message direct la plus isolée plutôt que d’hériter de la valeur par défaut de session, si bien que le contenu distant ne rejoint jamais la session principale de l’opérateur et qu’un pair ne peut pas lire l’historique d’un autre. La configuration est petite : un délai de réponse de deux minutes par défaut dans une plage de cinq secondes à dix minutes, une limite glissante de trente requêtes par minute et par pair que zéro désactive, la liste d’exposition, et des pairs indexés par des noms en minuscules.

Les règles de sécurité

• La découverte de la carte est publique à dessein, donc quiconque atteint la passerelle lit la description et les identifiants d’agents exposés ; chaque requête JSON-RPC exige un jeton de pair configuré, il n’y a pas de mode non authentifié, et le pair authentifié est l’identité d’expéditeur pour la politique d’admission normale des canaux. Utilisez un jeton distinct à forte entropie par pair, gardez-les hors du contrôle de version, et faites-les tourner en mettant à jour l’environnement et en redémarrant.
• Les pairs envoient des tâches, pas des commandes : un message qui commence par une barre oblique est rejeté avec une explication, un texte ressemblant à une commande dans une tâche reste littéral, le rôle utilisateur du protocole n’authentifie pas un humain, et un travail qui exige une approbation attend toujours un opérateur autorisé sur un canal utilisateur ou l’interface de contrôle pendant que la tâche reste en cours.
• Les requêtes sont plafonnées à un mébioctet, les lots à trente entrées, les réponses à un mébioctet et le texte extrait à 64 Kio avec un marqueur de troncature ; les requêtes invalides selon le schéma comptent dans la limite de débit, les requêtes limitées renvoient une erreur JSON-RPC avec un HTTP 200, et les destinations sortantes ne viennent que des URL de pairs configurées par l’opérateur.

L’API d’OpenClaw couvre la surface HTTP propre à la passerelle à côté de laquelle se trouve le point d’accès A2A, et Les contrôles de sécurité de la passerelle OpenClaw le chemin d’authentification qui la protège.

Ce que la 1.0 laisse de côté

L’extension prend en charge les messages texte et les parties de données JSON structurées, ajoutées en JSON compact ; les parties d’URL de fichier et binaires brutes sont ignorées, et le streaming, les événements envoyés par le serveur, les notifications push, l’annulation de tâche, la liste des tâches, les cartes d’agent étendues et le routage multi-locataire ne sont pas pris en charge. Les tâches ne vivent qu’en mémoire : les tâches terminales sont gardées jusqu’à vingt-quatre heures avec un plafond de cinq cents entrées, et un redémarrage de la passerelle les efface toutes. Les sous-agents d’OpenClaw est le cousin en processus de ce schéma, la délégation sans saut réseau.

Sur Diali

Sur Diali, la messagerie d’agent à agent entre vos propres assistants est en service, chacun étant une instance isolée, avec les jetons de pairs générés pour vous plutôt que collés dans un fichier de configuration, et un agent A2A extérieur se connecte avec un jeton que vous créez dans le tableau de bord. OpenClaw hébergé sur Diali est l’assistant et La sécurité chez Diali décrit la frontière.

• Une carte publique, un jeton privé par pair.
• Des tâches, jamais des commandes ; l’annulation est refusée à dessein.
• Une session par pair et contexte, en mémoire seulement.