OpsAgents: Dziesięć agentów LangGraph do pracy w chmurze i w środowiskach DevOps.
Przewodnik po dziesięciu agentach DevOps z udziałem człowieka, zbudowanych na bazie LangGraph, od Terraform i Kubernetes po skanowanie Trivy, obejmujący zasady projektowania oraz wyciągnięte wnioski.
Źródła: DevOps Agents From the 2026 Guide to a Real Working Repo in 10 Agents
Inżynierowie ciągle zadają to samo pytanie o agenty DevOps, tylko innymi słowami: czy coś takiego naprawdę istnieje, gdzie jest kod i czy można to uruchomić już dziś? Koncepcje mają swoje ograniczenia, więc praktyczną odpowiedzią jest OpsAgents – zbiór dziesięciu agentów AI do zarządzania chmurą i procesami DevOps, stworzony przy użyciu LangGraph i Pythona. Działa zarówno jako narzędzie wiersza poleceń, jak i serwer MCP.
Uwaga dotycząca wersji beta: OpsAgents znajduje się w fazie beta. Nie używaj go w środowiskach produkcyjnych. Mogą pojawić się nieprzewidziane zmiany bez uprzedzenia, a korzystasz z niego na własne ryzyko.
Zasady projektowe
Człowiek potwierdza każdą destruktywną akcję. Zwiększanie skali implementacji, stosowanie Terraform lub uruchamianie instrukcji operacyjnych sprawiają, że agent zatrzymuje się i pyta przed dokonaniem czegokolwiek nieodwracalnego. Nie jest to ustawienie, które można wyłączyć, ponieważ infrastruktura produkcyjna nie powinna na to pozwalać.
Maszyny stanowe, a nie kruche łańcuchy poleceń. Każdy agent to graf skierowany, w którym stan przemieszcza się pomiędzy węzłami. Jeśli jakiś krok zawiedzie w trakcie, stan zostaje zachowany, a agent może się odzyskać. Dzięki funkcji checkpointing agent przetrwa restart bez utraty postępów.
Prawdziwe integracje. Agenci współpracują z AWS Cost Explorer, CloudWatch, CloudTrail, IAM, SSM i EC2, wykonują rzeczywiste operacje w Kubernetes za pomocą kubectl, wykorzystują Trivy do skanowania CVE oraz generują pliki JSON z dashboardami Grafana, które można wstawić do istniejącej struktury. Nic z tego nie jest symulowane ani udawane.
Wielu dostawców modeli. Claude, GPT-4, Gemini, Mistral i Ollama wszystkie działają, przy czym Ollama umożliwia pełnie lokalne, izolowane uruchomienia. Framework nie jest zależny od żadnego konkretnego dostawcy.
Dwa sposoby uruchomienia
W trybie CLI możesz uruchomić dowolnego agenta bezpośrednio z terminala, co nadaje się do operacji ad hoc, pisania skryptów i testowania.
W trybie serwera MCP OpsAgents łączy się z Claude Code, Cursor, Codex lub OpenCode, dzięki czemu możesz komunikować się ze swoją infrastrukturą jak z kolegą z zespołu. Po skonfigurowaniu serwera MCP w edytorze każdy agent staje się narzędziem, którego może używać edytor. Możesz poprosić go o przeszukanie klastra w poszukiwaniu awaryjnych podów lub o przygotowanie raportu dotyczącego rachunku AWS za ten miesiąc, a odpowiedni agent zajmie się prośbą, pokazując potwierdzenie przed jakimikolwiek zmianami.
Dziesięć agentów
Agenci chmurowe (AWS)
Dostawca infrastruktury. Narzędzie to obejmuje cały cykl życia Infrastructure-as-Code. Opisz po prostu, czego chcesz – na przykład publiczną VPC z dwoma podsieciami w różnych strefach dostępności – a narzędzie utworzy kompletny plik Terraform lub CloudFormation. Następnie sprawdza składnię i uruchamia terraform plan, dzięki czemu widzisz dokładnie, co się zmieni, zanim jakikolwiek zasób zostanie utworzony, a zmiany są wprowadzane tylko po interaktywnej potwierdzeniu. Później może przeprowadzić audyt aktualnego konta AWS i zaznaczyć odchylenia od konfiguracji przechowywanej w Git, co pozwala wykryć ręczne zmiany, które omijają proces Infrastructure-as-Code.
- Język naturalny na kompletny plik Terraform lub CloudFormation, a nie tylko szkielet
- Walidacja składni oraz symulacja planu przed wykonaniem
- Wprowadzanie zmian po potwierdzeniu przez człowieka
- Detekcja odchyleń pomiędzy aktualnym stanem AWS a konfiguracją zapisaną w Git
Bезpieczeństwo i zgodność. Konta produkcyjne w AWS stopniowo narażają się na ryzyko. Zasady IAM z czasem stają się mniej restrykcyjne, grupy bezpieczeństwa są otwierane w celach diagnostycznych i nigdy nie zamykane, a pojemniki S3 są źle skonfigurowane. Ten agent przeprowadza ciągłe audyty zamiast polegać na sporadycznych sprawdzeniach. Szuka uprawnień typu wildcard w zasadach IAM oraz nadmiernie uprzywilejowanych danych logowania, identyfikuje grupy bezpieczeństwa EC2 z dostępem publicznym (np. SSH otwarty na 0.0.0.0/0), a także sprawdza pojemniki S3 pod kątem braku szyfrowania i dostępu do danych dla wszystkich użytkowników. Wyniki są porównywane z standardem CIS AWS Foundations Benchmark, dzięki czemu otrzymuje się oceny stopnia powagi, a nie zwykłą listę.
- Analiza IAM obejmująca uprawnienia typu wildcard, ścieżki eskalacji i nieużywane uprawnienia
- Audyty grup bezpieczeństwa pod kątem portów publicznych i zbyt luźnego dostępu
- Audyty pojemników S3 dotyczące stanu szyfrowania i dostępu publicznego
- Porównanie wskaźników CIS wraz z oceną powagi problemu
Optymalizator kosztów. Rachunki AWS zawierają marnotrawstwa, których nikt nie ma czasu ręcznie wykrywać: nieprzyłączone woluminy EBS, instancje EC2 pracujące na 3% mocy obliczeniowej przez miesiące, Elastic IP przydzielone do niczego, a także zakres usług Reserved Instance, który zmienia się wraz ze zmianami floty. Agent wysyła zapytania do Cost Explorer w celu uzyskania raportów o wydatkach, znajduje nieużywane zasoby według typu i regionu, sugeruje dostosowanie rozmiaru dla słabo wykorzystywanych zasobów obliczeniowych oraz wskazuje, gdzie plany oszczędnościowe lub Reserved Instance mogą zmniejszyć wydatki. Każda rekomendacja zawiera szacunkową miesięczną oszczędność.
- Zapytania do Cost Explorer według usługi, regionu i okresu
- Wykrywanie nieprzyłączonych woluminów, bezczynnych instancji oraz nieużywanych Elastic IP
- Porady dotyczące dostosowania rozmiaru z szacunkowymi oszczędnościami
- Analiza zakresu planów oszczędnościowych i Reserved Instance
Reakcja na incydenty. Po wywołaniu alarmu w środowisku produkcyjnym najważniejsze są pierwsze 15 minut. Ten agent rozpoczyna dochodzenie równolegle, zanim osoba ludzka w pełni się obudzi. Zbiera wszystkie alarmy CloudWatch znajdujące się obecnie w stanie ALARM, wyszukuje w Log Insights najnowsze błędy oraz wykazuje wywołania API CloudTrail z okresu awarii – taka kombinacja zazwyczaj ujawnia, co się zmieniło. Jeśli pasuje standardowe podręcznik postępowania SSM, może je uruchomić po twojej potwierdzeniu. Po rozwiązaniu problemu tworzy ustrukturyzowany raport typu post-mortem w formacie markdown, obejmujący chronologię wydarzeń, przyczynę podstawową oraz środki łagodzące.
- Agregacja alarmów pokazująca, co znajduje się w stanie ALARM, od kiedy i jakie zasoby
- Analiza przyczyny podstawowej na podstawie danych z Log Insights oraz historii CloudTrail
- Wykonanie procedury z podręcznika SSM po uzyskaniu zatwierdzenia
- Stworzone raporty post-mortem
Przegląd architektury. Większość zespołów sprawdza swoją architekturę w oparciu o AWS Well-Architected Framework raz podczas wdrożenia i rzadko ponownie. Ten agent utrzymuje to sprawdzanie w biegu. Odkrywa bazy danych RDS, instancje EC2, balansery obciążenia, funkcje Lambda oraz pojemniki S3 bez konieczności podawania informacji o istniejących elementach, a następnie tworzy diagramy przepływu w formacie Mermaid pokazujące, w jaki sposób są one połączone. Ocenia ustawienia pod kątem filarów Well-Architected i zaznacza braki, takie jak brak wdrożenia w kilku regionach, RDS bez automatycznych kopii zapasowych oraz architektury jednoregionalne, mimo że planowano architekturę wieloregionalną.
- Automatyczne odkrywanie, więc nie jest potrzebna ręczna inwentaryzacja
- Diagramy topologiczne w formacie Mermaid tworzone na podstawie aktualnych danych
- Ocena filarów dotyczących niezawodności, wydajności i kosztów
- Specyficzne informacje na temat wielu regionów, kopii zapasowych i wąskich gardeł
Agenci DevOps (operacje platformy)
Przepływ CI/CD. Wszyscy mają swoje opinie na temat przepływów budowania oprogramowania, a nikt nie ma czasu na ich optymalizację. Ten agent analizuje bazę kodu i tworzy dostosowaną konfigurację przepływu zamiast korzystać z ogólnego szablonu. Wykrywa język, menedżera pakietów oraz system budowania, a następnie tworzy workflow w GitHub Actions z cache’owaniem zależności, minimalnymi uprawnieniami (OIDC zamiast długotrwałych haseł) oraz rozsądnym rozdzieleniem zadań. Gdy przepływ zawodzi, agent analizuje logi i podaje dokładną diagnozę – nie „budowa się nie udała”, lecz coś w rodzaju błędu cache’u spowodowanego edycją pliku lockfile, która sprawiła, że hasz klucza cache’u stał się przestarzały.
- Wykrywanie języka, menedżera pakietów i systemu budowania
- Tworzenie workflow z cache’owaniem, OIDC i kontrolą uprawnień
- Diagnoza nieudanej budowy z określoną przyczyną i rozwiązaniem
Operacje w Kubernetes. Ten agent zachowuje się jak administrator klastra, posiadający pełne uprawnienia diagnostyczne i naprawcze, i jest prawdopodobnie najbardziej przydatny do pracy w trybie on-call. Podsumowuje stan węzłów, przestrzeni nazw oraz kontenerów systemowych w jednej tabeli. W przypadku awaryjnych kontenerów stosuje specjalne ścieżki diagnostyczne dla przypadków CrashLoopBackOff, OOMKilled i ImagePullBackOff, analizując odpowiednie zdarzenia i warunki. Tworzy pliki YAML dla zasobów typu Deployments, Ingresses i Services, a także może skalować liczbę kopii lub bezpośrednio dokonać cofnięcia po potwierdzeniu.
- Podsumowanie stanu klastra w jednej tabeli
- Strukturyzowana diagnostyka kontenerów dla częstych stanów awaryjnych
- Generowanie plików YAML dla Deployments, Ingresses i Services
- Skalowanie i cofnięcie po potwierdzeniu
Monitorowanie i widoczność. Wszyscy zgadzają się, że konfiguracja monitoringu jest ważna, ale uważają ją za uciążliwą. Składnia PromQL jest wymagająca, JSON interfejsu Grafana jest rozbudowane, a drzewa routingu w Alertmanagerze łatwo błędnie skonfigurować. Ten agent tworzy reguły alertingowe w PromQL dla typowych wskaźników, takich jak wskaźnik błędów, procentyle opóźnień i poziom nasycenia, generuje gotowe do imporту pliki JSON interfejsu Grafana z zapytaniami do paneli oraz projektuje schematy routingu dla Alertmanagera przeznaczone do integracji z Slackiem lub PagerDuty. Na podstawie założonego poziomu dostępności, np. 99,9% lub 99,95%, oblicza również miesięczny budżet błędów oraz maksymalny dopuszczalny czas przestoju.
- Środki do tworzenia zapytań PromQL dla standardowych wskaźników infrastruktury
- Pliki JSON interfejsu Grafana gotowe do importu
- Schematy routingu Alertmanagera dla Slacka i PagerDuty
- Obliczenia związane z SLO, w tym budżet błędów i dopuszczalny czas przestoju
GitOps i wypuszczanie nowych wersji. Ten agent zajmuje się pracami związanymi z wypuszczaniem nowych wersji w kontekście implementacji: plikami konfiguracyjnymi, dziennikami zmian, podwyższaniem wersji oraz przygotowaniem do cofnięcia zmian. Tworzy manifesty aplikacji ArgoCD z funkcjami samoregeneracji i oczyszczania, a także konfiguracje Argo Rollouts do wypuszczania nowych wersji w trybie kanaryjnym lub blue-green, wraz z AnalysisTemplates umożliwiającymi automatyczne podejmowanie decyzji o promocji. W przypadku wypuszczania nowych wersji podnosi tagi semver, tworzy dzienniki zmian na podstawie historii komitetów i może tworzyć prośby o cofnięcie zmian, gdy konieczne jest szybkie odwrócenie implementacji.
- Manifesty ArgoCD z funkcjami samoregeneracji, oczyszczania i polityk synchronizacji
- Wypuszczanie nowych wersji w trybie kanaryjnym i blue-green z AnalysisTemplates
- Podwyższanie wersji semver i dzienniki zmian z historii git
- Tworzenie prośb o cofnięcie zmian
Bezpieczeństwo kontenerów i obrazów. Bezpieczeństwo łańcucha dostaw nie jest już opcjonalne w 2026 roku, a ten agent przeprowadza skanowanie oraz wzmacnianie zabezpieczeń, które powinny zostać zrealizowane przed wpuszczeniem jakiegokolwiek obrazu do produkcji. Sprawdza warstwy kontenerów pod kątem luk bezpieczeństwa CVE za pomocą Trivy i raportuje stopień powagi oraz dotknięte pakiety. Analizuje pliki Dockerfile i przeprowadza ich refaktoryzację poprzez budowę wieloetapową w celu zmniejszenia rozmiaru obrazu, czyszczenie cache, aby uniknąć nadmiernego rozrostu warstw, oraz wykorzystanie użytkowników innych niż root. Skanuje pliki lockfile (poetry.lock, package-lock.json, Gemfile.lock) w poszukiwaniu przestarzałych lub podatnych na ataki zależności, a w celu zapewnienia zgodności generuje raporty składu oprogramowania w formacie CycloneDX lub SPDX.
- Skanowanie luk CVE za pomocą Trivy z oceną stopnia powagi
- Wzmacnianie zabezpieczeń plików Dockerfile
- Skanowanie plików lockfile w celu wykrycia przestarzałych i podatnych na ataki pakietów
- Wydawanie raportów SBOM w formatach CycloneDX i SPDX
Dlaczego u podstaw znajduje się LangGraph
Mogło tu posłużyć kilka frameworków, w tym LangGraph, Claude SDK, OpenAI Agents SDK, CrewAI oraz AutoGen. LangGraph wygrał, ponieważ jego zalety odpowiadają wymaganiom DevOps.
Procesy produkcyjne nie są liniowe. Skan bezpieczeństwa, który wykrywa krytyczny problem z IAM, musi być kierowany inaczej niż ten, który nic nie znajduje, a dochodzenie w przypadku incydentu, które nie potrafi określić przyczyny źródłowej w logach, powinno zostać przekazane do CloudTrail. Warunkowe kierowanie ruchem w LangGraph rozwiązuje to sprawnie.
Trwałość stanu oznacza, że agent działający w trakcie złożonego incydentu przetrwa restart bez utraty uzyskanych informacji. Funkcja punktów kontrolnych umożliwia odtworzenie procesu pracy z dowolnego węzła z zmienionymi danymi wejściowymi, co jest niezbędne podczas debugowania agenta, który podjął zaskakującą decyzję. Ponadto wsparcie ludzkiego operatora jest częścią samego modelu grafu, a nie dodatkowym elementem. To ty decydujesz, które węzły wymagają potwierdzenia, a graf w tym miejscu się zatrzymuje.
Lekcje z budowy
Trzy rzeczy nie były oczywiste, dopóki nie powstały agenci:
- Krok potwierdzenia jest kluczowy. Dobrze umieszczone pytanie przed działaniami destrukcyjnymi odróżnia przydatnego agenta od niebezpiecznego. Prawidłowe jego wykonywanie oznacza traktowanie zatwierdzenia przez człowieka jako ograniczenia architektonicznego, a nie tylko jako pola do zaznaczenia, co zmusza do ustalenia, które węzły w każdym grafie faktycznie powodują skutki uboczne.
- Projektowanie stanu to najtrudniejsza część. Uruchomienie logiki agenta jest łatwe. Decydowanie o tym, co musi zostać zachowane, co jest tymczasowe oraz jak przenoszą się błędy, wymaga wielokrotnych prób – agent Kubernetes przeszedł przez trzy przeredagowania swojego stanu, zanim proces diagnostyczny stał się naturalny.
- Narzędzia są ważniejsze niż wybór modelu. Agent jest tak skuteczny, jak tylko pozwalają na to jego narzędzia. Umożliwienie funkcjom narzędzi AWS zwracania ustrukturyzowanych, spójnych wyników przyniosło większe korzyści niż modyfikowanie zapytań, ponieważ model lepiej rozumuje, gdy otrzymuje czyste dane.
Co następuje
To jest punkt wyjścia, a nie produkt końcowy. Agenty obejmują najczęściej spotykane procesy w chmurze i DevOps, ale pozostaje jeszcze wiele do zrobienia. Rozważane kierunki rozwoju to m.in. obsługa wielu chmur za pomocą agentów GCP i Azure, wykrywanie anomalii kosztowych oparte na historycznych wzorcach zamiast statycznych progów, automatyczne naprawianie odchyleń, przy którym agent generuje i stosuje rozwiązanie po uzyskaniu zatwierdzenia, oraz lepsza integracja z mechanizmami Claude Code i Cursor MCP.
Jak przyczynić się do rozwoju
Nie musisz być ekspertem – wystarczy ciekawość. Najbardziej przydatna pomoc zależy od tego, kim jesteś:
- Inżynier DevOps lub chmurowy: uruchom agent na rzeczywistej infrastrukturze i opisz, co się zepsuło, jakie wyniki były mylące oraz jaki proces zakładałeś, że agent ma obsłużyć. Informacje z praktyki to w tym etapie najcenniejszy materiał do analizy.
- Rozwijający: wybierz dowolnego agenta, przeczytaj jego definicję grafu i ulepsz coś – czy to lepsze radzenie sobie z błędami, brakujące narzędzie, czy pole stanu, które należy śledzić. Baza kodu jest na tyle mała, że można zrozumieć całego agenta w około 30 minut.
- Początkujący w obsłudze agentów DevOps: repozytorium służy jednocześnie jako środowisko edukacyjne. Stwórz jego kopię (fork), uruchom ją lokalnie za pomocą Ollamy, aby uniknąć kosztów API, i przeczytaj kod wraz z ogólnym przewodnikiem po agentach DevOps. Zgłoszenie pytania poprzez otwarcie issue również stanowi wkład.
- Każdy, kto ma pomysł na nowego agenta: otwórz issue opisujące proces pracy. Jeśli coś, co obecnie robisz ręcznie, powinno zostać zautomatyzowane, napisz o tym. Agent do audytu w Secrets Manager, agenci dla wielu chmur oraz agent do wykrywania nieprawidłowości kosztów znajdują się na liście planowanych rozwojów i są dostępne do stworzenia przez kogokolwiek.
Zaobserwuj repozytorium, otwórz problem lub wyślij prośbę o połączenie. Celem są agenci, które działają stabilnie w środowisku produkcyjnym i zostały stworzone w sposób otwarty.