Aller au contenu

Les quatre couches d'un système d'agent sont loop, graph, harness et meta-harness. Lorsqu'un agent consomme des jetons, déclare la tâche terminée, puis échoue aux tests, il s'agit généralement d'un problème d'architecture, et non d'un problème de prompting. Le loop vérifie le travail par rapport à des preuves externes. Le graph décide où l'exécution doit aller ensuite. Le harness est l'environnement opérationnel du modèle — outils, permissions, mémoire, contexte, journalisation. Le meta-harness gouverne de nombreux harnesses afin que le contexte et la politique puissent circuler entre les agents. Mercury Core est construit comme le harness et le meta-harness. Cette boucle n'est pas Mercury Loop, le service géré.

Architecture d'agent, boucles de vérification, graphes de flux de travail, harnesses d'agents, gouvernance meta-harness, systèmes d'exploitation homme-agent, limites de l'ingénierie de prompt, Mercury Core, Booster Packs, mémoire OpenClaw

Mercury Technology Solutions, Mercury Core, Mercury Flux, Mercury Loop, OpenClaw, Booster Pack, Unified Bus, infrastructure Agent-native

[ SYS: MERCURY_CORE // NOTES DE TERRAIN ]

Notes de terrain sur les systèmes agentiques

Les Quatre Couches d'un
Système d'Agent

Un agent consomme des jetons, déclare la tâche terminée, puis échoue aux tests. C'est généralement un problème d'architecture, pas de prompting. Voici la pile — et comment trouver quelle couche a échoué.

Quatre couches d'exécution. Construire de la boucle vers le haut.

En bref

Quelles sont les quatre couches d'un système d'agents

  • Les agents AI échouent généralement en raison de l'architecture, et non du prompt : un meilleur prompt ne peut pas créer d'outil, de passerelle, de route ou de politique manquante.
  • Les quatre couches d'exécution sont : loop (vérifier le travail), graph (acheminer le travail), harness (exposer la capacité) et meta-harness (gouverner de nombreux harnesses).
  • Une loop fiable s'arrête sur des preuves externes — un test réussi, une build verte, une sortie validée — jamais sur l'auto-évaluation du modèle.
  • Mercury Core est le système d'exploitation construit comme le harness et le meta-harness : une mémoire, une interface, une couche de politique.
  • La loop sur cette page est un pattern d'exécution. Mercury Loop est un produit différent : un service géré qui empêche le système d'exploitation de dériver.
La pile

Les quatre couches en un coup d'œil

Les quatre couches d'un système d'agent — le travail, l'échec et la correction avant de réécrire le prompt.
CoucheTâcheÉchecCorrection d'abord
LoopVérifier le travail jusqu'à ce que les preuves indiquent de s'arrêterL'agent « complète » sans test, build ou passerelle de validationAjouter une condition d'arrêt mesurable
GraphDécider où l'exécution doit aller ensuiteMauvais chemin, pas de repli, transferts improvisésRendre explicites les branches, les tentatives et les spécialistes
HarnessExposer les outils, la mémoire, les permissions, le contexte, le journalisationLe modèle comprend la tâche mais ne peut pas accéder à ce dont il a besoinExposer la capacité manquante — un Booster Pack sur Mercury Core
Meta-harnessGouverner de nombreux harnesses ; déplacer le contexte sous une seule politiqueClaude Code, Codex et agents internes comme des silos non coordonnésPolitique partagée, isolation et contexte portable — le substrat Core
Couche 01 — Loop

Qu'est-ce qu'une boucle d'agent ?

Une boucle d'agent est la plus petite unité d'agence : agir, vérifier le résultat, puis s'arrêter ou réessayer.

Un agent fiable ne s'arrête jamais car le modèle croit que le travail est correct. Il s'arrête sur des preuves externes — un test réussi, une construction verte, une sortie validée.

Act → check → (fix) → done

Observez l'agent tenter la tâche deux fois. Le premier passage semble terminé — la vérification est en désaccord. Seul le second passage franchit la porte.

Agir
Vérifier
Réessayer
Terminé

Boucle inactive. Exécutez-la pour observer une vérification échouée, puis une porte franchie.

La règle

Condition d'arrêt

Arrêt sur des conditions mesurables : tests réussis, build réussi, sortie validée — jamais sur l'auto-évaluation du modèle.

Mode d'échec

Sans vérification, un agent déclare avec confiance le succès alors que la tâche est encore incomplète.

Couche 02 — Graph

Qu'est-ce qu'un agent graph ?

Un agent graph décide où l'exécution doit aller ensuite : branches, réessais, transferts spécialisés, chemins de repli et état partagé.

Une boucle décide si l'exécution continue. Un graph décide où elle va. Lorsqu'un flux de travail comporte plusieurs chemins, le graph les rend explicites, inspectables et contrôlables.

Nouvelle tâche
Chemin standard
Agent spécialiste
Réessayer / repli
Dégrader
Livré
Route par classe de tâche
Transfert
Après N échecs

Graph inactif. Dérouter une tâche pour observer un chemin standard qui bascule vers un spécialiste.

Couche 03 — Harness

Qu'est-ce qu'un agent harness ?

Un agent harness est l'environnement d'exploitation du modèle — outils, APIs, fichiers, mémoire, permissions, contexte et journalisation (logging).

Le modèle fournit le raisonnement ; le harness détermine ce que ce raisonnement peut réellement faire. La capacité du modèle et la capacité de l'agent ne sont pas la même chose.

Tools
Ce que l'agent peut toucher et invoquer
Permissions
Ce qu'il est autorisé à faire
Memory
Ce qu'il se souvient entre les exécutions
Context
Ce qu'il peut voir en ce moment
Logging
Ce que vous pouvez auditer après
Missing tool
Aucun prompt ne corrige cela. L'agent s'arrête ici.
Le test du harness

Le modèle peut comprendre exactement comment résoudre une tâche. Mais si l'outil, la source de données ou la permission requis n'est pas exposé via le harness, l'agent ne peut toujours pas la compléter.

Cinq capacités rendent le modèle opérationnel. Un seul manque fait échouer tout le processus — peu importe la qualité du prompt.

Couche 04 — Meta-harness

Qu'est-ce qu'un meta-harness ?

Un meta-harness est la couche commune au-dessus de multiples agent harnesses : orchestration, gouvernance, isolation, politique partagée et contexte portable.

Les équipes réelles font fonctionner Claude Code, Codex, des agents internes et des spécialistes de domaine côte à côte — chacun avec ses propres outils, sessions, politiques et environnement d'exécution. Sans meta-harness, les humains deviennent la couche de copier-coller entre des jardins clos.

Meta-harness · portabilité de politique / gouvernance / contexte partagée
Agent A
Code harness
Agent B
Research harness
Agent C
Spécialiste de domaine

Le point mobile est le contexte : un résultat validé ou un état partagé traversant d'un harness à un autre sous une couche de politique unique — au lieu d'être copié-collé entre des jardins clos.

Le diagnostic en une ligne

Un meilleur prompt ne peut pas compenser pour un manque de capacité.

— heuristique de triage, architecture d'agent

Mais le prompt reste une partie de la solution

L'heuristique concerne l'ordre, pas le rejet. L'ingénierie de prompt est réelle et précieuse — elle façonne la manière dont le modèle utilise ce que le harness expose. Il ne peut simplement pas créer ce que le harness n'a jamais exposé.

La bonne séquence : corriger la couche en premier (ajouter l'outil, la passerelle, le chemin, la politique), puis ajuster le prompt pour utiliser cette capacité efficacement. Prompting sur une pile défectueuse, c'est du vernis sur des fondations fissurées.

Utilisation sur le terrain

Quatre questions avant de réécrire le prompt

01

Échec de la boucle

L'agent « complète » sans preuve
Y a-t-il un test, une construction ou une validation qui contrôle réellement l'achèvement ?
02

Échec du graphe

Mauvais chemin, pas de repli, impasse
Les branches, les nouvelles tentatives et les transferts sont-ils explicites — ou improvisés à chaque exécution ?
03

Échec du boîtier (Harness)

L'agent manque d'outil, de données ou de permission
L'environnement expose-t-il ce que la tâche nécessite réellement ?
04

Échec du méta-boîtier (Meta-harness)

Les agents ne peuvent pas partager de politique ou de contexte
Y a-t-il une gouvernance sur l'ensemble de votre flotte d'agents, ou N silos non coordonnés ?
Pourquoi cela se situe sous Mercury Core

Le diagnostic. Puis le substrat.

Ces quatre couches d'exécution expliquent pourquoi un meilleur prompt échoue toujours lorsque le boîtier est manquant. Mercury Core est le système d'exploitation construit comme ce boîtier et le méta-boîtier au-dessus — une mémoire, une interface, une couche de politique.

Les cinq couches de mémoire sur Core sont la manière dont le système d'exploitation stocke la vérité. OpenClaw est ce tissu.Les quatre couches de cette page montrent comment le travail est autorisé à s'exécuter.

A Booster Pack est la manière dont Core expose un outil, une vue et un schéma de mémoire ensemble — le harnais, en place.

La boucle de cette page est la passerelle d'exécution : agir, vérifier, arrêter sur des preuves. Mercury Loop le produit est une autre chose : un service géré qui empêche le système d'exploitation de dériver de l'activité commerciale.

Lorsque la passerelle est un passage de modèle, Mercury Flux route le modèle capable le moins cher et s'arrête sur des tests avant que quoi que ce soit ne soit déployé.

Étape suivante

Installez les couches. Ne peaufinez pas le prompt.

Si l'échec est dû à l'absence d'outils, de mémoire partagée ou de politique de flotte, la page suivante est le système d'exploitation — pas un autre paquet de prompts.

FAQ

FAQ sur l'architecture des agents

Quelles sont les quatre couches d'un système d'agent ?

Loop, graph, harness et meta-harness. La boucle vérifie le travail par rapport à des preuves externes. Le graphe décide où l'exécution doit aller ensuite. Le harnais est l'environnement d'exploitation du modèle — outils, permissions, mémoire, contexte, journalisation. Le meta-harnais gouverne de nombreux harnais afin que le contexte et la politique puissent passer entre les agents au lieu d'être copiés-collés.

Pourquoi les agents IA échouent-ils même avec un bon prompt ?

Parce que le prompt ne peut pas créer ce que le harnais n'a jamais exposé. Si la condition d'arrêt, le chemin, l'outil ou la politique partagée est manquant, le modèle peut toujours raisonner correctement et l'exécution échoue toujours. Diagnostiquez la couche en premier, puis ajustez le prompt.

Un agent loop est-il la même chose que Mercury Loop ?

Non. Un agent loop est un pattern d'exécution : agir, vérifier, s'arrêter sur preuve. Mercury Loop est un service géré qui déploie des agents Entry, Analyst et Implementer pour trouver et corriger la dérive de l'infrastructure. Même mot, produit différent.

Quel est le lien avec Mercury Core et OpenClaw ?

OpenClaw est la mémoire hiérarchique à cinq couches de Mercury Core — la manière dont le système d'exploitation stocke la vérité. Ces quatre couches d'exécution sont la manière dont le travail est autorisé à s'exécuter. Core est construit comme le harness et le meta-harness : les humains et les agents partagent la mémoire, l'interface et la politique. Un Booster Pack intègre un outil, un tableau de bord et un schéma de mémoire dans ce harness.

Pourquoi un meilleur prompt ne peut-il pas corriger un outil manquant ?

Le prompting façonne la manière dont le modèle utilise ce que le harness expose. Il ne peut pas créer un outil, une permission, une source de données ou une politique que l'environnement n'a jamais offerts. Corrigez la couche en premier, puis ajustez le prompt.

Qu'est-ce qu'un meta-harness ?

La couche commune au-dessus de multiples environnements d'agents. Les équipes exécutent déjà côte à côte Claude Code, Codex, des agents internes et des spécialistes. Sans meta-harness, chacun est un jardin clos. Avec un, ils partagent la politique, l'isolation et le contexte portable. C'est la thèse de Mercury Core : arrêter d'utiliser les humains comme couche d'intégration.

Comment diagnostiquer quelle couche d'agent a échoué ?

Posez-vous quatre questions avant de réécrire le prompt. Loop : y a-t-il un test qui conditionne l'achèvement ? Graph : les branches et les transferts sont-ils explicites ? Harness : l'environnement expose-t-il l'outil, la donnée ou la permission dont la tâche a besoin ? Meta-harness : les agents peuvent-ils partager la politique et le contexte, ou sont-ils N silos non coordonnés ?
Définitions

Termes d'architecture d'agent utilisés sur cette page

Agent loop
Agir, vérifier, arrêter sur des preuves externes. Pas Mercury Loop, le service géré.
Agent graph
Routes explicites, nouvelles tentatives, transferts spécialisés, mécanismes de repli et état partagé.
Agent harness
L'environnement d'exploitation du modèle : outils, permissions, mémoire, contexte, journalisation.
Meta-harness
Gouvernance sur de nombreux harnesses — politique partagée et contexte portable. Le rôle de Mercury Core.

Published 2 September 2026. Concept distilled from public discussion on agent architecture (Rishi, @RishiUvaach). Frame and implementation: Mercury Technology Solutions.