Les runtimes d’agent d’OpenClaw

Quatre étiquettes se côtoient dans la sortie de statut et la configuration d’OpenClaw, et elles désignent quatre choses différentes. Un fournisseur décrit comment OpenClaw s’authentifie, découvre les modèles et nomme les références de modèles. Un modèle est celui qui est sélectionné pour le tour d’agent. Un runtime d’agent est la boucle ou le moteur bas niveau qui exécute le tour préparé, et un canal est simplement l’endroit par où les messages entrent et sortent. Les runtimes sont la couche que l’on lit le plus souvent de travers, car ils apparaissent près de la configuration des modèles et portent des noms qui recoupent ceux des fournisseurs.

Deux familles de runtimes

• Les harnais embarqués tournent à l’intérieur de la boucle d’agent préparée et comprennent le runtime OpenClaw intégré ainsi que les harnais d’extension enregistrés comme les runtimes Codex et Copilot.
• Les moteurs en ligne de commande lancent un processus local tout en gardant la référence de modèle canonique, donc un modèle Anthropic portant un runtime Claude CLI limité au modèle signifie choisir le modèle Anthropic et l’exécuter via Claude CLI.
• Un harnais est l’implémentation qui fournit un runtime d’agent, ce qui explique que le harnais Codex fourni implémente le runtime Codex, et que l’identifiant Claude CLI n’est pas un identifiant de harnais embarqué et ne doit pas être passé à la sélection de harnais.
• La configuration publique place l’identifiant de runtime sur les entrées de fournisseur ou de modèle, les clés de runtime valables pour tout un agent sont héritées et ignorées, et la commande de réparation doctor retire ces anciens épinglages et réécrit les références de modèle héritées en références canoniques de fournisseur et de modèle, avec une politique de runtime limitée au modèle là où il le faut.

Les runtimes sont faciles à confondre avec les fournisseurs car les deux apparaissent près de la configuration des modèles.

Comment un runtime est choisi

OpenClaw ne résout un runtime embarqué qu’après la résolution du fournisseur et du modèle, et l’ordre est fixe. La politique de runtime limitée au modèle l’emporte d’abord, qu’elle vive dans une entrée de modèle de fournisseur configurée ou dans le réglage de runtime par modèle des valeurs par défaut des agents ou d’un agent précis. Un joker de fournisseur s’applique après la politique de modèle exacte, donc des modèles de fournisseur découverts dynamiquement peuvent partager un runtime sans écraser les exceptions exactes par modèle. La politique de runtime limitée au fournisseur vient ensuite. En mode automatique, les runtimes d’extension enregistrés peuvent revendiquer les paires fournisseur et modèle prises en charge, et si rien ne revendique le tour, OpenClaw retombe sur son propre runtime comme runtime de compatibilité, ce qui explique qu’un identifiant de runtime explicite soit le bon choix quand une exécution doit être stricte. Les runtimes d’extension explicites échouent de façon fermée quand le harnais manque ou ne peut pas gérer la route ou l’authentification, avec une exception au moment de la sélection : un harnais peut déclarer qu’OpenClaw sait reproduire la requête exacte, et Codex utilise ce repli pour les surcharges de requête rédigées comme les en-têtes, les paramètres de requête, les délais ou les commutateurs de compatibilité de charge utile, qu’il préserve au lieu de les abandonner en silence. Une fois qu’un harnais commence à s’exécuter, ses échecs ne sont pas rejoués dans un autre runtime. Les enregistrements historiques de harnais disent quel runtime a produit une transcription mais n’épinglent pas le tour suivant, et le runtime Copilot sur inscription n’est jamais choisi automatiquement.

Qui possède quoi

• Avec le runtime OpenClaw embarqué, OpenClaw possède la boucle de modèle, la transcription canonique, la boucle d’outils native, l’assemblage du contexte et la livraison sur le canal.
• Avec le runtime Codex app-server, Codex possède la boucle de modèle et le fil canonique tandis qu’OpenClaw garde un miroir de transcription, relaie ses outils dynamiques par l’adaptateur Codex et projette le contexte assemblé dans le tour Codex.
• Le compactage suit la même division, puisque OpenClaw ou le moteur de contexte choisi s’en charge dans le cas embarqué alors que le compactage natif de Codex opère dans l’autre, avec des notifications OpenClaw et l’entretien du miroir autour.

La règle de conception derrière ce tableau est courte. Si OpenClaw possède la surface, il peut offrir le comportement normal des points d’ancrage d’extension, si le runtime natif la possède, OpenClaw a besoin d’événements de runtime ou de points d’ancrage natifs, et si le runtime natif possède l’état canonique du fil, OpenClaw reflète et projette le contexte au lieu de réécrire des internes qu’il ne contrôle pas. Voir les fournisseurs et les références de modèles pour la façon dont les références de modèles sont nommées, et la boucle d’agent et l’exécution des tours pour la façon dont un tour préparé est mené.

Pourquoi les étiquettes restent séparées

Séparer les couches n’est pas du pédantisme, c’est ce qui rend une conversation de support possible. Une référence de modèle désigne le fournisseur et le modèle choisis, un identifiant de runtime nomme la boucle qui exécute le tour, et une étiquette de canal dit où se tient la conversation, si bien que devant un runtime inattendu la première chose à inspecter est la politique de runtime du fournisseur et du modèle choisis. La page est tout aussi prudente sur ce que signifie une discussion verrouillée sur un modèle concret : le verrou empêche les changements de modèle, il ne cède ni la propriété du modèle ni celle de l’authentification à un runtime natif, et les réglages de requête rédigés restent partie prenante de la requête concrète. Une session native liée est l’autre cas, qui garde son modèle natif et, séparément, l’authentification de sa connexion native, vérifiée contre le harnais épinglé exact et sa liaison privée plutôt que contre un rapport d’usage antérieur. Les métadonnées de runtime du tour suivant peuvent inclure un repli déclaré quand le harnais enregistré sait le déduire de la route configurée, mais elles ne sondent pas les identifiants et ne démarrent pas de runtime, et le résultat terminé enregistre le runtime qui a réellement tourné. Quand un runtime n’est pas OpenClaw, sa propre documentation doit indiquer quelles surfaces il prend en charge, y compris les données de compactage exposées et le fait que le cycle de vie du moteur de contexte s’exécute ou non, et les guides sur le compactage du contexte et le cycle de vie du moteur de contexte complètent le reste pour que personne ne suppose une équivalence jamais promise.

Sur Diali

Sur Diali, la configuration du runtime est générée depuis le tableau de bord et remplacée à chaque version, si bien que les choix de fournisseur, de modèle et de runtime derrière un assistant restent au même endroit. Chaque client fait tourner son propre assistant, avec un état sur un volume persistant ; des instantanés quotidiens et une restauration en un clic sont disponibles grâce à l’option Sauvegardes (incluse avec Max). Voir OpenClaw hébergé sur Diali pour ce que nous hébergeons, et La sécurité Diali pour la façon dont nous traitons cet état.

• Fournisseur, modèle, runtime d’agent et canal sont quatre couches distinctes.
• La politique par modèle l’emporte, puis celle du fournisseur, puis le mode auto.
• Un verrou de modèle empêche les changements, pas la propriété de l’authentification.