2026-05-26 · Mis à jour 2026-07-22

[!NOTE] Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.

Agents AI à exécution prolongée Runtime en 2026 : sessions, Sandboxes, Checkpoints, et plateformes d’orchestration

Partie 5 de la série « Ingénierie de la pile Agentic »

Les quatre articles précédents ont abordé la conception interne de l’agent : boucles de raisonnement, mémoire, tool use, et sécurité. Cet article traite du runtime qui permet à ces composants de rester opérationnels malgré la durée prolongée des sessions ainsi que les pannes de processus.

Une exécution d’agent peut durer des heures, tandis que son processus travailleur peut être redémarré à tout moment. Le modèle choisit toujours l’action suivante, mais le runtime doit conserver l’état, gérer l’exécution et se remettre d’une panne au cours d’un tool call. Cet article définit les limites du runtime. La partie 6 examinera ensuite le harness qui s’y trouve : la logique de retour d’information, de tentative répétée, de transfert et d’acceptation qui détermine si l’agent continue de fonctionner ou s’arrête.

Qu’est-ce qu’un agent AI runtime ?

Un AI agent runtime constitue la couche d’infrastructure qui permet à un agent utilisant des outils de rester actif, isolé, observable et capable de reprendre son exécution une fois l’appel au modèle terminé. Il gère l’état de la session, l’exécution des outils, checkpoints, les vérifications de politique, les secrets, les traces, les limites de coût ainsi que la structure de déploiement. Le modèle choisit l’action suivante ; le runtime détermine où cette action sera exécutée, si elle est autorisée, comment elle sera enregistrée, et comment la séquence d’exécution pourra reprendre en cas d’échec.

Utilisez le runtime comme unité de conception pour les agents à exécution prolongée. Si vous ne parvenez pas à indiquer l’emplacement de chaque primitive, l’agent reste un prototype.

Les exécutions prolongées remettent en cause les hypothèses relatives aux processus sans état

Un endpoint de chat sans état peut conserver l’état de la requête au sein d’un seul processus avant de le supprimer une fois la réponse générée. En revanche, une exécution prolongée d’un agent implique des redémarrages de travailleurs, des déploiements, des réinitialisations de contexte ainsi que des pauses liées à l’approbation. Dans de telles conditions, le processus de travailleur ne peut plus constituer la source unique de vérité.

L’équipe OpenAI Codex indique la longueur de séquence dans son harness engineering rapport de synthèse:

« Nous constatons régulièrement que des exécutions isolées de Codex sur une seule tâche peuvent durer plus de six heures (souvent pendant que les humains dorment). »

L’équipe d’ingénierie d’Anthropic décrit le problème de l’état correspondant dans Des mécanismes efficaces pour les agents à exécution prolongée:

Le défi principal des agents à exécution prolongée réside dans le fait qu’ils doivent fonctionner au sein de sessions discrètes, chaque nouvelle session commençant sans aucun souvenir de ce qui s’est produit précédemment.

Ces deux observations indiquent la même conception runtime : conserver l’état en dehors du worker et rendre ces derniers remplaçables.

La session doit exister en dehors du processus travailleur. Un stockage durable enregistre les appels au modèle, tool results, ainsi que les approbations, afin qu’un autre processus travailleur puisse reprendre à l’endroit le plus sûr après une panne. Checkpoints permet également aux runtime de démarrer une nouvelle session de modèle lorsque la fenêtre de contexte est pleine, sans avoir à rejouer toute l’historique. Dans La formulation d’Anthropic, Les harness deviennent éphémères et réinitialisables ; l’état durable est stocké ailleurs.

Le modèle décide de la prochaine action à entreprendre. Le runtime détermine si le mouvement est autorisé, où il s’exécute, comment il est enregistré, ainsi que la manière dont l’exécution reprend après une panne. Le reste de cet article porte sur ce runtime.

Les cinq primitives runtime dont tout agent AI à exécution prolongée a besoin

Anthropic’s Échelle des agents gérés Ce document présente un vocabulaire utile pour les cinq responsabilités associées à runtime. Le harness fait avancer l’agent, tandis que les enregistrements de session consignent ses actions et que le sandbox exécute les commandes. Le checkpoint fournit au travailleur suivant un point de reprise ; quant aux traces, elles permettent de conserver des preuves utiles pour le débogage ultérieur. Une implémentation peut fusionner ces composants, mais les responsabilités ainsi que les limites de défaillance doivent néanmoins disposer de noms bien définis.

Session. Un journal d’écriture seule qui enregistre tout ce qui s’est produit : les appels au modèle, tool calls, les résultats, les erreurs, les approbations. La récupération est wake(sessionId) → getSession(id) → resume from last event. Dans LangGraph, il s’agit d’un thread_id plus un pointeur de vérification de Postgres (voir Persistance de LangGraph). L’OpenAI Agents SDK intègre dix backends de session prédéfinis, y compris SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession, et EncryptedSession (voir le Documentation des sessions).

Harness. La boucle d’orchestration. Elle appelle le modèle, analyse tool calls, les exécute, écrit les résultats en retour dans la session, et applique les règles de tentative répétée. Anthropic l’exprime sans détour :

« Chaque composant au sein d’un harness encode une hypothèse concernant ce que le modèle ne peut pas faire seul. »

L’équipe Codex d’OpenAI qualifie cette discipline de harness engineering : l’écriture de logiciels exige toujours de la rigueur, mais une part bien plus importante de celle-ci est désormais consacrée aux infrastructures de soutien plutôt qu’au code lui-même. LangGraph’s CompiledStateGraph, des agents profonds create_deep_agent, Claude Code lui-même constitue également un outil de ce type.

Sandbox. L’environnement d’exécution isolé dans lequel les commandes sont réellement exécutées. Les SDK d’OpenAI sandbox concepts page trace la frontière de manière nette :

« L’ runtime externe conserve toujours la gestion des approbations, du traçage, des transferts ainsi que de la comptabilité des reprises. La session sandbox gère les commandes, les modifications de fichiers et l’isolation de l’environnement. »

Sandboxes diffèrent selon la durée de leur existence et les informations qu’ils conservent entre plusieurs exécutions. La forme la plus simple est celle des objets éphémères frais : on en crée un uniquement pour une tâche donnée, on le détruit à la fin de cette tâche, et il faut supporter les coûts liés au démarrage à froid à chaque exécution.

L’arrêt persistant sandboxes permet de conserver le système de fichiers ainsi qu’une capture mémoire entre les exécutions. La reprise suivante peut ainsi éviter un démarrage complet. Les approches de capture ou de forking créent une image de type copy-on-write à partir d’un parent préparé, ce qui permet à de nombreuses tâches de partager des dépendances installées et des caches prêts à l’emploi, sans pour autant partager leur état écrivable.

Per-worktree sandboxes permet à chaque tâche d disposer de son propre espace de travail ainsi que de sa propre pile d’outils d’observabilité. En séparant les journaux, les métriques et les traces, il devient possible de déboguer une exécution sans que l’état de celle-ci ne se propage à une autre. Le tableau des fournisseurs présenté plus loin dans cet article compare le comportement en mode démarrage froid et celui en mode persistance.

Checkpoint. État reprendable. Celui de LangGraph PostgresSaver écrit un StateSnapshot à chaque frontière de super-étape, grâce à des écritures par tâche checkpoint_writes Ainsi, les sorties des nœuds qui fonctionnent correctement ne sont pas recalculées en cas de défaillance d’un nœud frère. Le snapshot est un dictionnaire JSON-serialisable.v, ts, id, channel_values, channel_versions, versions_seen, pending_sends) documenté dans le langgraph-checkpoint-postgres page PyPI et le LangGraph checkpoints de référence.

Jus de traçage. C’est l’interface permettant de rejouer les événements et de déboguer. Chaque appel de modèle, tool call, ainsi que chaque étape d’un sous-agent deviennent une entité représentant des données temporelles, des entrées, des sorties, des comptages de tokens et des coûts associés. Lorsqu’une exécution d’une durée de six heures échoue, c’est ce jus de traçage que l’on consulte pour identifier la cause du problème. À ce stade, les sorties de terminal générées lors de l’exécution ont déjà disparu depuis longtemps. OpenTelemetry’s Conventions sémantiques des GAN standardiser les noms des attributs (quel modèle, quel fournisseur, combien de tokens, quelle conversation, quel flux de travail), afin que la même trace s’affiche de manière propre dans Tempo, Jaeger, Honeycomb, ou LangSmith sans avoir à réinstrumenter le système.

La politique et les secrets constituent des domaines distincts runtime

Deux frontières traversent l’ensemble des cinq primitives et il est plus simple de les considérer comme des préoccupations distinctes. Il s’agit de la version runtime de l’argument de sécurité issu de Partie 4.

Moteur de politique

Une vérification des permissions est effectuée avant chaque tool call afin de déterminer s’il peut être exécuté. Deux schémas sont couramment utilisés en environnement de production. Deep Agents permet à chaque sous-agent de déclarer quels chemins de fichiers il peut lire ou écrire, et le middleware bloque tout ce qui dépasse ces déclarations. Anthropic Managed Agents fait passer chaque tool call par un proxy MCP, ce qui permet au proxy d’appliquer les permissions au lieu du code de l’agent. Lorsqu’une requête sensible nécessite l’approbation humaine, LangGraph’s interrupt() Et le mécanisme d’approbation des agents profonds suspend le graphe jusqu’à ce qu’une personne donne son accord.

Intermédiaire secret

Le modèle ne doit pas avoir accès à des secrets à long terme, et le sandbox ne devrait généralement pas non plus en disposer. Le pattern des Agents gérés est celui qu’il convient d’adopter :

« Pour Git, nous utilisons le token d’accès de chaque répertoire afin de cloner ce dernier lors de l’initialisation sandbox et de le connecter au remote git local. Git » push et pull Il est possible d’opérer à l’intérieur du sandbox sans que l’agent n’ait jamais à gérer le jeton lui-même. Pour les outils personnalisés, nous prenons en charge MCP et stockons les jetons OAuth dans un coffre-fort sécurisé. Claude appelle les outils MCP via un proxy dédié ; ce proxy reçoit un jeton associé à la session. … Le harness n’est jamais informé de l’existence de quelque identifiant ou mot de passe que ce soit.

Dans le market-analyst-agent pile de référence : le sidecar MCP lit les tokens OAuth à partir d’un secret Docker (en environnement de production, HashiCorp Vault) Et il n’expose que l’interface de l’outil au processus LangGraph. Ce dernier ne voit jamais le token. git push cat ~/.ssh/id_rsa Ce n’est pas le cas.

Une vérification de fiabilité pratique consiste à énumérer chaque composant ainsi que la primitive parmi les cinq qu’il implémente. Postgres Il peut couvrir la session ainsi que checkpoint. Le conteneur d’agent est le harness. Un service tel que Daytona, modalité, ou E2B fournit le sandbox, tandis que Tempo ou LangSmith stocke la trace.

Examinons maintenant les défaillances couplées. Lorsque deux primitives évoluent au sein du même processus, une panne entraîne l’arrêt des deux. S’ils partagent des identifiants d’autorisation, une fuite de données peut franchir les limites propres à chacun d’eux. Des exemples courants sont un travailleur qui gère également la durabilité des traces, ou un token sidecar qui permet également d’accéder à la base de données checkpoint.

Modes de défaillance des agents runtime en production AI

Le runtime gère les tentatives de réexécution, restaure le travail antérieur, isole les espaces de travail et applique les contraintes budgétaires. Les cinq primitives mentionnées ci‑dessus contrôlent le cycle de vie d’une exécution, tandis que les mécanismes de politique et de gestion des secrets interviennent à différents niveaux. Lorsque les exécutions s’étendent sur plusieurs nœuds de traitement ou fenêtres de contexte, les échecs entraînent des problèmes liés à l’état, des effets secondaires redondants, du sandbox et au non‑respect des budgets.

Les pannes se répartissent en quatre catégories :

• Défaillances liées à la qualité de la sortie : l’agent proclame sa victoire avant que le travail ne soit réellement achevé, oublie ce qu’il a fait suite à un réinitialisation de la fenêtre de contexte, ou se fie à son propre évaluation pour livrer une sortie défectueuse.
• Défaillances de contrôle des coûts : l’agent reste bloqué dans une boucle de tentative, ou épuise son budget de tokens ou d’appels d’outils sans produire quoi que ce soit d’utile.
• Défaillances liées à l’état et aux plantages : les espaces de travail se détériorent parce qu’une exécution modifie des fichiers appartenant à une autre exécution, tool calls est déclenché plus d’une fois en raison des tentatives de répétition, ou le travail est perdu lorsque le processus concerné s’arrête entre deux événements.
• Défaillances de la fenêtre de contexte : le modèle effectue un résumé et s’arrête prématurément, pensant manquer d’espace, même lorsque la fenêtre dispose encore de marge disponible.

Le tableau associe à chaque défaillance une mesure d’atténuation, l’hook runtime qui la met en œuvre, ainsi que les fondements de la recommandation correspondante. Comme le comportement spécifique au modèle peut varier, il convient de considérer les observations fournies par le fabricant comme prompts afin de réexaminer ces hypothèses plutôt que de les traiter comme des règles définitives.

Deux idées apparaissent dans chaque ligne. Anthropic, concernant la harness de péremption Harness conception pour le développement d’applications à exécution prolongée:

« Chaque composant au sein d’un harness encode une hypothèse concernant ce que le modèle ne peut pas faire seul, et il est essentiel de soumettre ces hypothèses à des tests de résistance, tant parce qu’elles peuvent être fausses que parce qu’elles deviennent rapidement obsolètes à mesure que les modèles s’améliorent. »

Vercel, concernant le problème associé d’un trop grand nombre d’outils qui intègrent un trop grand nombre d’hypothèses, en Nous avons supprimé 80 % des outils de notre agent.:

« Nous en avons supprimé la majeure partie et avons réduit l’agent à un seul outil : l’exécution de commandes Bash arbitraires. Nous qualifions cet agent de fichier système. »

Selon les résultats communiqués par Vercel pour une requête représentative, le taux de réussite est passé de 80 % à 100 %, tandis que le pire scénario est passé de 724 s pour 100 étapes et 145 463 tokens (échec) à 141 s pour 19 étapes et 67 483 tokens (succès). La leçon à retenir n’est pas de « supprimer ses outils ». Il s’agit plutôt du fait que chaque primitive présente dans votre runtime, y compris l’interface d’utilisation des outils, possède une durée de vie limitée. Il convient de réévaluer ces hypothèses lorsque le modèle évolue.

Cognition a observé le même comportement lié à la durée de session avec Sonnet 4.5. Dans Reconstruire Devin pour Claude Sonnet 4.5 Ils décrivent un modèle qui écrit de manière proactive SUMMARY.md / CHANGELOG.md Comme le modèle détecte une épuisement du contexte tout en sous-estimant le nombre de tokens qui lui restent, la solution adoptée consiste à activer la version bêta de 1 M de tokens et à limiter leur utilisation à 200 k, afin que le modèle continue de croire disposer d’espaces suffisants. Cependant, cette mesure d’atténuation deviendra elle aussi inutile avec le temps.

L’équipe de harness chez OpenAI résume cette discipline en une seule phrase : « Les humains dirigent. Les agents exécutent. » Lorsqu’un problème survient, la question n’est pas de « s’efforcer davantage », mais plutôt de déterminer quelle capacité fait défaut et comment la rendre à la fois compréhensible et applicable pour l’agent.

Le cycle de vie d’un exécution saine

Un exécution bien comportée est ennuyeuse : il s’agit d’une chaîne de petites étapes réparables, où chacune enregistre son résultat dans un stockage durable avant que la suivante ne commence.

Cette frontière englobe les dommages causés par une panne. En cas de défaillance, seule l’étape en cours d’exécution est perdue, et le travailleur suivant reprend à partir de la dernière étape terminée, au lieu de devoir relancer toute la requête depuis le début.

1. Démarrez soit depuis une session fraîche, soit depuis une session reprise. Lors de la reprise, montez l’espace de travail à partir de son dernier état connu et lisez tous les fichiers de progression laissés par la tentative précédente (PROGRESS.md, feature-list.json), puis charger le dernier checkpoint depuis la base de données. C’est à ce stade que le harness transmet à l’agent tout ce que l’agent précédent avait en mémoire avant sa mort.
2. Planifier avant toute exécution tool calls. Définir ce qu’on entend par « tâche terminée », le temps alloué à l’exécution, les outils dont l’agent peut disposer, ainsi que les conditions permettant d’interrompre prématurément l’exécution. Ces valeurs de planification deviennent des vérifications runtime ; sans elles, l’exécution ne dispose d’aucun critère de contrôle.
3. Exécuter un tool call à la fois. La couche de politique décide si l’appel est autorisé. Le harness le lance, enregistre le résultat et écrit un événement dans le journal de session. Une étape, un événement. Une panne survenant entre deux événements est réparable, car c’est le journal, et non la mémoire de l’agent, qui constitue la source de vérité.
4. Faire un Checkpoint aux frontières des super-étapes, ou après chaque événement dans un harness plus simple. Persister l’état du graphe, la différence d’espace de travail, ainsi que les références à tous les artefacts générés. C’est ce checkpoint que lit l’étape 1 lors de la reprise. Si le checkpoint fait défaut ou est obsolète, la récupération se réduit à la lecture complète du journal de session depuis le début, ce qui est beaucoup plus lent.
5. Évaluer les artefacts lorsque l’agent estime avoir terminé : exécuter des tests, faire appel à un revueur avec un contexte frais, valider le schéma et effectuer des vérifications dans le navigateur. Si la vérification réussit, l’exécution se termine avec succès. En cas d’échec, l’exécution reprend à partir du dernier état propre checkpoint, la message d’erreur étant ajouté au contexte, avant de tenter à nouveau.

Aucune étape de cette liste ne nécessite que l’agent mémorise quoi que ce soit entre deux exécutions. L’état est conservé dans la session ainsi que dans le checkpoint, et l’agent le lit à nouveau à chaque reprise.

Les outils générant des effets secondaires doivent disposer d’une propriété d’idempotence. Tout outil présentant des effets secondaires nécessite une clé d’idempotence dérivée de l’ID de session et de l’ID d’appel de l’outil, qui doit être stockée avant que l’effet secondaire ne se produise. send_email(session_id, tool_call_id, message_hash). create_pr(session_id, tool_call_id, branch_name). charge_customer(session_id, tool_call_id, invoice_id). L’exécution au moins une fois est la valeur par défaut dans les files d’attente et les moteurs de workflows. Si la répétition d’un tool call peut causer des dommages réels, l’outil n’est pas prêt à être utilisé avec des agents.

L’évaluation doit intégrer des preuves provenant d’un contexte externe à celui de production. Un évaluateur indépendant permet de réduire le biais lié au contexte partagé, tandis que les tests, les outils de vérification de syntaxe, les contrôles dans le navigateur et la validation du schéma fournissent des preuves déterministes. La vérification peut alors renvoyer pass, fail, ou needs_human. Pour les agents de traitement de code, l’examinateur peut être une autre session de modèle dotée d’outils en lecture seule. Dans le cas des agents chargés du traitement des données et de la génération de rapports, il convient de combiner une validation déterministe avec un modèle d’examinateur qui nécessite néanmoins une évaluation humaine.

Onze modèles de déploiement d’agents AI et les facteurs qui les distinguent

Une fois les cinq primitives nommées, la question qui se pose est de déterminer quel format de déploiement les exécutera. Par « format », j’entends une disposition spécifique de ces primitives : l’emplacement où se trouve harness, le lieu où l’état est persisté, ainsi que le type de sandbox chargé d’effectuer les tâches. Il ne s’agit pas simplement d’un choix imposé par un seul fournisseur. Le graphique ci-dessous indique sur quelle portion de l’axe du nombre d’exécutions chaque format fonctionne le mieux. Le texte qui suit explique les critères qui permettent de faire le choix entre eux.

Si vous ne devez en lire qu’un seul parmi ces onze, choisissez le schéma 2 : file d’attente + travailleur + checkpoint DB. Il s’agit de la configuration par défaut que je recommande pour la plupart des équipes, celle utilisée dans le dépôt de référence, ainsi que du modèle de base autour duquel se déclinent la plupart des autres schémas : file d’attente → travailleur → état persistant, avec substitution du fournisseur de données sandbox, du propriétaire harness ou du moteur d’état. En commençant par le schéma 2, vous pourrez parcourir plus rapidement les autres configurations.

Le graphique compare les formes en fonction de leur longueur d’exécution. La matrice ci-dessous les compare en fonction de leur propriétaire : l’endroit où chacune des cinq primitives se trouve physiquement. Les cellules vertes indiquent que la forme fournit elle-même la primitive ; les cellules grises indiquent que vous devez la connecter manuellement.

1. SDK à l’intérieur d’un serveur d’application (synchrone, par requête)

La forme originale. L’agent SDK s’exécute à l’intérieur d’un gestionnaire de requêtes. Il convient aux tâches se déroulant en moins de 30 secondes, aux démonstrations ainsi qu’aux outils internes. En revanche, il est inadapté pour tout scénario où un client HTTP pourrait se déconnecter. Le délai de timeout HTTP de Cloud Run Sa durée maximale est de 60 minutes, et toute panne au niveau du tier web met fin à l’exécution. Le SDK correspond au harness ; le processus web agit également en tant que sandbox, et l’état est généralement stocké en mémoire de processus, sauf si vous le transférez explicitement ailleurs. Il ne faut pas l’utiliser pour des tâches d’une durée supérieure à quelques heures.

2. File d’attente + travailleur + checkpoint de base de données

La configuration par défaut que je recommande pour la plupart des équipes, ainsi que la version en production utilisée dans market-analyst-agent: un travailleur Python équipé d’un checkpointer PostgreSQL, Streams Redis (ou) RabbitMQ) Pour la file d’attente entrante, ainsi qu’un sidecar MCP dédié aux outils. Ce modèle convient aux exécutions allant de 10 minutes à plusieurs heures, grâce à des étapes idempotentes. Le lanceur local permet de contourner la file d’attente pour un développement synchronique, mais celle-ci devient indispensable en environnement de production lorsque l’on a besoin de soumissions asynchrones et de gestion du backpressure.

L’application reçoit une demande, crée une ligne de session, envoie un travail à exécuter et renvoie un identifiant de exécution. Le travailleur récupère ce travail, lance le harness, enregistre les checkpoints, diffuse des mises à jour sur l’état d’avancement et stocke les artefacts générés au fur et à mesure. PostgreSQL reste opérationnel, les travailleurs ne sont que des ressources interchangeables, et la profondeur de la file d’attente assure une contrainte de contrepression. Le calcul Spot/Préemptible fonctionne tant que le point de contrôle termine d’écrire sur le disque avant de signaler un succès.

Dans cette architecture, l’agent d’exécution est le harness. Son conteneur ainsi que l’espace de travail par thread définissent une frontière d’exécution, mais le code non fiable nécessite néanmoins un environnement sécurisé tel qu’un sandbox ou une machine virtuelle. PostgreSQL gère la session ainsi que l’état checkpoint. Les traces sont acheminées via OpenTelemetry vers n’importe quel stack d’observabilité que vous utilisez.

3. Moteur de flux de travail durable (style Temporal)

Le code d’orchestration des agents s’exécute à l’intérieur d’un flux de travail Temporal ; les appels aux modèles ainsi que les tool calls sont traités en tant qu’Activités. L’état du flux de travail est stocké dans un journal d’historique d’événements hébergé par Cassandra, MySQL ou Postgres, ce qui permet une reprise propre de cet état lors des déploiements. La version en prévisualisation publique Intégration Temporal × OpenAI Agents SDK envoie des OpenAIAgentsPlugin et un activity_as_tool aide, ainsi que le description détaillée de agentic et sandboxes décrivait le fait de faire forker un agent en cours d’exécution vers un fournisseur sandbox différent au milieu d’une conversation. Les workflows inactifs ne consomment aucune ressource de calcul. Cependant, il existe des limites réelles : les agents de type streaming et vocaux ne sont pas pris en charge dans cette intégration actuelle. LocalShellTool et ComputerTool Ils sont désactivés car ils ne correspondent pas à un modèle distribué.

Utilisez cette forme lorsque l’exécution comporte des points d’attente réels : approbations humaines, appels externes, temps d’attente prolongés, tentatives de réessai soumises à des règles métier, fenêtres de déploiement. Une approbation humaine se transforme en un état d’attente durable qui ne consomme aucune ressource de calcul, contrairement à une boucle de sondage.

Le code du flux de travail correspond au harness. Le sandbox se trouve généralement en dehors de Temporal et est invoqué depuis les activités. L’état de la session ainsi que celui du checkpoint sont intégrés au journal d’historique des événements de Temporal, tandis que la visibilité des traces provient de l’interface utilisateur de Temporal ainsi que des plages de temps définies par le OpenTelemetry pour chaque activité.

4. Fournisseur Sandbox par session

Une architecture plus récente. Chaque exécution d’agent dispose de sa propre microVM ou conteneur fourni par un fournisseur de sandbox en mode service. Le harness est stocké dans un espace persistant ; le sandbox constitue quant à lui l’environnement d’exécution jetable.

Le tableau combine les Comparaison E2B vs Daytona, Daytona’s sandboxes documentation et fork/journal des modifications du snapshot, Modal’s sandboxes et démarrage en froid guides, les Fiche de produit Runloop sur le AWS Marketplace, et Vercel Sandbox – tarification.

Daytona enregistre un lien parent-enfant pour chaque fork indépendant, ce qui permet de préserver la filiation des sandboxes dérivés. Le harness de OpenAI utilise quant à lui une approche par worktree : « Codex fonctionne sur une version complètement isolée de cette application, y compris ses journaux et ses métriques, qui sont supprimés une fois cette tâche terminée. »

Optez pour cette configuration lorsque l’agent exécute du code non fiable, de l’automatisation de navigateur, des tests ou des installations de paquets. Le compromis réside dans les coûts et le couplage avec le fournisseur, qui sont tous deux plus élevés que lors de l’utilisation de workers partagés.

Le fournisseur est propriétaire de sandbox et d’aucun autre élément. Harness, la session, checkpoint ainsi que les traces restent sous votre contrôle, généralement organisés selon un modèle de file d’attente associée à des travailleurs comme décrit en #2.

5. Agents gérés par Anthropic (hébergés harness)

Anthropic a lancé les Managed Agents en bêta public le 8 avril 2026, derrière le managed-agents-2026-04-01 En-tête beta. Le service propose une session hébergée, harness, sandbox, ainsi qu’un proxy MCP soutenu par un coffre-fort. wake(sessionId) Il est possible d’initialiser le harness sur un nouvel agent de travail sans perdre l’état de session persistant.

Claude facture les Managed Agents au tarif standard par token, majoré de 0,08 $ par heure de session. La facturation s’effectue au niveau du millisecondes et n’est appliquée que tant que l’état de la session est « en cours » ; le temps d’inactivité reste gratuit. Par conséquent, une boucle de tentative déroutée entraîne des coûts supplémentaires liés aux heures de session en plus des coûts liés aux tokens.

Lisez les mises en garde. La remise pour le traitement par lots API ne s’applique pas (« Les sessions sont à état et interactives. Il n’existe pas de mode par lots. »). Managed Agents n’est pas disponible via AWS Bedrock ou Google Vertex AI. La Multi-agent coordination ainsi que l’auto-évaluation restent encore en phase de prévisualisation dans la recherche. Le risque de verrouillage est élevé : on sacrifie la liberté harness de gérer le cycle de manière autonome au profit d’une solution prête à l’emploi.

Anthropic prend en charge les cinq primitives suivantes : session, harness, sandbox, checkpoint et trace. Vous lui transmettez le runtime et vous obtenez les résultats correspondants.

6. Déploiement d’agents profonds LangChain (géré en mode ouvert harness)

deepagents deploy packages a deepagents.toml dans un déploiement LangSmith offrant une exécution durable, une gestion fine de la mémoire, le multi-tenancy, human-in-the-loop, des capacités d’observabilité, une exécution de code en environnement sandboxé, ainsi que des exécutions planifiées. Les modes de déploiement cloud, hybride et auto-hébergé sont pris en charge. Les fournisseurs Sandbox (LangSmith Sandboxes, Daytona, Modal, Runloop ou personnalisés) peuvent être changés via une seule valeur de configuration. L’état est stocké dans un système de fichiers virtuel doté de backends interchangeables ; la mémoire est attribuée au niveau de l’utilisateur, de l’assistant ou des deux. Le risque de verrouillage est moindre par rapport aux agents gérés : le harness est licencié sous licence MIT, et les instructions utilisent des outils open source. AGENTS.md standard, et les agents sont exposés via MCP, A2A, ainsi que le Agent Protocol. Voir LangChain’s runtime – agents profonds en environnement de production rapport de synthèse.

Les cinq primitives sont hébergées par défaut, mais chacune peut être remplacée via des paramètres de configuration. Le sandbox est géré par une valeur de configuration spécifique. La session ainsi que le checkpoint fonctionnent sur un système de fichiers virtuel disposant de backends interchangeables. Les traces sont envoyées à LangSmith.

7. Service ou job Google Cloud Run

Cloud Run dispose de deux modes distincts runtime, et le choix dépend de la manière dont l’agent est invoqué. Les services sont liés à HTTP et passent en état zéro entre les requêtes ; le harness s’exécute en tant que gestionnaire de requêtes qui cesse son fonctionnement une fois l’exécution terminée. Les jobs, quant à eux, se poursuivent jusqu’à leur fin sans point d’entrée HTTP ; le harness fonctionne comme un travailleur à usage unique qui s’arrête dès que la tâche est achevée. Ces deux approches peuvent héberger le harness, mais aucune ne conserve d’état entre différentes exécutions. Les sessions ainsi que les checkpoints doivent être stockées dans Postgres, Spanner ou un système de stockage externe similaire.

Les limites intrinsèques diffèrent considérablement entre les deux approches. Délai d’attente dépassé pour la demande de service Cloud Run: Valeur par défaut : 300 s, valeur maximale : 3 600 s (60 min). WebSockets obtenir le même délai d’expiration. Les jobs Cloud Run: Par défaut, 10 minutes par tâche, avec une limite maximale de 168 h (7 jours) ; pour les tâches utilisant GPUs, la limite maximale est de 1 heure. Les services sont réduits à zéro sauf si vous activez le mode CPU permanent ; les jobs ne disposent pas de protocole HTTP et ne sont pas auto-scalés.

Utilisez un service pour les exécutions synchrones d’une durée allant jusqu’à 60 minutes. Préférez plutôt une tâche pour des travaux ponctuels plus longs ou asynchrones. Les Cloud Run Jobs permettent de maintenir une tâche active pendant plusieurs jours, mais ils ne garantissent pas une reprise fiable après des déploiements, des mises à jour de version ou le remplacement des travailleurs. Au-delà de 7 jours, évitez d’utiliser Cloud Run.

Cloud Run héberge le harness. Les sessions ainsi que l’état de checkpoint sont stockés dans Postgres, Spanner ou un autre système de stockage externe, et les traces peuvent être transmises via Cloud Logging et OpenTelemetry. Le conteneur de service constitue un environnement d’exécution ; il convient d’ajouter un sandbox distinct lorsque l’agent exécute du code non fiable.

8. AWS Lambda (pourquoi c’est l’outil inadapté)

Le délai maximal d’exécution d’une fonction Lambda Il s’agit de 900 s (15 minutes), ce qui est très difficile. Si le gateway API expose cette fonction, la limite d’intégration dépend du type de API. HTTP APIs autorise 30 secondes; Les intégrations REST ont pour valeur par défaut 29 secondes, tandis que Les REST régionaux et privés APIs permettent de définir un délai d’attente plus long.. Aucun de ces scénarios ne transforme Lambda en un processus exécuté pendant des heures. Un processus harness qui fonctionne sur une longue période a néanmoins besoin d’un état externe ainsi que d’une nouvelle invocation, ce qui entraîne la création à nouveau de la file d’attente et du travailleur associés. Utilisez Lambda pour des tâches tool calls à durée limitée, comme la récupération de fichiers ou les téléchargements vers S3, et faites-en l’appel depuis un orchestrateur ayant une durée de vie plus longue. Ne placez pas l’orchestrateur directement à l’intérieur de Lambda.

Au maximum, Lambda ne peut conserver qu’un seul tool call au sein de sa limite de 15 minutes. Le harness, c’est‑à‑dire la session, ainsi que le checkpoint et le sandbox, doivent tous être stockés ailleurs.

9. Tâche AWS ECS / Fargate par exécution

Contrairement à Lambda, la documentation de Fargate ne précise pas de limite maximale pour les tâches runtime. Quotas de limitation de Fargate Permettre une impulsion de lancement de 100 unités, avec un rechargement à un rythme de 20 unités par seconde, et disposer de budgets distincts pour les demandes sur demande et les offres spot. Quotas de service ECS Limiter les services à 1 000 tâches par service grâce à la découverte via AWS Cloud Map, et les clusters basés sur EC2 à 5 000 instances de conteneur.

Fargate exige awsvpc En mode par défaut, chaque tâche dispose d’une interface réseau ainsi que d’une IP privée. Cette architecture convient parfaitement aux accès aux données au sein d’une VPC. Fargate Spot introduit un risque d’interruption, et la durabilité des données reste de votre responsabilité, puisque la plateforme ne dispose pas de mécanisme de réexécution similaire à Temporal.

Fargate héberge les harness et attribue à chaque exécution sa propre tâche. Cela permet de séparer les espaces de travail des identifiants des tâches, mais cela ne constitue pas en soi une protection complète sandbox contre du code malveillant. La gestion des sessions, checkpoint, ainsi que l’élaboration des traces, sont gérées par des services externes tels que RDS ou DynamoDB, ainsi que par CloudWatch/X-Ray.

10. Job Kubernetes ou espace de noms par session

Excellente solution lorsque l’on travaille déjà avec ce système. Kubernetes et on souhaite une gestion sandbox par session, associée à des contrôles au niveau du cluster. Cela est problématique lorsque l’on a besoin d’un démarrage en quelques sous-secondes, car le téléchargement de l’image de conteneur et l’initialisation du pod prennent trop de temps lors d’un démarrage à froid. Le schéma retenu consiste en un Job pour chaque exécution d’agent. activeDeadlineSeconds, une PersistentVolumeClaim pour l’espace de travail, ainsi qu’un sidecar destiné au serveur MCP. La récupération en cas de panne doit être implémentée par vous-même. Adopter Kubernetes uniquement pour héberger des agents entraîne des coûts importants en termes de surcharge de configuration et de charge opérationnelle. Cela n’en vaut la peine que si vous utilisez déjà K8s pour d’autres raisons.

Kubernetes héberge l’harness ainsi que l’environnement d’exécution par exécution, généralement au sein d’un Job et parfois dans un espace de noms dédié. Une forte isolation dépend néanmoins de la classe runtime, des politiques de réseau, de la sécurité des pods, ainsi que des limites imposées par le conteneur ou la VM sous-jacente. Les sessions et l’état checkpoint sont stockés dans une base de données externe ou via un PersistentVolumeClaim.

11. Docker Compose local (uniquement en environnement de développement)

Le référentiel pour la section suivante. L’avantage de cette architecture réside dans le fait qu’elle reproduit à l’identique la topologie de production (mêmes primitives, même structure réseau) tout en étant exécutée sur une seule machine. Consultez la liste des éléments « non sûrs pour la production » à la fin de la section suivante avant de déployer tout système présentant ce type de conception.

On crée des miroirs de la configuration #2 sur un seul hôte. PostgreSQL gère la session ainsi que l’état checkpoint, tandis que le conteneur travailleur constitue le harness. Le montage du espace de travail partagé est pratique pour le développement, mais il ne permet pas d’isoler les exécutions non fiables. La pile OpenTelemetry optionnelle enregistre les traces d’exécution.

Stack de référence : Docker Compose

La topologie de référence, utilisée dans slavadubrov/market-analyst-agent, est un travailleur LangGraph, un checkpointer PostgreSQL, Qdrant pour la récupération, un sidecar MCP, une file Redis destinée à des exécutions asynchrones similaires en environnement de production, ainsi qu’un élément optionnel Prometheus / Grafana / Loki / Tempo / OTel pile d’observabilité. Dans Local Compose, Redis n’est optionnel que parce que l’exécutant synchrone peut appeler directement le travailleur. docker compose up met l’ensemble de la topologie en état opérationnel localement.

La seule partie qui mérite d’être affichée en ligne est le schéma de connexion canonique de LangGraph. Il s’agit du plus petit exemple concret de la primitive checkpoint :

import os
from urllib.parse import quote

from langgraph.checkpoint.postgres import PostgresSaver

password = quote(os.environ["POSTGRES_PASSWORD"], safe="")
DB_URI = f"postgresql://agent:{password}@postgres:5432/agent"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates tables on first run
    graph = builder.compile(checkpointer=checkpointer)

Observabilité résistante tout au long de l’exécution

Les gestionneurs de requêtes de courte durée sont faciles à déboguer : en cas d’échec, il suffit de lire la réponse ainsi que le journal en temps réel. Les agents à exécution prolongée ne disposent pas de ce luxe. Lorsqu’une exécution de six heures échoue, l’événement pertinent s’est déjà produit il y a cinq heures, les sorties du terminal en direct ont disparu, et le processus qui les générait a été remplacé. Personne ne pourra reconstituer l’exécution à partir de sa mémoire. Il faut donc se baser sur des artefacts durables qui ont été enregistrés tant que l’exécution était encore active.

Les stacks de production couvrent généralement quatre types d’artefacts, regroupés en deux catégories. Deux d’entre eux sont consultés après la fin de l’exécution, aux fins d’analyse a posteriori et de rejeu : un journal des événements consultable pour chaque étape, ainsi que des traces OpenTelemetry indiquant où le temps et les tokens ont été utilisés. Les deux autres sont consultés pendant l’exécution, afin de suivre ce qui se passe en temps réel : une vue en direct du contenu généré par l’agent dans l’espace de travail, ainsi qu’une stack d’observabilité par worktree que l’agent lui-même peut interroger tant qu’il est encore en cours d’exécution.

Journal d’événements structuré (à consulter après l’exécution)

Chaque appel de modèle, tool call, résultat, erreur ou décision d’approbation est enregistré dans un stockage persistant, identifié par l’ID de session et une horodatage. Une fois l’exécution terminée, il est possible de le consulter comme une table de base de données ordinaire. Addy Osmani fixe clairement les standards en la matière. Agents à exécution prolongée: « Si l’on ne parvient pas à reconstituer les actions menées par l’agent au cours des 24 dernières heures à partir d’un stockage fiable, on a affaire à un script shell en exécution continue qui se contente d’appeler un LLM, et non à un agent fonctionnant de manière persistante. »

OpenTelemetry Traçages de la génération d’IA (à consulter après l’exécution)

Le même type de données étape par étape, mais émises sous forme de spans en utilisant les attributs standards provenant du gen_ai.* conventions sémantiques: Nom du modèle, fournisseur, nombre de tokens d’entrée et de sortie, identifiant de conversation, nom du flux de travail (état de développement à partir de v1.36.0). Les champs spécifiques au fournisseur se trouvent dans des sous-espaces.anthropic.*, openai.*) désactivé par clé gen_ai.provider.nameLa raison d’utiliser cette norme réside dans la portabilité : le même suivi s’affiche correctement dans Tempo, Jaeger, Honeycomb ou LangSmith, sans nécessiter de réinstrumentation du code à chaque changement de backend.

Chronologie des appels d’outils ainsi que les différences d’espace de travail (à consulter pendant l’exécution)

Le moyen le plus rapide de savoir ce qu’un agent est en train de faire à l’instant présent consiste à suivre les éléments qu’il génère dans l’espace de travail, plutôt que de parcourir un journal de session. Anthropic’s Harness Primitifs pour des agents Claude à exécution prolongée Le guide de démarrage rapide fournit deux hooks à cet effet : watch -n 5 'git log --oneline -8' affiche les derniers commits effectués par l’agent, et watch -n 5 'find screenshots -name "*.png" | tail -5' Affiche les captures d’écran les plus récentes qu’il a prises. Deux panneaux de terminal mis à jour toutes les cinq secondes suffisent pour déterminer si une exécution réalise des progrès concrets ou reste simplement en attente.

Stack éphémère par worktree (lue par l’agent lui-même pendant son exécution)

Par La publication de harness par OpenAI: Les journaux, les métriques et les traces sont exposés à Codex au moyen d’une pile d’observabilité locale qui est éphémère pour chaque worktree donné. Chaque agent worktree dispose de sa propre instance temporaire de Loki + Prometheus + Tempo, dédiée exclusivement à son exécution. L’agent interroge cette pile pendant qu’il fonctionne. C’est ce qui permet à une prompt telle que « aucune durée de suivi dans ces quatre parcours utilisateur ne dépasse deux secondes » de devenir quelque chose que l’agent peut vérifier directement, plutôt que quelque chose qu’il doit deviner.

(L’évaluateur de contexte frais provenant de la table des modes d’échec lit ces artefacts afin de déterminer si l’étape est « terminée ». Il fait partie de l’évaluation et non de l’observabilité ; voir § Cycle de vie d’exécution saine.

Une pile d’observabilité auto-hébergée minimale

Pour un cas similaire market-analyst-agent:

1. OpenTelemetry Collecteur associé au processeur GenAI, équipé d’un filtre d’attributs gen_ai.*.
2. Tempo (ou Jaeger) pour les traces, indexées par gen_ai.conversation.id / thread_id.
3. Loki pour les enregistrements structurés de journaux d’événements.
4. Prometheus pour gen_ai.client.token.usage, gen_ai.client.operation.duration, gen_ai.server.time_to_first_token (voir le Conventions des métriques pour les GenAI).
5. Tableaux de bord Grafana basés sur gen_ai.agent.name et gen_ai.request.model.

Alternatives hébergées (en choisir une, pas trois) :

• LangSmith: Intégration native avec LangGraph ; c’est également la cible de déploiement pour Deep Agents Deploy. équipe d’experts: La meilleure solution si les suites de régression basées sur l’évaluation en premier lieu constituent la priorité.
• Arize Phoenix: OSS, natif OTLP, s’associe à OpenInference Instrumentation.
• Le tableau de bord de suivi d’OpenAI : fonctionne automatiquement lorsque l’on utilise les OpenAI Agents SDK ou leur intégration Temporal.
• Le suivi de Claude d’Anthropic : destiné aux sessions exécutées au sein des Managed Agents.

Instrumenter le nœud LangGraph

# In the LangGraph node, around the model call:
span.set_attribute("gen_ai.operation.name", "chat")
span.set_attribute("gen_ai.provider.name", "anthropic")
span.set_attribute("gen_ai.request.model", "claude-sonnet-4-5")
span.set_attribute("gen_ai.response.model", "claude-sonnet-4-5")
span.set_attribute("gen_ai.conversation.id", thread_id)
span.set_attribute("gen_ai.agent.name", "market-analyst")
span.set_attribute("gen_ai.workflow.name", "research_then_write")
span.set_attribute("gen_ai.usage.input_tokens", usage.input_tokens)
span.set_attribute("gen_ai.usage.output_tokens", usage.output_tokens)

Noms d’attributs repris tels quels du OpenTelemetry Registre des conventions sémantiques des modèles de génération de langage.

Consultations relatives à trois pannes courantes

# Loki: token usage per agent over 1h
sum by (gen_ai_agent_name) (
    rate({service_name="market-analyst-agent"} | json | unwrap gen_ai_usage_output_tokens [1h])
)

# PromQL: p95 model latency per model
histogram_quantile(0.95,
    sum by (le, gen_ai_request_model) (
        rate(gen_ai_client_operation_duration_bucket[5m])
    )
)

# TraceQL: long-running tool calls
{ span.gen_ai.operation.name = "execute_tool" && duration > 30s }

Le schéma de bundle de débogage

Lorsqu’un exécution échoue, le worker doit la rejeter. /workspaces/${THREAD_ID}/_debug/ contenant les artefacts que vous demanderiez lors d’un post-mortem :

• session.jsonl: export complet du journal des événements généré par PostgresSaver (checkpointer.list({"thread_id": ...})).
• last_state.json: StateSnapshot.values à partir du dernier super‑étape réussi. trace.json: Les spans exportés en OTLP pour l’exécution.
• tool_calls.csv: (ts, tool, input_hash, latency_ms, status, error).
• workspace.tar.zst: le répertoire d’espace de travail plus git diff contrairement à la branche de démarrage. screenshots/*.png: Ce que l’agent a observé.
• PROGRESS.md, feature-list.json, ainsi que tous les autres fichiers de progression générés par l’agent. env.txt: balises d’image, version du modèle, SHA de la commit harness.

Ce paquet fournit à un agent humain ou d’audit des preuves suffisantes pour reconstituer la cause de défaillance. L’expression « L’agent est bloqué » est trop vague. Un rapport illustratif, en revanche, est concret : session s_123 A consacré 71 % de ses tokens à répéter trois commandes successivement. npm install Échec.

Choisir la forme adéquate : un guide de décision

La majeure partie des comparaisons présentées ci-dessus se résume à un petit nombre de décisions à prendre.

Commencer par la longueur de série

Utilisez la longueur de série comme premier filtre :

• Moins de 30 secondes, opération idempotente : cycle de vie de la requête SDK sur un serveur d’application.
• De 30 s à 60 min, pas de récupération en cas de panne nécessaire : file d’attente + travailleur + base de données checkpoint.
• De 60 min à 24 h : même file d’attente + travailleur, ou un Cloud Run Job pour des tâches ponctuelles. Utilisez un moteur de workflows durables si vous avez également besoin de gestion des versions et de réexécution.
• Plus de 24 h, doit survivre aux déploiements : moteur de workflows durables (de type Temporal). Les Cloud Run Jobs peuvent gérer des tâches longues jusqu’à leur limite de tâches, mais ils ne prennent pas en charge de sématique de réexécution.
• Boucles d’entraînement par apprentissage par renforcement sur plusieurs jours : K8s Job + volume de stockage + Temporal.

Après ce filtre grossier, il convient d’évaluer les effets secondaires, les mécanismes de récupération, la possibilité de rejouer les opérations, l’isolation des composants, l’emplacement des données, ainsi que l’équipe chargée de l’exploitation du système.

Adaptation de la plateforme en fonction du cas d’usage

La matrice est dense car aucune seule cellule verte ne détermine l’architecture. Une large couverture des charges de travail est utile, mais elle ne reflète pas la résidence des données, les sémiotiques de rejouement, la dépendance vis-à-vis du fournisseur, le niveau de maturité opérationnelle, ni le coût lié au transfert ultérieur de l’état.

Deep Agents Deploy couvre tous les types de charges de travail identifiés dans la matrice, ce qui en fait une solution adaptée lorsque l’on doit gérer des exécutions de courte durée, des tâches s’étendant sur plusieurs heures, des agents de traitement de code, des agents de recherche ainsi que des jobs planifiés. Toutefois, cette polyvalence se traduit par un historique de déploiement en production plus limité par rapport à une architecture basée sur une file d’attente, des workers et Postgres. Considérez les cellules vertes comme des affirmations de capacités à valider, puis comparez les contraintes opérationnelles que la matrice ne peut pas refléter.

Les Agents gérés d’Anthropic s’adaptent soit entièrement à votre charge de travail, soit pas du tout. Ce produit présente trois contraintes strictes : il ne peut être utilisé que en mode hébergé, uniquement avec Claude, et les sessions ne peuvent durer moins de 24 heures. Si votre charge de travail répond à ces trois critères, par exemple un agent de codage interne qui fonctionne en séquences de 2 à 6 heures et que vous préférez ne pas gérer vous-même via harness, les Agents gérés constituent une solution idéale, permettant à votre équipe d’éviter une grande partie des tâches liées à la plateforme. En revanche, si l’une de ces contraintes n’est pas respectée – en raison du besoin d’un modèle autre que Claude, d’une configuration auto-hébergée ou de sessions de 48 heures – les Agents gérés ne conviennent pas. Aucune modification de configuration ne peut y remédier.

Il est essentiel de modéliser le coût avant de prendre une décision définitive, et non après. Le tarif horaire pour les sessions s’élève à 0,08 $/heure en plus des coûts standards liés aux tokens. Si une seule session fonctionne en continu, cela représente environ 58$ par mois par session. Avec 100 sessions en cours en permanence, le coût s’élève à environ 5 800 $ par mois avant de prendre en compte les tokens. Multipliez 0,08 par le nombre d’heures estimées de sessions simultanées, ajoutez ce montant à la facture des tokens, puis comparez-le au coût d’une architecture basée sur des files d’attente et des workers sur vos propres infrastructures. Faites cela avant de valider la solution, car migrer vers des agents gérés ultérieurement revient à effectuer un re-platforming, et non simplement à modifier des paramètres de configuration.

Hébergement harness contre propriété harness

La différence réside ici sur le plan opérationnel, et non sur l’auteur du code harness. Une solution hébergée signifie que le fournisseur exécute la boucle harness au sein de ses infrastructures, tandis que vous appelez une API. Une solution propriétaire signifie que vous exécutez cette boucle sur vos propres infrastructures, même si le code harness lui-même provient d’un fournisseur.

LangChain apparaît des deux côtés de cette ligne, ce qui prête à confusion. Ils proposent LangGraph, une bibliothèque sous licence MIT que l’on héberge soi-même (et dont on est propriétaire), ainsi que Deep Agents Deploy, un produit géré qui exécute des Deep Agents. harness sur le déploiement de LangSmith en mode cloud par défaut (hébergé). Même entreprise, deux modèles opérationnels distincts. C’est vous qui choisissez le modèle, et non le fournisseur. (Deep Agents Deploy dispose également d’un mode auto-hébergé destiné aux équipes qui le souhaitent) harness

Choisissez une solution harness hébergée lorsque son support de modèles, ses limites de données, son comportement de récupération ainsi que ses points d’extension correspondent déjà à vos besoins. Optez plutôt pour une harness propriétaire lorsque ces contraintes représentent des exigences que vous prévoyez de modifier ultérieurement. La migration entre ces deux approches modifie l’état du système, l’observabilité et les limites d’exécution ; il est donc essentiel de tester le chemin de sortie avant que des données en production ne dépendent de cette solution.

Environnement d’exécution hébergé sandbox versus environnement d’exécution propriétaire

Choisissez un sandbox hébergé lorsque l’isolation offerte par le fournisseur, les fonctionnalités de pause/reprise, ainsi que les spécificités de fork correspondent au modèle de risques et au budget alloué pour le démarrage du système. Docker ou Fargate conviennent aux charges de travail internes fiables qui nécessitent un accès à une VPC ou une résidence stricte des données, mais un conteneur standard ne constitue pas une barrière suffisante contre du code malveillant. Ajoutez gVisor, Kata, une microVM, ou un autre runtime renforcé lorsque l’agent installe des paquets non fiables ou exécute des programmes générés.

Stockeurs d’état : Git, bases de données et systèmes de stockage d’objets côte à côte

Les agents à exécution prolongée emploient généralement trois stockeurs d’état en même temps, car chacun de ces stockeurs gère un artefact distinct.

Git stocke l’état de l’espace de travail : le code, les documents ainsi que les fichiers de suivi des progrès modifiés par l’agent. Chaque commit fournit à harness un point de récupération fiable et permet d’obtenir une histoire compacte pour la session suivante.

La base de données checkpoint stocke l’état du graphe : les décisions prises, les nœuds qui ont été exécutés, les résultats obtenus, ainsi que les tâches à exécuter ensuite. Le stockage des artefacts contient des fichiers de sortie volumineux tels que des PDF, des fichiers Parquet et des captures d’écran. Ces artefacts ne doivent pas être conservés dans Git ni dans la base de données checkpoint.

Quand utiliser git comme état

Utilisez Git lorsque le volume de travail est de nature codique (édits sur plusieurs fichiers, refactorisations, génération d’applications) ou suffisamment documentaire pour que l’historique des fichiers soit pertinent. Le schéma est simple : créez une branche de exécution, effectuez un commit initialisateur, puis effectuez des commits aux points clés : après la configuration, après chaque fonctionnalité, après que les tests ont réussi, et après le nettoyage final. Stockez l’SHA du dernier commit de l’espace de travail à côté de la ligne checkpoint. Lors de la reprise, le prochain travailleur fait checkout de la branche et lit git log --oneline -8, examine git status ainsi que la dernière différence, puis lit PROGRESS.md ou tout autre fichier de transfert généré par la session précédente.

Cela fait de Git une surface de récupération pour l’artefact en cours d’édition, et non un remplacement de la base de données checkpoint. Git peut répondre à deux questions : qu’est-ce qui a changé, et quelle version a réussi les tests. Il ne peut pas indiquer au harness quel nœud du graphe doit être exécuté en suivant, quel tool call attend encore une validation, ou quel essai a déjà utilisé sa clé d’idempotence. Le harness d’Anthropic utilise des commits d’initialisation ainsi que des commits par fonctionnalité comme source de vérité pour la récupération de l’espace de travail ; le modèle lit git log --oneline -8 pour récupérer l’état. Omettre Git lorsque le produit du travail se résume à une seule réponse conversationnelle ; la surcharge induite n’en vaut pas la peine.

Quand utiliser les points de contrôle de la base de données

Utiliser PostgresSaverUn mécanisme de sauvegarde de type checkpointing lorsque l’agent possède une structure en graphe composée de plusieurs nœuds dont l’état intermédiaire est crucial (planificateur → chercheur → rédacteur → vérificateur). Le dépôt de référence utilise cette approche précisément pour cette raison. Il ne faut pas stocker des artefacts de travail à l’échelle de téraoctets dans checkpoint ; ceux-ci doivent être placés dans un système de stockage d’objets.

Quand utiliser un stockage d’artefacts (S3 / GCS)

Utilisez le stockage d’objets lorsque :

• La taille du résultat dépasse ce que la base de données checkpoint est conçue pour stocker ;
• Les consommateurs finaux ont besoin d’un artefact accessible via une URL, sans devoir passer par l’agent ; ou
• Le produit livré et l’état d’exécution possèdent des périodes de conservation différentes.

Par exemple, vous pouvez supprimer les journaux de session après 30 jours, mais conserver le rapport final pendant des années. Définissez la structure en fonction de (thread_id, checkpoint_id, artifact_name) Ainsi, le cycle de production reste reconstructible.

Quand mettre en place des étapes d’approbation humaine

Ajoutez des portes de contrôle lorsque le tool call est destructeur et irréversible (écritures dans une base de données, mouvements financiers, envoi de communications externes), lorsque le tool call sort de la zone d’influence de l’agent (déploiements en production, publications destinées aux clients), ou encore lorsque les régulateurs exigent une révision. LangGraph’s interrupt() Le middleware de validation des agents profonds dispose également d’un support intégré pour ces portes de contrôle. Partie 4 J’ai expliqué pourquoi ces portes constituent un problème de permissions et non un problème prompt.

Une liste de contrôle pratique pour la production

Avant la mise en production d’un agent à exécution prolongée, répondez à ces questions en utilisant des termes concrets relatifs à l’infrastructure.

1. Quel stockage gère les événements de session et checkpoints ?
2. Que se passe-t-il si le travailleur s’arrête en cours de tool call ?
3. Un exécution peut-elle corrompre l’espace de travail d’une autre exécution ?
4. Quelles actions nécessitent une approbation ?
5. Le modèle ou sandbox peut-il lire des identifiants bruts ?
6. Quel tool calls peut être relancé en toute sécurité ?
7. Où est appliqué le plafond de coût par exécution ?
8. Quelle vérification de contexte frais détermine que l’exécution est terminée ?
9. Où sont stockés les résultats finaux une fois que sandbox a disparu ?
10. Pouvons-nous expliquer une exécution échouée demain sans la relancer ?

Si la réponse à l’une de ces questions est « le prompt indique à l’agent d’être prudent », le système n’a pas encore été déployé. Il s’agit toujours d’une démonstration.

La couche suivante correspond à la boucle harness

Ce runtime permet de maintenir une exécution en cours et réparable, mais la durabilité ne prouve pas que le travail est correct. Partie 6, Harness Engineering pour les agents AI, il couvre le cycle associé au modèle : la manière dont un suivi devient un cas de test, l’endroit où se trouvent les règles de tentative et d’arrêt, ce qu’un transfert doit préserver, ainsi que la façon dont une vérification d’acceptation externe détermine que l’exécution est terminée.

Références

Documents d’ingénierie

• OpenAI, Harness engineering : tirer parti de Codex dans un monde axé sur les agents.
• Anthropic Engineering, Des mécanismes efficaces pour les agents à exécution prolongée.
• Anthropic Engineering, Harness conception pour le développement d’applications à exécution prolongée.
• Anthropic Engineering, Échelle des agents gérés : découplage du cerveau des mains, 8 avril 2026.
• Cognition AI, Réconstruction de Devin pour Claude Sonnet 4.5 : leçons apprises et défis rencontrés.
• Vercel, Nous avons supprimé 80 % des outils de notre agent..
• Addy Osmani, Agents à exécution prolongée.

LangGraph et les agents profonds

• Documentation de LangGraph, Persistance.
• Référence LangGraph, Checkpoints.
• langgraph-checkpoint-postgres sur PyPI.
• Documentation de LangChain, Aperçu des agents profonds.
• Blog de LangChain, Le runtime derrière les agents profonds en production.

Agents OpenAI SDK

• OpenAI Agents SDK, Séances.
• OpenAI Agents SDK, Sandbox concepts.

Temporel

• Blog temporel, Présentation de Temporal et de agentic sandboxes : les agents OpenAI SDK.
• Blog temporel, Des agents prêts pour la production utilisant OpenAI Agents SDK + Temporal.
• Temporal × OpenAI Agents SDK contrib README (temporalio/sdk-python).

Plateforme Anthropic

• Anthropic, Prix de la plateforme Claude: Tarifs horaires de session pour les agents gérés. anthropics/cwc-long-running-agents: Code avec Claude 2026 à emporter, incluant un sous-agent évaluateur ainsi que des modèles de fichiers de progression.

Sandbox fournisseurs

• ZenML, E2B versus Daytona : comparaison sandbox pour les ingénieurs de plateforme.
• Documentation Daytona, Sandboxes.
• Journal des modifications de Daytona, Sandbox fork ainsi que les points de terminaison de capture d’image.
• Documents modaux, Sandboxes.
• Documents modaux, Guide de démarrage en conditions froides.
• Runloop sur le AWS Marketplace.
• Vercel Sandbox : tarifs et limites.

Délais d’expiration et quotas des plateformes cloud

• Google Cloud, Configurer le délai de timeout des requêtes pour les services.
• Google Cloud, Utilisation de WebSockets.
• Google Cloud, Définir le délai d’expiration des tâches pour les jobs.
• AWS, Configurer le délai de timeout de la fonction Lambda.
• AWS, Quotas Lambda.
• AWS, Quotas de limitation de Fargate.
• AWS, Quotas de service ECS et limites de limitation API.

Observabilité

• OpenTelemetry, Conventions sémantiques pour les systèmes génératifs AI.
• OpenTelemetry, Générer le registre des attributs AI.
• OpenTelemetry, Conventions sémantiques pour les agents de génération d’IA et les spans framework.
• OpenTelemetry, Conventions sémantiques pour les métriques génératives AI.

Série

• Partie 1 : AI Les boucles de raisonnement des agents en 2026: ReAct, ReWOO, ainsi que le modèle Plan-and-Execute. Partie 2 : AI L’architecture mémoire des agents en 2026: checkpoints, les bases de données vectorielles et la mémoire de documents. Partie 3 : AI Agent Tool Use en 2026: MCP, CLI, compétences, exécution de code, et ACI.
• Partie 4 : AI La sécurité des agents en 2026: les garde-fous, les permissions, sandboxes, HITL, ainsi que le cadrage MCP.
• Partie 5 : Les agents AI à exécution prolongée Runtime en 2026 (cet article) Partie 6 : Harness Engineering pour les agents AI: les vérifications d’acceptation, les traces, les tentatives de réessai, les transferts de responsabilité, ainsi que le boucle d’exécution autour du modèle.

Le code de l’agent d’analyse de marché (travailleur LangGraph, checkpointer Postgres, mémoire Qdrant, sidecar MCP, ainsi que la topologie Docker Compose décrite ci-dessus) est disponible sur GitHub._