GPT-6 Astra Mid-Turn Steering expliqué : Mettre à jour un agent pendant qu'il travaille
Comprendre le pilotage en cours de tour de GPT-6 Astra via WebSocket : événements acceptés, en attente, échoués et dirigés, attentes d'outils, points de validation, récupération et conception UX.
｜ Source: Elser AI
Les exécutions longues d'agents créent un problème UX : l'utilisateur remarque une hypothèse erronée mais doit attendre la fin avant de la corriger. Le pilotage en cours de réponse de GPT-6 Astra permet à un client d'envoyer une nouvelle entrée utilisateur pendant qu'une réponse est active. Le serveur passe de la réponse actuelle à une réponse successeur qui intègre la mise à jour.
Ceci n'est pas une simple continuation de chat ni une annulation avec une nouvelle requête. Il s'agit d'un protocole WebSocket avec accusés de réception, points de validation et règles de récupération.
Exigences et limites
Les documents OpenAI orientent le mode WebSocket de l'API Responses. Un client envoie un événement response.steer contenant :
type : "response.steer";previous_response_id, identifiant la réponse active ;input, contenant les messages du rôle utilisateur.
L'entrée peut inclure du texte, une image ou un fichier. N'ajoutez pas de stream_id non documenté. Le pilotage s'applique actuellement aux modes standard à agent unique pris en charge. Les réponses liées à la conversation et la compaction automatique ne le prennent pas en charge, choisissez donc entre ces capacités lors de la conception de l'architecture plutôt que de découvrir le conflit en production.
{ "type": "response.steer", "previous_response_id": "resp_active", "input": [{ "role": "utilisateur", "content": "Utilisez la version de la politique de l'UE, pas la version américaine." }] }
## Comprendre le cycle de vie
`response.steer.accepted` signifie que le serveur a accepté la responsabilité de l'entrée de direction. Ce n'est pas encore le point final d'engagement. L'événement successeur `response.created` est l'engagement : persistez son ID de réponse et associez l'entrée de direction à ce successeur.
La réponse active peut alors se terminer comme incomplète avec `incomplete_details.reason: "steered"`. Il s'agit d'un flux de contrôle attendu, et non d'un échec de l'application. Le successeur continue avec la mise à jour.
D'autres événements comptent :
- `response.steer.pending` : la mise à jour est en file d'attente car la réponse actuelle attend un travail appartenant au client ;
- `response.steer.failed` : le serveur n'a pas pu appliquer la mise à jour ;
- aucun accusé de réception avant la déconnexion : le résultat est inconnu.
Construisez une petite machine à états au lieu de traiter ces notifications comme indépendantes.
## Diriger pendant qu'un outil est en cours d'exécution
Si la réponse attend la sortie d'un outil client ou une approbation, la commande peut rester en attente. Le serveur ne peut pas inventer en toute sécurité le résultat manquant. Terminez le protocole requis à l'aide de souches appropriées et de résultats préservés, et ne réexécutez pas un outil simplement parce qu'une commande a eu lieu.
Exemple : un utilisateur oriente « ne pas envoyer l’e-mail » alors qu’une invite d’approbation est ouverte. Refusez l’approbation et appliquez la mise à jour d’orientation. Si l’outil de messagerie a déjà exécuté l’action et que l’accusé de réception a été perdu, commencez par réconcilier le système de messagerie. L’orientation ne peut pas annuler un effet secondaire.
## Machine d'état client
Un client robuste assure le suivi :
1. ID de réponse active ;
2. ID du message de direction et statut local ;
3. si `accepted` est arrivé ;
4. si un `response.created` successeur l'a commis ;
5. appels d'outils en attente et approbations ;
6. statut final de la réponse originale ;
7. dernier curseur d'événement durable ou point de contrôle d'application.
Désactiver la soumission répétée dans l'interface utilisateur tout en permettant toujours à l'utilisateur de modifier ou de remplacer une mise à jour en file d'attente selon vos propres règles. Afficher « Application de votre mise à jour » plutôt que de prétendre que la première réponse s'est arrêtée instantanément.
## Récupération après déconnexions
Trois cas nécessitent un traitement différent :
- **Aucun événement accepté :** le résultat est incertain. Reconnectez-vous, inspectez l'état de réponse disponible et évitez de renvoyer aveuglément une commande qui pourrait être appliquée deux fois.
- **Accepté, aucun successeur observé :** le serveur possède l’entrée, mais le client ne dispose pas de l’événement de validation. Récupérez la chaîne de réponse avant de soumettre à nouveau.
- **Successeur créé :** conservez cet ID et continuez à partir de celui-ci.
Donnez des identifiants générés par le client aux entrées de direction dans votre base de données, même si le schéma filaire ne les utilise pas comme champs de protocole. Cela permet de dédupliquer les actions de l'interface utilisateur et d'auditer ce que l'utilisateur a modifié.
## Cas d'utilisation bons et mauvais
La direction est excellente pour changer de portée, corriger une source, affiner une recherche, ajouter une contrainte manquante ou modifier le résultat souhaité pendant que la recherche est encore en cours.
Ce n’est pas un substitut à l’approbation, à l’annulation de transaction, aux vérifications d’autorisation ou à l’annulation déterministe. N’utilisez pas le pilotage pour autoriser un paiement ou pour supposer qu’une action externe déjà en cours s’est arrêtée.
## Testez les transitions maladroites
Simuler la direction pendant la génération de texte, l'exécution d'outils hébergés, les attentes d'outils clients, les attentes d'approbation, immédiatement avant la fin, et pendant une perte de réseau. Vérifier que les outils ne sont pas dupliqués, que les entrées acceptées ne sont pas perdues silencieusement, et que l'interface utilisateur attribue la sortie à la réponse correcte.
Mesurez la latence d'acceptation du guidage, la durée en attente, la latence de création du successeur, le statut de la réponse originale, les actions d'outil dupliquées et l'abandon par l'utilisateur. Ces métriques révèlent si le guidage améliore réellement l'expérience.
## Concevez l'expérience utilisateur autour de la propriété
L'interface doit distinguer trois moments. « Envoi de la mise à jour » signifie que le client l'a transmise mais n'a pas reçu d'accusé de réception. « Mise à jour acceptée » signifie que le serveur la possède. « Poursuite avec la mise à jour » signifie que la réponse du successeur a été créée. Ces libellés rendent une rare ambiguïté réseau compréhensible sans exposer le jargon du protocole.
Conservez la sortie visible déjà produite par la réponse originale, mais marquez-la comme remplacée si la correction l'invalide. La supprimer peut dérouter les utilisateurs qui ont agi en fonction de ce qu'ils ont vu ; la présenter comme définitive peut être pire. Pour un travail sensible à l'audit, conservez les deux branches et montrez quel successeur est devenu faisant autorité.
Débouncez les modifications rapides avec réflexion. Deux messages de pilotage — « utiliser la France » puis immédiatement « utiliser l’Allemagne » — peuvent tous deux être acceptés dans l’ordre. Si votre produit ne souhaite que la dernière instruction, mettez en œuvre une politique côté client et communiquez-la ; ne supposez pas que le protocole réduit silencieusement les mises à jour.
Pour l'accessibilité, annoncez les changements d'état sans relire intégralement la réponse générée. Permettez aux utilisateurs de clavier d'atteindre l'entrée de guidage pendant que la génération se poursuit, et conservez une commande d'arrêt claire. Un bon guidage relève autant du design d'interaction que de la maniabilité du transport.
## FAQ
### Est-ce que diriger est la même chose qu'envoyer un autre message ?
Non. Cela met à jour une réponse WebSocket active et crée un flux successeur.
### Est-ce que `accepted` signifie que la mise à jour est entièrement appliquée ?
Non. Traitez le successeur `response.created` comme le point de validation.
### Le fait de diriger peut-il annuler une action d'outil externe ?
Pas de manière fiable. L'annulation des outils et la réconciliation des effets secondaires sont des responsabilités distinctes de l'application.
### Puis-je utiliser le compactage automatique avec le guidage ?
Le guide officiel de direction indique que la compaction automatique n'est pas prise en charge pour les réponses dirigées. Concevez une stratégie de contexte explicite.
## Conclusion
Le guidage en cours de virage rend le travail long de GPT-6 Astra réactif, mais uniquement lorsque le client respecte son protocole. Suivez les événements acceptés, en attente, échoués, incomplets et successeurs ; conservez les résultats des outils ; réconciliez les effets secondaires incertains ; et exposez un état d'interface utilisateur honnête. Le guidage modifie la direction de l'agent — il n'efface pas la réalité des systèmes distribués.
