Vier autonome KI-Agenten können nun einen Softwarefehler erkennen, den fehlerhaften Code bearbeiten und die Behebung bestätigen – und das alles in weniger als einer Minute, dank eines neuen, auf Observability basierenden Workflows, der für den SigNoz-Hackathon entwickelt wurde.

Das System mit dem Namen AgentOps überwacht SigNoz auf Fehlerspitzen, ruft die relevanten Logs und Traces ab, identifiziert die exakte Datei und Zeile, die dafür verantwortlich sind, bearbeitet den Quellcode in einer Sandbox und spielt die Anfrage dann erneut ab, um zu beweisen, dass der Bug behoben ist. Jeder vollständige Zyklus dauert 30–60 Sekunden, und der gesamte Prozess läuft ohne ein einziges menschliches Prompt ab.

Warum Observability für KI-Agenten wichtig ist

Die traditionelle SRE-Praxis betrachtet Logs, Metriken und verteilte Traces als die „Augen“ eines Dienstes. Wenn eine Anfrage fehlschlägt, folgt ein Ingenieur dem Trace zum fehlerhaften Element. Dasselbe Prinzip treibt nun AgentOps an, aber der zu beobachtende „Dienst“ ist der KI-Agent selbst.

Jedes Tool, das der Agent aufruft – sei es ein Aufruf eines Sprachmodells, eine Dateisystem-Änderung oder ein Test-Runner – erstellt einen Span im Trace. Ein Span zeichnet Startzeit, Dauer und Erfolgsstatus auf, sodass der Agent sehen kann, wie lange jeder Denkschritt gedauert hat und ob er erfolgreich war. Durch das Zusammenfügen dieser Spans erstellt der Agent ein vollständiges Bild seines eigenen Denkprozesses, genau wie ein Mensch beim manuellen Debugging.

Der entscheidende Wandel liegt von „Observability als Berichtsebene“ hin zu „Observability als Wahrnehmung“. AgentOps speist die Trace-Daten zurück in die Agenten ein, sodass diese in Echtzeit über ihre eigenen Aktionen nachdenken können. Das Ergebnis ist ein Kreislauf, in dem die KI nicht nur eine Hypothese generiert, sondern diese auch anhand derselben Telemetrie validiert, die sie zur Erkennung des Problems verwendet.

Der vierstufige Workflow

  1. Monitor – Ein leichtgewichtiger Watcher scannt SigNoz nach neu gemeldeten Fehlern.
  2. Diagnose – Der Agent ruft die zugehörigen Logs und Traces ab, extrahiert den Stack und isoliert die Quelldatei sowie die Zeilennummer, die den Fehler ausgelöst haben.
  3. Fix – Mithilfe eines sandboxed Dateisystem-Servers schreibt der Agent einen Patch für die identifizierte Zeile. Die Sandbox erzwingt strikte Berechtigungen und führt automatisch ein Rollback durch, falls die Änderung gegen Richtlinien verstößt.
  4. Verify – Der Agent führt die ursprüngliche Anfrage erneut gegen den gepatchten Code aus. Wenn der Trace einen fehlerfreien Durchlauf zeigt, wird der Fix übernommen; andernfalls iteriert der Agent erneut.

Alle Schritte werden von demselben Satz von Agenten orchestriert, wobei jeder als autonomer Microservice fungiert. Die gesamte Kette ist durch OpenTelemetry-kompatible Spans beobachtbar, die von SigNoz aufgenommen und visualisiert werden.

Mühsam gewonnene Erkenntnisse zur Zuverlässigkeit

Fehlerklarheit

Ein generischer „failed“-Status sagt nichts aus. Das Team hat granulare Fehlergründe hinzugefügt – z. B. „falsche Hypothese“ oder „Patch hat Prozess unterbrochen“ –, damit nachgelagerte Agenten entscheiden können, ob sie es erneut versuchen, zurückgehen oder abbrechen. Dies spiegelt die Art und Weise wider, wie Menschen bei Post-Mortems die Ursachen benennen.

Datenlatenz

Telemetrie erscheint nicht sofort. Die Agenten beinhalten nun eine kurze Pause und einen Sanity-Check, um sicherzustellen, dass die erforderlichen Logs angekommen sind, bevor sie einen Fix bestätigen. Ohne diesen Schutz könnte ein Agent auf unvollständigen Daten agieren und ein falsch-positives Ergebnis liefern.

Sicherheitsgrenzen

Einer KI das Schreiben von Code zu erlauben, stellt ein Risiko für eine Privilegieneskalation dar. Die Sandbox läuft hinter einem dedizierten Dateisystem-Server, der den Schreibbereich auf das Ziel-Repository beschränkt und automatisch den vorherigen Zustand wiederherstellt, falls ein Test fehlschlägt. Dieses Containment-Modell hält die Macht der KI in Schach.

Token-Limits

Große Sprachmodelle verbrauchen API-Token, und die täglichen Quoten können mitten in der Untersuchung erschöpft sein. AgentOps verfolgt die Token-Nutzung pro Vorfall und drosselt weitere Aufrufe, sobald ein Schwellenwert erreicht ist, um eine Kaskade fehlgeschlagener Fixes zu verhindern, wenn die Quote aufgebraucht ist.

Was die Demo bewiesen hat

Das Team schleuste einen brandneuen Bug ein, der zuvor noch nie in der Codebasis aufgetreten war. AgentOps erkannte die Anomalie, verfolgte sie bis zur exakten Zeile, generierte eine korrigierende Änderung, wandte den Patch in der Sandbox an und verifizierte, dass die Anfrage erfolgreich war – alles ohne manuelle Codeänderungen oder neue Prompts. Die End-to-End-Zeit blieb unter einer Minute und entsprach der gemeldeten Dauer von 30–60 Sekunden.

Gegenargument: Autonomie ist kein Allheilmittel

Worauf man als Nächstes achten sollte

  • Modellagnostische Telemetrie – Da immer mehr Anbieter OpenTelemetry-kompatible Spans bereitstellen, könnte der Ansatz herstellerneutral werden, was die Einführung in heterogenen Stacks erleichtert.
  • Richtlinienbasierte Leitplanken – Die Einbettung konfigurierbarer Richtlinien, die festlegen, welche Dateien ein Agent bearbeiten darf oder welche Test-Suites vor einem Commit bestanden werden müssen, wird Governance-Bedenken ausräumen.
  • Kostenbewusstes Token-Budgeting – Eine dynamische Token-Zuweisung basierend auf der Schwere eines Vorfalls könnte die Erschöpfung von Kontingenten verhindern und gleichzeitig die Fähigkeit erhalten, kritische Bugs zu beheben.

AgentOps zeigt, dass der Bug-Fix-Zyklus 30–60 Sekunden dauern kann. Das Experiment dient als Proof-of-Concept dafür, dass Observability von autonomen Software-Assistenten genutzt werden kann.