Le harness devient le produit des systèmes agentiques

Résumé exécutif

Les sorties de mai et juin 2026 déplacent le centre de valeur des agents. Le modèle reste utile, mais il ne suffit plus. La qualité vient du système qui cadre sa tâche, choisit le contexte, ouvre les bons outils, limite les droits, garde l’état, vérifie le résultat et trace les écarts. HarnessX propose un harness fait de briques typées et apte à évoluer. AI Harness Engineering décrit onze rôles du runtime. De nouveaux travaux montrent aussi que les logs usuels ne prouvent pas sous quelle délégation une action a eu lieu, et que les skills ou les données lues peuvent orienter l’agent vers un acte non voulu. Pour l’UAH, le harness doit donc devenir une plate-forme versionnée, mesurée et sûre, pas un lot de prompts et de hooks.

Ce qui vient de sortir

HarnessX, publié le 12 juin 2026, assemble des briques de prompt, outil, mémoire et contrôle par une règle de substitution. Son moteur AEGIS lit les traces, cherche de meilleures formes de harness et transforme les trajets en mises à jour du runtime ou en signal d’entraînement. Les auteurs annoncent un gain moyen de 14,5 % sur cinq tests, avec un pic de 44 %. Ce résultat est fort mais non reproduit ici. Le code complet est annoncé pour plus tard, donc le papier sert surtout de piste de design.

AI Harness Engineering, publié le 13 mai, est plus simple à reprendre. Il donne au harness onze rôles : définir la tâche, choisir le contexte, gérer les outils, garder la mémoire projet, suivre l’état, tracer, attribuer les échecs, vérifier, filtrer les droits, suivre l’entropie et noter les actes humains. Il propose quatre niveaux, H0 à H3. En H0, on obtient surtout une sortie finale. En H3, on garde aussi les pas de preuve, les causes d’échec, les tests et le rapport de fin.

Observability for Delegated Execution ajoute un point clé. Deux traces peuvent sembler identiques tout en venant de deux mandats différents. Un span, une date et une chaîne causale ne disent pas toujours qui a donné le droit d’agir, dans quel but, sur quelles données et pour combien de temps. Le papier propose donc de joindre le contexte de délégation à l’appel au moment où il part, via un gateway et un format commun.

La sécurité change la forme du harness

Plus un harness donne de moyens, plus il doit être strict.

Une étude du 9 juin évalue des injections de consignes dans AgentDojo sur 80 couples de tâches, quatre domaines et plusieurs modèles. Dans le budget testé, les méthodes black-box dépassent les méthodes à gradient. Des consignes conçues pour une tâche peuvent aussi agir sur des tâches ou domaines non vus. En revanche, un texte optimisé sur un petit modèle ouvert ne se reporte pas toujours sur un grand modèle. Le risque est réel mais dépend du modèle, de la tâche et du cadre.

Un autre papier, publié le 17 mai, explique pourquoi séparer « données » et « consignes » ne suffit pas. Un contenu externe peut changer le sens du flux, imiter une norme légitime ou mêler plusieurs cadres. La leçon n’est pas que toute défense échoue. Elle est qu’un filtre de texte ne peut pas porter seul la sûreté. Le runtime doit limiter l’effet réel d’une phrase lue.

Les skills ouvrent une autre voie de risque. SkillSafetyBench réunit 155 cas, 47 tâches, six domaines et trente classes de risque. La demande de l’usager peut être saine alors qu’un fichier local, une doc ou un artefact lié au skill pousse vers un acte non prévu. Un skill doit donc être traité comme un paquet de code : origine, hash, droits, tests, bac à sable et mode canary.

Counterfactual Trace Auditing montre aussi que le seul taux de succès masque les effets. Sur 49 tâches de code, l’ajout d’un skill ne change le score moyen que de 0,3 point, mais l’audit repère 522 écarts de conduite : copie de modèle, fichier hors but, plan trop long ou reprise après erreur. Un skill peut donc changer le chemin sans changer le score final.

Pourquoi cela compte pour l’UAH

L’UAH a déjà GOAL.md, les AAS, les policy gates, le ROL, ASAL, ACCL, SDM, CAL et ACE. Le risque est de garder ces pièces dans des docs sans lien dur avec chaque run.

L’unité de base doit devenir un Episode Package. Il garde :

le but et les règles d’arrêt ;
l’agent et la version du harness ;
le mandat, les droits et la durée ;
le contexte et sa source ;
les outils, skills et modèles ;
les choix de routage ;
les actes, retours et erreurs ;
les tests et les contre-preuves ;
le coût, le temps et les quotas ;
le résultat, la confiance et les actes humains ;
les fichiers créés et les idées à garder.

Ce paquet devient la preuve du ROL. Il sert au debug, à l’audit, à la mémoire, à la sécurité et à l’ACE. Sans paquet commun, chaque outil garde un bout de l’histoire et la cause réelle d’un bon ou d’un mauvais résultat reste floue.

Architecture d’intégration proposée

1. Harness Core

Le cœur doit suivre une machine à états courte :

inspect → plan → authorize → act → observe → verify → score → record → stop.

Chaque pas a un schéma, un seuil d’entrée, un seuil de sortie et un plan de reprise. Le modèle peut proposer un acte. Le runtime valide les droits, le budget et le format avant de le lancer.

2. Registre de briques typées

Prompts, outils, skills, mémoires, tests et règles deviennent des briques avec un id, une version, des entrées, des sorties, des droits, un coût, des risques, des tests et une origine. Deux briques ne sont dites remplaçables que si elles suivent le même contrat. Une règle de substitution plus riche pourra venir après. Le MVP doit d’abord éviter les échanges faux ou non sûrs.

3. Enveloppe de délégation

Chaque appel doit porter au moins : id de mandat, épisode parent, sujet qui délègue, agent, but, actes permis, zone de données, budget, fin de vie et version de règle. Ce cadre doit suivre l’appel dans MCP, A2A, API, CLI, navigateur et file de jobs.

OpenTelemetry et Langfuse peuvent porter les spans et coûts. Ils ne doivent pas définir le sens métier du mandat. Le schéma de délégation reste sous le contrôle de l’UAH.

4. Gate de supply-chain des skills

Avant usage, un skill passe par :

contrôle du manifeste et de la licence ;
scan de code et de secrets ;
hash ou signature ;
bac à sable ;
test des droits ;
tests face à des données piégées ;
run avec et sans skill ;
shadow mode ou canary.

Un skill non validé peut être lu pour étude, mais pas recevoir un droit d’action. Le gateway ne doit jamais changer une ressource trouvée en pouvoir actif sans gate.

5. Plan de retour et d’évolution

Une trace ne doit pas modifier le harness en direct. Elle crée un candidat :

trace → pattern → lot de preuve → test → gate → version → bench → promotion.

Cette coupure réduit le reward hacking, la copie d’une erreur et la diffusion d’un cas local. L’ACE ne fige un pattern que s’il revient, gagne face à une base, reste sûr et apporte un gain net.

Place des briques OSS et des travaux proches

OpenHands SDK reste un bon point de repère pour le bac à sable, le cycle de vie, le mode local ou distant et le choix de plusieurs LLM. Il peut servir d’adapter de worker. Il ne doit pas devenir le noyau sans port de sortie.

mcp-proto-okn, publié fin mai, montre comment exposer des graphes de science via MCP : lecture du schéma, SPARQL, ontologies et requêtes sur plusieurs graphes. Il peut guider un ScientificKnowledgeGraphPort pour les AAS de veille.

La dissertation de Yuchen Xia, déposée le 18 juin, décrit une archi à trois couches pour unir LLM, jumeaux numériques et automate. Elle cite le rôle agent-as-a-service. Ce signal renforce l’idée qu’un AAS doit avoir des services, ressources et limites clairs, et non un simple rôle écrit.

La passe brevets n’a pas donné de texte primaire récent, net et centré sur le harness. PatentLMM, MemGraph, Agent Ideate et ClaimBrush restent utiles pour bâtir un futur adapter de veille brevets. Ils ne prouvent pas qu’un brevet récent couvre l’UAH. Garder ce manque est plus sûr que remplir la liste avec des titres mal liés.

Expérimentation recommandée

Le premier test doit être petit et réel : produire une note de veille à partir de trois sources, la faire revoir, puis décider si un pattern doit être gardé.

Comparer quatre niveaux :

H0 : modèle et prompt ;
H1 : outils et état ;
H2 : droits, tests et épisode ;
H3 : mandat traçable, gate des skills, test contre-factuel et ACE.

Faire trente runs par niveau sur les mêmes tâches. Mesurer le taux de succès prouvé, les fautes non vues, les actes hors portée, les appels sans mandat lisible, les écarts dus aux skills, le coût, le temps, la capacité à rejouer et le temps d’audit. Mesurer aussi les bons et faux candidats de capitalisation.

Un niveau ne passe au suivant que si le gain de qualité ou de sûreté paie le coût ajouté. Il faut garder une base simple. Sans base, tout progrès est une impression.

Risques

Le premier risque est de régler le harness pour un seul test. Le second est le reward hacking si le juge partage les biais du modèle. Le troisième est l’excès de logs : plus de traces ne veut pas dire plus de sens. Le quatrième est un gateway trop central. Le dernier est la fuite de secrets, de données perso ou de code dans les épisodes.

Les gardes sont connus : juges distincts, tests hors domaine, quotas, masque des secrets avant stockage, plans de contrôle et d’action séparés, durée de garde courte, hash des pièces et replay en bac à sable.

Assets réutilisables à capitaliser

La veille justifie six briques :

AgentHarnessEpisode.schema.json ;
DelegationContextEnvelope.schema.json ;
SkillSupplyChainPolicy.rego ;
HarnessMaturityAssessment.md ;
CounterfactualSkillEval ;
HarnessEvolutionWorkflow.

Ces briques peuvent cadrer Claude Code, Codex, OpenHands, n8n, Stagehand ou un autre worker. Elles ont plus de valeur qu’un cadre fermé de plus.

Cette étape doit aussi produire un jeu de données stable : tâches, entrées, droits, sorties, notes des juges, coûts et incidents. Ce corpus permettra de comparer les futures versions du harness sans changer les règles au milieu du test.

Prochaine itération R&D

Ne pas lancer tout de suite un moteur qui se change seul. Standardiser d’abord l’épisode, le mandat et le gate des skills. Puis instrumenter le test de veille. Après trente à cent épisodes, l’UAH aura assez de faits pour juger une évolution par outcomes, et non par intuition.

Sources

Les dix sources primaires de cet article sont indexées dans ../research/source_index.md : HarnessX, AI Harness Engineering, Observability for Delegated Execution, les deux études sur l’injection, SkillSafetyBench, Counterfactual Trace Auditing, OpenHands SDK, mcp-proto-okn et la dissertation de Yuchen Xia.