Tworzenie autonomicznego Copilota SRE w AWS wykorzystującego MCP, Bedrock Nova oraz zatwierdzenie przez człowieka.

Przez około rok branża skupiała się na ChatOps: łączeniu modeli LLM z Slackiem lub Telegramem jako sprytnych narzędzi otaczających procesy CI/CD. Boty czatowe są jednak jedynie widoczną częścią tego rozwiązania. Prawdziwa wartość dla przedsiębiorstw wynika z przejścia od reaktywnych botów czatowych do autonomicznych agentów. Autonomiczny copilot do inżynierii niezawodności serwisów (SRE), zbudowany na Amazon Bedrock (Nova), Model Context Protocol (MCP) oraz AWS, pokazuje, jak to wygląda w praktyce. Robi więcej niż tylko uruchamia procesy – samodzielnie analizuje incydenty w produkcji, pobiera metryki i logi, ustala przyczyny problemów i stosuje naprawy, wszystko to w bezpiecznym środowisku z udziałem człowieka.

Opcja zarządzana: AWS DevOps Agent

Zanim architekt zacznie projektować coś specjalnego, powinien sprawdzić, czy AWS już oferuje takie rozwiązanie. Rzeczywiście, w pewnej formie je dostarcza. AWS wprowadził DevOps Agent na konferencji re:Invent 2025 – w wersji wstępnej od grudnia 2025 roku, a w pełni dostępnym od marca 2026 roku. Jest to zaawansowany system wielu agentów przeznaczony do autonomicznego reagowania na incydenty w środowisku AWS.

Jego możliwości znacznie przewyższają te starszych narzędzi, takich jak DevOps Guru:

• Autonomiczne reagowanie na incydenty. Alarm w CloudWatch uruchamia dochodzenie, które łączy dane telemetryczne, logi, ślady działania systemu, zmiany w kodzie oraz historię implementacji, aby znaleźć przyczynę problemu i opracować plany łagodzenia skutków.
• Proaktywna prewencja. Narzędzie analizuje historyczne wzorce incydentów i proponuje ulepszenia dotyczące możliwości monitorowania, infrastruktury oraz procesów automatyzacji.

Przeglądy gotowości do wdrożenia. Sprawdza zmiany w kodzie oraz procesy wdrażania, zanim trafią one do środowiska produkcyjnego.

Projektowanie z udziałem wielu agentów. Główny orkiestrator kieruje specjalistycznymi podagentami do analizy logów, ustalania przyczyn źródłowych i podobnych zadań – to ten sam model użyty w tym rozwiązaniu.

Szerokie integracje. Datadog, Dynatrace, New Relic, Splunk, PagerDuty, GitHub, GitLab, ServiceNow i Slack łączą się bez dodatkowych ustawień.

Na papierze obejmuje to wszystko, o co może prosić zespół SRE.

Dlaczego tworzyć rozwiązanie dostosowane pod potrzeby?

Problemem jest dostęp. DevOps Agent jest dostarczany w pakiecie z planami wsparcia AWS na poziomie Business+ i Enterprise i nie jest dostępny dla ogółu społeczeństwa na żądanie. Organizacje korzystające z planu Developer Support, startupy, zespoły niezależne lub konsultanci pracujący w kontach klientów bez wsparcia Enterprise po prostu nie mogą go używać.

Sługa zarządzana nadaje się dla zespołów już korzystających z Enterprise Support, które pracują według standardowych wzorców AWS, ponieważ AWS zajmuje się większością zadań, a integracje są szerokie. Dla architekta AI jednak bardziej interesujące jest to, czy wzorzec jest wystarczająco dobrze zrozumiany, aby można go było samodzielnie stworzyć i rozszerzyć tam, gdzie kończy się produkt zarządzany. To właśnie pokazuje ten projekt.

Główny problem: narzędzia na dużą skalę

Narzędzia takie jak Amazon Nova rozumieją systemy rozproszone, architektury AWS oraz złożone procesy debugowania. Od razu po uruchomieniu pozostają jednak „mózgami w słoiku” – nie mogą przeglądać metryk CloudWatch ani edytować tabel DynamoDB.

Używanie narzędzi zewnętrznych dla modeli LLM tradycyjnie oznaczało kruche, spersonalizowane kodowanie:

1. Zdefiniuj schemat JSON dla narzędzia.
2. Napisz funkcję w Pythonie, która je uruchomi.
3. Wbuduj dane uwierzytelniające AWS bezpośrednio do kodu agenta.

To ściśle łączy agenta z infrastrukturą, co powoduje problemy z bezpieczeństwem oraz wąskie gardła w konserwacji.

Pojawia się MCP

Model Context Protocol, wprowadzony przez Anthropic i szybko stający się standardem branżowym, sprawnie rozwiązuje ten problem. Jest to standaryzowany protokół, coś w rodzaju USB-C dla sztucznej inteligencji, który łączy modele z zewnętrznymi źródłami danych i narzędziami. Zamiast wbudowywać narzędzia AWS bezpośrednio do agenta, tworzy się oddzielny serwer MCP. Znajduje się on w środowisku AWS z niezbędnymi rolami IAM i udostępnia ściśle skategoryzowane, semantyczne narzędzia poprzez standardowy protokół. Agent, działający gdziekolwiek, łączy się jako klient MCP. Nie potrzebuje uprawnień AWS, ponieważ po prostu prosi serwer o uruchomienie dla niego narzędzi.

Wolność wyboru modelu

Ponieważ MCP nie przejmuje się tym, jaki model znajduje się po drugiej stronie, orkiestrator agentów SRE może użyć dowolnego modelu, który pasuje:

Amazon Nova  ─┐
Claude 3.5   ─┼──→  SRE Agent Orchestrator  ──→  MCP Server  ──→  AWS Cloud
OpenAI GPT-4o─┘          (agent.py)                (server.py)

Ocena modelu od innego dostawcy oznacza zmianę jednej linijki kodu. Serwer MCP oraz wszystkie bezpieczne narzędzia AWS, które on udostępnia, pozostają zupełnie takie same.

Architektura kopilota SRE

1. Infrastruktura docelowa

Aby agent miał co naprawić, przy użyciu Terraform wdrażany jest standardowy bezserwerowy mikrosłużba: API Gateway przed funkcją Lambda, która zapisuje dane do tabeli DynamoDB. Celowym błędem jest uszkodzona tabela skonfigurowana z tylko 1 jednostką przepustowości odczytu i 1 jednostką przepustowości zapisu. Przy jakiejkolwiek rzeczywistej obciążeniu ta API wywołuje błędy ProvisionedThroughputExceededException.

2. Serwer MCP

Server FastMCP w języku Python pełni rolę „rąk i oczu”, udostępniając cztery funkcje SRE:

• describe_architecture znajduje wszystkie zasoby AWS (ARN-y) posiadające tag aplikacji.

query_cloudwatch_metrics pobiera dane serii czasowych, takie jak ThrottledRequests.

query_cloudwatch_logs wykonywa zapytania CloudWatch Logs Insights w celu znalezienia śladów wykonywania kodu.

remediate_dynamodb_capacity to narzędzie modyfikujące, które zwiększa pojemność tabeli.

Granica zaufania to miejsce, w którym interweniuje człowiek. Narzędzia tylko do odczytu są w pełni autonomiczne, więc model może je używać według własnego uznania podczas badania. Narzędzie korygujące natomiast wymusza ścisłe zasady udziału człowieka – przed wywołaniem API AWS zatrzymuje się i prosi operatora w terminalu o zatwierdzenie poprzez [y/N], pokazując jednocześnie uzasadnienie modelu. Posiadanie punktu kontrolnego podlegającego audytowi przy każdej akcji zmieniającej stan, kształtowanego według własnych zasad organizacji, to funkcja, której nie oferują DevOps Guru ani Amazon Q.

3. Autonomiczny agent

Agent to niewielki skrypt w Pythonie, który komunikuje się z API Amazon Bedrock Converse za pośrednictwem boto3, przy czym wybrano rodzinę modeli Amazon Nova ze względu na ich możliwości i niską cenę. Działa w oparciu o autonomiczną pętlę while:

1. Otrzymuje prośbę, na przykład „Użytkownicy zgłaszają, że API płatności wyświetla błąd czasu oczekiwania. Napraw to.”
2. Zadaje serwerowi MCP pytanie o dostępne narzędzia.
3. Schematy narzędzi MCP są bezpośrednio przekształcane do formatu Bedrock Converse.
4. Rozpoczyna proces rozumowania: znajduje zasoby API płatności, sprawdza ich metryki, a następnie czyta logi.
5. Wykorzystuje narzędzia przez MCP, przekazuje wyniki z powrotem do Bedrock i kontynuuje działanie, aż znajdzie rozwiązanie i uruchomi odpowiednie narzędzie naprawcze.

Pętla w praktyce

Gdy agent otrzymuje informację o ograniczeniach w tabeli DynamoDB i zostaje poproszony o ustalenie przyczyny, dla której demo API zwraca odpowiedzi 429 i 500, postępuje zgodnie z tymi krokami:

1. Wywołuje funkcję describe_architecture, aby znaleźć ARN tabel Lambda i DynamoDB.
2. Wywołuje query_cloudwatch_metrics na tych tabelach, sprawdza wartość ProvisionedThroughputExceededRequests i zauważa gwałtowny wzrost.
3. Aby mieć pewność, wywołuje query_cloudwatch_logs na funkcji Lambda, analizuje logi w formacie JSON i potwierdza wystąpienie błędu ProvisionedThroughputExceededException.
4. Wniosek: przepustowość jest niewystarczająca, więc wywołuje funkcję remediate_dynamodb_capacity, prosząc o 50 RCU i 50 WCU.

Tutaj serwer MCP przechwytuje to wywołanie i pyta użytkownika:

=======================================================
⚠️ URGENT: AGENT REQUESTING PERMISSION TO MODIFY INFRASTRUCTURE
=======================================================
Action: Scale DynamoDB Table 'sre-copilot-payments-dev'
New Capacity: Read=50, Write=50
Agent's Reason: The table is experiencing severe throttling (ProvisionedThroughputExceededException). Scaling up to mitigate the incident.
=======================================================
Approve this change? [y/N]: y

Ten sam agent działa również jako aplikacja czatowa w Streamlit, pokazując proponowane rozwiązanie oraz krok zatwierdzenia. Gdy osoba odpowiedzialna to zatwierdzi, pojemność zostaje zaktualizowana, a incydent rozwiązany.

Korzyści wynikające z tej architektury

Rozdzielenie „mózgu” (Amazon Nova poprzez Bedrock) od „rąk” (API AWS) za pomocą MCP zapewnia elastyczność, której nie mogą dorównać narzędzia do zarządzania AWS:

• Przenośność modeli LLM. Zamiana Novy na Claude lub GPT-4o wymaga tylko jednej zmiany w konfiguracji.
• Bезpieczeństwo. Surowe dane uwierzytelniające nigdy nie trafiają do środowiska uruchamiania modeli LLM.
• Bezpieczeństwo operacyjne. Akcje są poddawane kroku zatwierdzenia przez człowieka, który można dostosować.
• Rozszerzalność. Nowe narzędzie, czy to PagerDuty, zapytanie do API Datadog czy sprawdzenie ticketa w ServiceNow, można dodać za pomocą pojedynczej funkcji @mcp.tool().

Autonomia. Agent swobodnie przegląda dane telemetryczne odczytu tylko, dzięki czemu może diagnozować nietypowe problemy, których nie dostrzegłyby narzędzia do porównywania wzorców, takie jak DevOps Guru.

Wygląda na to, że operacje chmurowe będą ewoluować od monolitycznych usług zarządzanych, które ograniczają zespoły, w kierunku agentów komponowalnych, niezależnych od modeli i poddawanych audytowi, które zespoły same tworzą, kontrolują i stale udoskonalają. To rozwiązanie nadaje się do użycia w produkcji, a nie jest jedynie demonstracją.

Dla referencji specyfikacja MCP jest dostępna pod adresem modelcontextprotocol.io, a AWS Labs utrzymuje otwarte serwery referencyjne MCP.

Literatura pokrewna

• Mapowanie ekosystemu AI w Laravel: Prism, LarAgent, Neuron AI i Boost — Od zwykłych wezwań do LLM po pełne agenty w Laravel: co robi każdy z narzędzi – Prism, LarAgent, Neuron AI, SDK AI i Boost – wraz z przykładem RAG do pytań dotyczących polityki HR.
• Agent finansowy QuickBooks działający na lokalnym LLM za pomocą Ollamy i LangChain — Agent ReAct na bazie Qwen 3.5 9B i karty RTX 4070 odczytuje dane z QuickBooks w czasie rzeczywistym bez żadnych kosztów chmurowych. Zobacz kod, wyniki oraz znane ograniczenia.

Notatki praktyczne: Rozjaśnienie koncepcji Agentic Mesh: skalowanie agentów AI i modeli LLM — Szczegółowy przewodnik po Notatkach praktycznych: Rozjaśnienie koncepcji Agentic Mesh: skalowanie agentów AI i modeli LLM, w tym informacje o kontraktach, sprawdzaniach oraz miejscach na kod do wdrożenia dla zespołów stosujących ten wzorzec.