AI agent harness : concevoir un runtime fiable

Un AI agent harness est la boucle de contrôle logicielle qui appelle le modèle de façon répétée, assemble le contexte, route les tool calls, persiste l’état et décide quand un run doit continuer, s’arrêter, reprendre ou être transmis à une personne. Le modèle propose l’étape suivante, mais le harness possède l’execution loop et l’environnement. Deadlines, limites d’étapes, permissions, sandbox, retries, checkpoints, tracing et vérification du résultat terminal vivent ici.

Il ne faut pas utiliser ce terme comme étiquette à la mode pour un simple system prompt ou wrapper SDK. Le prompt engineering règle les instructions ; le context engineering sélectionne les informations pour un model call précis ; un planner propose un chemin ; un framework fournit des abstractions ; le harness relie ces éléments à un vrai runtime contract. Un produit peut fournir un harness géré, un autre des primitives pour construire le vôtre, mais la marque du modèle ne détermine pas la fiabilité du système complet.

• Modèle → propose une réponse ou un tool call dans le contexte visible.
• Harness → gère loop, state, tools, budgets, isolation et recovery.
• Application policy → définit authority, approvals et outcomes autorisés.
• Environment → exécute les commandes et stocke les artefacts autoritatifs.

Un baseline de production requiert cinq contrats séparés. La session est un journal append-only d’événements avec correlation ID. Le loop assemble l’input, appelle le modèle, valide la réponse et applique la stop policy. Le tool gateway publie une allowlist étroite et revalide arguments et permissions. La sandbox isole filesystem, processus et destinations réseau. Le state store conserve task status, références d’artefacts, approvals et postconditions indépendamment du transcript de chat.

Cette séparation rend les composants remplaçables. Le modèle ou le prompt peut évoluer sans migration du task state autoritatif ; la sandbox peut être durcie sans réécrire le planner ; une implémentation de tool peut être rollbackée tout en conservant le trace. Anthropic décrit session, harness et sandbox comme des parties distinctes des systèmes de managed agents, tandis qu’OpenAI décrit un model-native harness avec sandbox execution. Ce sont des descriptions d’architecture de première partie, pas la preuve d’une supériorité universelle d’un fournisseur.

• Session log : model calls, tool requests, résultats, approvals et raison terminale.
• Task state : planned, running, blocked, awaiting-approval, completed ou failed.
• Artifact store : outputs versionnés, checksums, provenance et owner.
• Sandbox policy : mounts, secrets, network egress, resource limits et cleanup.
• Control plane : budgets, kill switch, concurrency, resume et reconciliation.

Un agent de longue durée traverse context windows, restarts et attentes d’approval. La compaction aide à faire tenir l’historique, mais ne remplace pas un état durable. Un checkpoint doit contenir version de tâche, acceptance criteria terminés, artefacts vérifiés, risques ouverts, approvals en attente, dernières postconditions autoritatives et une prochaine étape concrète. Une nouvelle session commence par vérifier environment et state au lieu de faire confiance au résumé optimiste produit par le modèle précédent.

Dans ses recherches sur les harnesses de longue durée, Anthropic a utilisé une feature list, un progress artifact, le version control et une vérification end-to-end de base avant la modification suivante. Le principe transférable n’est pas le nom de fichier mais le handoff protocol : le travail est découpé en slices terminables, le statut est confirmé par un test et le worker suivant reçoit un paquet court et vérifiable. En support ou research, ce paquet peut être un case state, un evidence ledger et une action inachevée plutôt qu’un commit git.

Un harness ne doit pas donner au modèle un catalogue universel de tools en espérant qu’un prompt maintienne les frontières. À chaque étape, le tool gateway vérifie actor, tenant, resource, action, parameters, risk tier, version de l’approval et expiration. Les opérations read, draft et write utilisent des credentials différents. Une action conséquente reçoit idempotency key, preflight preview et postcondition attendue ; un timeout après l’appel mène à reconciliation plutôt qu’à un retry aveugle.

La sandbox réduit le blast radius mais ne crée pas à elle seule une business authorization. Un processus peut être isolé tout en possédant un token dangereux ou un egress autorisé vers une API de production. L’effective authority est donc l’intersection de sandbox policy, credential scope, tool contract, application rules et approval valide. Prompt injection, dependency compromise ou erreur du modèle ne doivent pas pouvoir élargir cette intersection via des instructions textuelles.

• Permission inconnue ou approval obsolète → fail closed.
• Résultat inconnu d’un write call → reconcile avant retry.
• Nouvelle destination ou nouveau scope → décision d’autorisation séparée.
• Kill switch → bloque les nouvelles actions tout en conservant forensic evidence et recovery path.

Les golden tasks doivent évaluer outcome et trajectory. Des graders déterministes vérifient schema, filesystem diff, API postcondition, budget et événements interdits. Un model grader peut juger la qualité d’un artefact ouvert, mais ne remplace ni la vérification des permissions ni celle du side effect réel. Human review reste nécessaire pour une utilité ambiguë et un risque matériel. Une violation critique de policy ne doit pas être moyennée avec un bon style rédactionnel.

La failure suite doit couvrir context exhaustion, checkpoint corrompu, duplicate delivery, tool response perdue, partial commit, credential révoqué, stale branch, dependency indisponible, prompt injection dans le contenu récupéré et un agent annonçant completion avant le passage de l’acceptance test. Comparez non seulement task success, mais verified progress par run, tool calls inutiles, recovery success, reviewer minutes, wall-clock time et cost per accepted outcome sur le même corpus. Les expériences publiées par un vendor ne sont pas votre baseline.

Commencez par une tâche read-only bornée qui possède déjà un baseline de workflow déterministe. Ajoutez un model loop, deux ou trois tools distincts, des terminal states explicites, le task state hors du transcript et un trace complet. Ajoutez ensuite un restart fixture, un corrupted-state fixture et un canary sur un petit segment. N’introduisez planner-generator-evaluator multi-agent, longues boucles autonomes ou write authority que lorsque le harness plus simple échoue de façon mesurable sur des task slices enregistrés.

Un harness encode des hypothèses sur les faiblesses du modèle actuel ; chaque workaround a donc besoin d’un owner, d’un eval et d’une review date. Après une mise à niveau du modèle ou d’un tool, réalisez une ablation : faut-il encore un planner séparé, un context reset forcé, trop de critique loops ou un gros prompt ? Le rollback rétablit un ensemble compatible de loop policy, tool versions et checkpoint schema ; les writes actifs sont d’abord reconciled. Le meilleur harness n’est pas le plus grand, mais le plus petit circuit qui termine de façon démontrable vos tâches dans les limites définies.

• Define → outcome, authority, environment et terminal states.
• Instrument → session events, state transitions, budgets et artifacts.
• Evaluate → success, policy, recovery, efficiency et human acceptance.
• Canary → read-only, bounded concurrency, kill switch et on-call owner.
• Simplify → supprimer régulièrement le scaffolding qui n’apporte plus de gain mesurable.