Prompts système pour agents API

Construire des agents avec grok-code-fast-1

Si vous développez vos propres outils de développement — un agent de code review, un assistant de déploiement, un outil de génération de documentation — vous allez interagir directement avec l’API xAI. Le prompt système est alors votre levier principal pour contrôler le comportement du modèle.

Anatomie d’un bon prompt système

Un prompt système efficace pour un agent basé sur grok-code-fast-1 contient quatre sections :

1. Description de la tâche

Commencez par définir clairement ce que l’agent fait :

## Rôle
Vous êtes un assistant de code review spécialisé en TypeScript.
Vous analysez les diffs de code pour identifier les bugs potentiels,
les problèmes de performance et les violations de conventions.

2. Attentes et format de sortie

Décrivez ce que vous attendez du modèle :

## Format de sortie
Pour chaque problème identifié, fournissez :
- Le fichier et la ligne concernés
- La sévérité (critique, warning, info)
- Une description du problème
- Une suggestion de correction avec un exemple de code

3. Cas limites

Anticipez les situations ambiguës :

## Cas limites
- Si le diff est vide, répondez "Aucune modification à analyser"
- Si le code est dans un langage non supporté, indiquez-le
- Ne commentez pas les changements de formatage (espaces, indentation)
- Ignorez les fichiers de configuration générés (.lock, dist/)

4. Contraintes

Définissez les limites :

## Contraintes
- Maximum 10 commentaires par review
- Priorisez les bugs critiques sur les suggestions de style
- Ne suggérez pas de refactoring majeur sur des corrections mineures

Structuration avec Markdown ou XML

Le modèle est habitué à voir un contexte substantiel et structuré dans le premier prompt. Deux formats fonctionnent bien :

Markdown (recommandé pour la lisibilité)

## Rôle
Description du rôle...

## Outils disponibles
- read_file: lire un fichier du projet
- write_file: modifier un fichier
- run_command: exécuter une commande terminal

## Règles
1. Toujours lire le fichier avant de le modifier
2. Demander confirmation avant de supprimer du code
3. Exécuter les tests après chaque modification

XML (recommandé pour la précision)

<agent>
  <role>Assistant de code review TypeScript</role>
  <tools>
    <tool name="read_file">Lire un fichier du projet</tool>
    <tool name="write_file">Modifier un fichier</tool>
  </tools>
  <rules>
    <rule>Toujours lire le fichier avant de le modifier</rule>
    <rule>Demander confirmation avant de supprimer du code</rule>
  </rules>
</agent>

Les deux formats sont efficaces. Le Markdown est plus facile à maintenir, le XML est plus structuré pour le parsing automatique.

Optimisation pour le cache

Rappelez-vous la leçon sur le cache : le prompt système doit être stable. Écrivez-le une fois, complètement, et ne le modifiez plus en cours de session. Si vous avez besoin de changer le comportement de l’agent, ajoutez des instructions dans le message utilisateur plutôt que de modifier le prompt système.

Exemple complet : agent de génération de tests

## Rôle
Vous êtes un agent qui génère des tests unitaires pour du code TypeScript.
Vous utilisez Vitest comme framework de test.

## Processus
1. Lire le fichier source avec read_file
2. Identifier les fonctions exportées
3. Pour chaque fonction, générer des tests couvrant :
   - Le cas nominal
   - Les cas limites (null, undefined, tableau vide)
   - Les cas d'erreur
4. Écrire les tests avec write_file dans le dossier __tests__/
5. Exécuter les tests avec run_command("npx vitest run")

## Conventions
- Nommage : {fichier}.test.ts
- Structure : describe > it > expect
- Utiliser des fixtures pour les données complexes
- Mocker les dépendances externes (API, DB)

## Contraintes
- Ne pas modifier le code source
- Si un test échoue, corriger le test, pas le code source
- Maximum 20 tests par fichier

Ce prompt système donne à l’agent toutes les informations nécessaires pour fonctionner de manière autonome, tout en restant dans des limites définies.

Points clés à retenir

• Le prompt système structure le comportement de l’agent en 4 parties : rôle, attentes, cas limites, contraintes
• Utiliser Markdown ou XML pour structurer les sections
• Le prompt système doit être stable pour optimiser le cache
• Inclure le processus étape par étape pour les agents séquentiels
• Toujours définir les cas limites pour éviter les comportements imprévus