Quick answer: DeepSeek Harness livre un court document de motifs défensifs, chacun écrit comme une règle générale accompagnée du bug précis qui l'a motivée. C'est le fichier le plus transposable du dépôt : rien n'y...

Sept motifs défensifs tirés de la documentation DeepSeek Harness

Updated August 16, 2026 · first published August 16, 2026

DeepSeek Harness livre un court document de motifs défensifs, chacun écrit comme une règle générale accompagnée du bug précis qui l'a motivée. C'est le fichier le plus transposable du dépôt : rien n'y dépend de l'adoption du harness, et chaque point correspond à un mode de défaillance qui apparaît dans les runtimes d'agents maison.

1. Rapporter séparément les résultats orthogonaux

Ne jamais imbriquer le rapport d'un drapeau dans la condition d'un autre. Un processus peut dépasser le délai et sortir avec zéro, parce qu'il a intercepté le signal et s'est arrêté proprement. Si le dépassement n'est rapporté que dans la branche de sortie non nulle, ce résultat disparaît. Délai dépassé, signal et code de sortie sont des faits indépendants et exigent des champs indépendants.

Pertinence économique : les dépassements avalés en silence sont la façon dont naissent les boucles de retry. L'appelant voit un succès, n'obtient rien d'utile, et recommence.

2. Honorer les contrats publics des deux côtés

Quand un résultat a plusieurs représentations valides, normalisez-les avant de les exposer. L'exemple traité est l'échec de requête modèle : les implémentations peuvent lever une exception ou émettre un chunk de fin en erreur, et la frontière d'API normalise tout en un chunk terminal. Sans cela, un appelant qui attrape une exception ne peut savoir si elle vient du fournisseur, du middleware, du logging ou de son propre code.

3. L'état asynchrone n'est pas un état synchrone

Les requêtes de statut ne sont pas causalement liées à des opérations asynchrones précises. Attendre l'état idle d'un agent comme signal d'achèvement d'un message est faux, car plusieurs opérations en file partagent des intervalles d'exécution : l'idle peut arriver avant que la vôtre ne tourne, ou après celle d'un autre.

Le correctif prescrit : un appelant d'automatisation propriétaire d'une exécution définit son intervalle explicitement, de la réception en boîte jusqu'au prochain idle de l'agent entier, et attribue les sorties à cet intervalle plutôt qu'à des messages isolés. Traitez aussi la branche rien-à-attendre, sinon l'appelant se bloque indéfiniment.

Un harness d'automatisation bloqué à attendre le mauvais signal d'idle garde une session et ses enfants résidents. La facture, ce n'est pas le blocage : c'est tout ce qui reste vivant derrière.

4. Le dispose doit atteindre la quiescence, pas seulement la demander

Demander la terminaison n'est pas l'obtenir. Le dispose attend la terminaison réelle des enfants avant de rendre la main. Et les registres d'écouteurs se ferment avant l'envoi des signaux de kill, pour que les fins tardives atterrissent en silence au lieu de déclencher des callbacks dans un système à demi démonté.

C'est le motif au tranchant financier le plus net. Un dispose qui rend la main trop tôt laisse tourner des sous-processus orphelins et des bacs à sable non fermés, et le calcul facturé ne s'arrête pas parce que son parent l'a oublié.

5. Contenir les exceptions de callback dans le dispatcher

Enveloppez les boucles de dispatch dans try/catch. Un abonné en échec ne doit pas rejeter la promesse de dispatch ni affamer les écouteurs en file derrière lui. Dans un runtime d'agents, l'écouteur affamé est souvent justement celui qui fait la comptabilité, et c'est ainsi que des relevés d'usage disparaissent sans qu'aucune erreur ne remonte.

6. Ne jamais donner à une sortie non fiable l'environnement ambiant ni des chemins prévisibles

La règle la plus forte du document, et la première à adopter. Nettoyez l'environnement des commandes lancées : retirez les variables correspondant à key, secret, token et password avant le démarrage du sous-processus. Utilisez des répertoires privés créés avec des permissions propriétaire uniquement, des noms de fichiers aléatoires et des ouvertures exclusives plutôt que des chemins prévisibles.

Deux menaces distinctes. Le nettoyage empêche les identifiants du harness de fuir dans la sortie du sous-processus que le modèle lit ensuite — et une fois lue, cette sortie est dans le journal de session et dans la fenêtre de contexte. Noms aléatoires et création exclusive ferment les courses de liens symboliques sur les répertoires temporaires partagés.

7. Délier les chemins en forme de lien

Vérifiez si un chemin est un lien symbolique avant de le supprimer, et supprimez le lien plutôt que de le suivre. La suppression récursive est réservée aux vrais répertoires confirmés, car elle peut traverser des liens jusqu'à leurs cibles et échoue sur les jonctions. Un code de nettoyage qui supprime plus qu'il n'a créé est un mode de défaillance sans plafond de dégâts.

Comment se servir de cette liste

  1. Portez dès aujourd'hui les motifs 1 et 4 dans votre code de démontage des sous-processus et bacs à sable. C'est là que l'argent fuit.
  2. Portez le motif 6 partout où vous lancez un processus dont le modèle lira la sortie.
  3. Portez le motif 3 dans votre couche d'automatisation, surtout là où une attente s'exprime en « jusqu'à ce que l'agent soit idle ».
  4. Portez le motif 5 dans votre pipeline de télémétrie et vérifiez qu'un écouteur en échec ne peut pas affamer celui de la comptabilité.

Related

Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →

Back to research