For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navigation principale

Observabilité et utilisation

Consultez la progression en temps réel, le travail effectué et la consommation de tokens enregistrée.

Suivez l’activité des agents en temps réel, examinez le travail effectué et consultez les traces détaillées des tours :

  1. Vous pouvez consulter les journaux de session dans le tableau de bord de la plateforme.
  2. Vous pouvez suivre la session grâce à ses événements et à son historique enregistré.
  3. Vous pouvez examiner les tours et identifier les exécutions de commandes déléguées.
  4. Vous pouvez consulter la consommation de tokens enregistrée pour les tours de l’agent racine et des sous-agents.

Consultez la session dans le tableau de bord

Accédez à platform.openai.com/logs?api=agents et ouvrez l’onglet Agents .

Recherchez une session par son identifiant pour examiner ses tours, ses appels d’outils et ses sous-agents.

Utilisez le guide du traçage pour examiner les réponses enregistrées du modèle, les appels d’outils et l’activité des sous-agents dans le tableau de bord, ou exportez les traces de session au format OTLP JSON via l’API publique.

Suivez les événements et consultez l’historique de la session

Chaque session fournit un flux d’événements qui montre ce que fait l’agent en temps réel. Définissez OPENAI_API_KEY et remplacez l’identifiant de session fourni à titre d’exemple par celui de votre session enregistrée :

Suivez les événements de la session en temps réel
// Replace the illustrative IDs and URLs below with your own resource values.
import OpenAI from "openai";

const client = new OpenAI();
const events = await client.beta.agents.sessions.events.stream("sess_123");
try {
  for await (const event of events) {
    if (
      [
        "agent.session.turn.failed",
        "agent.session.turn.cancelled",
        "agent.session.failed",
        "agent.session.environment.failed",
        "error",
      ].includes(event.type)
    ) {
      throw new Error(`Agent lifecycle failure: ${event.type}`);
    }
    console.log(JSON.stringify(event));
  }
} finally {
  events.controller.abort();
}

Le flux reste ouvert même lors des événements d’inactivité pour que vous ne manquiez pas le travail en attente. Appuyez sur Ctrl+C pour arrêter le suivi.

Au fil de l’exécution de la session, vous verrez des événements tels que :

agent.session.environment.connected
agent.session.turn.created
agent.session.turn.in_progress
agent.session.turn.item.added
agent.session.turn.output_text.delta
agent.session.turn.completed
agent.session.idle

Pour examiner le travail déjà effectué, récupérez les éléments enregistrés de la session :

Examinez les éléments enregistrés de la session
// Replace the illustrative IDs and URLs below with your own resource values.
import OpenAI from "openai";
const client = new OpenAI();

const sessionId = "sess_123";
const items = await client.beta.agents.sessions.items.list(sessionId, {
  order: "asc",
  limit: 100,
});
console.log(items.data);

Examinez les tours et identifiez les commandes déléguées

Les tours de session sont accessibles via l’API publique. Utilisez le champ turn_id d’un élément de commande avec l’identifiant de votre session enregistrée. L’exemple cURL nécessite jq :

Identifiez les exécutions de commandes déléguées
// Replace the illustrative IDs and URLs below with your own resource values.
import OpenAI from "openai";
const client = new OpenAI();

const sessionId = "sess_123";
const turns = await client.beta.agents.sessions.turns.list(sessionId, {
  limit: 20,
  order: "desc",
});
console.log(turns.data);
const turnId = "turn_123";
const turn = await client.beta.agents.sessions.turns.retrieve(turnId, {
  session_id: sessionId,
});
console.log(turn.subagent_id);

Utilisez la valeur last_id renvoyée comme valeur de after pour la page suivante lorsque has_more vaut true.

Les éléments de commande contiennent turn_id. Récupérez le tour correspondant et consultez subagent_id pour identifier l’agent délégué qui a exécuté la commande. Un identifiant de sous-agent égal à null indique un travail effectué par l’agent racine. La troncature de la sortie des commandes n’est pas signalée.

Examinez la trace d’un tour

Utilisez le tableau de bord de la plateforme pour examiner un tour terminé et l’activité de l’agent au cours de ce tour. Pour récupérer les traces enregistrées via l’API publique, utilisez le point de terminaison d’exportation des traces de session avec une clé API de projet. Les points de terminaison de traçage du tableau de bord restent distincts de l’API prise en charge pour les clients.

Les ressources de tour incluent un champ usage renseigné au mieux selon les données disponibles, ainsi qu’un champ subagent_id qui identifie le travail délégué. La consommation peut valoir null lorsqu’elle est inconnue et peut évoluer. Consultez la section Examinez la consommation de tokens des sous-agents.

Pour déterminer quel agent a exécuté une commande shell, récupérez le tour identifié par le champ turn_id de l’élément de commande, puis consultez turn.subagent_id. L’API destinée aux clients n’indique pas si la sortie de la commande a été tronquée.

Utilisation des modèles et coût

Un agent peut effectuer plusieurs appels de modèle pour accomplir une tâche. Chaque appel suit la tarification des tokens et les règles de mise en cache des prompts du modèle, comme dans l’API Responses. Estimez le coût en tenant compte de tous les appels nécessaires à l’accomplissement de la tâche.

Quels éléments contribuent au coût ?

Chaque appel de modèle peut consommer :

  • Tokens d’entrée : instructions de l’agent, définitions des outils, historique de la conversation, saisie de l’utilisateur, fichiers ou images et résultats des outils.
  • Tokens d’entrée en cache : données d’entrée réutilisées à partir d’un préfixe de prompt identique, facturées au tarif du modèle pour les entrées en cache.
  • Tokens de sortie : texte généré, arguments des appels d’outils et raisonnement.

Les tokens de raisonnement sont facturés comme des tokens de sortie.

Les sous-agents peuvent également effectuer des appels de modèle. Lorsque vous analysez les coûts des modèles, examinez leur consommation enregistrée par tour ainsi que le travail de l’agent racine.

Tenez compte du travail de l’agent racine et des sous-agents, y compris des nouvelles tentatives, ainsi que des éventuels frais liés aux outils, au calcul dans le bac à sable et aux services tiers. Pour les modèles qui facturent l’écriture en cache, l’écriture des données d’entrée dans le cache a également un coût. Les champs de consommation de l’API Agents ci-dessous ne fournissent pas de décompte distinct des écritures en cache. Ils ne permettent donc pas de déterminer le montant exact facturé pour le modèle lorsque cette tarification s’applique.

Mise en cache des prompts

Les agents conservent le contexte au fil d’une session. Lorsque des appels de modèle successifs partagent le même préfixe de prompt, la mise en cache des prompts permet de réutiliser le traitement déjà effectué sur ce préfixe. Le modèle génère une nouvelle réponse ; le cache ne renvoie pas une ancienne réponse. Le maintien d’une session ne garantit pas l’utilisation du cache. La réutilisation dépend de la présence d’un préfixe identique, ainsi que des règles d’éligibilité à la mise en cache et de durée de vie du cache propres au modèle.

Dans la mesure du possible, gardez les instructions initiales et les définitions des outils stables, et ajoutez les nouvelles précisions sur la tâche dans les messages suivants. Avec la recherche d’outils, les définitions découvertes sont ajoutées à la fin de la conversation, ce qui préserve le contenu antérieur pour sa réutilisation depuis le cache. Consultez la section Mise en cache des prompts pour connaître les règles propres à chaque modèle.

Un pourcentage élevé de tokens d’entrée en cache ne mesure pas les économies réalisées sur le coût total de la tâche. Les entrées en cache restent facturées, et les appels répétés peuvent traiter un historique volumineux. Comparez le coût d’exécution d’une même tâche avec les niveaux de qualité et de latence dont votre application a besoin.

Comprenez la consommation de tokens

Les ressources de session et de tour fournissent un champ usage renseigné au mieux selon les données disponibles. Il peut valoir null lorsque la consommation est inconnue, et les décomptes enregistrés peuvent évoluer à mesure que les données de comptabilisation arrivent. L’absence de données de consommation ne signifie pas une consommation nulle. Ces décomptes ne constituent pas une facture définitive.

Un objet de consommation enregistré contient les catégories de tokens suivantes :

{
  "input_tokens": 5000,
  "input_tokens_details": {
    "cached_tokens": 1500
  },
  "output_tokens": 900,
  "output_tokens_details": {
    "reasoning_tokens": 200
  },
  "total_tokens": 5900
}

Dans cet exemple, l’agent a traité 5 000 tokens d’entrée et généré 900 tokens de sortie. Parmi les tokens d’entrée, 1 500 étaient en cache. Parmi les tokens de sortie, 200 étaient des tokens de raisonnement.

Les tokens en cache sont inclus dans input_tokens, et les tokens de raisonnement sont inclus dans output_tokens.

Examinez la consommation de tokens des sous-agents

Listez ou récupérez les tours de session et examinez le champ usage de chaque tour. Le champ subagent_id identifie le sous-agent ; il vaut null pour les tours de l’agent racine. Lorsque has_more vaut true, transmettez last_id comme valeur de after, en conservant la même valeur de order, pour lire les tours restants.

La consommation est renseignée au mieux selon les données disponibles : elle peut valoir null lorsqu’elle est inconnue, et les valeurs enregistrées peuvent évoluer. Vous pouvez également consulter la consommation enregistrée de chaque agent dans le tableau de bord de traçage.