Comment construire des agents GPT-6 Astra à longue durée avec état de conversation et compactage
Concevez des agents GPT-6 Astra durables en utilisant previous_response_id, Conversations, état explicite, budgets de contexte, compaction, points de contrôle et modèles de récupération.
Un agent à exécution longue n'est pas simplement un chatbot doté d'un transcript énorme. C'est un système avec état qui doit préserver les objectifs, le travail accompli, les résultats des outils, les permissions et les décisions non résolues tout en restant dans une fenêtre de contexte finie. GPT-6 Astra offre une fenêtre de contexte de 1 050 000 jetons, un support de raisonnement persistant, un état de conversation et une compaction—mais l'architecture détermine toujours si un flux de travail reste cohérent après des heures ou des jours.
Distinguer quatre types d'état
Traiter chaque événement comme un texte de conversation rend la récupération difficile. Maintenez des couches distinctes :
- État du dialogue : ce que l'utilisateur et le modèle ont dit.
- État de la tâche : objectifs, plan, contraintes, étapes terminées et obstacles.
- État du monde : enregistrements dans les bases de données, fichiers, tickets et autres systèmes externes.
- État d'exécution : identifiants d'appel d'outil, clés d'idempotence, approbations, tentatives et points de contrôle.
Seule la première couche appartient naturellement à une transcription. Les trois autres devraient avoir des représentations propres à l'application. Le modèle peut aider à les mettre à jour, mais il ne devrait pas être le seul système d'enregistrement.
Deux façons de poursuivre une réponse
Le mécanisme de continuation le plus simple est previous_response_id :
const first = await client.responses.create({
model: "gpt-6-astra",
input: "Rédiger un plan de mise en œuvre pour la migration."
});
const next = await client.responses.create({
model: "gpt-6-astra",
previous_response_id: first.id,
input: [{ role: "user", content: "Commencez par le module d'authentification." }]
});
Ceci crée une chaîne de réponses. C'est pratique pour une session, mais ce n'est pas un raccourci de facturation : OpenAI précise que les jetons d'entrée précédents dans la chaîne sont facturés comme entrée. Les réponses sont stockées pendant 30 jours par défaut, sauf si store: false est utilisé.
Pour des fils de discussion durables, utilisez l'API Conversations. Une conversation peut contenir des messages, des appels d'outils et des sorties d'outils, et peut être réutilisée entre sessions, appareils ou tâches. Les objets de conversation ne sont pas soumis au TTL de réponse de 30 jours. Une requête ne peut pas utiliser à la fois un conversation et un previous_response_id ; choisissez délibérément le modèle d'état.
Établissez un budget de contexte avant d'en avoir besoin
Le contexte inclut les tokens d'entrée, de sortie et de raisonnement. N'attendez pas que le modèle atteigne la limite. Réservez de l'espace pour le prochain résultat de l'outil et la réponse finale, puis compactez ou élaguez avant de franchir votre seuil.
Un budget utile peut allouer des pourcentages à :
- instructions et outils durables ;
- résumé de la tâche en cours ;
- détails de la conversation récente ;
- preuves récupérées ;
- raisonnement et résultat attendus ;
- une marge d'urgence pour les résultats inhabituellement volumineux des outils.
Un contexte important a également des implications sur la tarification. La page du modèle GPT-6 Astra documente un tarif plus élevé pour les demandes dont l’entrée dépasse 272 000 jetons, appliqué à l’ensemble de la demande. Ce seuil rend l’hygiène précoce du contexte financièrement importante, même lorsque la fenêtre complète est loin d’être épuisée.
Ce que fait la compaction
La compaction réduit le contexte antérieur tout en conservant les informations nécessaires pour les échanges futurs. OpenAI expose un point de terminaison explicite /responses/compact et une gestion automatique du contexte. Le matériel de compaction renvoyé est opaque : transmettez-le comme indiqué, sans l'analyser, le modifier ou le traiter comme un résumé destiné à l'utilisateur.
Compact aux étapes sémantiques :
- une fois la recherche synthétisée et l'exploration des sources brutes n'étant plus nécessaire ;
- après qu'une phase de code passe les tests ;
- après que l'utilisateur approuve un plan ;
- avant de commencer une nouvelle phase indépendante ;
- lorsque le contexte mesuré approche votre seuil prévu.
Évitez de compacter après chaque tour. Cela ajoute du travail, peut éliminer des détails locaux utiles et modifie le préfixe réutilisable de l'invite, ce qui peut affecter le comportement du cache d'invite.
const compacted = await client.responses.compact({
model: "gpt-6-astra",
input: accumulatedItems
});
// Persist the returned compacted items and use them as the base for later work.
Utilisez la référence SDK actuelle pour les types exacts ; les surfaces bêta et SDK peuvent évoluer. La règle durable est de préserver la sortie opaque inchangée.
Vérifiez le travail, pas seulement les mots
Un point de contrôle de production doit enregistrer :
- objectif visible par l'utilisateur et dernier périmètre accepté ;
- étapes complétées et preuves de vérification ;
- appels d'outils en attente et état d'approbation ;
- identifiants de ressources externes et versions ;
- décisions importantes avec provenance ;
- l'identifiant de la réponse ou de la conversation ;
- une version de point de contrôle monotone.
Supposons qu'un workflow d'animation ait approuvé un script, généré des références de personnages et commencé l'assemblage des scènes. L'agent doit stocker les identifiants des actifs, les approbations et l'état des scènes dans les données de l'application. Une plateforme telle que Elser AI est une destination naturelle pour les actifs créatifs, mais la couche d'orchestration a toujours besoin d'un état explicite pour qu'un agent repris ne régénère pas les scènes approuvées.
Récupération après interruption
Concevoir pour une exécution au moins une fois. Une connexion peut disparaître après qu'un outil a agi mais avant que le client n'ait reçu le résultat. Chaque outil modifiant l'état doit accepter une clé d'idempotence ou prendre en charge une vérification de lecture avant écriture. Lors de la reprise :
- charger le dernier point de contrôle validé ;
- inspecter l'état externe pour les opérations incertaines ;
- concilier les résultats des outils par appel ou par ID d'idempotence ;
- reconstruire le contexte à partir de l'état compacté plus les événements récents ;
- demander au modèle de continuer à partir d'un travail en attente explicite.
Ne dites jamais « continue » au modèle sans fournir un état structuré après un crash. Il pourrait répéter des actions ou déduire la mauvaise étape.
Garder la compaction et la mémoire métier séparées
La compaction est un contexte optimisé pour le modèle. La mémoire métier est un enregistrement durable et inspectable pour votre application. Tenez un journal de tâches concis et lisible par un humain en parallèle des éléments compactés opaques. Le journal permet aux opérateurs d'auditer les décisions, de migrer les modèles et de récupérer si une chaîne de réponses est indisponible.
Un bon registre contient des faits, pas une prose persuasive. Par exemple : « Le client a approuvé le plan v7 à 14:32 UTC » est plus fort que « Le client semblait satisfait du plan. » Stockez les identifiants sources pour les affirmations issues des outils.
Contrôles de qualité pour les longues sessions
Testez plus que la précision de la réponse finale. Mesurez :
- rétention de l'objectif après 20, 50 et 100 tours ;
- effets secondaires en double après des déconnexions injectées ;
- reprise correcte après compactage ;
- provenance du résultat de l'outil ;
- persistance et expiration de l’autorisation ;
- coût par étape clé ;
- dérive entre le registre des tâches et l'état externe.
Incluez des tests adverses où un ancien message entre en conflit avec une instruction plus récente, un outil renvoie une charge utile énorme, ou une approbation expire pendant que l'agent est en pause. La fiabilité à long terme concerne principalement les transitions.
FAQ
Dois-je utiliser Conversations ou previous_response_id ?
Utilisez previous_response_id pour un enchaînement simple de réponses. Utilisez une Conversation lorsque vous avez besoin d'un objet durable réutilisé entre sessions ou tâches. Ils ne peuvent pas être fournis ensemble dans la même requête.
Est-ce qu'une fenêtre d'un million de jetons élimine la compaction ?
Non. Le coût, la latence, la pertinence et le seuil de tarification documenté pour les longs contextes rendent la gestion du contexte utile avant la limite stricte.
Puis-je modifier le contenu compacté ?
Traitez les éléments compactés comme opaques. Conservez votre propre registre de tâches modifiable séparément.
Que change store: false ?
Cela désactive le stockage par défaut de la réponse. Votre application doit alors gérer explicitement l'état nécessaire et satisfaire ses propres exigences de conservation et de récupération.
Conclusion
Les agents durables GPT-6 Astra combinent la continuité conversationnelle gérée par API avec l'état des tâches et de l'exécution détenu par l'application. Enchaînez ou persistez les réponses délibérément, budgétez le contexte avant qu'il ne devienne coûteux, compactez aux étapes clés, préservez les éléments de compactage opaques, et rendez chaque action externe récupérable. Le résultat est un agent capable de reprendre le travail en toute sécurité—pas un simple agent qui se souvient d'une longue conversation.
