Runs & Traces
Runs zeigen Eingaben, Ausgaben, Kontext und Ausführungs-Traces. Sequential-Schritte erscheinen als verknüpfte untergeordnete Runs mit eigenem Trace.
Auf dieser Seite
Agent Runs
Der Tab Agent Runs im Projekt zeigt alle Agent Runs in chronologischer Reihenfolge. Jede Zeile enthält den Run-Status, den Namen des Agenten, das Deployment, die Dauer, die Token-Anzahl mit Token-Kosten in der Projektwährung und den Zeitpunkt, zu dem der Run in die Warteschlange gestellt wurde. Die Tabelle wird alle paar Sekunden aktualisiert.
Runs filtern
Mit der Filterleiste oben lassen sich die angezeigten Runs eingrenzen:
| Filter | Beschreibung |
|---|---|
| Status | Filtere nach einem oder mehreren Statuswerten: scheduled queued running awaiting approval completed failed cancelled |
| Zeitraum | Wähle eine Vorgabe wie 24h, 7d oder 30d oder lege einen eigenen Zeitraum fest. |
| Deployment | Zeige nur Runs aus einem bestimmten Deployment. |
| Suche | Durchsuche Run-Inhalte oder filtere mit einem Ausdruck wie context.customer == 'acme'. Der Button mit dem Funkeln-Symbol wandelt eine natürlichsprachliche Anfrage in einen Filter um. |
input.amount >= 40) und die Ausgabe des Agenten (output.priority == 'high') ab und lassen sich mit and, or und not kombinieren. Speichere einheitliche Metadaten wie Benutzer-IDs, Session-IDs, Anfragetypen oder Workflows in der Middleware, um zusammengehörige Runs gezielt zu finden. Das Fragezeichen-Symbol im Suchfeld zeigt die vollständige Syntax.Run untersuchen
Klicke in der Runs-Tabelle auf eine Zeile, um die Detailansicht zu öffnen. Die Detailseite führt Run-Metadaten, Anfrage- und Antwortdaten, Kontext und den Ausführungs-Trace zusammen.
Run-Header
- Run-ID und Status: Zeigt, um welche Ausführung es sich handelt und ob sie abgeschlossen oder fehlgeschlagen ist oder noch läuft.
- Verbindung: Zeigt, welche Verbindung den Run ausgelöst hat.
- Triggered by: Folge dem Link zum übergeordneten Run, wenn ein anderer Agent diese Ausführung gestartet hat.
- Duration: Prüfe die verstrichene Ausführungszeit, die für laufende Runs live aktualisiert wird. Bei abgeschlossenen Runs zieht der Header erfasste Approval-Wartezeiten ab. Run-Listen und aggregierte Kennzahlen verwenden die aktive Backend-Laufzeit, die zusätzlich Wartezeiten auf untergeordnete Sequential-Runs ausschließt.
- Token usage: Öffne den Tooltip für die Aufschlüsselung der Tokens und die Token-Kosten in der Projektwährung.
Bereiche eines Runs
Run Again löst denselben Agenten erneut mit derselben Eingabe aus. Für geplante, wartende und laufende Ausführungen steht außerdem eine Abbruchaktion zur Verfügung.
Ausführungs-Traces
Ein Trace gliedert einen Run in einen hierarchischen Baum aus Spans. Jeder Span steht für eine Operation, etwa einen LLM Call, einen Tool-Aufruf, einen Middleware-Hook oder den Link zum separaten Run eines ausgelösten Agenten.
Span-Typen
| Symbol | Span-Typ | Was er darstellt |
|---|---|---|
| LLM | Ein logischer Schritt des Sprachmodells mit Prompt, Antwort und – sofern verfügbar – Reasoning. | |
| LLM Call | Eine tatsächliche Anfrage an den Provider. Wiederholungsversuche erscheinen als nachfolgende Anfragen; Backoff-Details stehen in den Metadaten. | |
| Tool | Ein Tool-Aufruf mit den übergebenen Argumenten und dem zurückgegebenen Wert. | |
| MCP Tool | Ein Aufruf eines externen MCP-Servers einschließlich Server, Tool, Argumenten und Antwort. | |
| Middleware | Ein Before- oder After-Middleware-Hook und die Daten, die ihn durchlaufen. | |
| Verbindung | Die eingehende Verbindung, die den Run gestartet hat, gefolgt von einer gruppierten Aufzeichnung aller ausgehenden Zustellungen. | |
| Ausgelöster Agent | Ein Aufruf eines anderen Agenten. Jeder Sequential-Schritt wird als eigener untergeordneter Run gespeichert und über diesen Span verlinkt. | |
| Run / Step | Der übergeordnete Run oder eine Iteration der Agent-Loop. |
Traces kennzeichnen außerdem Tool Discovery, Kontext- oder Gesprächskomprimierung, Guardrail-Gruppen und -Ergebnisse, Approval-Entscheidungen und Tool-Agenten.
Trace lesen
Untergeordnete Spans sind unter der Operation eingerückt, die sie erzeugt hat. Prüfe für jeden Span Status, Dauer, Eingaben, Ausgaben und Metadaten. LLM-Spans können außerdem Thoughts enthalten, wenn der Provider Reasoning-Inhalte zurückgibt. Dieses Verhalten lässt sich mit reasoning_effort in der Agent-Konfiguration steuern.
- Status: ob der Span erfolgreich abgeschlossen wurde oder ein Fehler aufgetreten ist.
- Dauer: wie lange die Operation gedauert hat.
- Eingaben und Ausgaben: die Daten, die in den Schritt eingeflossen sind und ihn verlassen haben.
- Metadaten: Modellnamen, Anzahl der Wiederholungsversuche und Details zu Tool-Fehlern.
Trace-Beispiel
Hier durchläuft die Anfrage zunächst die Before-Middleware. Das Modell wählt calculator.add, verarbeitet das Tool-Ergebnis zu einer endgültigen Antwort und die After-Middleware schließt den Run ab.