Skip to main content
Le runtime des agents fournit un magasin mutable, isolé par requête, pour partager des données entre votre code applicatif et les outils exécutés par le modèle. Il remplace les abus d’experimental_context et évite d’injecter des chemins sensibles dans les prompts.

Initialiser un runtime

  • RuntimeStore<T> accepte des valeurs typées ; get, set, require, delete fonctionnent comme une Map.
  • onCleanup enregistre une fonction appelée automatiquement à la fin de la requête (y compris en streaming).
  • Le runtime est cloné pour chaque appel afin d’éviter les fuites d’état.

Outils orientés runtime

createRuntimeTool injecte automatiquement le runtime courant dans la signature execute. Si aucun runtime n’est disponible (par exemple si l’appelant oublie runtime), l’exécution échoue immédiatement.

Ressources déclaratives

registerRuntimeResource centralise l’encodage/décodage et garantit un nettoyage cohérent via dispose. runtime.load invoque le loader, stocke la valeur puis déclenche le cleanup après la réponse.

Bonnes pratiques

  • Isolation asynchrone – chaque appel generate/stream s’exécute dans un contexte AsyncLocalStorage. Les outils peuvent récupérer le runtime actif sans paramètre supplémentaire.
  • Streaming – le runtime reste actif jusqu’à la fermeture du flux ; les onCleanup sont déclenchés dès que la génération se termine ou échoue.
  • Runtimes multiples – instanciez plusieurs RuntimeStore pour séparer les domaines fonctionnels (ex. fichiers, utilisateurs).
  • Typage fort – paramétrez RuntimeStore<{ ... }> et createRuntimeTool<INPUT, OUTPUT, RuntimeState> pour conserver le typage bout en bout.