Praktische Erfahrungen beim Ersetzen des Automatisierungsstacks durch MCP-Server und lokale LLMs

Setup und Hardware

Der Entwickler betreibt eine Mischung aus Qwen 2.5 32B (quantisiert) und Llama 3.3 70B auf einem Dual-3090-System. Jede Automatisierungsaufgabe erhält einen eigenen MCP-Server, der Werkzeuge bereitstellt, die das Modell aufrufen kann – ähnlich einer API, die ein LLM nutzt, statt eines Menschen.

Was gut funktioniert

• Automatisierte Code-Überprüfung: Das Modell zeigt über MCP-Werkzeuge auf einen Git-Diff und erkennt echte Probleme wie Logikfehler, fehlende Fehlerbehandlung und Race Conditions. Funktioniert etwa 70 % so gut wie eine Überprüfung durch einen Senior-Entwickler.
• Loganalyse und Alarmierung: Der MCP-Server verbindet sich mit dem ELK-Stack, wobei das Modell nach Anomaliemustern sucht. Es hat 3 Produktionsprobleme erkannt, bevor Grafana-Alarme ausgelöst wurden. Der Schlüssel liegt darin, genügend Kontext darüber zu geben, was für Ihr System „normal“ ist.
• Dokumentationsgenerierung: Das Modell liest den Codebestand über MCP-Dateiwerkzeuge und generiert/aktualisiert API-Dokumentation, spart Stunden pro Woche und liefert tatsächlich gute Ausgabequalität.

Was (noch) nicht funktioniert

• Mehrstufige Argumentationsketten: Alles, was mehr als 3–4 Werkzeugaufrufe in Folge erfordert, gerät aus dem Ruder, da das Modell den Kontext des ursprünglichen Ziels verliert. Kleinere Kontextfenster verschlimmern dies. Chain-of-Thought-Prompting hilft, löst das Problem aber nicht.
• Echtzeit-Entscheidungsfindung: Die Latenz bei 70B-Modellen bedeutet, dass dies nicht für zeitkritische Aufgaben verwendet werden kann. Die Code-Überprüfungspipeline dauert 2–3 Minuten pro PR, was für asynchrone Workflows in Ordnung, aber für Echtzeitanwendungen unbrauchbar ist.
• Kreative Problemlösung: Lokale Modelle haben Schwierigkeiten mit Aufgaben, die Ansätze erfordern, die in den Trainingsdaten nicht gut repräsentiert sind. API-Modelle (Claude, GPT-4) sind hier deutlich besser.

Wichtige Architekturlektionen

• Halten Sie MCP-Server zustandslos. Lassen Sie das Modell den Zustand über Werkzeugaufrufe verwalten, nicht serverseitige Sitzungen.
• Integrieren Sie Wiederholungslogik in Ihren MCP-Client, nicht in den Server. Modelle machen in etwa 5 % der Fälle fehlerhafte Werkzeugaufrufe.
• Protokollieren Sie jeden Werkzeugaufruf und jede Antwort zur Fehlerbehebung, wenn das Modell etwas Unerwartetes tut.
• Verwenden Sie strukturierte Ausgabe (JSON-Modus) für alles, was nachgelagerte Systeme konsumieren. Freiform-Textausgabe ist ein Debugging-Albtraum.