SKILL.md — Modèle d'Acteur Agha : Conception de Systèmes d'Agents Concurrents
Points de Décision
Choix de la Stratégie de Création d'Acteur en Fonction du Type de Tâche
SI la tâche a des dépendances séquentielles :
├─ Utiliser le modèle client : créer un enfant avec une adresse de réponse
├─ Passer l'adresse du client à l'enfant en paramètre
└─ L'enfant envoie le résultat directement au client (pas au parent)
SI la tâche nécessite un long calcul :
├─ Créer un acteur insensible pour le calcul
├─ Transférer les messages entrants à un acteur tampon
└─ Reprendre depuis le tampon lorsque le calcul est terminé
SI la tâche nécessite une allocation dynamique de ressources :
├─ Créer des acteurs gestionnaires de ressources à la demande
├─ Passer les capacités (adresses) comme données de message
└─ Pas de registre central - les adresses circulent dans le système
SI la tâche a des exigences d'isolation des pannes :
├─ Créer des acteurs enfants supervisés pour les opérations risquées
├─ Le superviseur détecte les pannes via les réponses manquantes
└─ Remplacer les acteurs défaillants sans affecter les autres
SI vous composez des systèmes d'agents existants :
├─ Vérifier que l'interface préserve la structure causale
├─ Tester le comportement en composition (pas seulement en isolation)
└─ Utiliser les protocoles de messages comme frontières (pas l'état partagé)
Arbre de Décision : Envoi de Message vs Remplacement d'État
SI une coordination avec d'autres agents est nécessaire :
├─ ENVOYER des messages (ne pas modifier l'état local d'abord)
├─ Inclure une adresse de réponse si une réponse est attendue
└─ Ne jamais supposer un ordre des messages
SI un calcul local est nécessaire :
├─ SPÉCIFIER un comportement de remplacement
├─ Encapsuler le nouvel état (ne pas exposer les détails internes)
└─ Assurer un traitement un-message-à-la-fois
SI une mise à l'échelle dynamique est nécessaire :
├─ CRÉER de nouveaux acteurs avec des comportements spécifiques
├─ Passer les adresses nécessaires aux nouveaux acteurs
└─ Pas d'état d'initialisation partagé
Modes de Défaillance
1. Anti-patron de l'Orchestrateur Central
Détection : Si vous voyez un acteur router tous les messages ou détenir tout l'état du système Symptômes : Point de défaillance unique, goulot d'étranglement sous charge, problème de régression infinie Correctif : Décomposer en une communauté d'acteurs, chacun ne connaissant que le contexte local, utiliser le routage par capacité
2. Erreur de Blocage Synchrone
Détection : Si des acteurs attendent/bloquent pour des réponses au lieu de spécifier un comportement de remplacement Symptômes : Interblocage sous charge, hypothèses de temporisation cachées, concurrence réduite Correctif : Modéliser en paires de messages requête-réponse, utiliser le modèle client pour les dépendances, appliquer le patron d'acteur insensible
3. Contamination de l'État Partagé
Détection : Si plusieurs acteurs lisent/écrivent la même structure de données (même avec des verrous) Symptômes : Conditions de concurrence, goulots d'étranglement séquentiels, état global caché Correctif : Encapsuler l'état dans un seul acteur, utiliser le passage de messages pour la coordination, l'exclusion mutuelle est gratuite
4. Vérification Uniquement par les Sorties
Détection : Si les tests ne comparent que les sorties finales sans vérifier les modèles d'interaction Symptômes : Anomalie de Brock-Ackerman - sorties identiques mais comportement de composition différent Correctif : Vérifier la préservation de la structure causale, tester le comportement en composition, utiliser l'équivalence d'observation
5. Hypothèse de Topologie Statique
Détection : Si le graphe de communication est fixé au démarrage sans reconfiguration à l'exécution Symptômes : Impossible de gérer les systèmes ouverts, pas de gestion dynamique des ressources, fragile face au changement Correctif : Traiter les adresses comme des données de première classe, implémenter le routage par capacité, prendre en charge les changements de topologie à l'exécution
Exemples Concrets
Exemple 1 : Décomposition de Tâches avec le Modèle Client
Scénario : Un agent doit traiter une requête complexe nécessitant des sous-tâches séquentielles A → B → C, mais doit rester réactif à d'autres messages.
Approche Novice :
recevoir requête →
bloquer en appelant la sous-tâche A
bloquer en appelant la sous-tâche B
bloquer en appelant la sous-tâche C
envoyer le résultat final
Application Experte du Modèle d'Acteur :
recevoir requête →
créer un acteur client_BC avec les adresses pour B, C, et le destinataire final
envoyer la requête de sous-tâche A à A_processeur avec client_BC comme adresse de réponse
spécifier le comportement de remplacement : prêt pour la prochaine requête
client_BC reçoit le résultat de A →
envoyer le résultat à B_processeur avec client_C comme adresse de réponse
client_C reçoit le résultat de B →
envoyer le résultat à C_processeur avec destinataire_final comme adresse de réponse
Décisions Clés Prises :
- Utilisation du modèle client pour éviter le blocage
- Chaque étape crée le client suivant dans la chaîne
- L'agent d'origine reste réactif tout au long du processus
- Une défaillance dans une sous-tâche n'affecte que cette chaîne
Exemple 2 : Récupération après Panne avec Supervision
Scénario : Le système doit gérer les défaillances d'agents sans les propager à l'ensemble du système.
Approche Novice : Try-catch autour des appels d'agents, redémarrer tout en cas de défaillance.
Application Experte :
superviseur crée acteur_travailleur →
envoie la tâche au travailleur avec un délai de réponse
spécifie le remplacement : "en_attente_de_reponse"
SI une réponse est reçue dans le délai →
transmettre le résultat au client
spécifier le remplacement : "prêt"
SI le délai expire →
créer un nouvel acteur_travailleur (l'ancien a échoué)
renvoyer la tâche au nouveau travailleur
spécifier le remplacement : "en_attente_de_reponse"
Compromis Navigués :
- La supervision est une préoccupation distincte de la logique métier
- Les acteurs défaillants sont isolés et remplacés, non réparés
- Équilibre entre détection de délai et livraison garantie
- Aucun état partagé entre le superviseur et les travailleurs
Gates de Qualité
- Aucun acteur ne bloque sa boucle de traitement de messages (patron d'acteur insensible appliqué si nécessaire)
- Toute la coordination utilise le passage de messages (pas d'état mutable partagé entre acteurs)
- La livraison des messages est garantie mais l'ordre n'est pas présumé
- Les adresses sont traitées comme des données de première classe pour le routage par capacité
- Chaque acteur spécifie un comportement de remplacement pour chaque type de message
- La création d'acteurs se fait dynamiquement en fonction des besoins de calcul
- L'isolation des pannes empêche les défaillances en cascade entre les frontières des acteurs
- La topologie du système peut se reconfigurer à l'exécution sans registre central
- Le comportement en composition est vérifié, pas seulement le comportement isolé des composants
- Les opérations synchrones sont modélisées comme des paires de messages requête-réponse
Limites de cette Compétence
Cette compétence ne doit PAS être utilisée pour :
- Les calculs séquentiels simples → utiliser la programmation fonctionnelle à la place
- Les systèmes où la mémoire partagée est physiquement nécessaire → utiliser des modèles de concurrence basés sur les verrous
- Les systèmes temps réel avec des contraintes de temps strictes → utiliser le passage de messages synchrone avec une analyse temporelle formelle
- Les calculs mathématiques sans coordination → utiliser des approches fonctionnelles pures
Déléguer à d'autres compétences lorsque :
- Implémentation de frameworks d'acteurs spécifiques → utiliser des guides d'implémentation propres à la plateforme
- Optimisation des performances des systèmes d'acteurs → utiliser la compétence [optimisation-des-performances]
- Vérification formelle des propriétés des acteurs → utiliser la compétence [méthodes-formelles]
- Conception de bases de données pour la persistance des acteurs → utiliser la compétence [architecture-des-données]
Idées reçues courantes sur le périmètre :
- Les acteurs ne sont pas simplement des "objets avec des méthodes asynchrones" - ils nécessitent le triple complet de réponse
- Le modèle d'acteur n'est pas réservé aux systèmes distribués - il s'applique à tout calcul concurrent
- Ce n'est pas principalement une optimisation des performances - c'est un cadre pour la correction et la compositionnalité