Choisir entre un agent unique et un essaim multi-agents pour un workflow complexe.
Commencez avec un agent unique + outils. Ne divisez en plusieurs agents que lorsque les limites des tĂąches sont claires, que les fenĂȘtres de contexte dĂ©bordent, ou que diffĂ©rents niveaux de modĂšle sont nĂ©cessaires par sous-tĂąche.
Pourquoi: Le multi-agent ajoute de la latence, une surface d'erreur et des coûts d'orchestration. La plupart des charges de travail de production réussissent avec un agent bien outillé.
L'agent doit raisonner sur les observations avant d'agir Ă nouveau.
ImplĂ©mentez une boucle ReAct (Raisonner + Agir) : le modĂšle gĂ©nĂšre une pensĂ©e, sĂ©lectionne un outil, reçoit le rĂ©sultat et rĂ©pĂšte jusqu'Ă ce qu'une condition d'arrĂȘt soit remplie.
Pourquoi: ReAct rend le raisonnement intermédiaire visible, améliorant la débogabilité et vous permettant d'auditer la chaßne de pensée.
L'agent doit interagir avec des systÚmes externes (API, bases de données, systÚmes de fichiers).
Définissez des outils via l'API tool_use. Le modÚle émet un bloc tool_use ; votre code l'exécute et renvoie un tool_result. Le modÚle continue ensuite.
Référence
L'orchestrateur doit distribuer des sous-tùches hétérogÚnes (revue de code, recherche web, analyse de données).
Utilisez un agent superviseur qui décompose l'objectif, délÚgue à des sous-agents spécialistes et agrÚge les résultats. Chaque sous-agent a son propre prompt systÚme et son propre ensemble d'outils.
Plusieurs sous-agents doivent se coordonner sans communication directe de pair Ă pair.
Acheminez tous les messages inter-agents via un superviseur. Le superviseur décide quel sous-agent s'exécute ensuite, transmet le contexte et applique les contraintes d'ordonnancement.
Pourquoi: La messagerie directe entre pairs crée des cycles et rend l'état difficile à suivre. Un superviseur central maintient le DAG d'exécution explicite.
L'agent doit se souvenir du contexte tout au long d'une session multi-tours.
Passez l'historique complet de la conversation (systĂšme + tours utilisateur/assistant prĂ©cĂ©dents) dans le tableau de messages. Pour les sessions longues, rĂ©sumez les tours plus anciens pour rester dans la fenĂȘtre de contexte.
L'agent a besoin de persistance entre les sessions ou entre les utilisateurs.
Stockez les faits dans une couche de mémoire externe (base de données vectorielle, magasin clé-valeur, fichier). Récupérez les souvenirs pertinents via RAG et injectez-les dans le prompt systÚme à chaque tour.
L'équipe utilise par défaut l'architecture agentique pour chaque fonctionnalité LLM.
N'utilisez pas d'agents lorsqu'un seul prompt + une sortie structurée suffisent. Les agents ajoutent de la latence, des coûts et des modes de défaillance. Réservez les boucles agentiques pour les tùches nécessitant une itération ou l'utilisation d'outils.
Une tùche de raisonnement complexe nécessite plus de délibération interne avant la réponse.
Activez la réflexion étendue avec un paramÚtre budget_tokens. Le modÚle utilise un bloc de pensée avant de répondre, améliorant la précision sur les problÚmes à plusieurs étapes.
Pourquoi: La réflexion étendue échange la latence contre la qualité. Définissez budget_tokens proportionnellement à la complexité de la tùche ; plafonnez-le pour contrÎler les coûts.
Référence
L'appel d'outil renvoie une erreur ; l'agent doit se récupérer gracieusement.
Renvoie l'erreur en tant que tool_result avec is_error: true. Le modÚle voit l'échec et peut réessayer avec des paramÚtres corrigés, essayer un outil alternatif ou expliquer l'échec à l'utilisateur.
Référence
DĂ©faillances transitoires de l'API (429, 529) pendant une boucle agentique.
ImplĂ©mentez une attente exponentielle avec jitter. Pour les 429 (limite de dĂ©bit), respectez l'en-tĂȘte retry-after. Pour les 529 (surchargĂ©), attendez plus longtemps. Ne rĂ©essayez jamais les erreurs de classe 400 aveuglĂ©ment.
Mesurer si un systÚme agentique s'améliore réellement au fil du temps.
Construisez une suite d'évaluation : définissez des paires entrée-sortie, exécutez l'agent, notez les sorties (correspondance exacte, LLM en tant que juge, révision humaine). Suivez le taux de réussite par version.
Pourquoi: Sans évaluations, les ajustements de prompt sont des suppositions. La détection de régression nécessite une notation automatisée et reproductible.
L'agent produit une sortie de mauvaise qualité au premier passage.
Ajoutez une étape de réflexion : aprÚs avoir généré une réponse, invitez le modÚle à critiquer sa propre sortie et à la réviser. Utilisez un tour de message séparé ou une réflexion étendue.
Le workflow agentique effectue des actions irréversibles (suppression de ressources, envoi d'e-mails).
Insérez un point de contrÎle avant les opérations destructrices. Présentez l'action prévue à l'utilisateur, attendez l'approbation, puis exécutez. Enregistrez la décision pour l'audit.