DevOps-Agenten im Jahr 2026: MCP, Frameworks und was tatsächlich funktioniert.

Wie DevOps-Agenten funktionieren, warum MCP wichtig ist, welche Frameworks geeignet sind, wo sie in CI/CD, Infrastruktur, Überwachung und Sicherheit helfen, und was immer noch nur Hype ist.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 20269 Min. Lesezeit2138 Wörter

Quellen: The Complete 2026 Guide to DevOps Agents From CI/CD to Production Monitoring

Über einen langen Zeitraum hinweg bedeutete „KI in DevOps“, dass Copilot Ihren Terraform-Code ergänzte. Sie beschrieben das Ziel, es erschien ein Vorschlag, Sie nahmen ihn an oder lehnten ihn ab und gingen weiter. Das Tool war eine intelligentere Autocomplete-Funktion, doch der Entwickler erledigte weiterhin die eigentliche Arbeit. Diese Struktur weicht nun etwas anderem.

Heute übernehmen Agenten Aufgaben, anstatt nur Codevorschläge zu machen. Sie prüfen Pull Requests, bevor ein Mensch sie öffnet, untersuchen Incidents, während Sie noch die Benachrichtigung lesen, scannen Infrastrukturcode auf Sicherheitsprobleme, bevor ein Pipeline-Prozess startet, erkennen Anomalien in Produktivitätsmetriken bereits vor Erreichen von Schwellenwerten und erstellen Runbooks für die gerade abgeschlossenen Incidents. Die Menschen bleiben weiterhin in den Prozessen involviert, doch der Ablauf sieht anders aus. Sie sind nicht mehr der Erste, der einen Pull Request liest oder eine Benachrichtigung bearbeitet. Sie prüfen, was der Agent gefunden hat, entscheiden, was als Nächstes geschehen soll, und kümmern sich um die Fälle, die tatsächlich eine Urteilsfindung erfordern.

Die Adoption ist ungleichmäßig. Eine oft zitierte Umfrageangabe besagt, dass nur etwa 11 % der Organisationen Agenten in großem Umfang vollständig in der Produktion einsetzen, während der Rest irgendwo zwischen einer auffälligen Demo und einem Produktionsproblem liegt. Diejenigen, denen es gelungen ist, dies erfolgreich umzusetzen, arbeiten deutlich anders, und dieser Unterschied zeigt sich in der Bereitstellungsfrequenz, der Reaktionszeit auf Vorfälle sowie der Arbeitsbelastung in den Schichtzeiten. Im Folgenden wird erläutert, was DevOps-Agenten eigentlich sind, das Protokoll, das ihren Zugriff auf Tools ermöglicht, die Frameworks, die zur Erstellung verwendet werden, wo sie heute bereits Vorteile bringen und was noch nicht bereit ist, unüberwacht zu laufen.

Was ein DevOps-Agent ist

Es handelt sich nicht um ein Skript. Ein Skript tut nur das, was sein Autor geschrieben hat, und nichts weiter. Es liest keinen Kontext, denkt nicht über eine Situation nach oder passt sich Umständen an, die niemand vorausgesehen hat. Es ist auch kein Chatbot, denn ein Chatbot antwortet auf Fragen. Ein Agent wird durch Ereignisse ausgelöst, wie zum Beispiel das Öffnen einer Pull Request, das Auslösen einer Benachrichtigung oder das Abschließen eines Pipelines. Er liest den Kontext aus mehreren Quellen, denkt über das Erkannte nach und handelt anschließend oder erzeugt eine Ausgabe, die ein Ingenieur verwenden kann.

Die Architektur setzt sich aus drei Teilen zusammen:

Der Auslöser ist alles, was ihn in Gang setzt: eine Pull Request, eine Benachrichtigung, eine abgeschlossene Bereitstellung, ein Zeitplan oder ein expliziter Aufruf.
Die Tools sind die Ressourcen, auf die er zugreifen kann: die GitHub API, Prometheus, Kubernetes, Loki, AWS und weitere. Die Fähigkeiten eines Agents werden ausschließlich durch seine Tools definiert.

Die Logik ist das, was mit den Ergebnissen gemacht wird. Die Modelllogik bei der Verarbeitung eines Diffs, einer Protokolldatei oder einer Metrikenabfrage erzeugt eine strukturierte Erkenntnis, eine Empfehlung oder eine Entscheidung.

Diese letzte Schritt unterscheidet Agenten von Skripten, und dank des Model Context Protocols wird der Zugriff auf Tools in der Praxis nutzbar.

MCP und warum es hier wichtig ist

MCP wird in allen Kreisen rund um Agenten erwähnt, und für DevOps lohnt es sich, zu verstehen, warum, denn es verändert das, was Agenten tun können.

Was es ist

Das Model Context Protocol ist ein offener Standard, den Anthropic im November 2024 veröffentlicht hat. Laut den meisten Angaben wurde er im Dezember 2025 einer Initiative der Linux Foundation übergeben, der Agentic AI Foundation, die gemeinsam mit Block und OpenAI gegründet wurde, damit kein einzelnes Unternehmen ihn besitzt – genauso wie HTTP und OAuth keinen einzigen Eigentümer haben. Berichten zufolge unterstützen ChatGPT, Gemini, Microsoft Copilot, Cursor und VS Code dieses Protokoll, wobei die Infrastruktur von den großen Cloud-Anbietern bereitgestellt wird. Es wird angegeben, dass es Tausende öffentlicher Server gibt, die Datenbanken, Cloud-Infrastrukturen, Kommunikationswerkzeuge, Observabilitätsplattformen sowie Entwicklerwerkzeuge umfassen. Die Zahlen variieren je nach Quelle, daher sollte man jede einzelne Zahl nur als ungefähre Angabe betrachten.

Das Problem, das es löst, ist die Fragmentierung. Früher benötigte jeder KI-Client eine eigene Integration für jedes Tool. Die GitHub-Unterstützung in einem Code-Assistenten bestand aus anderem Code als die in einem anderen Editor und wiederum anders als in einem dritten – man musste sie also dreimal schreiben. Mit MCP baut man einen einzigen Server, den jeder kompatible Client aufrufen kann.

Ein Server kann drei Arten von Funktionalitäten bereitstellen:

Ressourcen ermöglichen es dem Modell, Informationen abzurufen, ohne sie zu ändern – beispielsweise eine Datei, eine Datenbankzeile, eine API-Antwort oder das Ergebnis einer Metrikenabfrage. Sie zeigen dem Agenten, wie die Dinge derzeit aussehen.
Tools sind Funktionen, die das Modell aufrufen kann, um Aktionen auszuführen: eine Bereitstellung auslösen, einen Kommentar auf GitHub hinterlassen oder eine Kubernetes-Bereitstellung skalieren.
Prompts sind wiederverwendbare Vorlagen für vorgefertigte Workflows: einen Sicherheitsscan durchführen, einen Vorfall zusammenfassen oder ein Handbuch erstellen.

Transport

Bis Anfang 2026 wurde der ältere SSE-Transport durch reines HTTP ersetzt, da dieses Protokoll die OAuth 2.1-Authentifizierung unterstützt und die zukünftige Entwicklung verfolgt. Wenn Sie derzeit Server auswählen oder entwickeln, sollten Sie HTTP mit OAuth 2.1 verwenden.

Welche Server gibt es für DevOps?

Das Angebot wuchs von einigen Dutzend Servern zu Beginn des Jahres 2025 auf Hunderte öffentlicher Servere im darauffolgenden Jahr, wobei Google Colab im April 2026 eigene Server bereitstellte. Für DevOps decken bereits erste-Partei- und offizielle Server die wichtigsten Bereiche ab: Cloud-Anbieter, Observabilitätsplattformen, Kubernetes, CI-Systeme sowie Quellcode-Hosts. Ein Anthropic-Plugin-Paket kombiniert Server von AWS, GCP, Datadog und Sentry mit Befehlen wie /incident, /deploy und /rollback, was den SRE-Arbeitsabläufen eine Ausgangsbasis bietet.

Das Schreiben eigener Lösungen ist mit den offiziellen Python- und TypeScript-SDKs unkompliziert. Ein typisches Beispiel ist ein Kubernetes-Server, der Agenten Lesezugriff sowie eine begrenzte Anzahl an Schreiboperationen auf einem Cluster gewährt.

Framework auswählen

Mehrere Frameworks spielen bei der Entwicklung von DevOps-Agenten eine Rolle, und der häufigste Fehler bei Teams besteht darin, aufgrund von Hype statt aufgrund der Passgenauigkeit zu wählen.

LangGraph modelliert einen Agenten als gerichteten Graphen. Die Knoten sind Funktionen wie Agenten, Tools oder Entscheidungspunkte, die Kanten stellen Übergänge dar, und der Zustand fließt durch den Graphen. Das entspricht den Anforderungen von Produktivworkflows:

Ableitung von Entscheidungen anhand der Ergebnisse: Ein fehlgeschlagener Sicherheitsscan leitet den Vorgang zur Eskalation weiter, ein erfolgreicher Scan geht direkt zur Bereitstellung über.
Checkpointing, damit ein Neustart mitten in einer Untersuchung nichts verloren geht.
Pausen an ausgewählten Knoten, bei denen ein Mensch auf Zustimmung wartet.

Wiederholung eines beliebigen Workflows an jedem Punkt mit geänderten Eingaben, was für das Debuggen unerlässlich ist.

LangSmith fügt schrittweises Protokollieren mit Tokenzählungen pro Knoten hinzu und ermöglicht es, während des Laufs geänderte Eingaben einzufügen – genau die Art von Debugging, die ein Infrastrukturteam benötigt, wenn ein Agent um 2 Uhr morgens ungewöhnliches Verhalten zeigt. Wählen Sie LangGraph für komplexe, mehrstufige Workflows, bei denen der Zustand erhalten bleiben muss, Fehler strukturiert behoben werden sollen, Genehmigungen erforderlich sind und die Audit-Trail von Bedeutung ist – was in der Produktion stets der Fall ist.

The Claude Agent SDK ist Anthropics Agent-Framework, das auf der Architektur hinter Claude Code basiert. Es eignet sich für Produktionsagenten, die Hooks, MCP, Skills, Subagenten sowie die Verwendung von Anthropic-eigenen Tools benötigen. Die MCP-Unterstützung ist bereits integriert: Übergeben Sie die Serverkonfigurationen, und das SDK kümmert sich um die Tool-Entdeckung, -Routierung und -Ausführung – es ist daher kein zusätzlicher Wrapper-Code erforderlich. Am besten funktioniert es mit erweitertem Denken, Tool-Nutzung und Vision-Funktionen. Wählen Sie es, wenn Sie Claude-basierte Agenten einsetzen, die einfachste MCP-Integration wünschen, für unklare Fälle erweitertes Denken benötigen oder Agenten in Claude Code-Arbeitsabläufe integrieren möchten.

The OpenAI Agents SDK ist ein leichtgewichtiges Python-Framework, das mit vielen Anbietern sowie über hundert Modellen zusammenarbeitet. Sein herausragendes Merkmal für DevOps sind die klaren Übergabeprozesse sowie eine saubere Verteilung der Aufgaben zwischen spezialisierten Agenten. Wählen Sie es, um einen schnellen Weg vom Prototypen bis zur Produktion zu gehen, um flexibel zwischen Claude, GPT-4o oder Gemini wechseln zu können, oder für Workflows, die sich natürlich auf solche Übergabeprozesse beziehen.

Wo Agenten eingesetzt werden

CI/CD

Hier ist die Adoption am weitesten fortgeschritten. Teams berichten von Pipelines, die durch intelligente CI/CD-Agenten um 30 bis 50 Prozent schneller ablaufen und bei denen 20 bis 40 Prozent weniger fehlgeschlagene Deployments auftreten – Zahlen, die auf Selbstberichten beruhen und vom Ausgangswert abhängen. Heute werden drei Aufgaben zuverlässig erledigt.

Prüfung von Pull-Requests. Ein Agent prüft den PR vor einem Menschen. Nehmen wir eine Änderung an einer Zahlung-API, die eine Wiederholungslogik für fehlgeschlagene Transaktionen hinzufügt:

Der Agent liest den Diff – insgesamt 47 Dateien.
Mithilfe von MCP markiert er die riskanten Änderungen: eine neue Wiederholungslogik in einem Zahlungsdienst, eine Erhöhung der Anzahl der Wiederholungsversuche von 3 auf 10 sowie eine verkürzte Timeout-Zeit des Schaltkreisbrechers.
Er fragt den Deployment-Verlauf über einen Argo CD-Server ab und stellt fest, dass zwei der letzten fünf Deploys zu Incidents führten – ein ausreichend hoher Anteil, um dies zu markieren.
Er überprüft die Sicherheitsmuster mit Semgrep und SAST-Tools und weist auf eine Wiederholungsschleife hin, bei der weder exponentieller Backoff noch Jitter vorhanden sind, was ein „Thundering Herd“-Risiko darstellt.
Er veröffentlicht einen Überprüfungscomment, der auf spezifische Zeilen verweist.

Pipeline-Intelligenz. Traditionelle CI-Systeme führen jede Phase für jeden Commit aus. Ein Agent liest den Diff und wählt die Phasen aus, sodass eine Änderung in den Dokumenten in drei Minuten abgeschlossen ist, während eine Änderung im Zahlungsdienst das gesamte Testprogramm einschließlich Leistungsprüfungen erfordert.

Implementierungsrisiko. Vor jeder Produktionseinrichtung prüft ein Agent die Implementierungshistorie, den aktuellen Zustand des Services, die Ergebnisse von Zeit- und Sicherheitsscans und gibt eine bewertete Empfehlung samt Begründung zurück.

Infrastruktur

Bei Infrastructure as Code führen Agenten eine systematische Erstprüfung durch: Sicherheitsfindungen mit Schweregradangabe, Kostenschätzungen basierend auf aktuellen Preisen über einen AWS Pricing-Server, Überprüfungen der Namenskonventionen sowie eine Zusammenfassung des Plans, bevor ein Mensch sich den Pull Request ansieht. Bei der Erstellung von IaC generieren Agenten mit einem aktiven Terraform Registry-Server und Preisdaten Konfigurationen, die zu Ihrem aktuellen Umfeld passen, anstatt Vorlagen, die auf zwei Jahre alten Praktiken aus Schulungsdaten beruhen.

Überwachung

Observability-Agenten lernen, wie sich das Normalverhalten jedes Services zu jeder Stunde und unter unterschiedlichen Lasten darstellt, und geben bei Verhaltensabweichungen Alarm – anstatt auf statische Schwellenwerte zu achten. Wenn um 3:47 Uhr morgens etwas Ungewöhnliches auftritt, überprüft der Agent kürzliche Bereitstellungen, verwandte Services sowie Infrastrukturereignisse und sendet anschließend eine Benachrichtigung, in der korrekt ein externer Anbieter als Ursache genannt wird – ohne den Bereitschaftsdienst wegen etwas zu alarmieren, gegen das niemand etwas unternehmen kann.

Incident Response

Ein Incident-Agent kann die ersten 15 Minuten der Untersuchung automatisch durchführen. Mehrere MCP-Server werden gleichzeitig abgefragt: Prometheus liefert Metriken, Loki protokolliert, Argo CD den Bereitstellungsverlauf und Tempo die Spuren. Anschließend werden diese Informationen zu einer Hypothese über die Ursache zusammengeführt, zusammen mit einem vorgeschlagenen Lösungsweg. Der auf Abruf bereite Ingenieur erhält eine strukturierte Analyse anstelle einer einfachen Benachrichtigung. Ein SaaS-Unternehmen berichtet, dass es die durchschnittliche Zeit bis zur Lösung um 35 Prozent verkürzen konnte, weil die Agenten Anomalien entdeckten, die Menschen im Störgeräusch übersehen hatten.

Sicherheit

Sicherheits-Agenten, die rund um die Uhr aktiv sind, erkennen Probleme, die einmalige Scans übersehen. Ein planmäßig arbeitender Compliance-Agent kann Bildsignaturen überprüfen, Produktbilder mit aktuellen CVE-Berichten vergleichen, den Clusterzustand gegenüber OPA-Richtlinien testen und Beweismittel für Prüfer zusammenstellen. Secrets-Audit-Agenten scannen die gesamte Git-Geschichte nach Zugangsdaten, die bereits vor jedem Scan existierten.

Eine vernünftige Adoptionsstrategie

Phase 1: Geringes Risiko und schneller Nutzen. Ein Prüfagent für Pull-Requests (ein kommerzielles Produkt wie CodeRabbit oder ein maßgeschneiderter Agent über das Claude SDK zusammen mit einem GitHub-Server) sowie ein Prüfagent für IaC (LangGraph in Kombination mit Terraform und AWS IAM-Servern).
Phase 2: Nach etwa 30 Tagen. Ein Intelligenzagent für Pipelines über das OpenAI Agents SDK sowie eine Anomalieerkennung mithilfe von Plattformfunktionen wie denen von Datadog oder Dynatrace.
Phase 3: Nach etwa 60 Tagen. Ein Incident-Response-Agent (LangGraph mit Prometheus, Loki und Kubernetes-Servern) sowie ein Risikobewertungsmodul für Deployments, das auf den Daten der früheren Phasen basiert.
Phase 4: Ausgereift. Autonome Rollback-Mechanismen mit Argo Rollouts sowie ein Analysetemplate, außerdem ein planmäßiger Compliance-Agent, der Beweismittelpakete erzeugt.

Eine ehrliche Bewertung

Die Vorteile ergeben sich aus eher unspektakulären Aspekten: intelligentere CI/CD-Prozesse, schnellere Überprüfungen, proaktive Behebung von Problemen sowie Kosteneinsparungen. Die Werbung verspricht vollständige Autonomie sowie „set-and-forget“-Pipelines – doch das existiert bisher noch nicht. Was heute funktioniert: Überprüfung von Pull Requests, Überprüfung von IaC-Dateien, Erkennung von Anomalien sowie Untersuchung von Vorfällen. Was überbeworben wird: vollständig autonome Deployment-Pipelines sowie KI, die das Urteilsvermögen der Techniker bei neuen Fehlerarten ersetzt.

Die Teams, die die Lücke zwischen Pilotprojekten und Produktivumgebungen überbrücken, beginnen klein, messen die Ergebnisse, bauen Schritt für Schritt Vertrauen auf und erweitern die Autonomie, sobald die Zuverlässigkeit nachgewiesen ist – und nicht, weil ein Anbieter es versprochen hat. Die Aufgabe des Ingenieurs verschiebt sich vom Konfigurieren hin zu Infrastrukturdesign, Kostenstrategie und Zuverlässigkeitsengineering. Die Rolle ändert sich, verschwindet aber nicht; diejenigen, die erfolgreich sind, sind diejenigen, die Agentensysteme entwickeln und verwalten.