La boucle d’agent d’OpenClaw
D’un identifiant d’exécution accepté à une réponse finale, la réclamation d’écrivain, les hooks, les flux, et les délais
Chaque réponse produite par un agent OpenClaw sort de la même boucle : l’exécution sérialisée, par session, qui transforme un message en actions et en réponse par l’admission, l’assemblage du contexte, l’inférence du modèle, l’exécution des outils, le streaming et la persistance. La documentation la parcourt étape par étape. Voici la séquence d’un identifiant d’exécution accepté à un événement terminal, la barrière qui empêche une exécution remplacée d’écrire des données de transcription périmées, les hooks qu’une extension peut attacher, ce qui s’écoule où, les délais, et les diagnostics qui classent une exécution qui paraît bloquée.
La séquence d’exécution
- L’appel RPC d’agent valide ses paramètres, résout la session, conserve les métadonnées de session et renvoie immédiatement un identifiant d’exécution ; la commande d’agent de la CLI est l’autre point d’entrée.
- La couche de commande résout le modèle et les valeurs par défaut de réflexion, de verbosité et de trace, charge l’instantané des compétences, lance l’agent embarqué, et émet une fin ou une erreur de cycle de vie de repli si la boucle ne l’a pas fait.
- L’exécution embarquée se sérialise par les voies de session et globale, résout le modèle et le profil d’authentification, construit la session, s’abonne aux événements d’exécution, diffuse les deltas d’assistant et d’outils, impose le délai d’exécution et renvoie les charges avec des métadonnées d’usage ; les événements d’outils vont vers un flux d’outils, les deltas d’assistant vers un flux d’assistant, et les événements de cycle de vie vers un flux de cycle de vie avec des phases de démarrage, de finition, de fin et d’erreur.
- L’appel RPC d’attente attend une fin ou une erreur de cycle de vie sur un identifiant d’exécution et renvoie ok, erreur ou délai avec les heures de début et de fin, plus la réponse terminale et, quand il est disponible, un reçu confirmant que la réponse finale a atteint la conversation d’origine.
La boucle d’agent est l’exécution sérialisée, par session, qui transforme un message en actions et en réponse : admission, assemblage du contexte, inférence du modèle, exécution des outils, streaming, persistance.
La réclamation d’écrivain et la préparation
Les exécutions sont sérialisées par clé de session et éventuellement par une voie globale. Avant le streaming, une exécution admise enregistre sa réclamation durable d’écrivain actif ; chaque ajout ou réécriture de transcription fournit l’identifiant d’écrivain attendu, et la transaction de validation synchrone vérifie qu’il correspond toujours, si bien qu’une exécution remplacée ne peut pas valider des données de transcription périmées ; la file d’écriture SQLite ordonne les mutations par agent et un verrou de répertoire d’état empêche une seconde passerelle ou un processus d’agent local de posséder le même répertoire. La préparation résout et crée l’espace de travail, en redirigeant les exécutions en bac à sable vers une racine de bac à sable, charge les compétences ou réutilise un instantané, résout les fichiers d’amorçage dans le prompt système, et prépare la cible de transcription et la réclamation d’écrivain avant le début du streaming. Le prompt système est construit à partir du prompt de base, du prompt des compétences, du contexte d’amorçage et des surcharges par exécution, avec les limites du modèle et les jetons de réserve de compaction imposés.
Hooks, flux, mise en forme de la réponse
- Deux systèmes de hooks : des scripts de hooks internes pour les événements de commandes et de cycle de vie, l’amorçage plus les commandes de nouvelle session, de réinitialisation et d’arrêt, et des hooks d’extensions typés dans la boucle, avant la résolution du modèle, avant la construction du prompt, avant la réponse de l’agent, à la fin de l’agent, autour de la compaction, autour des appels d’outils, avant l’installation, à la persistance des résultats d’outils, à la réception, à l’envoi et après l’envoi d’un message, au début et à la fin de session, au démarrage et à l’arrêt de la passerelle. Une décision de blocage ou d’annulation est terminale et arrête les gestionnaires de priorité inférieure, tandis qu’un faux est sans effet et n’efface pas un blocage antérieur.
- Les deltas d’assistant s’écoulent comme événements d’assistant, le streaming par blocs peut émettre des réponses partielles à la fin d’un texte ou d’un message, le raisonnement peut être son propre flux, les événements de début, de mise à jour et de fin d’outils sont émis sur le flux d’outils avec des résultats assainis en taille et en images, et les envois d’outils de messagerie sont suivis pour supprimer les confirmations en double ; la passerelle projette les événements de cycle de vie et d’outils dans un registre d’audit limité aux métadonnées.
- Les charges finales assemblent le texte de l’assistant, le raisonnement facultatif, les résumés d’outils en ligne quand la verbosité le permet, et le texte d’erreur quand le modèle échoue ; le jeton silencieux exact est filtré, les doublons de messagerie retirés, un avertissement d’erreur d’outil de repli n’apparaît que quand une exécution se termine sur un échec d’outil sans réponse, et un tour à réponse obligatoire qui se termine après un lot d’outils réglé sans réponse peut obtenir une passe de finalisation sans outils qui ne répète jamais les outils terminés.
La file de commandes d’OpenClaw est le système de voies par lequel cette boucle se sérialise, et Hooks et webhooks dans OpenClaw le côté automatisation de l’histoire des hooks.
Délais et exécutions bloquées
L’appel d’attente expire après trente secondes sans arrêter l’exécution ; le budget de l’environnement d’agent est de quarante-huit heures d’exécution écoulée, zéro pour illimité, les attentes d’approbation mettant en pause le budget inutilisé ; le chien de garde sans sortie de la CLI appartient à l’extension de backend ; cron possède son propre minuteur ; une requête de modèle est interrompue quand aucun morceau n’arrive pendant deux minutes chez les fournisseurs cloud ou cinq chez les auto-hébergés, extensible par fournisseur ; et le délai HTTP du fournisseur couvre la connexion, les en-têtes et le corps. Un délai terminal est un tour échoué, enregistré immédiatement pour la barre latérale. Avec les diagnostics activés, un seuil de deux minutes classe une longue session en traitement comme longue quand la progression est récente, bloquée quand elle ne l’est pas, et coincée pour une comptabilité périmée, avec un seuil d’interruption d’au moins cinq minutes et trois fois l’avertissement ; une tentative Codex en attente de travail natif est l’exception et n’est jamais interrompue seulement parce qu’elle est silencieuse. Une exécution peut finir tôt sur le délai de l’agent, un signal d’interruption, une déconnexion de la passerelle, ou le délai d’attente seule. Fenêtre de contexte et compaction dans OpenClaw explique la relance que la boucle déclenche quand le contexte déborde, et Streaming et découpage dans OpenClaw comment les deltas atteignent un canal.
Sur Diali
Sur Diali, c’est la boucle que votre assistant fait tourner dans son instance, avec le budget de quarante-huit heures et les chiens de garde d’inactivité à leurs valeurs amont par défaut, et le chat du tableau de bord montre le cycle de vie à mesure qu’il s’écoule. OpenClaw hébergé sur Diali est l’assistant et La passerelle OpenClaw expliquée le processus qui fait tourner la boucle.
- Un identifiant d’exécution d’abord, une fin de cycle de vie en dernier.
- Un écrivain par session, vérifié à chaque validation.
- Quarante-huit heures de budget ; deux ou cinq minutes de silence.
Arrêtez de lire, construisez le vôtre
Configurez un agent, choisissez un canal, et faites-le travailler dans l’application que vous gardez déjà ouverte.
