Un agent IA est un modèle de langage qui tourne en boucle avec des outils : il décide quoi faire, appelle un outil, lit le résultat et continue jusqu’à ce que la tâche soit terminée. Rédiger des prompts pour un agent diffère de le faire pour une réponse unique. Vous n’écrivez plus une question. Vous écrivez le mode d’emploi de quelque chose qui prendra de nombreuses décisions sans vous.
Workflow ou agent
Décidez d’abord si vous avez besoin d’un agent.
| Workflow IA | Agent IA | |
|---|---|---|
| Qui décide des étapes | Votre code | Le modèle |
| Prévisibilité | Élevée | Moindre |
| Coût et latence | Plus faibles, connus d’avance | Plus élevés, variables |
| Adapté à | Des tâches à procédure connue | Des tâches dont le chemin dépend de ce qu’on trouve |
| Débogage | Étape par étape | Lire toute la trace |
Si vous pouvez dessiner l’organigramme, construisez un workflow avec le chaînage de prompts. Utilisez un agent quand le nombre et l’ordre des étapes ne peuvent pas être connus d’avance, comme pour enquêter sur un bogue ou rechercher une réponse.
Les parties d’un prompt d’agent
Le comportement d’un agent vient de quatre choses qu’il lit : le prompt système, les définitions d’outils, la tâche et les résultats qui reviennent. Chacune demande une rédaction réfléchie.
1. Le prompt système
Couvrez six points.
Rôle et objectif. À quoi sert l’agent, en deux phrases.
Règles de fonctionnement. Comment travailler : enquêter avant de modifier quoi que ce soit, privilégier de petites étapes, vérifier les résultats.
Limites. Ce qu’il ne doit pas faire et ce qui nécessite une approbation.
Gestion des problèmes. Erreurs d’outils, information manquante, ambiguïté.
Quand s’arrêter. La condition qui signifie que la tâche est terminée, et une limite d’effort.
Comment rendre compte. Ce que contient la réponse finale.
You are a coding agent working in the user's repository.
## How to work
- Read the relevant files before proposing a change.
- Make the smallest change that satisfies the task.
- After editing, run the tests that cover the change.
## Boundaries
- Do not modify files outside the repository.
- Do not delete files or run destructive commands without asking.
- Do not change public interfaces unless the task says so.
## When things go wrong
- If a command fails, read the error and try a different approach once.
If it fails again, stop and report what you tried.
- If the task is ambiguous, ask one question before starting.
## When to stop
- Stop when the acceptance criteria are met and the tests pass.
## Final report
- What changed and why, files touched, how it was verified, and
anything left undone.
Expliquez la raison d’une règle quand elle n’est pas évidente. Un agent rencontre des situations que vous n’avez pas listées, et une règle assortie d’une raison généralise mieux qu’une interdiction nue.
2. Définitions d’outils
Le modèle choisit les outils en lisant leurs noms et leurs descriptions. Des définitions vagues sont la cause la plus courante d’un agent qui utilise le mauvais outil.
- Nommez les outils d’après ce qu’ils font :
search_orders, pasquery2. - Décrivez quand utiliser chacun, et quand ne pas le faire.
- Dites ce qui revient, y compris le format et les limites.
- Rendez les paramètres univoques : types, formats, valeurs autorisées, un exemple.
- Évitez les outils qui se chevauchent. Si deux outils peuvent faire le travail, le modèle choisira de façon incohérente.
- Renvoyez des erreurs exploitables : « la date doit être AAAA-MM-JJ », pas « entrée invalide ».
Peu d’outils bien décrits valent mieux qu’un grand ensemble d’outils semblables. Le Model Context Protocol standardise la façon dont les outils sont décrits et proposés aux agents.
3. Le prompt de tâche
Donnez à l’agent une spécification, pas une phrase. Plus il a d’autonomie, plus le brief de départ compte.
## Objective
Add rate limiting to the public API.
## Requirements
- 100 requests per minute per API key.
- Return 429 with a Retry-After header when exceeded.
## Constraints
- Existing clients must keep working: no changes to response schemas.
## Acceptance criteria
- New tests cover the limit and the 429 response.
- The existing test suite passes.
Les critères d’acceptation donnent à l’agent un moyen de savoir qu’il a terminé, et à vous un moyen de vérifier. L’extension VS Code PromptFlowEngine transforme une tâche d’une ligne en cette structure et joint les fichiers pertinents.
4. Gestion du contexte
Tout ce que l’agent lit reste dans son contexte et est relu à chaque étape. Laissé à lui-même, le contexte se remplit de sorties d’outils périmées, le coût grimpe et la qualité baisse.
- Renvoyez des résultats d’outils compacts. Les champs nécessaires, pas toute la charge.
- Résumez ou supprimez les anciens résultats une fois utilisés.
- Gardez des notes durables hors du contexte, dans un fichier que l’agent peut lire et mettre à jour, pour les longues tâches.
- Déléguez. Confiez une sous-tâche autonome à un sous-agent avec un contexte neuf et ne reprenez que sa conclusion.
Voir l’optimisation des tokens.
Écrire des prompts pour des sous-agents
Quand un agent briefe un autre, le brief est tout ce que sait le destinataire. Un bon prompt de délégation énonce :
- L’objectif et pourquoi il compte.
- Ce qui est déjà connu, pour ne pas répéter le travail.
- La sortie exacte voulue, et son format.
- Les limites : ce qu’il faut toucher et ce qu’il faut laisser tranquille.
Un agent orchestrateur qui rédige des briefs vagues reçoit en retour un travail vague. C’est un endroit où un contrôle automatique aide : un agent peut passer son brouillon de brief dans les outils MCP de PromptFlowEngine pour repérer un objectif ou un format de sortie manquant avant de déléguer.
Sécurité pour les agents
Les agents agissent ; les erreurs et les attaques ont donc des conséquences.
- Moindre privilège. Chaque outil a la permission la plus étroite qui fonctionne. Lecture seule par défaut.
- Approbation pour les actions irréversibles. Supprimer, envoyer, payer, déployer.
- Traitez les résultats d’outils comme non fiables. Une page web ou un fichier peut contenir des instructions visant l’agent. Voir l’injection de prompt.
- Limites. Nombre maximal d’étapes, dépense maximale et délais d’expiration.
- Gardez les secrets hors du contexte. Donnez les identifiants directement aux outils. Voir la détection des données personnelles et des secrets.
- Journalisez chaque appel d’outil afin qu’une exécution puisse être revue.
Modes de défaillance courants
| Symptôme | Cause probable | Correction |
|---|---|---|
| Boucle sur la même action | Pas de règle d’arrêt ni de limite d’étapes | Ajouter les deux |
| Déclare le succès trop tôt | Pas de critères d’acceptation | Les définir ; exiger une vérification |
| Utilise le mauvais outil | Descriptions qui se chevauchent ou vagues | Réécrire les descriptions d’outils |
| En fait bien plus que demandé | Périmètre non énoncé | Énoncer explicitement les limites |
| Oublie des instructions antérieures | Contexte surchargé | Élaguer les résultats, résumer, utiliser des notes |
| Suit du texte trouvé dans un fichier | Contenu non fiable non marqué | Le marquer comme données ; restreindre les outils |
Évaluer les agents
Notez le résultat, pas le chemin : les tests ont-ils réussi, le bon enregistrement a-t-il été mis à jour, la réponse est-elle correcte ? Examinez ensuite les traces pour repérer les étapes inutiles et les actions risquées. Gardez un ensemble de tâches aux résultats connus comme bons et relancez-le quand le prompt, les outils ou le modèle changent. Voir les tests et l’évaluation de prompts.
Pour la boucle de raisonnement qui sous-tend tout cela, voir le prompting ReAct.