Où placer le gestionnaire et ce qu’il reçoit
Événements émis par le runtime
Les clés de détail sont listées ci-dessous en snake_case ; TypeScript utilise la forme camelCase.
Rust
0.2 utilise ses propres noms pour certains événements :
Une exécution qui se termine sur une condition d’arrêt envoie
run.stopped en TypeScript et aucun événement terminal en Python, Go, C#, PHP, Ruby ou Java ; lisez plutôt le statut de l’exécution. En TypeScript, step.completed est envoyé après l’enregistrement du point de reprise de l’étape ; les consommateurs de persistance et de télémétrie peuvent donc le traiter comme une frontière stable.
Événements de flux
Avec le streaming, les mêmes événements de cycle de vie arrivent en même temps que les événementsresponse.* du modèle. En TypeScript, Python, Go, C# et Java, le gestionnaire les reçoit ; en PHP et Ruby, ils apparaissent aussi dans fullStream() / full_stream. Rust n’a pas de streaming. Streaming décrit les consommateurs de flux.
Garder les gestionnaires rapides
Le runtime attend le gestionnaire avant de continuer : rendez donc la main rapidement et déplacez le stockage lent ou le travail réseau dans une file d’attente. Masquez les entrées et sorties d’outils sensibles avant que les événements ne quittent votre processus.Choisir les événements pour une interface produit
Utilisezresponse.output_text.delta pour le texte de réponse en direct, les événements d’outils pour les cartes d’appels d’outils et les indicateurs de progression, run.waiting_for_human (Rust : run.paused) pour afficher les contrôles d’approbation ou de saisie, et les événements terminaux d’exécution pour fermer les états de chargement. Pour garder une trace locale d’exécutions complètes pendant le développement, utilisez DevTools.