# Comment éviter qu’une longue session de code perde son contexte ? > Évitez la perte de contexte en déplaçant les faits durables du chat vers un registre compact des tâches, décisions, tests et points de contrôle du dépôt. Avant une compression ou un changement de modèle, restaurez l’état depuis ces artefacts au lieu de rejouer une conversation illimitée. Les longues sessions échouent généralement par dérive, pas par amnésie soudaine. L’agent se souvient du but général, mais perd une petite contrainte, fait confiance à un test obsolète, répète une enquête ou édite selon un plan qui ne correspond plus au dépôt. La solution est un état externe durable, plus court et plus fiable que la conversation. Traitez la conversation comme mémoire de travail et le dépôt comme source de vérité. À chaque point de contrôle utile, notez ce qui a changé, ce qui est vérifié, ce qui reste incertain et la prochaine action. ## Suivez quatre types de contexte Séparez les faits par fonction afin que le résumé ne devienne pas un récit indifférencié. | Type | Exemples | Emplacement durable | |---|---|---| | Objectif | Résultat utilisateur et critères d’acceptation | Registre des tâches | | Contraintes | Compatibilité, sécurité, style et portée | Registre des tâches | | État du dépôt | Fichiers modifiés et branche actuelle | Contrôle de version | | Preuves | Tests, logs, captures et benchmarks | Registre de vérification | Ajoutez les hypothèses comme cinquième catégorie uniquement si elles sont clairement signalées. Chacune doit indiquer l’action la moins coûteuse pour la confirmer ou l’écarter. ## Maintenez un registre compact Un registre utile tient sur un écran. Mettez-le à jour après les jalons, pas après chaque message. ```md Objective: Ship model-switch support without changing existing tool behavior. Constraints: * Preserve the public API. * No destructive migration. Current state: * Parser adapter added in src/stream.ts. * Unit tests pass; cancellation test still fails. Decisions: * Buffer tool arguments until the final event. Evidence: * npm test: 142 passed, 1 failed. Next action: Fix duplicate execution after stream cancellation. ``` Conservez les chemins, commandes et noms d’échec exacts. Évitez un journal de la discussion. ## Placez les points de contrôle sur des états vérifiés Un point de contrôle doit suivre un résultat reproductible : groupe de tests réussi, petit changement confirmé, réponse API vérifiée ou décision appuyée par un cas. Enregistrez les fichiers non validés avant de changer de modèle ou de compresser. Ne déclarez pas une fonction opérationnelle parce que le code est écrit ; liez l’affirmation à un test, un build ou un artefact observable. | Affirmation | Preuve nécessaire | |---|---| | Le parseur accepte deux appels | Cas avec deux IDs corrélés | | La nouvelle tentative est sûre | Test d’idempotence avec déconnexion | | Le refactoring préserve le comportement | Ancienne et nouvelle suites réussissent | | L’interface est correcte | Inspection rendue aux tailles cibles | ## Relisez la source au lieu de rejouer le chat Lorsqu’un détail compte, rouvrez le fichier, le schéma ou le document officiel actuel. Un ancien extrait peut décrire du code déjà modifié. Donnez des chemins et termes de recherche pour inspecter l’état présent. La récupération doit rester ciblée : chargez interface, implémentation, test en échec et log pertinent avant le dépôt entier. Cela laisse de la place au raisonnement. ## Compressez en conservant décisions et preuves Une bonne compression retire la répétition, mais garde contraintes, décisions difficiles à annuler, alternatives rejetées et vérifications. Distinguez `verified`, `observed`, `assumed` et `pending`. Ne résumez pas une expérience ratée comme conception finale. Conservez la raison du rejet si la même approche peut réapparaître. ## Limitez la sortie des outils Les longs logs et fichiers générés consomment vite l’attention. Demandez des plages, comptes ou lignes correspondantes ; stockez la sortie complète comme artefact et renvoyez un résumé avec son chemin. Pour les tests, gardez la première trace utile, l’assertion et les détails d’environnement, pas des centaines de cadres répétés. ## Reprenez avec un rituel déterministe Après une pause, une compression ou un changement de modèle : * Lisez l’objectif et les contraintes. * Inspectez le contrôle de version et les changements récents. * Ouvrez les fichiers cités dans l’état actuel. * Relancez la dernière vérification pertinente. * Confirmez que l’action suivante reste valide. Cette routine détecte les résumés périmés avant de nouvelles modifications. ## Choisissez les modèles sans dépendre de la mémoire Une gateway facilite le changement, mais l’état reste sous votre responsabilité. Atlas Cloud propose plusieurs protocoles depuis une URL de base ; consultez la [matrice des protocoles](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) et le [catalogue de modèles](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) avant de déplacer un agent actif. Donnez au remplaçant le registre, les fichiers pertinents et une vérification récente. Ne dépendez pas d’identifiants propres au fournisseur sans confirmer protocole et comportement. ## Conclusion Les longues sessions gardent leur contexte lorsque l’état durable est compact, étayé et facile à recharger. Maintenez un registre d’un écran, créez des points de contrôle après des changements vérifiés, relisez la source actuelle, limitez les sorties et utilisez une reprise déterministe. Une grande fenêtre aide, mais un état externe discipliné rend le travail récupérable. ## FAQ ### Une fenêtre de contexte plus grande suffit-elle pour une longue session ? Non. Elle retarde la pression, mais ne garantit pas que les anciennes contraintes restent visibles ni que les observations obsolètes soient corrigées. ### Que doit contenir le registre d’une session ? L’objectif, les contraintes, le plan actuel, les fichiers modifiés, les décisions, les vérifications, les risques ouverts et la prochaine action exacte. ### Quand l’agent doit-il créer un point de contrôle ? Après un changement d’état significatif : test réussi, étape terminée, décision de conception ou découverte modifiant le plan. ### Faut-il coller toute la conversation dans un nouveau modèle ? Généralement non. Fournissez un point de contrôle sélectionné, les fichiers et journaux utiles, puis laissez le modèle inspecter l’état actuel. ### Comment empêcher un résumé de conserver une erreur ancienne ? Séparez faits vérifiés et hypothèses, joignez des commandes ou chemins comme preuves et retirez toute affirmation contredite par de nouveaux tests. ### Quelle est la reprise la plus sûre après une interruption ? Rechargez le registre, inspectez le contrôle de version, relancez la dernière vérification pertinente et partez de l’action suivante enregistrée.