L'ingénierie des prompts, du contexte, des boucles et des graphes s'est avérée être une pièce d'une même machine. Le harnais est l'endroit où elles cohabitent enfin.
Chaque phase de développement avec l'IA a eu son propre intitulé de poste. L'ingénierie des prompts est venue en premier, à l'époque où tout le métier consistait à trouver la phrase juste.
L'ingénierie du contexte a suivi, dès qu'il est devenu évident que la phrase comptait moins que tout ce qui était chargé autour. Cet été, c'était les boucles, et quelques semaines plus tard, les graphes.
Le terme qui se répand maintenant est l'ingénierie du harnais (harness engineering), et c'est le premier qui explique tous les autres.
Un harnais englobe tout ce qui entoure le modèle : les outils qu'il peut appeler, les fichiers qu'il lit avant toute chose, les répertoires dans lesquels il peut écrire, les contrôles que sa sortie doit passer, le planificateur qui le réveille et la règle qui termine l'exécution.
Chaque discipline précédente s'avère être un simple composant de ce cadre, construit séparément et doté de son propre nom.
J'ai commencé à y prêter attention pour une raison pratique. Le modèle sous-jacent ne cesse de changer, gagnant parfois dix-sept places au classement lors d'une seule mise à jour, et le harnais est la seule partie du système qui vous appartient vraiment.
1/ Sept ingénieries, une machine
Discipline
La question à laquelle elle répond
Où elle vit dans le harnais
Ingénierie des prompts
Que demande-je exactement ?
SKILL.md, la spécification de tâche chargée en premier
Ingénierie du contexte
Que voit le modèle à chaque étape ?
L'assembleur de contexte : contraintes, schémas, pages récupérées
Ingénierie des outils
À quoi peut-il toucher, et sous quelle forme ?
Définitions d'outils avec entrées et sorties typées
Ingénierie des boucles
Qu'est-ce qui démarre une exécution et qu'est-ce qui la termine ?
Le runner : déclencheurs, conditions d'arrêt, budgets
Ingénierie des graphes
Que retient-il et comment les éléments sont-ils liés ?
La couche mémoire : nœuds, arêtes typées, alias
Ingénierie de l'évaluation
Comment un résultat est-il rejeté ?
Le vérificateur, hors du contrôle de l'agent
Ingénierie du harnais
Qu'est-ce qui maintient le tout ensemble ?
Le cadre, les permissions et les hooks
Lisez le tableau de haut en bas et c'est une histoire. Lisez-le de bas en haut et c'est une architecture : l'ingénierie du harnais consiste à décider où vivent chacune des six autres disciplines, afin qu'aucune ne finisse cachée dans un prompt.
Ce dernier point porte la majeure partie du poids.
Un prompt est l'endroit le plus facile pour mettre n'importe quoi, donc tout y dérive : le format de sortie, la règle d'arrêt, les corrections de la semaine dernière, la liste des choses que l'agent ne doit jamais toucher. Cela fonctionne parfaitement sur le modèle pour lequel vous l'avez écrit, puis le modèle suivant lit le même paragraphe différemment.
2/ Anatomie d'un harnais
L'habitude la plus utile que j'aie prise est de noter l'intégralité du harnais dans un seul fichier de configuration, afin que rien d'important ne reste implicite :
1# harness.yaml2model: kimi-k3 # one line. everything below survives a swap3tools: [browser, fs, shell, search]4permissions:5 write: [./10-returns, ./20-graph, ./40-runs]6 ask_first: [send, publish, pay, delete]7context:8 always: [SKILL.md, CONSTRAINTS.md, SCHEMA.md]9 per_agent: return_schema10runner:11 trigger: cron "0 2 * * *" # nightly, while you sleep12 stop: 40 verified nodes OR 3 passes with nothing new13 budget: { agents: 300, minutes: 45, retries: 2 }14memory:15 graph: ./20-graph16 aliases: ./aliases.csv17verify:18 - script: checks/schema.py19 - agent: reviewer, fresh context20hooks:21 pre_tool: hooks/pre_tool.sh22 post_run: append 40-runs/
Trois lignes dans ce fichier font la majeure partie du travail.
model: est volontairement une ligne unique. Tout le reste est écrit pour ne pas se soucier de ce que dit cette ligne. C'est toute l'histoire de la portabilité.
permissions: compte plus que tools:, même si cela apparaît plus bas dans le fichier. Écrire ce que l'agent peut modifier et ce dont il doit demander l'autorisation préalable est ce qui sépare un système que vous laissez tourner pendant la nuit d'un système devant lequel vous restez assis à surveiller.
verify: contient deux entrées pour une raison. Le script ne coûte rien et attrape tout ce qui est mécanique. Le reviewer est un second agent qui n'a jamais vu le premier travailler, car un agent qui note sa propre sortie trouve toujours une raison de l'approuver.
Sur le disque, le harnais est un dossier unique, et chaque ingénierie du tableau y possède sa propre adresse.
3/ Pourquoi Kimi K3 est le moteur que j'y installerais
Ce dont le harnais a besoin
Ce que Kimi K3 apporte
Un runner capable de se déployer largement
Agent Swarm : jusqu'à 300 agents sur un même problème simultanément, sans écrire d'orchestrateur
Du code assez fort pour écrire ses propres tests
N°1 sur le Frontend Code Arena avec 1 679 points, devant Fable 5 (1 631) et GPT-5.6 Sol (1 618), leader dans 6 des 7 domaines
Un moteur qui s'améliore sous vos pieds
De la N°18 à la N°1 lors d'une seule mise à jour en juillet
La première ligne compte plus qu'elle n'en a l'air. Presque tous les harnais faits maison développent un orchestrateur artisanal à un moment donné, et c'est généralement le fichier le plus fragile du dossier. Avec le swarm, le déploiement devient une ligne de budget, agents: 300, et le harnais n'a plus qu'à gérer ce qui revient.
La deuxième ligne compte parce qu'un harnais est principalement du code que le modèle écrit pour vous : scripts de hook, vérifications de schéma, le petit tableau de bord qui lit 40-runs. Un moteur qui domine l'arena frontend réussit ces tâches du premier coup bien plus souvent.
La troisième ligne est la preuve de l'ingénierie du harnais en un seul point de données. Quand un modèle grimpe de dix-sept places en une nuit, un harnais met cette progression à profit le jour même, car la seule ligne qui doit changer est model.
4/ Hooks : Les réflexes
Un hook est un court script que le harnais exécute à un moment précis, quelles que soient les décisions du modèle. Les hooks sont l'endroit où un harnais cesse d'être une simple structure de dossiers pour commencer à agir comme un système de sécurité.
Hook
Quand il se déclenche
Ce qu'il fait
pre_tool
Avant tout appel d'outil
Bloque les écritures hors de la liste de permissions
post_tool
Après chaque retour
Exécute la vérification de schéma et rejette immédiatement toute sortie malformée
pre_send
Avant que quoi que ce soit ne quitte la machine
Met en file d'attente jusqu'à votre validation
on_fail
Après un résultat rejeté
Attache la raison de l'échec à la nouvelle tentative
post_run
Quand la condition d'arrêt est atteinte
Ajoute le record d'exécution à 40-runs et diff le graphe
Le hook pre_tool de la première ligne tient en cinq lignes :
1# hooks/pre_tool.sh2case "$TARGET" in3 ./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;4 *) echo "blocked: $TARGET is outside the write list"; exit 1 ;;5esac
Le hook on_fail à lui seul change l'économie d'une boucle. Une nouvelle tentative qui porte la raison de l'échec de la dernière est une correction. Sans cette raison, la boucle paie deux fois pour la même erreur.
5/ À quoi ressemble une nuit
Assemblez toutes les pièces et le harnais se comporte comme une équipe de nuit qui suit des règles. À 02:00, le déclencheur se lance et la requête de démarrage sélectionne chaque nœud nécessitant du travail. Le swarm se déploie, un agent par nœud.
Les retours qui ne respectent pas le schéma sont rejetés par post_tool avant d'atteindre le graphe, et chaque nœud rejeté effectue une nouvelle tentative avec sa raison d'échec attachée. Quand un agent essaie d'écrire hors de son dossier, pre_tool l'arrête sans réveiller personne.
Les nœuds fusionnés et les arêtes typées atterrissent dans 20-graph. Un e-mail rédigé atteint pre_send et attend. post_run ajoute le record, et la boucle s'arrête selon sa propre condition, bien en dessous du budget de 45 minutes défini dans la config.
À 07:30, vous lisez un fichier et prenez deux décisions. C'est le coût total de votre matinée pour faire tourner l'ingénierie des boucles et des graphes de cette manière, et c'est tout l'intérêt du harnais : tout ce qui pouvait tourner sans vous l'a fait, et les rares choses qui avaient besoin de vous attendent au même endroit.
6/ Le test de remplacement
L'audit le plus rapide de toute configuration d'agent : changez la ligne du modèle et relancez. Tout ce qui casse était un harnais vivant au mauvais endroit.
Ce qui casse après le remplacement
Où c'était caché
Où cela devrait être
Le format de sortie dérive
"réponds toujours en JSON" dans le prompt
Un schéma de retour plus un script qui rejette tout le reste
Les exécutions cessent de s'arrêter seules
"continue jusqu'à ce que ce soit complet"
Une condition d'arrêt basée sur des comptes
Les corrections de la semaine dernière ont disparu
L'historique du chat
CONSTRAINTS.md, chargé à chaque exécution
La même entreprise apparaît trois fois
Le jugement du modèle
aliases.csv, vérifié avant la fusion
Il écrit quelque part où il ne devrait pas
Une phrase polie dans le prompt
Une liste de permissions et un hook pre_tool
Une configuration qui passe le test de remplacement est portable, et la portabilité est ce qui lui donne de la valeur.
Combien ça coûte et combien ça rapporte
Les entreprises investissent des trimestres entiers dans des plateformes internes d'agents. Un harnais fonctionnel est un dossier, un fichier de configuration et cinq courts scripts, et il tourne sur un abonnement Kimi. Cet écart est l'opportunité.
Canal
Ce que ça rapporte
Ce dont vous avez besoin d'abord
Configuration de harnais pour une petite équipe
Des honoraires uniques à quatre chiffres pour la config, les hooks et le vérificateur autour de leur workflow
Votre propre harnais, tournant sur un planning
Retainer de jour de sortie
Des honoraires mensuels pour effectuer le test de remplacement à chaque sortie majeure de modèle et déplacer l'équipe vers celui qui mène
Un client dont les exécutions sont déjà journalisées dans 40-runs
Un template de harnais de niche
Le dossier et le yaml packagés pour une industrie : recherche, recrutement, conformité
Le même harnais prouvé sur deux marchés différents
Le second canal est celui que je construirais en premier. Chaque sortie majeure redistribue le classement, K3 seul a gagné dix-sept places en une mise à jour, et chaque équipe avec un harnais a besoin de quelqu'un dont le job est de faire le test de remplacement le jour de la sortie.
La version courte
L'ingénierie des prompts, du contexte, des outils, des boucles, des graphes et de l'évaluation s'avèrent toutes être des composants d'une même machine, et l'ingénierie du harnais consiste à décider où chacun d'eux vit.
Mettez le modèle derrière une ligne, les permissions avant les outils et le vérificateur hors de l'agent. Ensuite, le prochain bond au classement est un changement de config plutôt qu'une reconstruction.
Et si vous avez trouvé cela utile :
- Mettez cet article en favori. Les liens changent et de nouveaux repos apparaissent chaque semaine, vous aurez besoin de ceci comme référence
- Pour des analyses hebdomadaires approfondies sur l'architecture IA, le trading quantitatif et l'économie des agents, suivez-moi : @polydao
- Rejoignez le Canal TG : Buzzoni Notes - ici je partage mes prompts bruts, mes skills personnalisés et les infos alpha trop tôt pour X
