Microsofts Foundry-Team hat OpenTelemetry-basiertes Tracing zu seinem Agenten-Framework hinzugefügt und bietet Entwicklern so die Möglichkeit, die End-to-End-Ausführung über heterogene, LLM-gestützte Agenten hinweg zu verfolgen.

Warum Multi-Agenten-Systeme mehr als nur Logdateien benötigen

Eine typische KI-gesteuerte Incident-Response-Übung nutzt einen Commander-Agenten, der mehrere Spezialisten-Agenten orchestriert: Einer analysiert Logs, ein anderer erkennt Metrik-Anomalien, ein dritter gleicht Symptome mit Runbooks ab, und ein Router wählt das beste Sprachmodell für jede Teilaufgabe aus. Jeder Spezialist kann ein anderes Modell aufrufen – zum Beispiel eine „gpt-5-mini“-Variante – und seine eigenen Tools nutzen. Wenn etwas schiefgeht, starren Ingenieure auf isolierte Logs, die zwar zeigen, was jede Komponente getan hat, aber keine Übersicht darüber bieten, wie die Teile zusammenpassen.

Ohne einen einheitlichen Trace verbirgt sich die Ursache (Root Cause) in der Übergabe zwischen den Agenten. Der Commander sendet möglicherweise eine Anfrage, die der Log-Reader korrekt verarbeitet, doch der Metrik-Spezialist interpretiert die Daten falsch und schlägt das falsche Runbook vor. Das manuelle Debugging dieser Kette kostet Zeit und ist fehleranfällig.

Wie OpenTelemetry den Workflow zusammenfügt

OpenTelemetry definiert zwei Kernkonzepte: Traces und Spans. Ein Trace ist eine eindeutige Kennung, die eine Anfrage vom Eingang bis zur finalen Antwort verfolgt. Ein Span zeichnet eine einzelne Operation auf – wie etwa einen Aufruf eines Sprachmodells oder eine Tool-Invocations – innerhalb dieses Traces.

Wenn ein Agent eine Anfrage erhält, extrahiert er die eingehende Trace ID aus den Metadaten der Anfrage und erstellt einen Child Span, der dieselbe ID erbt. Der Child Span protokolliert seine Startzeit, Dauer, Attribute (Modellname, verwendetes Tool) und etwaige Fehler. Dieser Prozess wiederholt sich für jeden nachgelagerten Agenten und baut einen Baum auf, der den logischen Ablauf der Gesamtaufgabe widerspiegelt.

OpenTelemetry unterstützt zudem Baggage, einen leichtgewichtigen Träger für benutzerdefinierte Key-Value-Paare. Indem man am Anfang des Traces eine „drill-id“ oder einen anderen Geschäftskontext an das Baggage anhängt, erbt jeder nachgelagerte Span automatisch diese Kennung. Ein Span-Processor macht das Baggage anschließend zu regulären Attributen, sodass es einfach möglich ist, alle Spans abzufragen, die zu einer bestimmten Incident-Übung gehören.

So sieht die neue Tracing-Oberfläche aus

Mit der implementierten Instrumentierung stellt Azure Monitor (oder ein anderes OpenTelemetry-kompatibles Backend) eine visuelle Hierarchie dar:

  • Agentenname / ID – zeigt, welche Komponente die Operation ausgeführt hat.
  • Tool-Nutzung – zeichnet auf, welcher externe Dienst oder welche Funktion aufgerufen wurde.
  • Modellversion – protokolliert das exakte verwendete LLM, was nützlich ist, um Regressionen nach einem Modell-Upgrade zu verfolgen.
  • Token-Verbrauch – erfasst, wie viele Token an das Modell gesendet und von ihm empfangen wurden, was Teams bei der Kostenkontrolle hilft.
  • Latenz / Dauer – hebt hervor, wo Engpässe auftreten, sei es bei der Modell-Inferenz oder beim Tool-I/O.

Im Beispiel der Incident-Übung erzeugt der Root Span des Commanders Child Spans für jeden Spezialisten, und jeder Spezialist erzeugt weitere Child Spans für seine Modellaufrufe. Durch Klicken auf einen Knoten werden alle Attribute angezeigt, sodass ein Ingenieur sofort die Details jeder Operation sieht.

Die Tragweite für KI-zentrierte Abläufe

  • Geschwindigkeit der Ursachenanalyse – Teams können einen Fehler bis zum exakten Span zurückverfolgen, der einen Fehler ausgelöst hat, was die mittlere Zeit bis zur Behebung (Mean Time to Resolution) verkürzt.
  • Kostentransparenz – Die Token-Anzahl steht neben der Latenz, sodass die Finanzabteilung eine unkontrollierte Nutzung erkennen kann, bevor die Cloud-Rechnungen explodieren.
  • Leistungsoptimierung – Spans mit hoher Latenz über verschiedene Agenten hinweg zeigen auf, wo Caching, Modellwahl oder ein Redesign von Tools den Durchsatz erhöhen könnten.

Ausblick

Projekte, die auf LangChain, dem OpenAI SDK oder anderen Orchestrierungsschichten basieren, können dieselben semantischen Konventionen für GenAI übernehmen und so den Weg für Traces ebnen, die über Cloud-Anbieter und On-Premise-Deployments hinweg fließen.

Unternehmen müssen lediglich das OpenTelemetry SDK in ihren Agenten aktivieren und die Daten an Azure Monitor oder einen Open-Source-Collector senden.

Fazit

OpenTelemetry liefert Multi-Agenten-KI-Systemen den fehlenden Klebstoff, der eine Ansammlung von Logs in eine kohärente Erzählung verwandelt. Durch die Weitergabe einer einzigen Trace ID über heterogene LLMs, Router und Tool-Aufrufe hinweg können Entwickler Fehler lokalisieren, Kosten überwachen und die Leistung optimieren, ohne die Tracing-Infrastruktur neu erfinden zu müssen.