Observability für KI-Agenten: Tracing, Spans, Evals
KI-Agenten in Produktion instrumentieren mit OpenTelemetry-Tracing, Spans und kontinuierlichen Evals auf Azure AI Foundry — Zuverlässigkeit statt Demos.
TL;DR / Die wichtigsten Erkenntnisse
- Tracing, Spans und Evals sind drei verschiedene Aufgaben. Traces und Spans sagen Ihnen, was der Agent getan hat; Evals sagen Ihnen, ob es korrekt war. Produktive Agenten brauchen beides.
- Standardisieren Sie auf OpenTelemetry. Das Microsoft Agent Framework, das am 3. April 2026 General Availability erreichte, emittiert OpenTelemetry-kompatible Traces — so vermeiden Sie Vendor-Lock-in und leiten Telemetrie an Azure Monitor oder jedes OTLP-Backend.
- Der prägende Shift 2026 ist Pilot-zu-Produktion. Mit über 400.000 Custom-Agenten in mehr als 160.000 Organisationen sind Zuverlässigkeit, Observability, Sicherheit, Evaluierung und Kosten-Governance jetzt der schwierige Teil — nicht der Bau des Agenten.
- Instrumentieren Sie den vollständigen Kausalbaum. Erfassen Sie den Nutzer-Turn, jeden Modellaufruf, jeden Tool-Aufruf, Retrieval-Schritte und Sub-Agent-Übergaben als Eltern-Kind-Spans, mit Token- und Kostenattributen auf jedem.
- Gaten Sie Deployments auf Eval-Scores, nicht auf Bauchgefühl. Kontinuierliche Online-Evals machen Qualität zu einer überwachbaren Metrik, auf die Sie alerten und gegen die Sie zurückrollen können.
Das Problem: Agenten, die die Demo bestehen und das Audit nicht
Fast jedes Unternehmen, mit dem wir arbeiten, erzählt dieselbe Geschichte. Ein Team baut einen Agenten, der in der Demo brilliert. Er beantwortet Fragen, ruft ein, zwei Tools auf und wirkt produktionsreif. Dann geht er live, und drei Wochen später stellt jemand eine Frage, die einfach sein sollte: Warum hat der Agent diesem Kunden zweimal erstattet? Niemand kann sie beantworten, weil niemand sehen kann, was der Agent tatsächlich getan hat.
Das ist das prägende Problem von 2026. Die Branche hat sich entschieden von Piloten zur Produktion bewegt — allein auf Copilot Studio haben über 160.000 Organisationen mehr als 400.000 Custom-Agenten deployt — und der limitierende Faktor ist nicht mehr „können wir einen Agenten bauen", sondern „können wir einen betreiben, dem wir vertrauen". Die schwierigen Teile sind Zuverlässigkeit, Observability, Sicherheit, Evaluierung und Kosten-Governance. Observability liegt unter allen, denn Sie können nichts absichern, evaluieren oder kostenseitig steuern, das Sie nicht sehen.
Agenten brechen die Annahmen, auf denen klassisches Monitoring aufbaut. Ein traditioneller Dienst ist deterministisch: Dieselbe Anfrage durchläuft denselben Code-Pfad. Ein Agent ist nicht-deterministisch — er schlussfolgert, wählt Tools, wiederholt und delegiert, und dieselbe Eingabe kann jedes Mal einen anderen Weg nehmen. Ein Dashboard mit 200 ms Latenz und null 500ern sagt Ihnen also fast nichts darüber, ob der Agent das Richtige getan hat.
Drei Ebenen: Traces, Spans und Evals
Es hilft, die Belange präzise zu trennen, denn Teams vermengen sie regelmäßig und wundern sich dann, warum „wir haben doch Logging" sie nicht gerettet hat.
| Ebene | Beantwortete Frage | Primäres Signal | Werkzeuge auf Azure |
|---|---|---|---|
| Traces | Wie sah die vollständige Schrittfolge dieses Laufs aus? | Ein Baum von Spans je Agenten-Lauf | Azure AI Foundry Tracing, Application Insights |
| Spans | Was geschah innerhalb eines Schritts (Modellaufruf, Tool, Retrieval)? | Latenz, Tokens, Ein-/Ausgabe, Status | OpenTelemetry GenAI Semantic Conventions |
| Evals | War das Ergebnis korrekt, grounded, sicher, vollständig? | Scores je Dimension | Azure AI Foundry Evaluierung |
Traces: der Kausalbaum eines Laufs
Ein Trace ist die vollständige Aufzeichnung eines einzelnen Agentenaufrufs, von der Nutzeranfrage bis zur finalen Antwort. Es ist ein Baum, keine Liste: Der Wurzel-Span ist der Agenten-Turn, und Kinder umfassen jeden Modellaufruf, jeden Tool-Aufruf, jedes Retrieval und jede Übergabe an einen Sub-Agenten. Wenn ein Agent Arbeit über das A2A-Protokoll an einen anderen Agenten delegiert, sollte diese Delegation als verknüpfter Span erscheinen, damit die Kausalkette den Netzwerk-Hop übersteht.
Spans: wo Kosten und Latenz tatsächlich entstehen
Ein Span ist eine Arbeitseinheit. Die Disziplin, die in der Praxis zählt, ist Attribut-Hygiene — die richtigen semantischen Daten auf jedem Span. Die OpenTelemetry GenAI Semantic Conventions definieren dafür Standardattribute: Modellname, Prompt- und Completion-Tokens, Tool-Name und Operationstyp. Machen Sie das richtig, beantworten Sie Fragen wie „welcher Tool-Aufruf verbrennt 60 % unserer Tokens" durch Gruppierung von Spans, statt Logs zu durchsuchen.
Evals: die einzige Ebene, die Korrektheit misst
Tracing und Spans sind notwendig, aber nicht hinreichend. Ein Trace kann einen schnellen, fehlerfreien Lauf zeigen, der eine selbstbewusst falsche Antwort erzeugt hat. Evals sind automatisierte Urteile über die Ausgabequalität entlang Dimensionen wie Groundedness (hielt sich der Agent an den abgerufenen Kontext), Korrektheit, Sicherheit und Aufgabenerfüllung. Offline gegen ein Golden Dataset vor dem Deployment ausgeführt und kontinuierlich online gegen eine Stichprobe des Live-Traffics, verwandeln Evals „der Agent fühlt sich gut an" in eine Zahl, auf die Sie alerten können.
Agenten mit dem Microsoft Agent Framework instrumentieren
Das Microsoft Agent Framework 1.0, seit dem 3. April 2026 allgemein verfügbar, ist ein Open-Source-Framework für .NET und Python, das Observability einbaut statt sie nachzurüsten. Es emittiert OpenTelemetry-kompatible Traces nativ, was die wichtigste Designentscheidung zur Vermeidung von Lock-in ist: Dieselben Spans fließen zu Azure Monitor, Application Insights oder jedem OTLP-kompatiblen Backend, das Sie bereits betreiben. Für den architektonischen Kontext, wie das Framework Agenten, Runtimes sowie die A2A- und MCP-Protokolle strukturiert, siehe unsere Analyse der Agent-Framework-1.0-Architektur.
Eine praktische Instrumentierungs-Checkliste, die wir in Projekten anwenden:
- Framework-Tracing aktivieren und den OTLP-Exporter setzen auf Ihren Application-Insights- oder Azure-Monitor-Workspace. Schreiben Sie keinen eigenen Tracer; nutzen Sie die Konventionen, die Sie kostenlos erhalten.
- Trace-Kontext über jede Grenze propagieren — Tool-Aufrufe, MCP-Server und A2A-Übergaben — sodass eine einzige Trace-ID den gesamten verteilten Lauf zusammenfügt. Die Kontext-Propagierung über MCP-Server ist die häufigste Stelle, an der wir Traces fragmentieren sehen.
- Token- und Kostenattribute auf jedem Modell-Span erfassen. Kosten-Governance ist im Nachhinein unmöglich, wenn die Daten nie erfasst wurden.
- Fachliche Korrelations-IDs hinzufügen (Mandant, Vorgang, Nutzer) als Span-Attribute, sodass Sie von einem Support-Ticket direkt zum verursachenden Lauf tracen können.
- Intelligent sampeln. Tracen Sie 100 % der Fehler und eine repräsentative Stichprobe der Erfolge; das vollständige Tracing jedes Tokens in jedem Lauf wird schnell teuer.
Als wir für einen europäischen Versicherer einen internen Agenten zur Schadentriage deployten, war es Schritt 4 — die fachlichen Korrelations-IDs —, der eine zweitägige Incident-Untersuchung in eine zweiminütige Trace-Abfrage verwandelte. Der Agent hatte einen Vorgang doppelt bearbeitet; der Trace zeigte ein Tool, das nach einem Timeout wiederholt wurde, aber beim ersten Mal tatsächlich erfolgreich war. Kein Latenz-Dashboard der Welt hätte das zutage gefördert.
Von Traces zu Evals: den Qualitätskreislauf schließen
Sobald Telemetrie fließt, ist der nächste Reifeschritt, Qualität messbar zu machen. Azure AI Foundry — die zentrale Plattform zum Bauen, Deployen und Governen von Agenten — unterstützt sowohl Offline-Evaluierung gegen kuratierte Datensätze als auch kontinuierliche Online-Evaluierung gegen Live-Traffic. Das von uns empfohlene Muster:
Eine pragmatische Eval-Pipeline
- Bauen Sie ein Golden Dataset repräsentativer Eingaben mit bekannt-guten Ausgaben oder Bewertungsrubriken. Halten Sie es versioniert und lassen Sie es aus echten Incidents wachsen.
- Definieren Sie Eval-Dimensionen, die auf Ihr Risiko abbilden: Groundedness und Korrektheit für Genauigkeit, Sicherheits- und Schadinhaltsprüfungen für Konformität, und Aufgabenerfüllung für Nützlichkeit.
- Gaten Sie das Deployment. Kein Agent geht live, wenn die Eval-Scores gegen das Golden Set unter den Schwellenwert fallen. Behandeln Sie das exakt wie eine fehlschlagende Testsuite.
- Führen Sie kontinuierliche Online-Evals auf einer Stichprobe der Produktions-Traces aus, mit LLM-as-Judge oder regelbasierten Scorern, und emittieren Sie die Scores als Metriken.
- Alerten und zurückrollen bei Score-Drift. Ein Groundedness-Score, der über eine Woche von 0,92 auf 0,78 rutscht, ist ein Incident, auch wenn Latenz und Fehlerraten perfekt aussehen.
Hier hört Observability auf, ein Debugging-Komfort zu sein, und wird zu einer Kontrolle. Für regulierte europäische Workloads liegt hier auch die Compliance-Story: Der EU AI Act erwartet von Anbietern und Betreibern höher-riskanter Systeme Protokollierung, Nachvollziehbarkeit und menschliche Aufsicht, und DORA sowie NIS2 erhöhen die Anforderungen an operative Resilienz und Incident-Nachweise. Eval-Scores und Traces sind genau die Nachweispflichten — die Evidenz —, nach der Prüfer fragen werden. Observability von Tag eins an einzuplanen ist weit günstiger, als sie unter Audit-Termindruck nachzurüsten.
Häufige Anti-Muster
Einige Fehlermuster, die wir wiederholt sehen:
- Logging statt Tracing. Unstrukturierte Log-Zeilen können keinen Kausalbaum rekonstruieren. Sie brauchen Spans mit Eltern-Kind-Beziehungen.
- Tracing ohne Evals. Sie haben dann perfekte Sicht auf einen selbstbewusst falschen Agenten.
- Prompts erfassen, aber keine PII redigieren. Trace-Payloads enthalten oft personenbezogene Daten; wenden Sie Redigierung am Exporter an, nicht als Nachgedanke, um DSGVO-konform zu bleiben.
- Herstellerspezifische Instrumentierung. Die Anbindung eines Agenten an ein proprietäres Observability-SDK sperrt die Telemetrie ein. OpenTelemetry hält sie portabel.
- Keine Kostenzuordnung. Ohne Token- und Kostenattribute auf Spans wird die Rechnung Ihre erste Überraschung sein.
Wo Sie anfangen
Wenn Sie Agenten vom Piloten in die Produktion bringen, tun Sie zuerst diese drei Dinge: Schalten Sie OpenTelemetry-basiertes Tracing im Agent Framework ein, hängen Sie Token- und fachliche Korrelationsattribute an jeden Span, und stellen Sie ein kleines Golden-Dataset-Eval-Gate auf, bevor Sie ausliefern. Alles Weitere baut auf diesem Fundament auf.
Wir unterstützen europäische Unternehmen dabei, diesen Stack durchgängig zu entwerfen und zu betreiben — Tracing, Evals, Kosten-Governance und die regulatorische Evidenzebene auf Azure AI Foundry. Wenn Sie mit Agenten ringen, die in der Demo glänzen, aber in der Produktion nicht vertrauenswürdig sind, hilft Ihnen unser Team für KI- und Datenplattform-Engineering, sie observierbar, evaluierbar und auditfähig zu machen.
FAQ
Was ist Observability für KI-Agenten?
Observability für KI-Agenten ist die Praxis, strukturierte Telemetrie — Traces, Spans, Metriken und Logs — über jeden Schritt eines Agenten zu erfassen, von der ursprünglichen Nutzeranfrage über Tool-Aufrufe und Modellaufrufe bis zu Übergaben an Sub-Agenten. Anders als klassisches Application-Monitoring muss sie nicht-deterministisches Reasoning, Token-Verbrauch und die Qualität der Ausgaben erfassen, nicht nur Latenz und Fehler. Ziel ist es zu beantworten, ob ein Agent nicht nur lief, sondern auch korrekt schlussfolgerte und handelte.
Wie unterscheidet sich Observability für KI-Agenten von klassischem APM?
Klassisches APM setzt deterministische Code-Pfade voraus und misst Latenz, Durchsatz und Fehlerraten. Agenten sind nicht-deterministisch: Dieselbe Eingabe kann zu unterschiedlichen Tool-Aufrufen und Ausgaben führen. Agent-Observability ergänzt semantische Dimensionen — Prompt- und Completion-Inhalte, Token-Kosten, Tool-Auswahl, Retrieval-Relevanz und Eval-Scores — und behandelt Korrektheit als gleichrangiges Signal neben Performance. Sie brauchen beide Sichten: die operative und die Qualitätssicht.
Welche Rolle spielt OpenTelemetry beim Agent-Tracing?
OpenTelemetry liefert den herstellerneutralen Standard zum Emittieren von Traces und Spans, und seine GenAI Semantic Conventions definieren, wie Modell-, Token- und Tool-Attribute konsistent erfasst werden. Das Microsoft Agent Framework emittiert OpenTelemetry-kompatible Traces ab Werk, sodass dieselbe Telemetrie ohne Lock-in an Azure Monitor, Application Insights oder jedes OTLP-Backend geleitet werden kann. Die Standardisierung auf OpenTelemetry hält Ihre Observability über Clouds und Werkzeuge hinweg portabel.
Was sind Spans im Kontext eines KI-Agenten?
Ein Span repräsentiert eine einzelne Arbeitseinheit innerhalb eines Trace — etwa einen Modellaufruf, einen Tool-Aufruf oder einen Retrieval-Schritt. Ein Trace ist der vollständige Baum von Spans für einen Agenten-Lauf und zeigt die Eltern-Kind-Beziehungen zwischen Reasoning-Schritten, Tool-Aufrufen und Delegationen an Sub-Agenten. Die Inspektion von Spans zeigt genau, wo Latenz, Kosten oder falsche Entscheidungen innerhalb eines mehrstufigen Agenten entstanden sind.
Warum sind Evals nötig, wenn ich bereits Tracing habe?
Tracing sagt Ihnen, was passiert ist; Evals sagen Ihnen, ob es gut war. Ein Trace kann einen schnellen, fehlerfreien Lauf zeigen, der dennoch eine falsche, unsichere oder nicht-konforme Antwort erzeugt hat. Evals — die automatisierte Bewertung von Korrektheit, Groundedness, Sicherheit und Aufgabenerfüllung — verwandeln Qualität in ein messbares, überwachbares Signal, auf das Sie Deployments gaten und das Sie über die Zeit verfolgen können.
Wie unterstützt Azure AI Foundry die Observability von Agenten?
Azure AI Foundry ist die zentrale Plattform zum Bauen, Deployen und Governen von Agenten, mit integriertem Tracing, Evaluierung und Monitoring, die sich in Azure Monitor und Application Insights integrieren. Sie erfasst End-to-End-Traces von Agenten-Läufen, unterstützt sowohl Offline- als auch kontinuierliche Online-Evaluierung und liefert Kosten- und Token-Telemetrie für die Governance. Zusammen mit dem Microsoft Agent Framework ergibt das einen produktionsreifen Observability-Stack auf Azure.
Themen