Wie man einem LLM-Agenten für die Infrastruktur beibringt, nicht zu lügen

Es wurde ein interner schreibgeschützter LLM-Agent entwickelt, um Infrastrukturfragen wie ‚Warum liefert der Dienst einen 502-Fehler?‘ zu beantworten. Er wurde in Go ohne LangChain implementiert und rief die Modelle DeepSeek-V4-Flash und Qwen3.6-27B-FP8 über eine OpenAI-kompatible API auf. Die erste Version verwendete eine freie ReAct-Schleife und lieferte Antworten, die formal korrekt, aber oft irreführend waren. Wenn beispielsweise ein 502-Fehler durch einen übermäßig großen Antwort-Header im Proxy verursacht wurde, zog der Agent den Schluss ‚kein Fehler auf Anwendungsebene‘ und übersah die eigentliche Ursache. Es wurden fünf Fehlerklassen identifiziert: falscher Gültigkeitsbereich, falsche Zeitsemantik, falsche negative Schlussfolgerungen, Verlust von Belegen und unkontrollierte Neuplanung. Die Lösung bestand darin, den LLM in ein strenges Anwendungsframework einzubetten. Tool-Aufrufe unterliegen einem erweiterten Vertrag namens „x-agent“, der Belege, Ausgabeart, Aktualität, negative Semantik und Schreibschutzstatus definiert. Der Planer erstellt zunächst Ziele (z. B. symptom.http_502, route.edge_to_ingress) und eine Abbruchbedingung: Jedes erforderliche Ziel muss entweder gelöst oder explizit nicht verfügbar sein. Eine Belegsperre verhindert, dass der Finalisierer zu einem Schluss kommt, bevor alle Ziele erfüllt sind. Die Tool-Auswahl erfolgt stufenweise: Filterung nach Richtlinien, lexikalische Vorfilterung, LLM-Neubewertung (Top 8), dann Zielrelevanzprüfung. Für riskante Absichten gibt es deterministische Vorab-Routen. In der abschließenden Evaluierung bestanden 44 von 45 Szenarien (29 von 29 Pflichtszenarien), jeweils zweimal durchgeführt. Der einzige fehlgeschlagene Test betraf ein optionales Kapazitätsberichtsformat. Der Agent bleibt schreibgeschützt; Änderungen in der Produktion werden von Menschen entschieden.