Vous demandez à un assistant de vérifier les commandes clavier, puis réalisez que la prochaine version doit être tactile. La réorientation de GPT-6 Astra pendant une tâche vise ce type de changement. Une intégration compatible peut modifier la suite du travail, mais pas effacer une modification terminée ni un appel d'outil déjà envoyé.
Ce guide repose sur la documentation. Les exemples proposent des conceptions d'applications ; ce ne sont pas des démonstrations exécutées avec un compte API payant.
Lecture rapide
Points clés
- Une nouvelle exigence n'annule pas une action terminée.
- Suivez séparément le travail prévu, en cours et achevé.
- Vérifiez l'autorisation lorsque l'action ou sa destination change.
Ce que modifie la réorientation en cours de tâche
La documentation officielle de réorientation décrit le support de GPT-6 Astra par connexion WebSocket à la Responses API. Elle distingue réorientation et annulation : les sorties livrées ne sont pas réécrites et les outils démarrés ne sont pas automatiquement interrompus.
L'interface doit traduire cette distinction. « Changer l'exigence » et « Arrêter l'opération » doivent avoir des sens différents. Si la destination change pendant une écriture externe, l'application ne peut pas supposer que cette écriture n'a jamais eu lieu.
Un bon message indique ce qui reste en attente et ce qui est terminé. « La nouvelle exigence s'appliquera au prochain travail » est plus clair qu'un remplacement silencieux de la demande qui oblige l'utilisateur à deviner les instructions appliquées à la dernière action.
Suivre l'ordre des événements
Le streaming affiche les sorties à leur arrivée. La réorientation change les instructions du travail à venir. Un produit peut proposer l'un sans exposer l'autre.
Dans le flux WebSocket documenté, envoyez response.create et attendez response.created. Sur la même connexion, envoyez response.steer avec l'identifiant de réponse dans previous_response_id et la nouvelle instruction dans input. response.steer.accepted confirme la mise en file de l'actualisation, pas l'achèvement du travail révisé. Si des résultats d'outils ou autorisations manquent, response.steer.pending les signale. Suivez la continuation séparément de la réponse d'origine.
Un message de suivi après la fin ne correspond pas non plus à une modification pendant une réponse active. Distinguez ces parcours dans les journaux pour reconstituer correctement la tâche.
Le guide de GPT-6 Astra présente cette réorientation parmi les nouvelles fonctions de travail du modèle. Cela ne signifie pas que tous les chats ou outils tiers gèrent les événements requis. Vérifiez l'interface utilisée, pas seulement le nom du modèle.
Dans l'application, séparez « mise à jour reçue » de « nouveau travail terminé ». Affichez l'exigence actuelle à côté de l'opération encore active. Il s'agit d'une recommandation de conception, pas de l'affirmation que l'API fournit un tableau de bord complet.
Préserver le travail utile dans la nouvelle consigne
Une bonne actualisation précise ce qui change, ce qui reste et ce qui ne doit pas se produire ensuite.
Par exemple : « Conserve la mise en page de bureau. Concentre la prochaine itération sur le tactile. Ne publie pas et ne remplace pas la version actuelle. » Vous préservez le contexte utile tout en limitant la prochaine action.
« Fais autrement » oblige l'assistant à deviner s'il faut changer d'objectif, revoir le visuel ou s'arrêter. L'interface peut aider en affichant l'objectif actif et en permettant de modifier une exigence concrète.
Si la nouvelle consigne contredit un travail terminé, signalez explicitement le conflit. Une correction reste une nouvelle action, avec son périmètre et ses conséquences.
Supposons qu'un assistant examine le clavier d'un prototype lorsqu'un besoin mobile apparaît. La bonne consigne est « garde l'objectif de jeu, examine ensuite le tactile et ne modifie pas le clavier existant », plutôt que « recommence tout ».
Les observations précédentes peuvent rester utiles. Les nouveaux tests devraient couvrir les zones tactiles, les répétitions accidentelles, les changements d'orientation et la cohérence du retour pour une même action. Ce sont des contrôles suggérés, pas des mesures de performance d'Astra.
Pour préciser le besoin, essayez des jeux d'arcade et observez comment sont signalés les appuis, les pressions maintenues et les actions répétées rapidement. Utilisez ces observations pour la prochaine revue, sans déduire quel modèle a produit ces jeux, ni même si un modèle a été utilisé.
| Élément de la consigne | Exemple d'exigence |
|---|---|
| Conserver | Maintenir le clavier et l'objectif de jeu. |
| Modifier | Examiner ensuite les zones tactiles et les appuis répétés. |
| Limiter | Ne pas modifier, téléverser ou publier la version actuelle. |
| Rapporter | Indiquer les conclusions précédentes encore valables. |
Un modèle d'état pour les exigences changeantes
Distinguez le travail prévu, en cours et terminé dans les enregistrements de l'application.
Ce tableau facilite la conception ; il ne remplace pas la référence des événements API. Il évite de traiter toute tâche comme un paragraphe modifiable.
Rattachez chaque résultat d'outil à son opération d'origine. Un résultat tardif ne doit pas être pris pour une preuve obtenue sous les nouvelles exigences. Même périmé et inutilisable pour la prochaine décision, il peut devoir être conservé.
Imaginez une lecture lancée sous l'exigence A, puis l'arrivée de B, puis le retour de cette lecture. Enregistrez le résultat sous A et décidez s'il répond aussi à B. Ne le rebaptisez pas nouveau contrôle : une observation sur le clavier ne prouve pas le fonctionnement du tactile.
| État | Exemple | Réaction au changement |
|---|---|---|
| Prévu | La modification proposée n'a pas commencé | La réévaluer selon la nouvelle exigence |
| En cours | Un appel d'outil a été envoyé | Suivre le résultat et vérifier son utilité |
| Terminé | Un fichier a changé ou une sortie a été livrée | Rapporter l'effet et corriger par une action distincte si nécessaire |
Contrôler les modifications dans l'application
Le modèle ne doit pas être l'unique protection entre une consigne ambiguë et une opération importante. L'application peut garder une file d'écritures proposées, exiger une autorisation pour les étapes à fort impact et vérifier qu'elle correspond encore à la tâche actuelle.
Si un utilisateur autorise l'envoi d'un brouillon puis change de projet cible, l'accord ne doit pas être transféré silencieusement. Vérifiez à nouveau la destination et le contenu.
Cela vaut aussi pour les messages externes, achats, suppressions et déploiements. La réorientation aide à comprendre l'objectif révisé ; elle ne fournit ni système transactionnel ni garantie de retour arrière.
Pour une lecture, un résultat tardif entraîne généralement du travail perdu ou de la confusion. Pour une écriture, il peut modifier un état réel. Concevez et testez ces cas séparément.
Tester les changements aux moments délicats
Les cas suivants constituent un plan de tests d'intégration proposé. Ils n'ont pas été exécutés pour cet article.
Définissez pour chaque cas le statut visible, la possibilité de commencer une nouvelle action et l'enregistrement de la fin. Jugez la cohérence du comportement, pas seulement l'accusé de réception du modèle.
- L'actualisation arrive avant le lancement d'un outil.
- Elle arrive pendant un outil en lecture seule.
- Elle arrive pendant une écriture déjà lancée.
- Deux actualisations contiennent des exigences contradictoires.
- La connexion coupe avant l'affichage de la confirmation.
- Un résultat tardif appartient à une ancienne version de la tâche.
Rendre la prochaine action visible
Une expérience fiable montre l'objectif actuel, le travail terminé et la prochaine action qui attend une autorisation. L'utilisateur ne devrait pas devoir les déduire d'un long historique.
Le bénéfice pratique est de réduire les reprises évitables, pas d'offrir une autonomie illimitée. Gardez des changements vérifiables et un compte rendu fidèle des faits.
Pour un nouveau cahier des charges d'interaction, explorez la bibliothèque de jeux et choisissez un comportement à examiner. Limitez l'exercice pour pouvoir préciser tout changement : ce qui reste, ce qui change et ce qui attend un accord.
Sources et lectures complémentaires
- Documentation officielle de réorientation
Événements WebSocket et limites consultés le 14 septembre 2026. Les exemples sont des conceptions proposées, pas des tests exécutés.
- Guide de GPT-6 Astra
Contexte des fonctions du modèle, sans preuve de support dans chaque application ou compte.
Étape suivante
