Vai al contenuto principale

title: “Python SDK” description: “Documentazione AgentEye Python SDK.”

AgentEye Python SDK ti offre visibilità completa sul comportamento dei tuoi agenti (ogni esecuzione dell’agente, chiamata di strumento, richiesta al modello, hook e intervento umano) per poter effettuare debug, audit e valutazione. Instrumenta il codice del tuo agente scrivendo eventi strutturati in file JSONL locali; il daemon collector li raccoglie e li invia automaticamente alla piattaforma.

Installazione

Scarica il wheel da GitHub Releases usando il tuo AGENTEYE_TOKEN. Se non hai ancora un token, consulta GitHub Token Setup per i passaggi di configurazione e le autorizzazioni richieste. Usando gh CLI + pip:
Usando gh CLI + uv:
Usando curl (senza gh CLI):

Avvio Rapido


configure()

Chiamalo una volta prima di qualsiasi chiamata event.*. È sicuro ometterlo; i valori predefiniti funzionano direttamente. Tutti gli argomenti sono keyword-only; passali per nome come mostrato sopra. Quando base_dir è None (il valore predefinito), l’SDK legge $AGENTEYE_HOME se impostato, altrimenti ricade su ~/.agenteye. Questo corrisponde alla risoluzione del collector stesso, quindi una singola variabile di ambiente AGENTEYE_HOME configura lo spool di eventi condiviso per sia l’SDK che il collector, necessario per i deployment sidecar / single-pod dove entrambi i processi devono concordare sul percorso dello spool.

Ambiente

Etichetta ogni evento con un ambiente di deployment (production, staging, qa, canary, ecc.). Impostalo una volta; l’SDK lo allega automaticamente a ogni evento. Opzione 1: tramite configure():
Opzione 2: tramite variabile di ambiente:
Priorità: configure(environment=...) prevale sulla variabile di ambiente. Se nessuno dei due è impostato, il valore predefinito è "dev". Il valore dell’ambiente appare come filtro di prima classe nel dashboard ed è archiviato come colonna indicizzata sul server per query rapide. Vincolo: i valori dell’ambiente non devono contenere una virgola , letterale. I filtri del dashboard utilizzano selezioni multiple separate da virgole sul collegamento (?environment=prod,staging), quindi un ambiente denominato prod,blue verrebbe diviso in due valori. Gli eventi con ambienti contenenti virgole vengono rifiutati al momento dell’ingestion.

Riferimento Eventi

Tutti i metodi degli eventi richiedono questi due campi:
CampoTipoDescrizione
session_idstrIdentifica l’esecuzione dell’agente di livello superiore
agent_idstrIdentifica quale agente nella sessione ha emesso l’evento
Tutti i metodi accettano anche **kwargs arbitrari per metadati personalizzati (vedi Campi Personalizzati).

event.agent_start()

Emesso quando un agente inizia il lavoro.

event.agent_end()

Emesso quando un agente finisce il lavoro.

event.tool_use()

Emesso quando un agente invoca uno strumento. Accoppialo con tool_result; l’SDK calcola automaticamente duration_ms.

event.tool_result()

Emesso quando uno strumento ritorna. Correla con tool_use tramite tool_call_id.

event.model_request()

Emesso subito prima di inviare un prompt a un LLM.
Le voci messages accettano sia un content semplice string che Anthropic-style list-of-blocks content. I parametri di sampling (temperature, max_tokens, ecc.) possono essere passati come kwargs aggiuntivi.

event.model_response()

Emesso quando l’LLM ritorna una risposta.
content accetta sia una semplice string (provider generici) che una lista di content block Anthropic-style. Le chiamate di strumenti vivono all’interno di content come blocchi {"type": "tool_use", ...}, senza un campo tool_calls separato.

event.hook_triggered()

Emesso quando un hook si attiva. Accoppialo con hook_completed; l’SDK calcola automaticamente duration_ms.

event.hook_completed()

Emesso quando un hook finisce. Correla con hook_triggered tramite hook_id.

event.error()

Emesso quando si verifica un errore non gestito.

Eventi Human-in-the-Loop

Gli eventi human-in-the-loop ti danno supervisione nei momenti in cui una persona interviene nell’esecuzione dell’agente (in attesa di approvazione, fornendo input, mettendo in pausa o fermando l’agente). Ti permettono di misurare quanto tempo gli umani impiegano per rispondere (l’SDK calcola automaticamente duration_ms sugli eventi accoppiati), controllare chi ha messo in pausa o interrotto un agente, e costruire flussi di lavoro di approvazione e supervisione che si presentano nel dashboard.

event.human_wait()

Emesso quando l’agente mette in pausa l’esecuzione per attendere che un umano fornisca input. Accoppialo con human_input; l’SDK calcola automaticamente duration_ms (quanto tempo l’umano ha impiegato per rispondere).

event.human_input()

Emesso quando un umano fornisce input e l’agente riprende. Correla con human_wait tramite input_id. duration_ms è calcolato automaticamente e non deve essere passato dal chiamante.

event.human_pause()

Emesso quando un umano mette attivamente in pausa l’agente (ad es. tramite un controllo dashboard). L’agente è sospeso ma non terminato.

event.human_interrupt()

Emesso quando un umano ferma attivamente l’agente durante l’esecuzione. A differenza di human_pause, il lavoro dell’agente viene terminato piuttosto che sospeso.

Campi Personalizzati

Tutti gli argomenti di parola chiave aggiuntivi vengono aggiunti all’evento dopo i campi standard:
timestamp, type e environment sono riservati e generano ValueError (I nomi dei campi riservati non possono essere utilizzati come campi personalizzati: [...]) se passati come campi personalizzati. session_id e agent_id sono parametri obbligatori su ogni metodo di evento e non possono essere forniti una seconda volta; Python genera TypeError se lo fai. Imposta l’ambiente con configure(environment=...) (o la variabile AGENTEYE_ENVIRONMENT) invece.

Come Vengono Scritti gli Eventi

Gli eventi vengono bufferizzati in-process e svuotati su disco ogni flush_interval secondi (default 500 ms). Ogni flush scrive un file JSONL:
Il collector osserva questa directory e carica i file automaticamente. Non hai bisogno di gestire questi file direttamente.