agents llm architecture typescript python rag

OpsAgents: Zehn LangGraph-Agenten für Cloud- und DevOps-Arbeiten.

Eine Übersicht über zehn DevOps-Agenten mit menschlicher Beteiligung, die auf LangGraph basieren – von Terraform und Kubernetes über Trivy-Scans bis hin zu den zugrunde liegenden Designregeln und gelernten Erkenntnissen.

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

Quellen: DevOps Agents From the 2026 Guide to a Real Working Repo in 10 Agents

Ingenieure fragen immer wieder auf unterschiedliche Weise dasselbe bezüglich DevOps-Agenten: Gibt es so etwas wirklich, wo befindet sich der Code und kann es bereits heute laufen? Konzepte helfen nur bis zu einem gewissen Grad, daher ist die praktische Antwort OpsAgents – eine Sammlung von zehn KI-Agenten für Cloud- und DevOps-Aufgaben, die mit LangGraph und Python entwickelt wurden. Sie läuft sowohl als Kommandozeilenwerkzeug als auch als MCP-Server.

Beta-Hinweis: OpsAgents befindet sich noch in der Beta-Phase. Verwenden Sie es nicht in Produktivumgebungen. Änderungen, die zu Fehlfunktionen führen können, treten ohne Vorwarnung auf – Sie nutzen es auf eigene Gefahr.

Entwurfsregeln

Ein Mensch bestätigt jede zerstörerische Aktion. Das Skalieren einer Bereitstellung, das Anwenden von Terraform oder das Auslösen eines Runbooks veranlassen den Agenten, anzuhalten und zu fragen, bevor etwas Unumkehrbares geschieht. Es handelt sich dabei um eine Einstellung, die man nicht deaktivieren kann, denn die Produktiv-Infrastruktur sollte das nicht zulassen.

State-Maschinen – keine brüchigen Prompt-Ketten. Jeder Agent ist ein gerichteter Graph, bei dem der Zustand durch Knoten übertragen wird. Fällt ein Schritt unterwegs aus, bleibt der Zustand erhalten und der Agent kann sich erholen. Durch Checkpointing überlebt ein Agent ein Neustart, ohne Fortschritte zu verlieren.

Echte Integrationen. Die Agenten arbeiten mit AWS Cost Explorer, CloudWatch, CloudTrail, IAM, SSM und EC2 zusammen, führen tatsächliche Kubernetes-Operationen über kubectl aus, nutzen Trivy für echtes CVE-Scanning und erzeugen Grafana-Dashboard-JSON, das man in eine bestehende Stack einfügen kann. Nichts davon ist simuliert oder fake.

Mehrere Anbieter von Modellen. Claude, GPT-4, Gemini, Mistral und Ollama funktionieren alle, wobei Ollama vollständig lokale, abgeschirmte Ausführungen ermöglicht. Das Framework ist nicht von einem bestimmten Anbieter abhängig.

Zwei Möglichkeiten zur Ausführung

Im CLI-Modus starten Sie jeden Agenten direkt aus der Terminal, was sich für ad-hoc-Aufgaben, Skripting und Tests eignet.

Im MCP-Server-Modus wird OpsAgents in Claude Code, Cursor, Codex oder OpenCode integriert, sodass Sie mit Ihrer Infrastruktur wie mit einem Teamkollegen kommunizieren können. Sobald der MCP-Server in Ihrem Editor konfiguriert ist, wird jeder Agent zu einem Tool, das der Editor aufrufen kann. Sie können ihn beispielsweise bitten, das Cluster nach fehlerhaften Pods zu durchsuchen oder einen Bericht über die diesmonatige AWS-Rechnung zu erstellen – der entsprechende Agent bearbeitet den Auftrag und zeigt vor jeder Änderung eine Bestätigungsanfrage an.

Die zehn Agenten

Cloud-Agenten (AWS)

Infrastruktur bereitstellen. Dieser Dienst umfasst den gesamten Lebenszyklus von Infrastructure-as-Code. Beschreiben Sie einfach auf Englisch, was Sie möchten – beispielsweise eine öffentliche VPC mit zwei Subnetzen in verschiedenen Verfügbarkeitszonen – und er erstellt vollständige Terraform- oder CloudFormation-Konfigurationen. Anschließend prüft er die Syntax und führt terraform plan aus, sodass Sie genau sehen, was sich ändern wird, bevor irgendwelche Ressourcen erstellt werden, und wendet die Änderungen nur nach interaktiver Bestätigung an. Danach kann er das aktuelle AWS-Konto auditen und Abweichungen von der in Git gespeicherten Konfiguration aufzeigen, wodurch manuelle Änderungen erkannt werden, die den IaC-Ablauf umgehen.

Von natürlicher Sprache zu vollständigen Terraform- oder CloudFormation-Konfigurationen, nicht nur zu einem Skelett
Syntaxprüfung sowie ein Probelauf vor der Ausführung
Anwendung nur nach menschlicher Bestätigung
Erkennung von Abweichungen zwischen dem aktuellen AWS-Zustand und der in Git gespeicherten Konfiguration

Sicherheit und Konformität. Produktiv-AWS-Konten sammeln leise Risiken an. IAM-Politiken werden im Laufe der Zeit lockerer, Sicherheitsgruppen werden zum Debuggen geöffnet und nie wieder geschlossen, und S3-Bucket werden falsch konfiguriert. Dieser Agent führt kontinuierliche Prüfungen durch, anstatt sich auf gelegentliche Überprüfungen zu verlassen. Er sucht nach Wildcard-Berechtigungen in IAM-Politiken sowie übermäßig berechtigten Anmeldedaten, erkennt EC2-Sicherheitsgruppen mit öffentlichem Zugang (SSH offen für 0.0.0.0/0 ist hier das klassische Beispiel) und überprüft S3-Bucket auf fehlende Verschlüsselung sowie öffentlichen Lesezugriff. Die Ergebnisse werden anhand des CIS AWS Foundations Benchmarks bewertet, sodass Sie Schweregradbewertungen erhalten und nicht nur eine einfache Liste.

IAM-Analyse bezüglich Wildcards, Eskalationspfaden und ungenutzter Berechtigungen
Prüfung von Sicherheitsgruppen auf öffentliche Ports und übermäßig offenen Zugang
S3-Prüfungen auf Verschlüsselungszustand und öffentlichen Zugriff

Vergleich der CIS-Benchmarks unter Berücksichtigung der Schweregrad

Kostenoptimierer. Die Rechnungen von AWS enthalten Verbrauch, den niemand die Zeit hat, manuell aufzuspüren: nicht angegebene EBS-Volumina, EC2-Instanzen, die monatelang mit 3 % CPU-Auslastung herumstehen, Elastic IPs, die nicht verwendet werden, sowie eine Reservierungsquote, die sich mit den Änderungen im Infrastrukturbestand verschiebt. Der Agent fragt Cost Explorer nach Ausgabenberichten, ermittelt nach Typ und Region ungenutzte Ressourcen, schlägt eine Anpassung der Rechenleistung bei untergenutzten Ressourcen vor und weist darauf hin, wo Savings Plans oder Reservierungsinstanzen die Ausgaben senken könnten. Jede Empfehlung enthält eine geschätzte monatliche Einsparung.

Abfragen in Cost Explorer nach Service, Region und Zeitraum
Erkennung von nicht angegebenen Volumina, inaktiven Instanzen und ungenutzten Elastic IPs
Ratschläge zur Anpassung der Rechenleistung mit geschätzten Einsparungen
Analyse der Abdeckung durch Savings Plans und Reservierungsinstanzen

Incident Response. Nach dem Auslösen eines Alarms in der Produktionsumgebung sind die ersten 15 Minuten am wichtigsten. Dieser Agent startet die Untersuchung parallel, noch bevor ein Mensch vollständig wach ist. Er sammelt alle derzeit im Zustand ALARM befindlichen CloudWatch-Alarms, durchsucht Log Insights nach kürzlichen Fehlern und listet die CloudTrail-API-Aufrufe zum Zeitpunkt des Ausfalls auf – eine Kombination, die in der Regel aufzeigt, was sich geändert hat. Falls ein Standard-SSM-Runbook passt, kann es dieses nach Ihrer Bestätigung auslösen. Nach der Behebung erstellt es einen strukturierten Markdown-Post-Mortem-Bericht mit Zeitplan, Ursache und Gegenmaßnahmen.

Aggregation der Alarms, die anzeigen, was sich im Zustand ALARM befindet, seit wann und welche Ressourcen
Ursachenanalyse anhand von Log Insights sowie der CloudTrail-Historie
Ausführung des SSM-Runbooks mit Genehmigung
Erstellte Post-Mortem-Berichte

Architekturüberprüfung. Die meisten Teams prüfen ihr Design einmal bei der Veröffentlichung anhand des AWS Well-Architected Frameworks und nur selten erneut. Dieser Agent sorgt dafür, dass die Überprüfung kontinuierlich stattfindet. Er entdeckt RDS-Datenbanken, EC2-Instanzen, Load Balancer, Lambda-Funktionen sowie S3-Bucket ohne Angabe dessen, was bereits vorhanden ist, und erstellt anschließend Mermaid-Flussdiagramme, die zeigen, wie sie miteinander verbunden sind. Er bewertet die Einstellungen anhand der Kriterien des Well-Architected Frameworks und weist auf Mängel hin, wie fehlende Multi-AZ-Implementierungen, RDS-Datenbanken ohne automatische Backups sowie Designs für eine einzige Region, obwohl eigentlich mehrere Regionen vorgesehen waren.

Automatische Erkennung – es ist daher kein manuelles Inventar erforderlich
Mermaid-Topologie-Diagramme, die aus aktuellen Daten erstellt werden
Bewertung der Kriterien Zuverlässigkeit, Leistung und Kosten
Konkrete Hinweise zu Multi-AZ-Implementierungen, Backups und Engpässen

DevOps-Agenten (Plattformverwaltung)

CI/CD-Pipeline. Jeder hat eine Meinung zu Pipelines, und niemand hat Zeit, sie anzupassen. Dieser Agent analysiert die Codebasis und erstellt eine maßgeschneiderte Pipeline-Konfiguration anstelle eines generischen Templates. Er erkennt die Programmiersprache, den Paketmanager sowie das Build-System und erstellt anschließend GitHub Actions-Arbeitsabläufe mit Abhängigkeitscaching, minimalen Berechtigungen (OIDC anstelle langlebiger Anmeldeinformationen) sowie einer sinnvollen Trennung der Aufgaben. Wenn eine Pipeline fehlschlägt, liest er die Protokolle und liefert eine präzise Diagnose – nicht nur „der Build ist fehlgeschlagen“, sondern beispielsweise ein Cache-Miss, der auf eine Änderung eines Lockfiles zurückzuführen ist, wodurch der Hash der Cache-Schlüssel veraltet wurde.

Erkennung der Programmiersprache, des Paketmanagers und des Build-Systems
Erstellung von Arbeitsabläufen mit Caching, OIDC und Berechtigungssteuerung
Diagnose fehlgeschlagener Builds mit konkretem Grund und Lösung

Kubernetes-Operationen. Dieser Agent verhält sich wie ein Clusteradministrator mit vollständigen Diagnose- und Behebungsmöglichkeiten und ist vermutlich der nützlichste für Notfallaufgaben. Er fasst den Zustand von Knoten, Namespaces und System-Pods in einer Tabelle zusammen. Bei fehlerhaften Containern verfolgt er spezifische Diagnosewege für CrashLoopBackOff, OOMKilled und ImagePullBackOff, indem er Ereignisse und Bedingungen prüft. Er erstellt YAML-Dateien für Deployments, Ingresses und Services und kann nach Bestätigung direkt Replikate skalieren oder zurücksetzen.

Zusammenfassung des Clusterzustands in einer einzigen Tabelle
Gestrukturierte Pod-Diagnosen für häufige Fehlerzustände
Erstellung von YAML-Dateien für Deployments, Ingresses und Services
Skalierung und Rücksetzung nach Bestätigung

Überwachung und Beobachtbarkeit. Alle sind sich einig, dass die Konfiguration der Überwachung wichtig ist, finden sie aber langwierig. Die PromQL-Syntax ist streng, das JSON der Grafana-Dashboards ist umfangreich, und die Routing-Strukturen von Alertmanager lassen sich leicht fehlerhaft konfigurieren. Dieser Agent erstellt PromQL-Alert-Regeln für gängige Kennzahlen wie Fehlerrate, Latenzprozente und Auslastung, generiert Grafana-Dashboard-JSON mit vorbereiteten Abfragungen zum Import sowie Routing-Pläne für Alertmanager in Slack oder PagerDuty. Bei einer Zielverfügbarkeit von beispielsweise 99,9 % oder 99,95 % berechnet er außerdem das monatliche Fehlerbudget sowie die maximale zulässige Ausfallzeit.

PromQL-Vorlagen für Standard-Infrastruktur-Kennzahlen
Importierbares Grafana-Dashboard-JSON
Alertmanager-Routing für Slack und PagerDuty
SLO-Berechnungen, einschließlich Fehlerbudget und Ausfallzeitlimit

GitOps und Veröffentlichungen. Dieser Agent kümmert sich um die Aufgaben rund um Deployments: Konfigurationsdateien, Changelogs, Versionsanpassungen sowie die Vorbereitung von Rollbacks. Er erstellt ArgoCD-Anwendungsmanifeste mit Funktionen zur Selbstheilung und Pflege sowie Argo Rollouts-Konfigurationen für Canary- oder Blue-Green-Veröffentlichungen, wobei AnalysisTemplates zur automatisierten Entscheidungsfindung bei der Freigabe genutzt werden. Bei Veröffentlichungen aktualisiert er die Semver-Tags, erstellt Changelogs aus der Commit-Geschichte und kann bei Bedarf schnell Rollback-Pull-Requests erstellen.

ArgoCD-Manifeste mit Funktionen zur Selbstheilung, Pflege und Synchronisierungsrichtlinien
Canary- und Blue-Green-Rollouts mit AnalysisTemplates
Semver-Updates sowie Changelogs aus der Git-Geschichte
Erstellung von Rollback-Pull-Requests

Sicherheit von Containern und Bildern. Die Sicherheit der Lieferkette ist im Jahr 2026 keine Option mehr, und dieser Agent führt die Scans sowie Optimierungen durch, die vor dem Einsatz eines Bildes in der Produktion erforderlich sind. Er prüft die Container-Ebenen mit Trivy auf CVEs und gibt Schweregrad sowie betroffene Pakete an. Zudem überprüft er Dockerfiles und optimiert sie mithilfe mehrstufiger Builds, um die Größe des Bildes zu verringern, führt Cache-Reinigungen durch, um eine Überlastung der Ebenen zu vermeiden, und verwendet nicht-root-Benutzer. Er scannt Lockfiles (poetry.lock, package-lock.json, Gemfile.lock) auf veraltete oder anfällige Abhängigkeiten und erzeugt zur Einhaltung von Vorgaben CycloneDX- oder SPDX-Bill-of-Materials-Dokumente.

Trivy-CVE-Scans mit Schweregradbewertungen
Optimierung von Dockerfiles
Scanning von Lockfiles auf veraltete und anfällige Pakete
Erstellung von SBOMs im Format CycloneDX und SPDX

Warum LangGraph dahintersteht

Mehrere Frameworks hätten hier zum Einsatz kommen können, darunter LangGraph, das Claude SDK, das OpenAI Agents SDK, CrewAI und AutoGen. LangGraph setzte sich durch, weil seine Stärken mit den Anforderungen von DevOps übereinstimmen.

Produktionsworkflows sind nicht linear. Ein Sicherheitsscan, der ein kritisches IAM-Problem aufdeckt, muss anders weitergeleitet werden als einer, der nichts findet, und eine Incidentsuche, bei der die Ursache in den Logs nicht ermittelt werden kann, sollte an CloudTrail weitergeleitet werden. LangGraphs bedingte Weiterleitungslogik bewältigt das problemlos.

Die Zustandspersistenz bedeutet, dass ein Agent, der mit einem komplexen Vorfall umgeht, nach einem Neustart seine Erkenntnisse behält. Durch Checkpointing können Sie einen Workflow von jedem Knoten aus mit geänderten Eingaben erneut ausführen – was unerlässlich ist, wenn Sie einen Agenten debuggen, der eine überraschende Entscheidung getroffen hat. Zudem ist die Unterstützung durch einen Menschen integraler Bestandteil des Graphenmodells selbst und nicht zusätzlich hinzugefügt. Sie entscheiden, welche Knoten eine Bestätigung benötigen, und der Graph pausiert an dieser Stelle.

Lektionen aus der Entwicklung

Drei Dinge waren erst mit der Existenz der Agenten offensichtlich:

Der BestätigungsSchritt ist entscheidend. Eine gut platzierte Aufforderung vor zerstörerischen Aktionen unterscheidet einen nützlichen Agenten von einem gefährlichen. Dies richtig umzusetzen bedeutet, die menschliche Genehmigung als architektonische Einschränkung und nicht nur als Kästchen zu betrachten, was dazu zwingt, herauszufinden, welche Knoten in jedem Graphen tatsächlich Nebenwirkungen haben.
Die Gestaltung des Zustands ist der schwierige Teil. Die Agentenlogik zum Laufen zu bringen, ist einfach. Die Entscheidung darüber, was persistent sein muss, was vorübergehend bleibt und wie Fehler übertragen werden, erfordert Iterationen – der Kubernetes-Agent durchlief drei Neugestaltungen seines Zustands, bevor der Diagnoseablauf natürlich wirkte.
Tools sind wichtiger als die Wahl des Modells. Ein Agent ist nur so leistungsfähig wie seine Tools. Dass die Funktionen der AWS-Tools strukturierte, konsistente Ausgaben liefern, zahlte sich mehr aus als das Anpassen von Prompts, denn ein Modell denkt besser, wenn die von ihm erhaltenen Daten sauber sind.

Was kommt als Nächstes

Das ist ein Ausgangspunkt und kein fertiges Produkt. Die Agenten decken die gängigsten Cloud- und DevOps-Arbeitsabläufe ab, doch es bleibt noch viel zu tun. In Erwägung gezogene Richtungen umfassen die Unterstützung mehrerer Clouds mit GCP- und Azure-Agenten, die Erkennung von Kostenanomalien anhand historischer Muster statt statischer Schwellwerte, die automatische Behebung von Abweichungen, wobei der Agent die Korrektur erstellt und mit Genehmigung anwendet, sowie eine engere Integration in die Claude Code- und Cursor MCP-Workflows.

Wie Sie beitragen können

Es ist nicht notwendig, ein Experte zu sein – Neugier reicht aus. Die nützlichste Hilfe hängt davon ab, wer Sie sind:

DevOps- oder Cloud-Engineer: Führen Sie einen Agenten auf der echten Infrastruktur aus und berichten Sie, was schiefgelaufen ist, welche Ausgaben Sie verwirrt haben und welchen Arbeitsablauf Sie erwartet hatten. Feedback aus der Praxis ist in dieser Phase der wertvollste Input.
Entwickler: Wählen Sie einen beliebigen Agenten aus, lesen Sie seine Graphendefinition und verbessern Sie etwas – sei es eine bessere Fehlerbehandlung, ein fehlendes Tool oder ein Zustandsfeld, das überwacht werden sollte. Die Codebasis ist klein genug, um einen ganzen Agenten in etwa 30 Minuten zu verstehen.
Neulinge bei DevOps-Agenten: Das Repository dient gleichzeitig als Lernumgebung. Forken Sie es, führen Sie es lokal mit Ollama aus, um keine API-Kosten zu haben, und lesen Sie den Code zusammen mit einer allgemeinen Anleitung zu DevOps-Agenten. Das Eröffnen eines Issues zur Stellung einer Frage zählt bereits als Beitrag.
Jeder, der eine Idee für einen neuen Agenten hat: Eröffnen Sie ein Issue, in dem Sie den Arbeitsablauf beschreiben. Wenn etwas, was Sie heute manuell erledigen, automatisiert werden sollte, geben Sie das an. Ein Secrets Manager-Auditing-Agent, Multi-Cloud-Agenten sowie ein Kostenanomalie-Agent gehören alle zum Roadmap und sind für die Entwicklung offen.

Markieren Sie das Repository, eröffnen Sie ein Issue oder senden Sie einen Pull Request. Das Ziel sind Agenten, die in der Produktion funktionieren und offen entwickelt werden.