Qu'est-ce que le harnais en IA ?

J'ai récemment vu que l'outil OpenClaw était qualifié de harnais. Je me suis dit : « Intéressant. » OpenClaw n'est pas un harnais. Il s'agit d'un environnement d'exécution pour agent : il gère la boucle de l'agent. Alors, que signifie réellement le mot « harnais » ?

La discussion jusqu'à présent

La structure de base du concept provient de l'article d'avril 2026 de Birgitta Böckeler, qui définit avec élégance un agent comme model + harness = agentmodèle + harnais = agent. Elle a divisé la pile en un harnais de création (l'environnement d'exécution interne fourni avec l'outil) et un harnais d'utilisateur (le contexte personnalisé du développeur). Cette définition s'appuie sur une vague de discussions datant de février 2026, qui incluait l'approche pragmatique de Mitchell Hashimoto en matière d'ingénierie AGENTS.mddes contextes AGENTS.md, de l'aperçu d'OpenAI sur l'ingénierie des harnais internes pour le déploiement automatisé et du mémorandum de synthèse original de Böckeler.

Cinq couches, de l'extérieur vers l'intérieur

Je pense qu'un agent ne se résume pas à l'association modèle + harnais. Pour moi, cela commence par le constat que nous ne pouvons tout simplement pas faire confiance à l'environnement d'exécution de l'agent. Afin d'obtenir une certaine certitude quant à la sécurité de la chaîne d'approvisionnement logicielle du code produit par une usine d'agents, nous avons besoin d'une couche de sandbox distincte pour capturer les informations de provenance et limiter l'impact potentiel d'un agent qui déraille.

Je conçois cette architecture d'environnement d'exécution d'agent sécurisée comme une poupée gigogne, de l'extérieur vers l'intérieur :

Infrastructure → sandbox → harnais d'agent → environnement d'exécution → modèle

Chaque couche possède un propriétaire, un mode de défaillance et un principe de conception différents. Passons-les en revue.

Couche 1 : infrastructure

L'infrastructure est le lieu où les agents s'exécutent physiquement. Il peut s'agir de runners GitHub Actions, de pods Kubernetes ou de machines virtuelles (VM). Cette couche concerne le calcul, la mise en réseau et la gestion des ressources, et elle importe plus qu'on ne le pense.

Considérez ce qui se passe lorsque vous passez d'un seul agent à des dizaines d'agents fonctionnant en parallèle. Roy Belio a fait fonctionner le système de recherche automatique d'Andrej Karpathy pour réaliser 198 expériences autonomes sur Red Hat OpenShift AI, y compris la planification des GPU et l'orchestration des tâches sans aucune intervention humaine. Ce n'est pas un problème de harnais. Ce n'est pas un problème de sandbox. C'est un problème d'infrastructure. Votre plateforme peut-elle gérer des demandes de ressources concurrentes, éviter que les agents ne se privent mutuellement de ressources et planifier les charges de travail des GPU ?

La planification des GPU devient elle-même une discipline d'infrastructure de premier ordre. Red Hat OpenShift 4.21 a introduit l'allocation dynamique des ressources, une API Kubernetes qui permet aux charges de travail de demander des GPU par attributs (modèle, mémoire, capacité de calcul) plutôt que par simple nombre. Elle permet également le partage des GPU entre les conteneurs, afin que les sidecars d'inférence légers ne gaspillent pas un périphérique entier. Il s'agit d'une infrastructure pure : aucune politique de sandbox, aucune entrée AGENTS.md, aucun choix de modèle. La plateforme fait simplement son travail.

Couche 2 : sandbox

La sandbox restreint les actions de l'agent et limite l'impact potentiel en cas de problème. C'est une question d'isolement. Ma collègue, Marta Anon Ruiz, a décrit cette couche comme « façonnant l'intentionnalité de l'agent ». Des projets tels qu'OpenShell de NVIDIA fonctionnent sur cette couche. Du point de vue de la sécurité de la chaîne d'approvisionnement logicielle, il s'agit de votre principale limite de confiance, la différence entre un agent qui peut rm -rf /et un autre qui ne peut pas, ou la différence entre un agent qui peut gh issue delete lire tous vos tickets GitHub et un autre qui ne le peut pas (ou un agent qui peut écrire et exécuter son propre script pour faire de même).

Si l'infrastructure demande : « Où l'agent s'exécute-t-il ? », la sandbox demande : « À quoi l'agent est-il autorisé à toucher ? » Ce sont des questions différentes avec des réponses différentes.

Red Hat a publié un guide détaillé sur la construction de garde-fous résilients pour les agents d'IA sur Kubernetes, incluant des contraintes de contexte de sécurité (SCC) restricted-v2, des NetworkPolicies de sortie avec refus par défaut et un contrôle d'accès basé sur les rôles (RBAC) par agent. Chacun de ces contrôles est soustractif : vous commencez par tout ce que l'agent peut faire et vous supprimez des capacités jusqu'à ce qu'il ne reste que celles qui sont nécessaires.

La couche de sandbox va plus loin que les politiques réseau. Les conteneurs en sandbox Red Hat OpenShift, basés sur Kata Containers et les peer-pods, constituent une technologie clé à ce niveau, car ils prennent des mesures supplémentaires pour isoler un processus d'agent de son hôte. Consultez également l'article sur les compétences des agents et les menaces de sécurité, qui explore les menaces et les solutions, notamment la signature cryptographique des compétences des agents afin de vérifier leur provenance avant l'exécution. Une compétence non signée injectée dans la chaîne d'outils d'un agent constitue une attaque de la chaîne d'approvisionnement logicielle. La couche de sandbox peut aider à contrer cela.

Des projets comme OpenShell de NVIDIA sont pertinents à ce niveau, tout comme les primitives de sécurité intégrées aux environnements d'exécution de conteneurs généraux. Rien de tout cela ne constitue des « harnais » au sens de Hashimoto : vous n'apprenez pas à l'agent à mieux travailler, vous l'empêchez d'effectuer un travail dangereux ou inattendu.

Couche 3 : harnais d'agent

C'est la couche sur laquelle Hashimoto a écrit, et ce que Birgitta Böckeler appelle le harnais d'utilisateur. Il s'agit de la couche d'activation, qui comprend les fichiers AGENTS.md, les compétences, les outils personnalisés, les linters faits main, les invites système et une bonne suite de tests. Ce sont les éléments que vous concevez de manière itérative pour augmenter les chances que l'agent réussisse.

L'article de Marco Rizzi sur l'ingénierie des harnais avec des flux de travaux structurés cristallise le principe « structure en entrée, structure en sortie ». L'article décrit l'analyse de la structure du projet avec LSP et MCP pour générer des invites contextuelles : il ne s'agit pas seulement de dire à l'agent quoi faire, mais de lui donner les informations structurelles nécessaires pour bien le faire. C'est ce qu'on appelle le contrôle par anticipation dans la terminologie de Birgitta.

L'utilisation d'outils est une partie critique du harnais qui permet ce que Birgitta Böckeler appelle des guides informatiques. L'avènement de l'utilisation des outils, et l'étape standard du MCP, a rendu possible la création d'agents significatifs, donnant à l'environnement d'exécution de l'agent une meilleure chance d'atteindre ses objectifs. Construire des agents d'IA efficaces avec MCP approfondit le sujet du MCP, en montrant comment vous pouvez activer des agents en donnant à leur harnais un moyen d'accéder dynamiquement aux ressources de votre entreprise.

Comment savoir si votre harnais fonctionne ? Vous l'évaluez. Michael Dawson écrit sur le développement piloté par l'évaluation, en présentant un cadre d'évaluation en huit étapes utilisant les modèles DeepEval et LLM-as-judge. Les évaluations constituent la boucle de rétroaction qui vous indique si les modifications de votre harnais ont amélioré ou dégradé l'agent. Sans elles, l'ingénierie des harnais n'est que pure conjecture. Des outils comme l'evaluation hub aident à gérer cela à grande échelle.

Les artefacts de harnais posent un problème de gestion. À mesure que votre fichier AGENTS.md s'étoffe, que vos outils personnalisés se multiplient et que vos invites système évoluent, comment les versionnez-vous ? Comment les partagez-vous entre les projets ? L'article sur Lola, un gestionnaire de paquets de contexte d'IA, traite le contexte d'IA comme des paquets versionnés. Cette approche est logique. Si vos artefacts de harnais sont des artefacts d'ingénierie, gérez-les comme tels.

Couche 4 : environnement d'exécution de l'agent

L'environnement d'exécution de l'agent est le moteur de la boucle de l'agent. Claude Code, OpenCode, Goose ou une solution personnalisée. Il gère la distribution des outils, les fenêtres de contexte et la gestion des conversations.

C'est ce qu'Anthropic a appelé un « harnais » dans cet e-mail. Je pense que c'est incorrect, ou du moins imprécis. L'environnement d'exécution n'est pas un élément que vous pouvez concevoir et améliorer, à moins de construire le vôtre. Il exécute la boucle : envoi de l'invite, réception de la réponse, répartition des appels d'outils, renvoi des résultats. Je ne peux pas minimiser l'importance de cette couche. Les environnements d'exécution s'améliorent de plus en plus et nous en bénéficions tous.

Cependant, certaines organisations construiront les leurs. Si vous avez des exigences de souveraineté, si vous avez besoin de fonctionnalités qu'aucun environnement d'exécution standard ne propose, ou si votre cas d'utilisation nécessite un degré de contrôle particulièrement élevé sur le comportement de l'environnement d'exécution, vous devez construire le vôtre et vous avez besoin d'API sur lesquelles vous appuyer. C'est là que des projets comme Llama Stack comptent, en exposant des API ouvertes pour les réponses, la gestion des fichiers, la recherche et, un jour, la mémoire. Un environnement d'exécution souverain construit sur des API ouvertes est une proposition différente d'un environnement verrouillé sur un service propriétaire. Les plateformes de Red Hat prennent en charge ces deux approches : les équipes qui adoptent un environnement d'exécution existant et conçoivent le harnais d'utilisateur autour, et les équipes qui construisent leur propre environnement d'exécution à partir d'API ouvertes parce que leur contexte l'exige.

Couche 5 : modèle et point de terminaison d'inférence

Du côté de la mise à disposition, le guide de Red Hat sur l'intégration de Claude Code avec Red Hat AI Inference Server on OpenShift place vLLM sur Red Hat AI pour l'inférence sur site. Votre modèle, votre cluster, vos données. L'exécution de l'inférence sur votre propre matériel a un impact majeur sur le modèle de confiance de l'ensemble de votre pile d'agents.

En ce qui concerne la provenance, les travaux de Red Hat sur la sécurité de la chaîne d'approvisionnement logicielle moderne, en particulier Red Hat Trusted Artifact Signer et la signature cryptographique des modèles, sont ici essentiels. Si vous ne pouvez pas vérifier et gérer la provenance du modèle que vous utilisez, toute votre pile supérieure repose sur des fondations non vérifiées. La signature de modèle est à la couche de modèle ce que la signature de compétence est à la couche de harnais : une garantie cryptographique que vous exécutez bien ce que vous pensez exécuter.

Soustractif ou additif

La sandbox et le harnais ont des philosophies de conception opposées. La sandbox est soustractive : vous retirez des capacités pour réduire les risques. Le harnais est additif : vous ajoutez des connaissances et des outils pour accroître les compétences. Si nous les confondons, nous brouillerons les principes de conception qui devraient guider chacun d'eux.

Ils présentent également des modes de défaillance différents. Une défaillance de sandbox signifie que l'agent a fait quelque chose qu'il n'aurait pas dû pouvoir faire. Une défaillance de harnais signifie que l'agent a mal accompli une tâche qu'il aurait dû bien faire. Ce sont des problèmes différents qui nécessitent des réponses différentes.

La sandbox peut jouer un rôle secondaire d'enregistreur (un observateur neutre des activités de l'agent) capable d'attester de ce qu'il a fait d'une manière plus digne de confiance que l'auto-attestation de l'environnement d'exécution de l'agent.

La sandbox restreint et observe. Le harnais fournit les capacités nécessaires et vous pouvez l'améliorer. L'environnement d'exécution exécute les tâches et vous ne devriez pas construire le vôtre, sauf en cas de nécessité. Les agents ne sont sûrs et fiables que si la pile qui les soutient l'est aussi, et Red Hat construit cette pile en open source, à tous les niveaux, de la planification des GPU à la signature cryptographique des modèles. Si vous déployez des agents en production et que vous souhaitez une base que vous pouvez vérifier, et non seulement espérer, c'est vers cela que nous nous dirigeons.