Protocoles de négociation pour les systèmes multi-agents

Dans un multi-agent system, ou système multi-agents, ordonner ne suffit pas toujours. Les agents peuvent posséder des ressources différentes, poursuivre des objectifs partiellement incompatibles ou perdre temporairement le contact. Le protocol negotiation transforme alors un conflit implicite en échange observable : une proposition, une réponse, un engagement et une issue.

Un protocole n’est pas seulement un format de message. C’est une règle de conversation : qui peut proposer, quelles informations sont obligatoires, combien de temps une proposition reste valable, comment refuser et comment sortir d’un désaccord. Cette distinction est importante lorsqu’un agent est remplacé ou lorsqu’un nouveau service rejoint le système.

Les technologies et protocoles disponibles

Les protocoles de type Contract Net — appel d’offres entre agents —, les mécanismes d’enchères, les automates de contrats et les APIs JSON-RPC — appels de fonctions structurés en JSON — offrent des points de départ différents. Dans les systèmes d’agents modernes, un protocole comme MCP peut standardiser l’accès à des outils ou à des ressources, mais il ne définit pas à lui seul la manière dont deux agents arbitrent des préférences contradictoires. Des bibliothèques de simulation multi-agents permettent de tester ces mécanismes avant de les connecter à des services réels.

La question de recherche est alors plus précise : quel niveau de formalité faut-il pour qu’un agent puisse refuser, renégocier ou déléguer une tâche sans provoquer de blocage collectif ? Il faut étudier à la fois le langage des messages, la stratégie de décision et les garanties offertes lorsque les informations sont incomplètes ou manipulées.

Choisir le bon mécanisme

Le protocole dépend de la décision à prendre et du coût d’un désaccord.

Mécanisme	Utile lorsque	Risque principal
Enchère	Une ressource doit être attribuée selon une valeur déclarée	Manipulation ou information incomplète
Consensus	Tous les participants doivent valider un état commun	Latence et blocage d’un participant
Contract	Un agent accepte une obligation vérifiable	Engagement difficile à tenir
Arbitration	Un tiers doit trancher rapidement	Centralisation et point de défaillance

Ce tableau n’impose pas un choix unique. Il oblige à relier le mécanisme à une hypothèse : les agents peuvent-ils faire confiance aux propositions, attendre une réponse ou accepter une autorité d’arbitrage ?

Décrire un échange minimal

Un message de coordination devrait préciser son contexte et sa durée de validité :

{
  "conversation_id": "task-042",
  "sender": "agent-a",
  "proposal": {"resource": "gpu-2", "duration_min": 20},
  "constraints": ["deadline<10:30", "budget<=3"],
  "expires_at": "2026-09-18T10:15:00Z"
}

L’important n’est pas le format JSON en lui-même. C’est la possibilité de vérifier qui a proposé quoi, sous quelles contraintes et pendant combien de temps. Un accord sans expiration peut devenir une promesse obsolète qui bloque tout le système. Le champ expires_at matérialise un timeout : après cette limite, l’agent doit confirmer, renégocier ou abandonner.

Mesurer le coût de l’accord

La qualité d’un protocole ne se résume pas au nombre d’accords. Mesurez le nombre de messages, le temps de négociation, les propositions retirées, les arbitrages et les cas d’abandon. Un consensus obtenu après plusieurs minutes peut être moins utile qu’une décision locale révisable.

Il faut également tester les comportements adverses ou simplement défaillants : agent silencieux, message dupliqué, capacité surestimée, horloge désynchronisée et proposition contradictoire. Chaque cas doit avoir une sortie documentée.

Gérer le désaccord et l’échec

Un protocole robuste prévoit plusieurs issues, et pas seulement accepted ou rejected. Un agent peut répondre counter-proposal, demander une information manquante, déléguer la tâche ou déclencher un arbitrage. Ces états rendent la conversation lisible et évitent qu’un agent interprète un silence comme un accord.

Le système doit aussi être idempotent : recevoir deux fois le même message ne doit pas créer deux engagements. Un message_id, un numéro de version et une durée d’expiration permettent de détecter les doublons et les messages trop anciens. Cette propriété est particulièrement importante lorsque les messages sont rejoués après une panne réseau.

Un test intéressant consiste à interrompre chaque agent à tour de rôle. Si un seul agent silencieux bloque tout le collectif, le protocole dépend trop d’une autorité unique. Si le système continue toujours sans demander de confirmation, il risque de produire des engagements que personne ne peut tenir.

Un exemple avec trois agents

Imaginons un agent Planner qui décompose une tâche, un agent Researcher qui cherche les sources et un agent Reviewer qui vérifie le résultat. Le protocole pourrait suivre cette séquence :

Planner → Researcher : propose une recherche, budget = 3 appels
Researcher → Planner : accepte, mais demande une source supplémentaire
Planner → Reviewer : soumet le résultat et les contraintes satisfaites
Reviewer → Planner : counter-proposal, citation manquante
Planner → Researcher : renégocie un dernier appel
Researcher → Reviewer : fournit la source et son identifiant
Reviewer → Planner : accepted, avec trace de vérification

Ce scénario permet de mesurer plus que le succès final : nombre de messages, coût des appels, temps de négociation, raisons des refus et capacité à revenir à un état cohérent. Il rend aussi visible la responsabilité de chaque agent.

Pistes à découvrir

Un banc d’essai pourrait comparer une négociation centralisée, une négociation pair à pair et une architecture hybride avec arbitre déclenché seulement en cas de conflit. Les critères seraient le temps d’accord, le nombre de messages, l’équité entre agents, la consommation de ressources et la capacité à sortir d’un cycle.

Une autre piste consiste à apprendre les stratégies de proposition avec du reinforcement learning tout en laissant les engagements dans un contrat vérifiable. On pourrait ainsi distinguer ce qui relève de l’exploration statistique de ce qui doit rester garanti par le protocole. La question ouverte est de savoir si un agent plus autonome rend réellement le collectif plus efficace, ou s’il augmente surtout le coût de vérification.

Concevoir l’interopérabilité

Une API de coordination devrait exposer les capacités, les engagements, les erreurs et les conditions de sortie. Elle ne doit pas imposer la manière dont chaque agent raisonne. Cette séparation permet de remplacer un agent, de rejouer une négociation et de comparer plusieurs stratégies sans réécrire l’infrastructure.

Un protocole devient mature lorsqu’un désaccord reste lisible : on sait ce qui a été proposé, ce qui a été refusé, qui a arbitré et pourquoi le système a finalement continué, attendu ou arrêté.