Prompts d'agents : orchestration multi-étapes sans se perdre

Un agent = un LLM dans une boucle : il planifie, appelle des outils, observe le résultat, corrige, et recommence. Le prompt système de l\'agent définit cette boucle. Voici l\'architecture qui évite les boucles infinies et les dérives.

1. Le cycle ReAct (Reason + Act)

PENSÉE : [analyse de la situation, quelle action prendre]
        ACTION : [nom_outil, paramètres]
        OBSERVATION : [résultat de l'outil]
        ... (répétition jusqu'à réponse finale)

        RÉPONSE FINALE : [réponse à l'utilisateur]

2. System prompt agent minimal

Tu es un agent [rôle : ex. analyste recherche, assistant devops].
        Tu fonctionnes en boucle PENSÉE → ACTION → OBSERVATION.

        OUTILS DISPONIBLES :
        - search_web(query) → résultats
        - read_file(path) → contenu
        - write_file(path, content) → confirmation
        - run_code(lang, code) → stdout/stderr

        RÈGLES :
        - Une seule ACTION par tour.
        - Max 10 tours. Si non résolu : RÉPONSE FINALE avec ce qui a été fait.
        - Jamais d'action destructive sans confirmation explicite utilisateur.
        - Cite tes sources (outil + résultat).

3. Planification explicite (Plan-and-Execute)

Pour les tâches > 3 étapes, forcez une phase de planification avant d\'agir :

PENSÉE : Je vais d'abord établir un plan.
        PLAN :
        1. [étape 1 - outil visé]
        2. [étape 2 - outil visé]
        3. [étape 3 - outil visé]
        CRITÈRE DE SUCCÈS : [condition mesurable]

        Puis j'exécute l'étape 1.

4. Garde-fous anti-dérive

• Budget de tours : max 5-10 itérations, puis réponse finale forcée.
• Détection de boucle : même action + mêmes params 2x → stop.
• Validation de sortie : schéma JSON attendu, rejet si invalide.
• Confirmation destructive : write/delete/send → pause utilisateur.

5. Évaluation d\'agent : le golden set

Testez votre agent sur 20-50 scénarios figés (entrée → sortie attendue + trace d\'outils). Mesurez : taux de succès, nombre de tours, coûts tokens, erreurs d\'outil. C\'est le seul moyen de savoir si un changement de prompt améliore ou casse l\'agent.

Architectures d\'agents prêtes à l\'emploi (recherche, code, analyse, support) dans les packs de prompts.