01
Le diagnostic commence par trois états différents
Une sortie coupée par max-tokens ne signifie pas automatiquement que la session est corrompue. Dans une interface d’Agent, plusieurs couches peuvent donner une impression similaire : le texte visible peut s’arrêter alors que le tour est correctement enregistré, la requête peut échouer côté modèle, ou bien l’historique persistant peut ne plus permettre de reconstruire une requête valide.
Nous séparons donc trois états.
1. Sortie interrompue, session encore exploitable
Le premier cas est le moins grave. L’interface accepte encore la saisie, le modèle sélectionné reste affiché, les contrôles de la session répondent et aucun message d’erreur durable n’apparaît. La dernière réponse est simplement incomplète.
Le signal important n’est pas la longueur visible du texte, mais la présence d’une fin de tour cohérente dans le journal. L’architecture officielle décrit les événements turn/*, step/*, assistant/* et tool/* comme des événements persistants ; le journal sert ensuite à reconstruire l’historique présenté au modèle. La documentation d’architecture décrit le flux de tour et les événements persistants.
Dans ce cas, une demande courte et sans effet de bord permet de vérifier si la session peut réellement repartir. Il ne faut pas immédiatement relancer une commande de modification, une migration ou un script de déploiement. Une demande de lecture, de résumé de l’état courant ou de confirmation du dernier événement offre un test plus propre.
Arrêt immédiat si :
- la demande de test déclenche une nouvelle erreur au même point ;
- l’Agent prétend avoir exécuté une action dont aucune trace n’existe ;
- le dernier outil laisse un résultat incomplet ou contradictoire ;
- l’interface répond, mais le modèle reçoit une histoire différente de celle affichée.
2. Échec reproduit au même emplacement
Lorsque la reprise échoue toujours après le même message, le même résultat d’outil ou le même changement de modèle, il faut arrêter les tentatives successives. Répéter une requête dans cet état peut multiplier les appels, produire de nouveaux événements ambigus et compliquer la comparaison entre l’état initial et l’état après incident.
Conservez d’abord une copie des journaux, des paramètres de lancement, de la version installée et du répertoire de travail. Ensuite, comparez trois facteurs :
- l’emplacement exact de l’échec dans l’historique ;
- le modèle et les options utilisés lors de la requête ;
- le dernier outil ou contenu injecté avant l’interruption.
Un échec lié à une réponse tronquée n’a pas la même signature qu’une limitation du fournisseur ou qu’une erreur du modèle. Dans le premier cas, l’ancienne session peut parfois redevenir exécutable après correction du traitement de fin de réponse. Dans le deuxième, une nouvelle session avec le même historique peut échouer de manière identique. Dans le troisième, le comportement peut changer avec un autre modèle ou une requête minimale.
Ne supprimez pas les journaux pour « repartir proprement ». Une suppression détruit précisément les éléments qui permettent de savoir si l’échec se produit pendant la relecture, la reconstruction du contexte ou l’appel au modèle.
3. Session visible mais impossible à exécuter
Une page qui s’ouvre ne prouve pas que l’ancienne session est récupérable. L’interface peut charger le titre, certains messages ou des métadonnées tout en échouant au moment de construire la prochaine requête.
La comparaison la plus utile consiste à créer une session neuve dans le même environnement, avec le même modèle et une demande sans effet de bord. Si la nouvelle session fonctionne mais que l’ancienne échoue, le problème doit être limité en priorité à l’état persistant ou à la compatibilité de l’historique.
La documentation officielle indique que le journal de session est la source du contexte présenté au modèle et que deriveMessages() projette l’historique à partir de ce flux. Elle précise également qu’un contenu visible par le modèle doit pouvoir être reconstruit depuis le journal. Le fonctionnement du journal et de la reconstruction de l’historique est détaillé dans la documentation officielle.
Cette distinction est essentielle pour répondre à la question souvent posée après une coupure : peut-on encore interroger DeepSeek Harness ? Oui, si la prochaine requête peut être assemblée à partir d’un historique cohérent. Non, si l’interface ne fait qu’afficher une session dont les événements nécessaires à la reprise sont manquants ou incompatibles.
