Présentation du concept de harness

Le projet Harness Engineering 101 propose une métaphore simple : l’LLM agit comme le cerveau, le harness comme le corps qui maintient le tableau de conversation. La version 1.0, publiée en septembre 2026, expose ce principe dans un livre‑blog disponible en ligne et sur GitHub. Chaque appel à l’API LLM reste stateless ; le harness doit donc reconstruire à chaque tour l’historique complet sous forme de tableau JSON et renvoyer le texte généré.

Architecture du toy agent

Le code source construit un agent de ~300 lignes en Python pur. Le fichier principal se trouve sous src/harness/ et illustre les étapes suivantes : initialisation du tableau, ajout de chaque échange, appel à l’API, puis traitement de la réponse. Le projet utilise Python 3.10+ et Matplotlib pour générer les diagrammes Mermaid via le script gen_all.py. La structure du projet est volontairement modulaire ; chaque chapitre ajoute une « patch » minimal qui corrige une défaillance identifiée, ce qui permet d’observer le coût additionnel de chaque amélioration.

cargo install mdbook mdbook-mermaid   # ou: brew install mdbook (+ mdbook-mermaid binary)
mdbook serve --open                    # prévisualisation en direct
mdbook build                           # génération du site statique

Gestion des limites opérationnelles

Les chapitres D et B détaillent les mécanismes de retries, rate limits et streaming. Le harness intercepte les erreurs de dépassement de quota, applique une stratégie de nouvelle tentative avec back‑off exponentiel, et conserve les métadonnées de chaque tentative dans le tableau. Le mode streaming est implémenté en lisant les fragments de texte dès qu’ils arrivent sur le fil, ce qui réduit la latence perçue mais augmente la complexité du parsing côté client.

Implications, licences et limites

Le code est publié sous licence MIT, tandis que le texte du livre est sous CC BY‑NC‑ND 4.0, ce qui interdit toute utilisation commerciale ou modification du contenu rédactionnel. Cette double licence sépare clairement la partie exécutable (réutilisable) de la partie explicative (non modifiable). Le modèle reste limité par le caractère stateless de l’API : chaque appel doit transmettre l’historique complet, ce qui entraîne une croissance linéaire du poids du JSON et un coût proportionnel au nombre de tokens. Le projet ne propose pas de mécanisme de compression du contexte, ce qui peut devenir un goulot d’étranglement pour des conversations longues. Enfin, le harness repose sur des hypothèses de stabilité de l’API LLM ; tout changement d’interface nécessiterait une mise à jour du code, ce qui souligne la fragilité d’une architecture purement « one‑loop ».