Wenn ein agentisches System in Produktion „komisch“ wird, ist das selten ein einzelner Bug, sondern ein Zusammenspiel aus Prompt, Kontext, Tool-Responses, Retries, Timeouts und Modellverhalten. Observability bedeutet hier: Du kannst nachvollziehen, was der Agent getan hat, warum er es getan hat, und wo genau es schiefging, ohne in den Kopf des Modells schauen zu müssen.
Setze auf strukturierte Logs (JSON), nicht auf freie Textzeilen. Kernprinzip: Jede relevante Aktion ist ein Event mit Feldern wie `timestamp`, `level`, `request_id`, `trace_id`, `agent_step`, `tool_name`, `tool_input_hash`, `tool_latency_ms`, `model`, `tokens_in/out`, `retry_count`, `outcome`.
Wichtig ist Korrelation: Ein User-Request erzeugt eine `request_id`, jeder Agent-Step und jeder Tool-Call trägt dieselbe ID. So kannst du die komplette Kette (Plan → Tool A → Ergebnis → Tool B → Antwort) wieder zusammensetzen.
Typische Prüfungs-Trade-offs:
Distributed Tracing überträgt das „Request-Graph“-Denken auf Agenten. Modellinferenz, Planungsschritt, Tool-Call, Retries, Backoff, Datenbankzugriff, Cache-Hit: alles als Spans in einem Trace.
Ergänzend helfen Metriken (Counters/Histograms), weil sie billig und aggregierbar sind: p50/p95 Latenzen pro Tool, Timeout-Rate, Retry-Rate, Token-Verbrauch pro Request, sowie „Tool-success-rate“ nach Tool/Endpoint. In der Praxis nutzt du Logs für Details, Traces für Ablauf, Metriken für Trends und Alerts.
Praktischer Nutzen:
Eine saubere Fehler-Taxonomie ist Exam-Gold, weil sie direkt zu Guardrails, Retries und Handoffs führt. Beispiele:
Jede Klasse hat eine Standardreaktion: Retry ja/nein, Backoff, Fallback-Modell, Degrade-Modus (z.B. „nur lesen“), oder Human Handoff.
1. Struktur + Korrelation: `request_id/trace_id` machen Agenten-Debugging überhaupt erst skalierbar.
2. Traces erklären Latenz: Du optimierst Timeouts/Retries anhand realer Spans, nicht Bauchgefühl.
3. Taxonomie steuert Verhalten: Fehlerklassen definieren deterministische Reaktionen (Retry, Fallback, Handoff).
Du betreibst einen Agenten mit Tool-Calls. Nutzer melden „manchmal dauert es ewig, manchmal kommt Unsinn“. Welche Observability-Daten sammelst du mindestens, um (a) Latenzursachen zu trennen und (b) Fehler systematisch zu kategorisieren?
Minimum: strukturierte Logs mit `request_id`, Step/Tool-Events, Latenzen, Retry-Zähler, Modell-/Token-Metadaten, plus Traces mit Spans pro Inferenz und Tool-Call. Für die Kategorisierung brauchst du eine Error-Taxonomie (z.B. Input/Dependency/Model/Policy/System) und pro Event ein eindeutiges `error_class`/`error_code`, damit Retries und Handoffs deterministisch werden.