Le design du harness d'agents d'Anthropic a transforme ma vision des systemes IA

J'etais plonge depuis quatre heures dans l'observation d'une IA construisant une station de travail audio numerique. Pas une demo jouet -- un DAW dans le navigateur avec l'API Web Audio, l'edition multipiste et un visualiseur de formes d'onde. L'agent fonctionnait de maniere autonome depuis le debut. Pas d'assistance. Pas de corrections en cours de session. Juste une IA qui enchainait fonctionnalite apres fonctionnalite, committait du code, testait son propre travail et avancait.

Puis il s'est arrete.

Pas a cause d'un crash. Pas a cause d'un depassement de contexte. Il s'est arrete parce qu'une IA distincte -- l'evaluateur -- lui avait signale que le timing de lecture audio etait decale de 12 millisecondes et que le rendu de la forme d'onde ne correspondait pas aux donnees frequentielles reelles. L'agent generateur est revenu en arriere, a corrige les deux problemes et a soumis a nouveau. L'evaluateur l'a teste une seconde fois, confirme les corrections et valide le sprint.

Cette interaction -- deux agents IA qui debattent de la qualite comme un developpeur et un ingenieur QA -- est au coeur de ce qu'Anthropic a publie dans son design de harness pour le developpement d'applications de longue duree. Et cela a completement reconfigure ma facon de concevoir les systemes autonomes.

Le modele n'est pas le produit. Le harness l'est.

Pourquoi votre agent IA echoue systematiquement sur les taches complexes

Voici un schema que j'ai vecu des dizaines de fois. Vous confiez a un agent IA un projet complexe -- construire une application full-stack, refactorer un code base volumineux, creer un systeme de design multi-pages. L'agent demarre en trombe. Les 20 premieres minutes sont prometteuses. Puis, vers la 45e minute, les choses commencent a deraper. Des etapes sont sautees. La qualite baisse. L'agent declare le projet "termine" alors qu'il en est peut-etre a 60 %.

Avant, j'accusais le modele. "Sonnet n'est pas assez intelligent pour ca." "Il me faut de meilleurs prompts." "La fenetre de contexte est trop petite."

Les recherches d'Anthropic ont completement inverse ce diagnostic. Le modele etait rarement le goulot d'etranglement. C'etait le harness.

Un harness d'agent est le framework logiciel qui enveloppe un modele IA -- gerant les prompts, orchestrant les outils, appliquant les contraintes, gerant les boucles de retour et validant les sorties. Voyez les choses ainsi : le modele IA est un moteur. De la puissance brute. Le harness, c'est la voiture. Volant, freins, transmission, GPS. Sans la voiture, le moteur reste sur un etabli a faire du bruit.

Cette distinction compte plus que la plupart des ingenieurs IA ne le realisent. Vous pouvez remplacer un V6 par un V8 (Sonnet par Opus), et vous obtiendrez une amelioration incrementale. Mais reconcevoir la voiture -- changer la facon dont le moteur se connecte aux roues, ajouter un systeme de navigation, installer de meilleurs freins -- et toute l'experience de conduite se transforme.

C'est ce qu'Anthropic a demontre. Pas un meilleur modele. Un meilleur systeme autour du modele. Et les resultats etaient suffisamment spectaculaires pour que je reconstruise mes propres workflows d'agents dans la semaine suivant la lecture de leur article.

Mais avant d'entrer dans le detail de ce qu'ils ont construit, vous devez comprendre ce qui ne cesse de mal tourner -- car ces modes de defaillance se cachent dans chaque systeme d'agent de longue duree que j'ai observe, y compris ceux que j'ai construits moi-meme.

Les deux modes de defaillance dont personne ne parle honnetement

Anthropic a identifie deux modes de defaillance critiques dans les agents de longue duree. Je les ai experimentes tellement de fois que lire leur analyse m'a donne l'impression que quelqu'un avait installe des cameras dans mon environnement de developpement.

L'anxiete de contexte : quand votre agent panique

L'anxiete de contexte est ce qui se produit lorsqu'un modele IA pressent qu'il approche des limites de sa fenetre de contexte. Le comportement est subtil et insidieux. L'agent ne plante pas. Il ne lance pas d'erreur. Au lieu de cela, il commence a se precipiter. Les etapes sont compressees. Les explications deviennent laconiques. Des sous-taches complexes qui necessiteraient une planification soignee sont evacuees d'un revers de main. L'agent commence a conclure prematurement -- declarant victoire sur un projet a moitie termine parce qu'un signal interne hurle "tu manques de place."

J'ai remarque cela pour la premiere fois avec Sonnet 4.5 pendant un projet de refactoring. Aux alentours des 80 000 tokens, l'agent est passe d'un travail soigneux et methodique a ce que je ne peux decrire que comme du speed-running anxieux. Il a arrete de lire les fichiers avant de les modifier. Il a saute les executions de tests. Il a commence a produire des commentaires comme "les elements restants sont simples et suivent le meme schema" -- ce qui, en langage d'agent, signifie "j'abandonne et j'espere que vous ne le remarquerez pas."

La solution d'Anthropic repose sur deux techniques complementaires.

La compaction de contexte resume et condense l'historique de conversation, preservant les informations essentielles tout en liberant de l'espace de tokens. L'IA s'ecrit essentiellement un briefing compresse de tout ce qui s'est passe jusqu'ici, puis travaille a partir de ce briefing plutot que de l'historique brut. C'est avec perte -- certains details sont elimines -- mais une bonne strategie de compaction preserve les decisions critiques et l'etat actuel.

Les reinitalisations de contexte vont plus loin. Au lieu de compresser le contexte existant, on donne a l'agent une fenetre de contexte completement vierge pour chaque sprint ou sous-tache. L'agent demarre proprement, avec uniquement les informations necessaires pour le travail en cours. La progression ne reside pas dans la memoire du modele -- elle reside dans les fichiers, les commits git et les artefacts structures sur disque.

Voici la percee qui compte pour les developpeurs : Opus 4.6 avec sa fenetre de contexte d'un million de tokens a largement elimine l'anxiete de contexte comme probleme pratique. La fenetre est si enorme que la plupart des sessions autonomes de plusieurs heures n'approchent jamais de la saturation. Anthropic a constate qu'ils pouvaient abandonner completement les reinitialisations de contexte avec Opus 4.6 et se reposer uniquement sur la compaction. Ce qui necessitait auparavant un systeme complexe de passage entre sessions multiples fonctionne desormais en une seule session continue.

Cela ne signifie pas que la gestion du contexte est resolue pour toujours. Poussez Opus 4.6 suffisamment fort -- une session autonome d'une journee complete avec une lecture extensive de fichiers -- et vous atteindrez des limites. Mais le seuil est passe de "un probleme serieux apres 45 minutes" a "un cas limite apres plus de 6 heures." Pour la plupart des taches reelles, c'est la difference entre avoir besoin d'une solution de contournement dans le harness et ne pas en avoir besoin du tout.

L'echec de l'auto-evaluation : l'agent qui pense que tout ce qu'il produit est formidable

Le second mode de defaillance est plus dangereux car plus difficile a detecter.

Quand vous demandez a un agent IA d'evaluer son propre travail, il ment. Pas deliberement -- mais de maniere constante. Le schema est previsible : l'agent genere une sortie, la passe en revue et conclut que la sortie est bonne. Meme quand, pour un observateur humain, la qualite est manifestement mediocre.

J'ai vu cela se produire en temps reel. Un agent construit une page d'atterrissage avec des elements desalignes, un espacement incoherent et une palette de couleurs qui semble choisie par un generateur de nombres aleatoires. Vous demandez a l'agent d'evaluer le resultat. "Le design est epure et professionnel, avec une bonne hierarchie visuelle et un espacement coherent." Il decrit le design qu'il avait l'intention de construire, pas celui qu'il a reellement construit.

Ce n'est pas un probleme de prompting. Vous pouvez ajouter "sois critique" et "cherche les defauts" dans le prompt systeme, et l'agent acquiescera, fera semblant d'etre critique, puis approuvera son propre travail avec quelques reserves de facade. "Bien qu'il y ait place a l'amelioration dans la palette de couleurs, le design communique efficacement le message de la marque." Traduction : "Je fais semblant d'etre critique sans rien changer."

Le diagnostic d'Anthropic est direct et, d'apres mon experience, juste : rendre un generateur autocritique est un probleme fondamentalement plus difficile que de construire un critique dedie et separe. La solution architecturale n'est pas d'ameliorer l'auto-evaluation du generateur. C'est de separer completement les roles.

Ce qui nous amene a l'architecture qui fonctionne reellement.

L'architecture a trois agents : Planificateur, Generateur, Evaluateur

Le design final du harness d'Anthropic utilise trois agents specialises travaillant de concert. Si vous avez deja travaille dans une equipe avec un chef de produit, un developpeur et un ingenieur QA -- cela vous semblera familier. Car c'est exactement la dynamique qu'ils ont repliquee.

Le Planificateur

Le Planificateur prend un prompt simple -- "construis une application de gestion de projet avec un tableau Kanban" -- et le developpe en une specification produit detaillee. Listes de fonctionnalites. User stories. Exigences techniques. Direction du design visuel.

Le Planificateur est deliberement ambitieux. Anthropic a constate qu'une planification conservatrice menait a des resultats decevants. Quand le Planificateur visait haut, le Generateur produisait des applications plus creatives, plus completes -- meme s'il n'atteignait pas toutes les cibles. Une specification qui demande "une interface magnifique, digne d'un musee, avec des elements 3D" produit de meilleurs resultats qu'une qui demande "une interface propre et fonctionnelle." L'exigence elevee tire la sortie vers le haut.

Une chose qu'Anthropic a apprise a ses depens : le Planificateur doit se concentrer sur le quoi et le pourquoi, pas sur le comment. Quand le Planificateur incluait des details techniques granulaires d'implementation, ces details propageaient des erreurs en cascade dans le travail du Generateur. Un Planificateur qui dit "implementer la collaboration en temps reel" est preferable a un qui dit "utiliser des WebSockets avec un pattern pub/sub sur Redis" -- car le Generateur pourrait trouver une meilleure approche que la specificite prematuree du Planificateur aurait empechee.

Le Generateur

Le Generateur travaille en sprints, implementant une fonctionnalite a la fois. Chaque sprint a un perimetre clair derive de la specification du Planificateur, et le Generateur committe le code de maniere incrementale -- ce qui signifie que la progression est preservee dans git independamment de ce qui arrive au contexte de l'agent.

Cette approche par sprints est la ou je vois le parallele le plus fort avec ma facon d'utiliser Claude Code. Quand je travaille avec l'architecture en essaim d'agents de Claude Code, le meme principe s'applique : decomposer le travail complexe en morceaux distincts, rendre la progression visible a travers des artefacts (fichiers, commits, graphes de taches), et ne jamais se fier a la memoire du modele comme source de verite.

Le Generateur inclut egalement une etape d'auto-evaluation integree avant de passer la main a l'Evaluateur -- une verification rapide de coherence. Cela detecte les problemes evidents (erreurs de syntaxe, imports manquants, builds casses) sans dependre de l'Evaluateur pour des choses que le Generateur devrait detecter lui-meme. Pensez a un developpeur qui lance ses propres tests avant d'ouvrir une PR. Vous avez toujours besoin de la revue de code, mais vous ne devriez pas faire perdre du temps au relecteur avec des problemes que votre linter aurait detectes.

L'Evaluateur : la ou reside la veritable innovation

L'Evaluateur est ce qui rend cette architecture veritablement differente de tout ce que j'ai construit auparavant.

La plupart des systemes d'evaluation IA examinent le code de maniere statique -- ils lisent les fichiers sources, analysent la structure et donnent un retour. L'Evaluateur d'Anthropic ne se contente pas de lire le code. Il utilise l'application. Via l'automatisation de navigateur Playwright, l'Evaluateur navigue dans l'application en cours d'execution, clique sur les boutons, remplit les formulaires, prend des captures d'ecran, teste les endpoints API et sonde les etats de la base de donnees. Il interagit avec le produit en direct comme le ferait un ingenieur QA humain.

Les criteres d'evaluation ne sont pas vagues non plus. Anthropic a defini quatre dimensions specifiques :

Qualite du design -- La sortie visuelle repond-elle aux standards professionnels ? Mise en page, typographie, couleurs, espacement -- mesures par rapport a la specification du Planificateur, pas par rapport a des ideaux abstraits.

Originalite -- La sortie ressemble-t-elle a du contenu generique d'IA, ou possede-t-elle une identite creative authentique ? Ce critere existe specifiquement pour combattre le probleme du "tout ce que l'IA construit se ressemble." En lisant cela, j'ai immediatement pense au guide des systemes de design IA que j'ai ecrit -- le probleme des interfaces generees par IA qui convergent toutes vers la meme esthetique est reel, et Anthropic l'evalue explicitement.

Finition -- Qualite de l'execution technique. Code propre, gestion correcte des erreurs, mises en page responsive, performance. Ce qu'un ingenieur senior remarquerait pendant une revue de code.

Fonctionnalite -- La fonctionnalite marche-t-elle reellement ? Pas "le code semble-t-il correct" -- le bouton fait-il ce qu'il est cense faire quand on clique dessus ?

L'Evaluateur note chaque sprint selon ces criteres. Si les notes n'atteignent pas le seuil, le Generateur revient iterer. Cela cree une boucle de retroaction structurellement identique au fonctionnement des GANs (reseaux antagonistes generatifs) -- un generateur qui tente de produire une sortie trompant le discriminateur, et un discriminateur qui s'ameliore dans la detection des lacunes.

Voici ce qui m'a surpris : obtenir un Evaluateur performant a necessite plusieurs iterations. Les evaluateurs initiaux d'Anthropic bases sur Claude avaient le meme probleme que l'auto-evaluation -- ils etaient trop indulgents. Ils approuvaient un travail mediocre avec des retours encourageants. Il a fallu un travail delibere d'ingenierie de prompts pour rendre l'Evaluateur veritablement adversarial. Un prompt systeme sceptique. Des instructions explicites pour chercher des types specifiques de defaillance. La permission de rejeter le travail et d'exiger des revisions.

Voici l'insight cle sur lequel je reviens sans cesse : calibrer un evaluateur dedie pour etre sceptique est un probleme fondamentalement plus tractable que de rendre un generateur autocritique. L'evaluateur a une seule mission -- trouver les problemes. Le generateur a une motivation conflictuelle -- il veut en avoir fini. Separer ces roles n'est pas seulement une bonne architecture. C'est necessaire.

Le contrat de sprint : aligner le Generateur et l'Evaluateur avant le debut du travail

Un detail du design d'Anthropic qui, a mon sens, n'est pas assez discute ailleurs est le contrat de sprint.

Avant le debut de chaque sprint, le Generateur et l'Evaluateur negocient un contrat. Le Generateur propose ce qu'il va livrer. L'Evaluateur confirme qu'il comprend les criteres d'acceptation. Les deux agents s'accordent sur la definition de "termine" avant qu'une seule ligne de code ne soit ecrite.

Cela semble bureaucratique. Ca ne l'est pas. C'est la difference entre une PR approuvee au premier passage et une qui fait des allers-retours cinq fois parce que le developpeur et le relecteur avaient des attentes differentes.

Sans le contrat, j'ai vu des agents evaluateurs rejeter du travail pour ne pas repondre a des standards qui n'avaient jamais ete communiques. Le Generateur construit une fonctionnalite d'une certaine maniere, l'Evaluateur la voulait autrement, et la boucle d'iteration brule des tokens a debattre d'exigences qui auraient du etre reglees en amont.

Le contrat resout ce probleme en rendant les attentes explicites. "Le sprint 3 implementera l'editeur de niveaux avec le placement de sprites en glisser-deposer, une palette de tuiles d'au moins 20 elements, et le support annuler/refaire. L'Evaluateur verifiera la fonctionnalite en creant un niveau de test, en placant des sprites et en confirmant que l'annulation fonctionne pour au moins 5 operations sequentielles."

Cette specificite -- nommer les tests d'acceptation exacts -- elimine toute une categorie d'iterations gaspillees. Et c'est un schema que j'ai commence a emprunter pour mes propres workflows d'agents, meme en dehors du design de harness d'Anthropic.

Ce que les experiences ont reellement montre

La theorie, c'est une chose. Anthropic a mene trois experiences qui ont mis cette architecture sous pression reelle. Les resultats racontent des histoires differentes selon celle que vous examinez.

Experience 1 : le site web du musee d'art neerlandais

La tache : concevoir un site web pour un musee d'art neerlandais fictif. C'est un defi subjectif, centre sur le design, ou "bien" est difficile a definir et encore plus difficile a evaluer.

Le harness a effectue plus de 10 iterations de retour entre le Generateur et l'Evaluateur. Les premieres versions etaient generiques -- le genre de pages au look de template que n'importe quelle IA produit. Vers l'iteration 7 ou 8, le design avait evolue vers quelque chose de veritablement inhabituel : une visualisation 3D de salle avec un sol en damier, des oeuvres d'art exposees sur des murs virtuels, et une navigation donnant l'impression de se promener dans une galerie.

L'important n'est pas que le design final etait parfait. C'est que la boucle adversariale iterative a pousse la sortie au-dela du plateau "assez bon" que la generation IA en un seul passage atteint toujours. Le Generateur n'a cesse de chercher des solutions plus creatives parce que l'Evaluateur n'a cesse de rejeter les options prudentes. Cette dynamique -- la pression pour depasser, et pas seulement atteindre, les standards -- n'existe pas quand un agent s'auto-evalue.

Experience 2 : le createur de jeux retro 2D

C'etait l'experience la plus revelatrice. Deux executions de la meme tache : construire un createur de jeux retro 2D avec un editeur de niveaux, un editeur de sprites et un systeme de comportements.

Execution 1 (harness solo -- Generateur uniquement) : La sortie semblait visuellement acceptable sur les captures d'ecran. Mais quand on essayait reellement de l'utiliser, le jeu ne fonctionnait pas. Les sprites ne bougeaient pas. L'editeur de niveaux ne pouvait pas sauvegarder les niveaux. C'etait un village Potemkine de createur de jeux -- presentable de l'exterieur, creux a l'interieur.

Execution 2 (harness complet -- Planificateur + Generateur + Evaluateur) : Le Planificateur a cree des specifications detaillees avec des definitions explicites de "termine" pour chaque sprint. L'Evaluateur a teste chaque fonctionnalite de maniere interactive via Playwright, detectant des defaillances fonctionnelles que le Generateur aurait declarees "terminees." Le resultat : un createur de jeux fonctionnel. Pas de qualite AAA, mais fonctionnel. On pouvait creer des sprites, construire des niveaux, assigner des comportements et reellement jouer au resultat.

L'ecart entre ces deux executions constitue a lui seul l'argument en faveur de l'ingenierie de harness en un seul exemple. Meme modele. Meme tache. Meme budget de calcul. La seule difference etait le systeme enveloppant le modele.

Experience 3 : le DAW dans le navigateur

Le test le plus ambitieux : construire une station de travail audio numerique dans le navigateur avec l'API Web Audio, executee sur Opus 4.6.

Cette experience s'est terminee en environ 4 heures pour un cout d'approximativement 125 $ en appels API. Le resultat etait fonctionnel -- audio multipiste, visualisation de formes d'onde, edition de base -- mais pas de qualite professionnelle. Plus important encore, cette experience a demontre comment les ameliorations de modele simplifient les exigences du harness.

Avec la fenetre de contexte d'un million de tokens d'Opus 4.6, Anthropic a abandonne completement les sprints. Pas de reinitialisations de contexte. Pas de negociation de contrat entre Generateur et Evaluateur. Juste une session continue unique avec une compaction automatique gerant la croissance du contexte. Le harness dont Sonnet 4.5 avait besoin -- complexe, multi-sessions, gerant soigneusement les frontieres de contexte -- est devenu inutile.

Voici l'enseignement le plus important pour les developpeurs : vos hypotheses de harness doivent evoluer avec le modele. Un harness concu pour les limitations de Sonnet 4.5 sur-concevra la couche d'orchestration lorsqu'il fonctionnera sur Opus 4.6. Et un harness concu pour les capacites d'Opus 4.6 cassera quand le modele suivant introduira de nouveaux comportements ou en eliminera d'anciens. L'ingenierie de harness n'est pas une configuration ponctuelle. C'est une pratique continue.

Si vous preferez que quelqu'un construise ce type de systeme de harness multi-agents pour votre cas d'usage, j'accepte des missions de developpement d'agents IA sur mesure. Vous pouvez voir ce que j'ai construit sur fiverr.com/s/EgxYmWD.

Comment cela se connecte a des schemas que vous connaissez deja

Le design de harness d'Anthropic n'existe pas en vase clos. Il cotoie deux autres schemas que tout constructeur d'agents serieux devrait comprendre -- car ils resolvent des pieces adjacentes du meme puzzle.

La boucle Ralph Wiggum

Creee par Geoffrey Huntley et formalisee par Boris Cherny (directeur de Claude Code chez Anthropic) fin 2025, la boucle Ralph Wiggum est elegante par sa simplicite. Vous executez un agent dans une boucle bash. Apres chaque iteration, vous verifiez la sortie par rapport a quelque chose qui ne peut pas mentir -- un linter, un verificateur de types, une suite de tests. Si ca passe, vous arretez. Si ca echoue, vous bouclez.

L'insight cle : la progression reside dans les fichiers et l'historique git, pas dans la fenetre de contexte du modele. Chaque iteration demarre avec un contexte frais. L'agent lit l'etat actuel du code base, y travaille et committe les changements. Si la boucle doit continuer, l'iteration suivante lit les fichiers mis a jour avec zero dette de contexte accumulee.

Ce schema est desormais un plugin de premier plan dans Claude Code lui-meme. Vous pouvez lancer /ralph-loop "Fix all TypeScript errors" --max-iterations 20 --completion-promise "ALL_FIXED" et vous absenter.

La ou la boucle Ralph Wiggum differe du harness a trois agents d'Anthropic : elle fonctionne mieux pour les taches objectivement verifiables. "Corriger toutes les erreurs de linting" a une verite terrain binaire -- le linter passe ou il ne passe pas. "Construire un createur de jeux beau et fonctionnel" n'en a pas. Cet ecart subjectif est exactement ce que l'evaluateur adversarial comble.

Le developpement pilote par les specifications

La troisieme piece du puzzle est la structuration des exigences avant que l'agent ne commence a coder. Des frameworks comme Spec Kit de GitHub, BMAD-METHOD et OpenSpec resolvent tous le meme probleme : des agents qui commencent a coder avant de comprendre ce qu'ils construisent.

Cela correspond directement a l'agent Planificateur dans le design d'Anthropic. Le Planificateur est essentiellement un redacteur de specifications automatise. Mais vous n'avez pas besoin d'un agent Planificateur dedie pour en tirer les benefices. Rediger une specification claire -- fonctionnalites, criteres d'acceptation, definition de "termine" -- avant de confier le travail a un agent produit des resultats considerablement meilleurs que de lancer un prompt vague a un modele en esperant le meilleur.

L'approche pilotee par les specifications explique egalement pourquoi l'experience du createur de jeux a montre des resultats si differents entre l'execution solo et l'execution avec le harness complet. L'execution solo n'avait pas de specification. L'agent l'a inventee au fur et a mesure, reduisant ses ambitions a chaque etape jusqu'a ce que "createur de jeux" devienne "quelques elements d'interface qui ressemblent a du jeu." L'execution avec le harness complet avait une specification explicite avec des definitions de "termine" -- et un evaluateur qui les faisait respecter.

J'utilise une version de cela dans mon propre travail depuis la redaction du guide de l'Agent SDK d'Anthropic. Chaque tache d'agent complexe commence desormais par une specification ecrite. Non pas parce que l'agent ne peut pas fonctionner sans -- mais parce que la specification est l'ancre qui empeche la derive du perimetre, l'achevement premature et la mort lente de l'ambition qui afflige chaque session IA de longue duree.

Ce que cela signifie pour la facon dont vous construisez des agents maintenant

C'est ici que je veux etre pratique. Les recherches d'Anthropic sont construites sur le Claude Agent SDK, mais les principes s'appliquent quel que soit le modele ou le framework que vous utilisez. Si vous construisez quoi que ce soit qui fonctionne de maniere autonome pendant plus de 15 minutes, voici ce que je retiendrais de ce travail.

Separez la generation de l'evaluation. Toujours.

C'est le changement a plus fort impact que vous puissiez apporter a n'importe quel workflow d'agent. Si votre agent genere une sortie et evalue cette sortie dans le meme contexte, vous avez un probleme de fiabilite. Il ne se manifestera peut-etre pas sur les taches simples. Mais des que la complexite augmente -- modifications multi-fichiers, exigences subjectives de qualite, interdependances entre fonctionnalites -- l'auto-evaluation echoue silencieusement.

Vous n'avez pas besoin d'un systeme adversarial sophistique pour commencer. Un second agent avec un prompt systeme sceptique qui passe en revue la sortie du premier agent suffit a detecter les cas les plus flagrants d'auto-approbation. J'utilise une version de cela dans mon pipeline de contenu, et l'evaluateur rejette environ 30 % des premiers jets -- des jets qui, sans controle, auraient ete publies avec des problemes structurels que je detecterais lors d'une revue manuelle.

Utilisez des artefacts, pas la memoire, comme source de verite

Chaque element de progression devrait exister en dehors de la fenetre de contexte du modele. Commits git. Fichiers JSON de taches. Specifications Markdown. Logs structures. Si la session de votre agent plante et que le seul historique de ce qui s'est passe reside dans l'historique de conversation -- vous avez construit un systeme fragile.

C'est le meme principe que celui derriere l'architecture de graphe de taches persistant de Claude Code. Le graphe de taches reside sur disque. Les agents le lisent, le mettent a jour et y ecrivent. Les fenetres de contexte vont et viennent. Le graphe de taches persiste.

Adaptez la complexite de votre harness aux capacites de votre modele

L'evolution propre d'Anthropic prouve ce point. Le harness qu'ils ont construit pour Sonnet 4.5 -- avec reinitialisations de contexte, frontieres de sprints, negociation de contrats -- etait necessaire parce que le modele en avait besoin. Le harness qu'ils ont construit pour Opus 4.6 a abandonne la moitie de ces composants parce que le contexte d'un million de tokens et la coherence amelioree du modele les rendaient inutiles.

Auditez votre propre harness. Executez-vous une gestion de contexte complexe parce que le modele en a reellement besoin, ou parce que vous avez concu le systeme il y a six mois quand le modele en avait besoin ? Sur-concevoir la couche d'orchestration gaspille des tokens, ajoute de la latence et introduit des points de defaillance que le modele actuel pourrait simplement gerer seul.

Definissez "termine" avant de commencer

Le schema du contrat de sprint -- ou le Generateur et l'Evaluateur s'accordent sur les criteres d'acceptation avant le debut du travail -- s'applique a chaque interaction avec un agent, pas seulement aux systemes multi-agents. Quand vous demandez a un agent de "construire un tableau de bord," definissez ce que le tableau de bord doit inclure, comment vous verifierez chaque fonctionnalite et quel niveau de qualite vous attendez. Plus votre definition de "termine" est explicite, moins l'agent a de marge pour declarer une victoire prematuree.

Les limites honnetes : ce que l'ingenierie de harness ne peut pas resoudre

Je vous rendrais un mauvais service si je vous laissais repartir en pensant que l'ingenierie de harness est une solution miracle. Ce n'en est pas une. Apres avoir passe des semaines a implementer ces schemas, voici les murs que j'ai rencontres.

Les couts s'accumulent rapidement. L'experience du DAW dans le navigateur a coute 125 $ en appels API pour environ 4 heures de travail autonome. Un systeme a trois agents consomme environ 3 fois plus de tokens qu'une approche a agent unique, car vous faites fonctionner trois modeles (ou trois sessions du meme modele) en coordination. Pour les projets personnels et les experimentations, c'est acceptable. Pour les systemes de production fonctionnant 24h/24 et 7j/7, les aspects economiques necessitent une modelisation attentive.

La qualite de l'evaluateur est le plafond. Votre systeme ne peut etre meilleur que la capacite de votre evaluateur a detecter les problemes. Si l'evaluateur ne peut pas identifier un desalignement subtil de l'interface ou une condition de concurrence dans du code asynchrone, ces problemes seront livres. Anthropic l'a reconnu -- leurs evaluateurs initiaux rataient des bugs subtils et approuvaient des implementations superficielles. Obtenir un evaluateur performant a necessite de l'iteration, pas seulement des ajustements de prompts.

La qualite subjective reste difficile. L'experience du musee neerlandais a montre une amelioration impressionnante grace a l'iteration adversariale. Mais "impressionnant pour une IA" et "impressionnant compare a un designer humain avec 10 ans d'experience" sont des barres differentes. L'ingenierie de harness reduit cet ecart. Elle ne le comble pas. Pour le travail creatif subjectif -- design, ecriture, musique -- l'evaluation humaine reste necessaire a l'etape finale.

Le debogage de harness est une competence a part entiere. Quand un agent unique produit une mauvaise sortie, le debogage est direct : lire la conversation, trouver ou ca a deraille, corriger le prompt. Quand un systeme a trois agents produit une mauvaise sortie, la defaillance peut se situer dans la specification du Planificateur, l'implementation du Generateur, les criteres de l'Evaluateur, ou l'interaction entre n'importe lequel d'entre eux. J'ai passe plus de temps a deboguer les interactions de harness que je n'en ai jamais passe a deboguer des prompts d'agents individuels.

Ce sont de vraies limitations. Elles n'invalident pas l'approche -- l'experience du createur de jeux prouve que l'architecture a trois agents produit des resultats considerablement meilleurs que la generation solo. Mais elles signifient que l'ingenierie de harness est une pratique qui exige de l'iteration, de la surveillance et un raffinement continu. Pas un schema que l'on implemente une fois pour l'oublier.

Ou tout cela nous mene

Anthropic a publie deux articles sur ce sujet -- le premier en novembre 2025 centre sur le schema initialiseur-et-agent-de-codage, et le suivi de mars 2026 introduisant l'architecture complete a trois agents avec evaluation adversariale. La trajectoire vous indique ou cela se dirige.

Les ameliorations de modeles simplifient le design des harness. Opus 4.6 a elimine le besoin de reinitialisations de contexte. La prochaine generation pourrait eliminer le besoin de compaction explicite du contexte. Mais les ameliorations de modeles n'eliminent pas le besoin d'orchestration et d'evaluation. Meme un modele hypothetiquement parfait -- avec un contexte infini, une memoire parfaite et zero erreurs de raisonnement -- produirait quand meme de meilleurs resultats avec un evaluateur separe contestant son travail. Ce n'est pas une limitation du modele. C'est un insight fondamental sur la facon dont la qualite emerge de la pression adversariale.

La prediction pratique que je ferais : d'ici 12 mois, les plateformes de harness-as-a-service seront aussi repandues que les plateformes de RAG-as-a-service le sont aujourd'hui. Des outils comme le Ralph Loop Agent de Vercel et l'ecosysteme croissant autour des frameworks de developpement pilote par les specifications comme le Spec Kit de GitHub en sont les premiers signaux. La matiere premiere -- modeles, capacites d'utilisation d'outils, API d'evaluation -- est deja prete pour la production. Ce qui manque, c'est la couche d'orchestration empaquetee qui la rend accessible aux ingenieurs qui ne veulent pas construire l'infrastructure de harness de zero.

Pour les developpeurs travaillant dans cet espace en ce moment, l'opportunite est claire. Le harness est le produit. Le modele est une commodite. Les equipes et les ingenieurs qui deviennent competents en design de harness -- qui apprennent a decomposer les taches, construire des evaluateurs fiables, gerer efficacement le contexte et iterer leurs schemas d'orchestration en parallele des ameliorations de modeles -- construiront des systemes IA qui fonctionnent en production pendant que tous les autres se battent encore avec des prompts a agent unique qui s'effondrent apres 30 minutes.

Cette session de DAW que j'ai observee ? Quatre heures de codage autonome qui ont produit une application fonctionnelle. Non pas parce que le modele etait magique. Mais parce que le systeme autour de lui etait concu pour garder le modele honnete, le garder concentre et le faire iterer jusqu'a ce que le travail soit reellement termine.

C'est la lecon. Pas de meilleure IA. De meilleurs systemes autour de l'IA.

Questions frequentes

Qu'est-ce qu'un harness d'agent en developpement IA ?

Un harness d'agent est le framework logiciel qui enveloppe un modele IA pour gerer les prompts, les outils, les boucles de retroaction et la validation -- transformant un modele brut en un systeme autonome fiable. Pensez-y comme la voiture qui rend le moteur utile : direction, freins, navigation, et tout le reste. Pour une analyse plus approfondie, consultez la section "Pourquoi votre agent IA echoue" ci-dessus.

Comment l'anxiete de contexte affecte-t-elle les agents IA ?

L'anxiete de contexte survient lorsque les modeles IA percoivent qu'ils approchent des limites de la fenetre de contexte et commencent a se precipiter, sauter des etapes ou declarer des taches terminees prematurement. Sonnet 4.5 presentait ce comportement aux alentours de 80 000 tokens. La fenetre d'un million de tokens d'Opus 4.6 elimine largement le probleme pour les sessions de moins de 6 heures. Consultez la section sur les modes de defaillance pour les strategies d'attenuation.

Quelle est la difference entre compaction de contexte et reinitialisation de contexte ?

La compaction de contexte resume l'historique de conversation pour liberer de l'espace de tokens tout en preservant les informations cles -- avec perte mais continue. La reinitialisation de contexte donne a l'agent une fenetre de contexte completement vierge pour chaque sous-tache, en s'appuyant sur les fichiers et artefacts pour l'etat. Les modeles plus recents avec des fenetres de contexte plus larges privilegient la compaction aux reinitialisations.

Comment l'evaluation adversariale ameliore-t-elle les sorties des agents IA ?

L'evaluation adversariale separe la generation de contenu de l'evaluation de qualite en utilisant deux agents distincts -- inspiree de l'architecture GAN. L'agent evaluateur utilise des outils comme Playwright pour tester interactivement les applications en cours d'execution, detectant des defaillances fonctionnelles que la seule revue de code manquerait. Les experiences d'Anthropic ont montre que cela produit des applications fonctionnelles la ou la generation solo produit des sorties visuellement similaires mais non fonctionnelles.

Puis-je implementer les schemas de harness d'agent sans le Claude Agent SDK ?

Oui. Les principes -- decomposition de taches, etat base sur les artefacts, evaluation separee, contrats de sprint -- sont agnostiques du modele et du framework. Le Claude Agent SDK fournit des abstractions pratiques, mais vous pouvez implementer les memes schemas avec n'importe quelle API de modele, une couche d'orchestration Python et des outils standards comme Playwright pour l'evaluation.

Travaillons ensemble

Vous cherchez a construire des systemes IA, automatiser des workflows ou faire evoluer votre infrastructure technologique ? Ce serait un plaisir de vous aider.

• Fiverr (developpements et integrations sur mesure) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de securite) : xcybersecurity.io