Modèle d’exécution
OpenAI exécute la boucle de l’agent, gère le contexte de la conversation et fournit les outils de délégation. CoreWeave fait tourner l’exécuteur ainsi que les programmes écrits par les agents. Votre application se charge du provisionnement de la sandbox, du transfert de fichiers et du nettoyage. Le coordinateur et ses sous-agents partagent une seule et même sandbox, ainsi qu’un même système de fichiers. Créer un sous-agent ne crée pas de sandbox CoreWeave distincte. Attribuez à chaque spécialiste ses propres fichiers de sortie et confiez la responsabilité du rapport final au coordinateur. Ces attributions de fichiers sont de simples conventions destinées à éviter les conflits d’écriture, et non des contrôles d’accès. Voir le guide multi-agent d’OpenAI.Prérequis
Avant d’exécuter l’exemple, vérifiez que vous remplissez les conditions suivantes :- Une clé API Forge, ou un jeton d’accès à l’API CoreWeave disposant de l’action
SANDBOX_USER, ainsi qu’une capacité suffisante pour une sandbox CPU. Suivez Choisir un identifiant d’authentification. - Un projet OpenAI ayant accès à l’API Agents et au modèle sélectionné.
- Python et
uv, dans les versions indiquées par le fichier de verrouillage de la recette associée. - Un accès HTTPS sortant vers
api.openai.comet un accès WebSocket sécurisé verscodex-cloud-environments.chatgpt.com. La configuration de l’image nécessite également l’accès aux registres de paquets utilisés pour installer l’exécuteur et les dépendances du runtime.
Séparer les identifiants d’authentification de l’application et de l’exécuteur
Cet exemple utilise trois identifiants d’authentification : un identifiant de sandbox et deux clés OpenAI. Chaque identifiant appartient à un seul composant, ce qui permet de tenir l’accès de l’application à l’écart de la sandbox :
Par défaut, la recette utilise l’authentification CoreWeave. Pour utiliser la clé API Forge, passez
--sandbox-auth wandb. Cette recette exige précisément le nom de variable d’environnement WANDB_API_KEY pour l’authentification Forge ; elle ne lit pas FORGE_API_KEY. Seul l’identifiant de sandbox sélectionné est requis, mais
les deux clés OpenAI sont nécessaires quel que soit le mode. L’application enregistre le mode
sélectionné afin que le nettoyage utilise les mêmes identifiants d’authentification du fournisseur.
La clé d’application OpenAI requiert api.agents.read, api.agents.write et
api.responses.write. Créez la clé d’environnement distincte dans
Agents > Environments > Keys.
Elle doit appartenir à la même organisation, au même projet et au même propriétaire (utilisateur ou compte de service)
que la session. Définissez les autorisations sans rapport sur None.
La recette transmet la clé restreinte de l’exécuteur via l’argument environment_variables
du SDK. Elle ne configure aucun magasin de secrets.
Ne téléversez que les entrées de la tâche. Conservez les identifiants d’authentification de l’application, la configuration locale et
le vérificateur hors de la sandbox. Suivez les
instructions d’authentification d’OpenAI.
Connecter une session d’agent
La recette exécutable met en œuvre ces étapes avec les SDK OpenAI et CoreWeave :- Créez une session API Agents auto-hébergée, puis enregistrez son ID de session et son ID
d’environnement. Au démarrage de l’exécuteur, utilisez exactement le
remote_urlrenvoyé. - Créez une sandbox CoreWeave dotée d’une durée de vie maximale explicite, ainsi que de Python et de Node.
- Démarrez
codex exec-serveravec l’ID d’environnement renvoyé et l’URL distante telle quelle. Injectez uniquement la clé restreinte de l’exécuteur en tant queCODEX_API_KEY. - Téléversez les entrées synthétiques et les instructions de la tâche, puis vérifiez la connexion à l’environnement. Soumettez la tâche et observez son résultat.
- Avant le nettoyage, récupérez les artifacts générés et les enregistrements d’activité de l’API.
client.beta.agents.sessions.create() :
--require-exit-codes exige, pour chaque spécialiste, une preuve numérique d’un code de sortie nul.
Le chevauchement des intervalles started_at et completed_at révèle des tours
de sous-agents simultanés. Ces horodatages n’étant précis qu’à la seconde, ils
ne prouvent ni l’exécution simultanée de processus shell ni un gain de vitesse par rapport à un run séquentiel.
Exécuter l’exemple
Suivez les étapes de configuration et d’exécution de la recette. La recette comprend des données synthétiques originales, une spécification de tâche, l’application et un vérificateur indépendant. Examinez le rapport téléchargé en regard des constats du vérificateur. Vous pouvez également examiner les tours de la session et les appels d’outils dans OpenAI Logs > Agents tant que la session existe. Sélectionnez l’organisation et le projet correspondants. Cet exemple ne fournit pas d’interface de discussion et n’assure pas de continuité avec les applications ChatGPT ou Codex. Pour un flux de travail existant basé sur une interface de ligne de commande (CLI), consultez OpenAI Agents API in cws-agent. La recette utilise directement les SDK et ne nécessite pas cette CLI.Durées de vie de la session, de la sandbox et des fichiers
Gérez séparément la conversation, les ressources de calcul et les fichiers du workspace lorsque vous choisissez ce que vous souhaitez conserver.
Définissez explicitement la durée de vie des ressources de calcul. La recette fixe une durée de vie maximale
de 20 minutes. Cette durée de vie maximale est un plafond, et non un délai d’inactivité réinitialisé à chaque
prompt.
Lorsque vous reconnectez un exécuteur à la même sandbox en cours d’exécution, son workspace est conservé. En revanche, démarrer
de nouvelles ressources de calcul avec le même ID d’environnement ne restaure pas ses fichiers.
Téléchargez les artifacts ou utilisez les fonctionnalités de persistance de CoreWeave avant d’arrêter les ressources de calcul.
La recette télécharge les artifacts, puis supprime ses ressources. Elle n’implémente
ni récupération automatique, ni mécanisme d’instantané et de restauration.
L’arrêt d’une sandbox ne supprime pas sa conversation API, et la suppression de la conversation
n’arrête pas la sandbox. Lancez les deux opérations de nettoyage et signalez chaque échec séparément.
Gérer les échecs
Pour diagnostiquer les échecs, suivez les recommandations ci-dessous :- L’exécuteur ne se connecte jamais : vérifiez la propriété de la clé d’environnement, l’accès réseau sortant, la compatibilité de l’exécuteur et l’URL distante exacte renvoyée par OpenAI.
- OpenAI signale une limite d’utilisation ou de facturation : vérifiez les limites de facturation de l’organisation et du projet OpenAI avant toute nouvelle tentative. Une connexion de l’exécuteur ne garantit pas à elle seule qu’un tour de conversation du modèle puisse s’exécuter.
- Le flux se déconnecte ou le client expire : examinez l’état de la session et les événements enregistrés avant de renvoyer une entrée. Un délai d’expiration n’annule pas en soi le travail en cours dans le cloud.
- Aucune délégation ni aucun chevauchement n’est observé : consultez les traces d’activité enregistrées. Un rapport correct ne suffit pas à prouver l’exécution d’un run multi-agent en parallèle.
- L’environnement OpenAI expire : examinez son état avant toute nouvelle tentative. La recette peut attendre l’échéance de son travail plutôt que d’échouer immédiatement.
- Le sandbox expire : récupérez les artifacts enregistrés, s’ils sont disponibles. Un sandbox de remplacement nécessite une politique explicite de restauration des fichiers.
- L’application est interrompue : utilisez le journal des ressources enregistré et la commande de nettoyage de la recette. La durée de vie maximale du sandbox est une solution de repli : elle ne remplace pas la suppression de la session de l’API.