Le même modèle peut sembler être une autre personne avec un autre contexte. Sait-il quel est le but, quels outils il peut employer, ce qui vient d’arriver, quelles règles il ne doit pas enfreindre ? Ces réponses changent directement son action suivante.
Le but de l’ingénierie du contexte n’est pas de montrer davantage au modèle, mais la bonne information, en quantité suffisante et fiable, à chaque étape.
01 / LAYERSRépartir le contexte en quatre couches
Instruction système, objectif utilisateur, historique assistant et résultats d’outils n’ont pas la même responsabilité. Les fondre en un grand bloc dégrade priorité, source et traçabilité. Gardez une couche système pour identité, règles durables, sécurité et conventions de sortie ; une couche tâche pour problème actuel et critère d’acceptation ; une couche trajectoire pour décisions, appels et retours réels ; une couche état pour étapes restantes, temps, budget, échecs et confirmations.
02 / PRACTICELes résultats d’outil doivent revenir au contexte
La boucle d’un agent n’est pas une prose continue. Il agit puis observe à nouveau. Paramètres, résultats et erreurs d’outil doivent entrer au tour suivant ; sinon le modèle confond « je vais faire » et « j’ai fait ». Les systèmes de production ont aussi un nombre maximal d’itérations, une détection de répétition et des conditions d’arrêt claires pour éviter de tourner sur la même erreur. Un plan n’est pas un résultat : seul un retour d’outil vérifiable fait avancer l’agent.
03 / CACHE-AWAREPlacer le contenu stable au début et le contenu changeant à la fin
KV Cache et prompt cache favorisent un préfixe stable. Gardez règles système, définitions d’outils fixes et quelques bons exemples dans le même ordre ; placez question actuelle, résultats d’outils et panneau d’état à la fin où ils changent. Ce n’est pas qu’une optimisation : cela force à distinguer règle durable et état temporaire d’une tâche.
04 / PRACTICEUn prompt système organise un processus
Un prompt système utile énonce rôle et objectif, puis workflow, règles d’outils, format de sortie et quelques limites. Davantage de règles n’est pas toujours plus sûr ; des règles contradictoires sans priorité sont difficiles à exécuter. Transformez les exigences abstraites en actions observables. Utilisez quelques exemples pour les cas limites. Traitez les matériaux externes comme entrées non fiables afin qu’une injection ne remplace pas la règle système. La description d’un outil doit dire quand l’utiliser, le sens des entrées, son échec et ses effets.
05 / PRACTICECharger les Skills à la demande et garder la direction avec l’état
Le savoir métier n’a pas à résider en permanence dans le contexte. Chargez un Skill lorsqu’une tâche correspond pour fournir méthode, modèle ou convention ; utilisez un panneau d’état court pour progrès, temps et prochaine action. Le Skill répond à « comment faire ce genre de travail ? », l’état à « où en est ce travail ? ».
06 / COMPRESS OR ISOLATEIsoler avant de compresser
Les tâches longues ne peuvent empiler la conversation brute sans limite. Conservez par couches originaux récents, résumés d’étapes, faits clés et archives externes. Lorsque les sous-tâches sont indépendantes, l’isolement est souvent plus fiable que la compression : un sous-agent vérifie les dates, un autre les citations, puis les conclusions sont combinées. Chaque contexte est plus court et se contamine moins. Premier exercice : retirez instruction système, description d’outil, trajectoire ou panneau d’état, puis observez la première étape où l’agent faiblit.
Livre source et références du chapitre
- bojieli/ai-agent-book.
- Chapter 2 — context engineering.
- Chapter 2 experiments.
- Cette page réorganise la pratique sans remplacer le livre source ; utilisez texte et code sources pour les formulations exactes.
COMMENTAIRES DES LECTEURS
Notez l’idée que cet article vous a laissée.
Aucun commentaire. Vous pouvez laisser le premier.