Le protocole Agent2Agent (A2A) offre des mécanismes sophistiqués pour gérer des interactions complexes entre agents. Cet article explore ses fonctions avancées, notamment le traitement en temps réel, les opérations asynchrones, l'extensibilité et la gestion du cycle de vie des tâches.

Traitement en flux continu avec Server-Sent Events (SSE)

Le prtoocole intègre un mécanisme de traitement en flux pour les tâches de longue durée ou générant des résultats incrémentaux. La technologie Server-Sent Events (SSE) permet au client de recevoir des mises à jour de progression et des résultats partiesl en temps réel.

Fonctionnalités clés du traitement en flux

Séquence d'opération type

Le processus commence par une requête message/stream du client. Si le serveur supporte le flux, il établit une connexion SSE. Pendant le traitement de la tâche, il envoie des événements TaskStatusUpdateEvent et TaskArtifactUpdateEvent. Un événement avec l'indicateur final: true signal la fin avant la fermeture de la connexion.

Exemple de déclaration de capacité serveur

{
  "capacities": {
    "streaming": true
  }
}

Structure d'événement SSE

Chaque événement SSE encapsule une réponse JSON-RPC 2.0 complète dans son champ data. Les principaux types événementiels sont :

• TaskEvent : Représente une unité d'état de la tâche en cours.
• TaskStatusUpdateEvent : Transmet un changement d'état du cycle de vie de la tâche.
• TaskArtifactUpdateEvent : Livre un artefact nouvellement généré ou mis à jour.

Mécanisme de reconnexion

En cas de déconnexion, le client peut réabonner une tâche existante :

{
  "procedure": "tasks/resubscribe",
  "arguments": {
    "taskId": "task-abc-789"
  }
}

Opérations asynchrones et notifications push

Pour les tâches s'étalant sur des durées très longues (minutes, heures) ou pour les clients incapables de maintenir une connexion persistante (applications mobiles, fonctions serverless), A2A propose des notifications push via Webhook.

Configuration de notification push

{
  "notificationEndpoint": "https://client.example.com/webhook",
  "securityToken": "jeton-secret-genere-par-client",
  "authentification": {
    "methodes": ["Bearer", "HMAC"],
    "parametres": {
      "emetteur": "serveur-a2a.exemple.com",
      "destinataire": "webhook-client"
    }
  }
}

Cette configuration peut être fournie soit dans la requête initiale (message/send), soit indépendamment via la méthode tasks/pushNotificationConfig/set pour une tâche déjà existante.

Considérations de sécurité critiques

Le serveur ne doit pas faire aveuglément confiance à l'URL Webhook fournie par le client. Les mesures suivantes sont essentielles :

1. Validation de l'URL : Maintenir une liste blanche de domaines de confiance, implémenter un mécanisme de vérification de propriété.
2. Authentification mutuelle : Utiliser Bearer Token (OAuth 2.0), HMAC, ou le TLS mutuel (mTLS).
3. Vérifications côté client : Valider l'identité du serveur (signature JWT, HMAC), vérifier le jeton de configuration, implémenter la validation d'horodatage et l'utilisation de nonce pour prévenir les attaques par rejeu.

Système d'extensions du protocole

Le mécanisme d'extensions permet d'ajouter des fonctionnalités personnalisées au protocole de base, sans compromettre la compatibilité. Les extensions sont identifiées par des URI et supportent la gestion de versions.

Typologie des extensions

Exemple de déclaration d'extension dans une AgentCard

{
  "agentName": "Oracle de sagesse",
  "capacities": {
    "extensions": [
      {
        "uri": "https://exemple.com/ext/prediction-avancee/v2",
        "description": "Active un moteur de prédictions complexes",
        "required": false,
        "params": {
          "niveau_confiance": 0.95
        }
      }
    ]
  }
}

L'activation se fait via l'en-tête HTTP X-A2A-Extensions. Le serveur valide les dépendances et active les extensions compatibles.

Gestion du cycle de vie des tâches

Les tâches dans A2A suivent une machine d'états explicite, permettant la gestion de flux de travail complexes.

États possibles d'une tâche

Une tâche peut traverser les états suivants :

• working : En cours de traitement.
• input-required : Nécessite une entrée supplémentaire du client.
• auth-required : Nécessite une autorisation.
• completed : Traitement terminé avec succès.
• failed : Traitement terminé en échec.
• canceled : Annulée.

Principe fondamental : Immutabilité des tâches terminées

Une fois qu'une tâche atteint un état terminal, elle ne peut pas être redémarrée. Cette conception apporte des avantages significatifs :

• Références fiables : Les clients peuvent faire référence de manière stable à une tâche et à son résultat.
• Unités de travail claires : Chaque requête, raffinement ou action de suivi devient une tâche indépendante.
• Simplicité d'implémentation : Évite la complexité de la gestion de redémarrage.

Suivi des artefacts et raffinement

Les artefacts produits par une tâche peuvent être référencés et modifiés par des tâches ultérieures dans le même contexte (identifié par contextId). Les stratégies de gestion incluent la conservation du nom d'artefact pour l'identification client ou l'attribution d'un nouvel ID pour garantir l'unicité versionnelle.

{
  "message": {
    "contextId": "ctx-session-xyz",
    "referenceTaskIds": ["task-gen-image-001"],
    "parts": [
      {
        "kind": "text",
        "content": "Rendre l'arrière-plan bleu ciel.",
        "metadata": {
          "artefactRef": {
            "artefactId": "artefact-image-v1",
            "taskId": "task-gen-image-001"
          }
        }
      }
    ]
  }
}

Bonnes pratiques et sécurité

• Pour le flux : Implémenter un mécanisme de buffer côté client, utiliser une stratégie de reconnexion exponentielle, fournir des indicateurs de progression utilisateur.
• Pour les webhooks : Valider la propriété de l'URL, utiliser HTTPS, implémenter la vérification de signature, ajouter des limitations de débit, journaliser tous les événements.
• Pour les extensions : Minimiser les extensions marquées comme required, valider rigoureusement les données entrantes, fournir une documentation complète.
• Sécurité JWT/JWKS : Le serveur signe les notifications avec un JWT. Le client vérifie la signature via la clé publique récupérée à l'endpoint JWKS du serveur A2A, puis valide les revendications (émetteur, destinataire, horodatage, identifiant unique).