Selon la documentation officielle de DeepSeek, les réponses d’API peuvent notamment signaler une requête mal formée, une authentification invalide, un solde insuffisant, une limite de débit, une erreur serveur ou une surcharge. Cela représente déjà plusieurs familles de causes, qui ne doivent pas recevoir le même traitement. (api-docs.deepseek.com)

Symptôme : DeepSeek Harness affiche encore « en cours », répète l’attente ou ne produit aucun résultat exploitable.

Solution la plus rapide : vérifiez d’abord qu’un nouvel événement de relance et qu’un début de requête existent réellement. Sans preuve de progression, arrêtez la tâche, conservez les journaux et relancez un test minimal dans un environnement vérifié.

Cette méthode s’adresse à trois profils :

  • Vous utilisez DeepSeek Harness en local et ne savez pas si le processus travaille encore.
  • Vous exploitez des agents distants et devez définir une limite d’attente sans surveillance humaine.
  • Vous administrez une plateforme et cherchez à corréler journaux de relance, disponibilité de l’API, outils et état du système.

Commencez par prouver que la relance existe

Cas de départ : l’interface attend, mais aucun nouvel appel n’apparaît

Vous lancez une tâche d’analyse de code, de montage vidéo ou de génération de contenu audio. L’interface reste animée. Pourtant, aucun nouvel appel vers le modèle n’apparaît dans les journaux. Il n’y a pas non plus de nouvelle transition d’état, de sortie d’outil ou d’activité du processus.

Ce cas ne prouve pas que DeepSeek Harness effectue une relance. Une animation de chargement n’est qu’un signal d’interface. Elle peut rester visible alors que la session est suspendue dans une approbation, un Hook, une commande Bash ou un processus enfant.

L’API de DeepSeek est sans état : l’historique nécessaire à une conversation à plusieurs tours doit être renvoyé par le client à chaque requête. Une session d’Agent peut donc progresser dans sa logique locale sans qu’un nouvel appel réseau soit immédiatement visible. (api-docs.deepseek.com)

Vérifiez successivement :

  1. L’identifiant de tâche et l’identifiant de session.
  2. Le dernier événement persistant connu.
  3. L’existence d’une entrée indiquant qu’une relance a été planifiée.
  4. L’existence d’une entrée distincte indiquant que cette relance a commencé.
  5. L’heure du dernier appel réseau.
  6. La progression du processus principal et de ses processus enfants.
  7. La présence d’une demande d’approbation ou d’un outil en attente.
Signal observé Hypothèse raisonnable Action immédiate
Événement de relance planifiée, mais aucun événement de démarrage Relance annulée, processus interrompu ou file locale bloquée Sauvegarder les journaux et vérifier l’état du processus
Nouvel appel réseau visible, réponse absente Réseau, délai amont ou service indisponible Contrôler la connexion et la réponse HTTP
Réponse du modèle visible, aucun outil terminé Blocage dans l’exécution de l’outil Examiner approbation, Hook, Bash et processus enfant
Aucun événement après le dernier message utilisateur Tâche arrêtée ou état non persisté Ne pas se fier à l’interface ; récupérer le contexte local
Processus actif, fichiers modifiés ou sortie croissante Travail probablement en cours Continuer sous surveillance, avec une limite d’attente définie

La règle est simple : une relance doit être établie par une paire de preuves, « planifiée » puis « commencée ». Ne comptez pas seulement les lignes affichées par la Web UI.

Attention : une déconnexion distante ne signifie pas forcément que la tâche est arrêtée. Elle ne prouve pas non plus que celle-ci continue. Sans signal indépendant — processus, événement persistant, fichier de sortie ou métrique d’activité — traitez l’état comme incertain.

Comment interpréter un affichage « en attente » ?

Dans une tâche longue, l’absence de résultat peut correspondre à quatre situations différentes :

  • le modèle n’a pas encore reçu la requête ;
  • la requête a été envoyée mais la réponse n’est pas revenue ;
  • la réponse du modèle est terminée et l’Agent attend un outil ;
  • le processus distant a perdu son environnement d’exécution.

Ces situations ont des coûts et des risques différents. Attendre davantage peut être pertinent dans le premier cas. Dans le quatrième, cela ne fait qu’augmenter la durée d’indisponibilité et la difficulté de reprise.

Vérifiez la paire « relance prévue / relance démarrée »

La relance a-t-elle vraiment commencé ?

Le terme LLM retry décrit une logique de répétition autour d’un appel au modèle. Il ne décrit pas toute la durée d’une tâche Agent. Une relance prévue peut être enregistrée avant que le processus ne lance effectivement la requête suivante.

Vous devez donc distinguer :

  • la création de l’intention de relancer ;
  • l’attente ou la temporisation locale ;
  • le démarrage de la nouvelle requête ;
  • la réception d’une réponse ;
  • la décision de poursuivre vers un outil ou une étape suivante.

Ne donnez pas à DeepSeek Harness un nombre fixe de relances sans consulter la version installée, son code actuel ou sa documentation correspondante. Le nombre exact, l’algorithme d’attente et les erreurs considérées comme réessayables peuvent changer. La documentation officielle confirme certaines catégories d’erreur, mais elle ne justifie pas à elle seule une politique universelle de relance pour votre Agent. (api-docs.deepseek.com)

La connexion distante ajoute une autre ambiguïté. Une coupure SSH, VNC ou WebSocket peut interrompre l’observation alors que le processus travaille encore. À l’inverse, une session peut rester visible alors que le processus a été tué par une fermeture de terminal, une mise en veille, un redémarrage ou une perte du répertoire de travail.

Conservez le contexte avant d’agir, notamment lorsque :

  • l’état de la tâche est ambigu ;
  • la commande en cours peut modifier des fichiers ;
  • un outil externe possède des effets irréversibles ;
  • la session distante vient juste de perdre sa connexion ;
  • les journaux ne sont pas encore copiés hors de l’environnement.

La sauvegarde minimale doit inclure la version de DeepSeek Harness, le modèle configuré, le Provider, le Base URL, l’identifiant de session, les derniers événements, les réponses HTTP et les changements du répertoire de travail.

Quand arrêter l’attente ?

Arrêtez plutôt que d’attendre indéfiniment si l’une de ces conditions est remplie :

  • aucun nouvel événement de relance n’est apparu ;
  • une relance est planifiée mais ne démarre pas ;
  • le processus principal n’existe plus ;
  • le même échec déterministe se répète ;
  • l’attente n’a pas de limite opérationnelle ;
  • le contexte de travail distant a changé ;
  • l’outil bloque sur une autorisation qui ne sera pas accordée.

L’arrêt n’est pas une preuve d’échec définitif. C’est une mesure de conservation du diagnostic. Vous pourrez reprendre correctement si vous avez gardé l’état, le contexte et le dernier point confirmé.

Traitez une erreur modèle comme une erreur de configuration tant qu’elle est déterministe

Pourquoi répéter ne corrige pas une mauvaise configuration ?

Si chaque tentative renvoie le même type d’erreur, n’augmentez pas le budget de relance par réflexe. Vérifiez d’abord :

  • le nom exact du modèle ;
  • le Provider réellement sélectionné ;
  • la clé d’API utilisée par le processus ;
  • le Base URL ;
  • les paramètres spécifiques au mode de raisonnement ;
  • le format des messages après un appel d’outil ;
  • la limite de contexte ;
  • la présence de paramètres incompatibles.

La documentation officielle distingue clairement l’authentification invalide, le solde insuffisant, les paramètres invalides, la limite de débit et les erreurs serveur. Une erreur d’authentification ou de paramètre ne devient pas transitoire parce qu’elle est répétée. (api-docs.deepseek.com)

Le contrôle du Base URL est particulièrement important. Les fonctions expérimentales peuvent utiliser une adresse différente de l’endpoint standard, et la documentation précise les conditions d’utilisation de l’endpoint bêta. Ne mélangez pas un réglage destiné à la complétion par préfixe avec un flux d’appels d’outils sans vérifier les contraintes de votre version. (api-docs.deepseek.com)

Pour un diagnostic propre, remplacez temporairement la tâche complexe par une requête minimale :

  1. un seul message utilisateur ;
  2. un modèle explicitement choisi ;
  3. aucun outil ;
  4. aucun Hook ;
  5. un texte de réponse très court ;
  6. une journalisation de la requête et de la réponse HTTP.
Test Ce qu’il vérifie Conclusion si le test échoue
Requête minimale sans outil Clé, modèle, Provider et Base URL Corriger la chaîne modèle avant toute relance
Même requête depuis le terminal distant Réseau et environnement d’exécution Examiner sortie réseau, DNS et variables
Requête avec historique court Sérialisation des messages Inspecter le format multi-tour
Appel avec outil factice Passage modèle-outil Examiner les événements et le protocole d’outil
Tâche réelle avec outil contrôlé Orchestration Agent complète Comparer au test minimal et isoler l’étape fautive

Un flux multi-tour doit reconstruire correctement les messages transmis à l’API. La documentation rappelle que le serveur ne conserve pas automatiquement l’historique. Une erreur de sérialisation peut donc réapparaître à chaque tentative, notamment après un appel d’outil. (api-docs.deepseek.com)

Le mode de raisonnement ajoute une contrainte importante. Lorsque le modèle a effectué un appel d’outil, certains éléments de raisonnement doivent être conservés dans la suite de l’échange selon le protocole utilisé. La documentation officielle décrit cette différence entre une conversation sans outil et un tour ayant déclenché un outil. (api-docs.deepseek.com)

Ne recopiez pas un message d’erreur depuis un forum ou une capture isolée. Utilisez le code HTTP et le texte réellement retournés par votre appel ou par une reproduction locale contrôlée.

Séparez la réponse du modèle du blocage d’outil

Le modèle a répondu, mais l’Agent n’a pas fini

Un modèle peut avoir terminé sa réponse et demander une action. L’Agent, lui, n’a pas terminé tant que l’outil n’a pas renvoyé son résultat et que la boucle n’a pas repris.

Cette distinction est fréquente dans les usages créatifs :

  • génération d’un scénario audio suivie d’un rendu local ;
  • préparation d’un montage vidéo suivie d’une conversion ;
  • création d’un fichier de design suivie d’une exportation ;
  • analyse d’un dépôt suivie d’un test automatisé ;
  • correction de code suivie d’une commande de validation.

Inspectez le dernier message assistant. S’il contient un appel d’outil, cherchez ensuite :

  • l’événement de demande d’approbation ;
  • l’événement de lancement de l’outil ;
  • la sortie standard et la sortie d’erreur ;
  • le code de retour ;
  • l’événement de fin d’outil ;
  • la reprise de la boucle LLM.

Un outil ne doit pas être diagnostiqué comme une relance modèle. Une commande Bash bloquée sur une entrée interactive, un Hook qui attend un fichier absent ou une approbation jamais donnée peuvent laisser l’interface dans un état identique à celui d’un appel API lent.

Ne désactivez pas toutes les protections pour « voir si cela passe ». Vous risqueriez de transformer un défaut d’autorisation en modification destructive. Réduisez plutôt le périmètre :

  1. remplacez l’outil réel par une commande sans effet secondaire ;
  2. utilisez un répertoire de travail temporaire ;
  3. interdisez les accès réseau non nécessaires ;
  4. vérifiez que l’outil termine et renvoie une sortie ;
  5. réactivez ensuite les permissions une par une.

Le critère de reprise est concret : un appel d’outil minimal doit se terminer, produire un résultat lisible et permettre à l’Agent d’envoyer le tour suivant. Si ce test échoue, la cause se situe dans la chaîne d’exécution, pas dans le nombre de relances du modèle.

Contrôlez l’environnement distant avant de reprendre

Un processus vivant suffit-il à reprendre une tâche ?

Non. Un processus peut être actif dans un environnement qui n’est plus celui du lancement initial. Vérifiez :

  • l’identifiant du processus principal ;
  • ses processus enfants ;
  • l’occupation CPU et mémoire ;
  • les fichiers récemment modifiés ;
  • le répertoire de travail courant ;
  • les variables d’environnement ;
  • la connectivité vers l’API ;
  • l’état de veille ou de redémarrage ;
  • les droits d’accès aux fichiers utilisés par les outils.

Une tâche est généralement récupérable si son identité n’a pas changé, si son état est persistant et si le processus poursuit une activité observable. Elle ne l’est pas automatiquement après un redémarrage, une restauration d’image, une migration ou une modification du répertoire de travail.

Pour un travail en arrière-plan, ne confondez donc pas « le Mac est joignable » avec « l’Agent est cohérent ». Une machine peut accepter une nouvelle connexion alors que l’ancien processus a perdu ses fichiers temporaires ou ses descripteurs ouverts.

Si vos tâches longues dépendent d’un poste local qui se met en veille ou d’une connexion instable, un environnement Mac distant peut simplifier la continuité d’exploitation. Vous pouvez comparer les conditions d’un Mac cloud pour DeepSeek Harness avec votre poste actuel, puis consulter les options de Mac mini cloud en Europe ou en Asie selon la latence attendue.

Ne forcez pas la reprise d’une ancienne tâche lorsque l’identité de l’environnement a changé. Créez une nouvelle tâche de validation avec :

  • un nouveau dossier de travail ;
  • une requête minimale ;
  • un outil factice ;
  • une copie des journaux précédents ;
  • un résultat attendu clairement défini.

Cette approche évite de mélanger un défaut historique et un nouvel incident réseau.

Utilisez cette liste de décision avant de relancer

  • [ ] Identifier la session, la tâche et la version exacte de DeepSeek Harness.
  • [ ] Exporter les derniers événements persistants avant de fermer le processus.
  • [ ] Vérifier qu’une relance a été planifiée puis effectivement démarrée.
  • [ ] Confirmer si un appel réseau a reçu une réponse HTTP.
  • [ ] Relever le modèle, le Provider, le Base URL et la source de la clé d’API.
  • [ ] Reproduire avec une requête minimale sans outil.
  • [ ] Vérifier si la dernière réponse du modèle contient un appel d’outil.
  • [ ] Tester l’outil avec une commande sans effet secondaire.
  • [ ] Contrôler le processus, le répertoire de travail et les fichiers modifiés.
  • [ ] Vérifier l’état du service sur la page officielle de disponibilité de DeepSeek. (status.deepseek.com)
  • [ ] Définir une limite d’attente avant toute nouvelle tentative.
  • [ ] Créer une nouvelle tâche si l’environnement distant a changé.
  • [ ] Conserver un cas minimal reproductible pour l’escalade.

Choisissez entre attendre, annuler et migrer

Votre décision finale doit reposer sur des preuves, pas sur l’animation de l’interface.

Continuez à attendre lorsque :

  • un nouvel appel est visible ;
  • les événements progressent ;
  • le processus reste actif ;
  • un outil produit encore des sorties ;
  • l’incident correspond à une erreur amont temporaire documentée.

DeepSeek recommande notamment de réessayer après une courte attente pour certaines erreurs serveur ou de surcharge, tout en distinguant ces situations des erreurs de clé, de solde ou de paramètres. (api-docs.deepseek.com)

Annulez et relancez proprement lorsque :

  • aucune relance ne démarre ;
  • la même erreur de configuration revient ;
  • l’outil est bloqué sans approbation possible ;
  • le processus a disparu ;
  • les journaux sont incomplets mais récupérables.

Migrez vers un nouvel environnement lorsque :

  • la machine a redémarré ;
  • le répertoire de travail a changé ;
  • les variables ou identifiants ne correspondent plus ;
  • le réseau sortant reste instable ;
  • l’ancienne session ne possède plus un état fiable.

Pour l’exploitation distante, formalisez trois niveaux : délai d’observation, condition d’arrêt et critère de reprise. Votre runbook doit également préciser qui peut approuver un outil, où sont stockés les journaux et comment vérifier le résultat final. Un simple statut « terminé » ne suffit pas : contrôlez les fichiers produits, les tests exécutés et la cohérence du répertoire de sortie.

Si le problème n’apparaît qu’après une déconnexion ou pendant les tâches longues, examinez aussi les conditions d’acceptation d’un travail DeepSeek Harness exécuté en arrière-plan avant de réinstaller le logiciel. Une autre machine ne corrigera pas une mauvaise clé, un mauvais Provider ou un Hook bloqué, mais elle peut supprimer les interruptions liées à la veille, au redémarrage et à une session locale fragile.

Votre environnement actuel reste pertinent pour les tests courts et les tâches qui exigent un accès physique direct. Il devient moins adapté lorsque les défauts récurrents sont la veille, la déconnexion, la perte du répertoire de travail et l’absence de surveillance nocturne. Dans ce cas, louer un Mac auprès de MACCOME peut offrir une continuité plus contrôlable pour les tâches longues, à condition de conserver vos preuves, de tester la reprise et de ne pas confondre disponibilité de la machine avec succès de l’Agent.