Passer au contenu principal
Le SDK Python AgentEye vous offre une visibilité complète sur le comportement de vos agents (chaque exécution d’agent, appel d’outil, requête de modèle, hook et intervention humaine), afin de vous permettre de déboguer, auditer et évaluer vos agents. Il instrumente votre code d’agent en écrivant des événements structurés dans des fichiers JSONL locaux ; le démon collecteur les récupère et les transmet automatiquement à la plateforme.

Installation

Téléchargez le wheel depuis GitHub Releases en utilisant votre AGENTEYE_TOKEN. Si vous ne disposez pas encore d’un token, consultez Configuration du token GitHub pour les étapes de configuration et les permissions requises. Via gh CLI + pip :
Via gh CLI + uv :
Via curl (sans gh CLI) :

Démarrage rapide


configure()

À appeler une seule fois avant tout appel event.*. Sans obligation ; les valeurs par défaut fonctionnent directement. Tous les arguments sont uniquement nommés ; passez-les par nom comme indiqué ci-dessus. Lorsque base_dir vaut None (valeur par défaut), le SDK lit $AGENTEYE_HOME si cette variable est définie, sinon il utilise ~/.agenteye. Ce comportement correspond à la résolution propre au collecteur, de sorte qu’une seule variable d’environnement AGENTEYE_HOME configure le spool d’événements partagé pour le SDK et le collecteur — requis pour les déploiements en sidecar ou en pod unique où les deux processus doivent s’entendre sur le chemin du spool.

Environnement

Étiquetez chaque événement avec un environnement de déploiement (production, staging, qa, canary, etc.). Définissez-le une seule fois ; le SDK l’associe automatiquement à chaque événement. Option 1 : via configure() :
Option 2 : via une variable d’environnement :
Priorité : configure(environment=...) est prioritaire sur la variable d’environnement. Si aucun des deux n’est défini, la valeur par défaut est "dev". La valeur d’environnement apparaît comme filtre de premier ordre dans le tableau de bord et est stockée en tant que colonne indexée sur le serveur pour des requêtes rapides. Contrainte : les valeurs d’environnement ne doivent pas contenir de virgule , littérale. Les filtres du tableau de bord utilisent une sélection multiple séparée par des virgules dans l’URL (?environment=prod,staging), de sorte qu’un environnement nommé prod,blue serait divisé en deux valeurs. Les événements dont l’environnement contient une virgule sont rejetés à l’ingestion.

Référence des événements

Toutes les méthodes d’événement requièrent ces deux champs :
ChampTypeDescription
session_idstrIdentifie l’exécution de l’agent de niveau supérieur
agent_idstrIdentifie l’agent au sein de la session qui a émis l’événement
Toutes les méthodes acceptent également des **kwargs arbitraires pour des métadonnées personnalisées (voir Champs personnalisés).

event.agent_start()

Émis lorsqu’un agent commence à travailler.

event.agent_end()

Émis lorsqu’un agent termine son travail.

event.tool_use()

Émis lorsqu’un agent invoque un outil. À associer avec tool_result ; le SDK calcule automatiquement duration_ms.

event.tool_result()

Émis lorsqu’un outil retourne un résultat. Se corrèle avec tool_use via tool_call_id.

event.model_request()

Émis juste avant l’envoi d’un prompt à un LLM.
Les entrées de messages acceptent soit un content sous forme de chaîne simple, soit un content sous forme de liste de blocs au style Anthropic. Les paramètres d’échantillonnage (temperature, max_tokens, etc.) peuvent être passés en kwargs supplémentaires.

event.model_response()

Émis lorsque le LLM retourne une réponse.
content accepte soit une chaîne simple (fournisseurs génériques), soit une liste de blocs de contenu au style Anthropic. Les appels d’outils se trouvent dans content sous forme de blocs {"type": "tool_use", ...}, sans champ tool_calls séparé.

event.hook_triggered()

Émis lorsqu’un hook se déclenche. À associer avec hook_completed ; le SDK calcule automatiquement duration_ms.

event.hook_completed()

Émis lorsqu’un hook se termine. Se corrèle avec hook_triggered via hook_id.

event.error()

Émis lorsqu’une erreur non gérée survient.

Événements humain dans la boucle

Les événements humain dans la boucle vous permettent de superviser les moments où une personne intervient dans l’exécution de l’agent (en attendant une approbation, en fournissant une entrée, en mettant en pause ou en arrêtant l’agent). Ils vous permettent de mesurer le temps de réponse des humains (le SDK calcule automatiquement duration_ms sur les événements appariés), d’auditer qui a mis en pause ou interrompu un agent, et de construire des workflows d’approbation et de supervision qui apparaissent dans le tableau de bord.

event.human_wait()

Émis lorsque l’agent suspend son exécution pour attendre une entrée humaine. À associer avec human_input ; le SDK calcule automatiquement duration_ms (le temps que l’humain a mis pour répondre).

event.human_input()

Émis lorsqu’un humain fournit une entrée et que l’agent reprend son exécution. Se corrèle avec human_wait via input_id. duration_ms est calculé automatiquement et ne doit pas être passé par l’appelant.

event.human_pause()

Émis lorsqu’un humain met activement l’agent en pause (par exemple via un contrôle du tableau de bord). L’agent est suspendu mais pas arrêté.

event.human_interrupt()

Émis lorsqu’un humain arrête activement l’agent en cours d’exécution. Contrairement à human_pause, le travail de l’agent est terminé plutôt que suspendu.

Champs personnalisés

Tout argument nommé supplémentaire est ajouté à l’événement après les champs standard :
timestamp, type et environment sont réservés et lèvent une ValueError (Reserved field names cannot be used as custom fields: [...]) s’ils sont passés comme champs personnalisés. session_id et agent_id sont des paramètres obligatoires sur chaque méthode d’événement et ne peuvent pas être fournis une seconde fois ; Python lève une TypeError si vous le faites. Définissez l’environnement avec configure(environment=...) (ou la variable AGENTEYE_ENVIRONMENT) à la place.

Comment les événements sont écrits

Les événements sont mis en mémoire tampon dans le processus et vidés sur disque toutes les flush_interval secondes (500 ms par défaut). Chaque vidage écrit un fichier JSONL :
Le collecteur surveille ce répertoire et télécharge les fichiers automatiquement. Vous n’avez pas besoin de gérer ces fichiers directement.