Nauka inżynierii sztucznej inteligencji opartej na agentach zgodnie z tym, czego uczą nas awarie.

Rozwijający się w dziedzinie inżynierii agentów często próbują poznawać każdą ramę jednocześnie, przechodząc przez LangChain, CrewAI, AutoGen i LangGraph w ciągu jednego tygodnia, nie dostarczając przy tym żadnych rezultatów. Problemem jest sekwencjonowanie działań: studiują narzędzia, zanim zrozumieją błędy, których mają zapobiec. Ten przewodnik przedstawia czternastostopniową ścieżkę zgodną z rzeczywistym wzajemnym powiązaniem umiejętności, od podstaw Pythona aż po dostarczenie agenta działającego samodzielnie. Po drodze dowiesz się o trzech typach błędów, które kształtują każdą decyzję projektową, o prostym zestawie narzędzi wystarczającym do większości zadań produkcyjnych oraz o wzorcach strukturalnych (pliki stanu, procesy weryfikacji, wielopoziomowa ocena i określanie uprawnień), które odróżniają demonstrację od systemu, któremu można zaufać od razu.

Część 1: Model mentalny

1. Inżynieria agentów to nie inżynieria promptów z nową nazwą

Inżynieria promptów polega na tworzeniu treści, które kierujemy do modelu. Inżynieria agentów polega na budowaniu systemu, który decyduje, nad czym powinien pracować model, kiedy powinien przestać oraz jak zareagować, gdy jego odpowiedź jest błędna.

Definicja ta jest konkretna: tworzymy oprogramowanie, w którym LLM wybiera kolejną akcję, uruchamia narzędzie do jej wykonania, sprawdza wynik i powtarza proces, aż zadanie zostanie zakończone, przy czym żaden człowiek nie kieruje każdym krokiem. Chatbot odpowiada na wiadomość, natomiast agent wybiera działania, je wykonuje, sprawdza ich rezultaty i iteruje. To właśnie ta różnica stanowi istotę tej pracy.

Niesie ze sobą trzy obowiązki, których praca z promptami nigdy nie wymagała:

• Traktowanie błędów jako kluczowego problemu. Agenci ciągle ponoszą porażki: API wygasają, dane JSON przychodzą w niewłaściwej formie, model wymyśla nieistniejące wywołania narzędzi, a wyniki tych narzędzi nie odpowiadają ustalonym schematom. Kod zakładający sukces zawiedzie w najgorszym możliwym momencie, zazwyczaj podczas demonstracji.
• Zarządzanie stanem. Pojedyncze wywołanie LLM nie przechowuje żadnych danych. Agent realizujący dziesięć kroków obejmujących wywołania narzędzi, próby ponowne oraz podagenty potrzebuje uporządkowanego, trwałego stanu, który przetrwa dłużej niż jedno okno kontekstowe.
• Wbudowanie mechanizmów oceny w infrastrukturę. Nie ma intuicyjnego sposobu, by stwierdzić, czy agent postąpił prawidłowo. Potrzebne są zautomatyzowane mechanizmy, takie jak testy, kryteria oceny lub model sędziego, które odrzucają złe wyniki bez konieczności sprawdzania każdego wykonywania przez człowieka.

Opisy stanowisk dla tych ról często przypominają katalog. Występują tu frameworki orkiestracji (LangGraph, LangChain, LlamaIndex), protokoły (MCP, A2A), funkcje modeli (wywoływanie funkcji, strukturyzowane wyniki, cacheowanie promptów), metody wyszukiwania (RAG, RAGAS, wyszukiwanie hybrydowe, ponowna sortowanie, modele embeddingów, bazy danych wektorowych i grafowych) oraz umiejętności operacyjne (wykonywanie w środowisku izolowanym, możliwość obserwacji, ocena), a zazwyczaj po nich następuje żądanie biegłości w szybkim iterowaniu. Lista wydaje się przytłaczająca, ale większość pozycji to w rzeczywistości kilka podstawowych koncepcji pod różnymi nazwami. Gdy poznasz te koncepcje, nazwy produktów staną się łatwe do zrozumienia.

2. Trzy sposoby awarii wyjaśniają większość problemów

Zanim napiszesz kod, zrozum, dlaczego systemy agentowe zawodzą. Prawie każde narzędzie i wzorzec w tej dziedzinie istnieje po to, by przeciwdziałać jednemu z trzech takich zachowań.

Lenistwo agenta. W obliczu długiego, wieloetapowego zadania model przerywa pracę wcześnie i zgłasza sukces po częściowym postępie. Rozwiązuje 20 z 50 pozostałych zadań i opisuje resztę jako już załatwioną. Środkiem zaradczym jest wyraźna warunek zatrzymania, którą sprawdza coś innego niż sam model.

Samouprzedzenie. Gdy prosi się model o ocenę własnego wyniku, zawsze go aprobuje. Osoba, która ma interes w tym rezultacie, nie może ocenić go obiektywnie. Rozwiązaniem jest strukturalna zmiana: agent, który tworzy pracę, nie może być tym samym, który ją ocenia.

Zmiana celu. W trakcie wielu kroków, a szczególnie po streszczeniu lub skompresowaniu kontekstu, agent stopniowo traci orientację co do pierwotnego celu. Ograniczenie takie jak „nie ingerować w moduł płatności” może się po cichu zniknąć już przy kroku 47. Środkiem zaradczym jest trwały plik specyfikacji, który jest odczytywany na każdym uruchomieniu i przechowuje ograniczenia, które w przeciwnym razie zostałyby utracone.

Gdy ekosystem wydaje się przytłaczający, zapytaj o każdy nowy narzędzie lub wzorzec, które z tych trzech problemów rozwiązuje. To pytanie pomaga odfiltrować większość niepotrzebnego hałasu.

3. Mała baza komponentów i cztery rzeczy do odłożenia

Listy wymagań są długie, ale większość pracy agenta produkcyjnego opiera się na czterech warstwach, które najlepiej poznać w tej kolejności:

Core stack (learn these, in this order):
1. Python + async    : the bedrock; everything else builds on it
2. LLM APIs          : Anthropic, OpenAI; understand tokens, context, costs
3. Tool use / MCP    : function calling; how models act on the world
4. LangGraph         : stateful orchestration for multi-step, multi-agent work

Odłóż to, co poniżej, dopóki nie wyślesz przynajmniej jednego rzeczywistego agenta:

• Dopracowanie modelu. Wczesne projekty prawie nigdy go nie wymagają. Sprawny model podstawowy z dobrze zaprojektowanymi instrukcjami zazwyczaj przewyższa model dopracowany, ale z kiepskimi instrukcjami.
• Zamartwianie się bazami wektorowymi. Coś takiego jak Chroma nadaje się do użytku lokalnego, a usługa zarządzana typu Pinecone jest odpowiednia w środowisku produkcyjnym. Odraczaj wybór, dopóki pobieranie danych nie stanie się prawdziwym wąskim gardłem w projekcie, który budujesz.
• Zmiana frameworków. Wybierz jeden framework do orkiestracji (LangGraph to solidny wybór domyślny), ukończ projekt, a dopiero potem rozważaj inne opcje. Zmienianie narzędzi co tydzień tylko dlatego, że każde z nich obiecuje być prostsze, nie gwarantuje ukończenia żadnego projektu.
• Agenci głosowi i w przeglądarce. Są to specjalizacje oparte na tych samych podstawach. Najpierw opanuj agenty tekstowe – wzorce działania są przenoszone.

Część 2: Elementy budulcowe

4. Python i kod asynchroniczny

Nie musisz być ekspertem od Pythona, ale potrzebujesz wystarczającej wiedzy, by debugować błędy, a agenci często je popełniają. Skup się na:

• Klasach i modelach danych. Agenci przekazują ustrukturyzowane dane z kroku na krok, więc musisz je zaprojektować. Schemat Pydantic pełni rolę umowy pomiędzy wywołaniami narzędzi a logiką agenta; traktuj go jako coś obowiązkowego, a nie opcjonalnego.
• Asynchroniczność z użyciem asyncio. Agenci spędzają dużo czasu w oczekiwaniu na działanie narzędzi: zapytania do bazy danych, wywołanie HTTP, podproces. Kod synchroniczny blokuje się podczas każdego oczekiwania, natomiast kod asynchroniczny może wykonywać inne zadania. Powolny kod agenta to bardzo często kod synchroniczny, który oczekuje kolejno na różne operacje.

HTTP i REST. Bez API agent może tylko myśleć, ale nie działać. Nauč się czytać dokumentację API, przestrzegać ograniczeń szybkości, interpretować odpowiedzi błędów i rozsądnie próbować ponownie. Narzędzie, które zawiesza się przy błędzie HTTP 429, nie nadaje się do używania przez agenta.

Rozwiązywanie błędów. Otaczaj każde wywołanie narzędzia blokiem try/except. Agenci działają bez nadzoru, a nieobsłużony wyjątek, który wyświetla ścieżkę wywołania i zamyka program, nie pomoże nikomu w środku nocy.

Praktyczny kryterium: jeśli możesz przekazać zadanie młodszemu inżynierowi wraz z listą kontrolną i polegać na zestawie testów do wykrywania jego błędów, znasz już wystarczająco Pythona, by zacząć. Więcej można dodać później.

5. Podstawy LLM: tokeny, kontekst i koszt

Modele takie jak Claude, GPT i Gemini są potężne, ale potrzebują kierunku, a nie można kierować tym, czego się nie rozumie.

Tokowalizacja. Modele czytają tokeny, a nie słowa, i jeden termin może zostać podzielony na kilka tokenów w zależności od narzędzia do tokowalizacji. Jako przybliżoną zasadę dla języka angielskiego można powiedzieć, że kontekst zawierający 100 000 tokenów obejmuje około 75 000 słów. Wszystko poza tym zakresem, czy to rozmowa z zeszłego tygodnia, czy plik, który zapomniałeś dodać, po prostu nie istnieje dla modelu. Jeśli coś ma znaczenie, musi znajdować się w kontekście.

Ograniczenia kontekstu i pobieranie informacji. Modele nie pamiętają; każda sesja zaczyna się od zera. Umieszczanie wszystkiego w instrukcji jest kosztowne i pogarsza jakość w miarę jej rozrostu. Technika generacji wzbogaconej pobieraniem informacji służy do wybierania tylko tych danych, które są istotne.

Inferencja, a nie szkolenie. Prawie nigdy nie będziesz szkolił modelu. Wykonujesz inferencję na modelu kogoś innego i płacisz za każdy token. Koszt to liczba tokenów wejściowych pomnożona przez cenę wejścia plus liczba tokenów wyjściowych pomnożona przez cenę wyjścia, więc pętla wykonująca 50 wywołań przy kontekście zawierającym 20 000 tokenów generuje znaczne rachunki.

Tworzenie promptów dla agentów. Prompty do agentów różnią się od promptów do czatu. Najważniejsze są trzy wzorce: chain-of-thought, w którym model wyraźnie rozważa sytuację przed podjęciem działania; ReAct, cykl rozumowania, działania i obserwacji; oraz reflection, w którym model krytykuje swój własny projekt przed jego zwróceniem. Większość innych technik tworzenia promptów to wariacje tych rozwiązań. Aby dowiedzieć się więcej o cyklu ReAct, zapoznaj się z tym, jak agenty ReAct łączą rozumowanie z działaniami w rzeczywistym świecie.

6. Użycie narzędzi i MCP przekształca chatbota w agenta

Model ograniczony do generowania tekstu to chatbot. Model, który może wywołać funkcję, sprawdzić jej wynik i zdecydować, co robić dalej, to agent, a użycie narzędzi jest mechanizmem, który to umożliwia.

Mechanicznie opisuje się każdą funkcję podając jej nazwę, opis w języku naturalnym oraz schemat JSON dla parametrów, a te definicje wysyła się wraz z wiadomością użytkownika. Model decyduje, czy potrzebne jest jakieś narzędzie, a jeśli tak, zwraca ustrukturyzowane wezwanie narzędzia wraz z argumentami zamiast zwykłego tekstu. Twój kod uruchamia funkcję, wysyła wynik z powrotem, a model kontynuuje pracę od tego momentu. Opis jest równie ważny jak schemat, ponieważ to na jego podstawie model decyduje, kiedy dany narzędzie jest przydatne.

Bardzo praktyczne narzędzia agentów dzielą się na cztery kategorie. Poniższe przykłady je ilustrują: narzędzia do odczytu (obserwacja świata), narzędzia do zapisu (zmiana stanu), narzędzia do wykonywania kodu oraz narzędzia do weryfikacji pracy:

# Category 1: Read  (agent observes the world)
def search_codebase(query: str, path: str) -> list[str]: ...
def fetch_url(url: str) -> str: ...
def read_file(path: str) -> str: ...

# Category 2: Write (agent changes state)
def create_file(path: str, content: str) -> None: ...
def open_pull_request(title: str, body: str, branch: str) -> str: ...
def send_slack_message(channel: str, text: str) -> None: ...

# Category 3: Execute (agent runs code)
def run_tests(test_path: str) -> dict: ...
def execute_sql(query: str, db: str) -> list[dict]: ...

# Category 4: Verify (agent checks its own work)
def lint_code(file_path: str) -> list[str]: ...
def run_type_checker(path: str) -> bool: ...

Kategorie te stanowią również przydatny punkt odniesienia dla oceny ryzyka. Narzędzia do odczytu i weryfikacji zazwyczaj można swobodnie używać bez obaw, natomiast narzędzia do zapisu i wykonywania kodu zmieniają stan rzeczy i wymagają bardziej restrykcyjnych uprawnień – to temat, który pojawia się również na etapie bezpieczeństwa.

Model Context Protocol (MCP) to nowo powstający standard, który zastępuje dostosowany kod integracyjny protokołem. Częstym porównaniem jest tu USB-C w kontekście sztucznej inteligencji: zamiast za każdym razem, gdy agent potrzebuje dostępu do GitHuba, Slacka lub bazy danych, pisać specjalny adapter, podłącza się istniejący serwer MCP, a aplikacja gospodarz odkrywa jego możliwości i korzysta z nich bez dodatkowego kodu pośredniczącego.

Najskuteczniejsze integracje to GitHub do zarządzania gałęziami, wnioskami o pull request oraz problemami; Slack do powiadamień i podsumowań; twoja baza danych do wykonywania zapytań i kontrolowanych zapisów; oraz narzędzie do śledzenia problemów w zespole. Gdy te cztery elementy są połączone, agent może obsługiwać większość etapów procesu inżynieryjnego.

7. Pobieranie danych, ponieważ kontekst ma swoje ograniczenia

Generowanie wzbogacone o pobieranie danych zapewnia agentowi wiedzę, która nie mieści się w jego kontekście. Jest to reakcja na istotne ograniczenie, a nie modna tendencja – okno kontekstowe jest skończone, podczas gdy kod i dokumentacja nie są.

System pobierania danych składa się z czterech głównych elementów:

• Dzielenie na fragmenty – to obszar, w którym początkujący najczęściej popełniają błędy. Zbyt duże fragmenty zawierają zbyt wiele nieistotnych informacji, natomiast zbyt małe tracą sens. Odpowiednia wielkość zależy od treści, a kod źródłowy zazwyczaj wymaga innych granic (np. całych funkcji) niż dokumentacja prozatorska.
• Embeddingi – umożliwiają one wyszukiwanie podobieństw. Model embeddingowy przekształca tekst w wektor liczbowy, dzięki czemu podobne fragmenty tworzą wektory znajdujące się blisko siebie.
• Wyszukiwanie – znajduje przechowywane wektory najbliższe zadanemu zapytaniu i zwraca odpowiadające im fragmenty.

Ocena, która odróżnia system, który faktycznie działa, od tego, który tylko tak wygląda. Kluczowymi miarami są precyzja wyszukiwania (czy to, co zostało pobraane, było rzeczywiście istotne?), wierność (czy odpowiedź pozostała w ramach pobraanego materiału?) oraz istotność odpowiedzi (czy odpowiadała ona na pytanie?). Narzędzia takie jak RAGAS lub modele sędziowskie mogą je oceniać. Bez pomiarów ulepszenia są jedynie domysłami.

Zaawansowane wyszukiwanie rzadko przebiega w linii prostej od zapytania do odpowiedzi. Systemy produkcyjne często przepisują pytanie przed wyszukiwaniem, ponownie sortują wyniki po wyszukiwaniu i wykorzystują krok oceny, aby sprawdzić, czy pobraany materiał rzeczywiście odpowiada na pytanie. W praktyce model rozważa, co należy pobrać oraz czy pobranie się udało.

8. Orkiestracja z zachowaniem stanu za pomocą LangGraph

Jedna wywołanie LLM nie stanowi agenta. Agent wykonuje kilka kroków, przechowuje stan pomiędzy nimi, podejmuje decyzje na podstawie tego, co zaobserwuje, oraz odradza się po awariach. LangGraph dostarcza strukturę właśnie do tego celu.

Strukturalnie aplikacja LangGraph to graf skierowany, którego węzłami są zwykłe funkcje, takie jak agenci, narzędzia czy kroki przetwarzania. Krawędzie określają, w jaki sposób kontrola przemieszcza się pomiędzy nimi. Każdy węzeł odczytuje i aktualizuje wspólny, typowany obiekt stanu.

Poniższy szkic definiuje stan zawierający zadanie, plan, wyniki, błędy oraz flagę zakończenia, a następnie rejestruje cztery węzły: planer, który dzieli pracę na części, wykonawcę, który uruchamia jeden krok, weryfikatora, który sprawdza wyniki, oraz obsługę błędów, która próbuje ponownie lub eskaluje sytuację. Warunkowy krawędź po weryfikatorze stanowi serce pętli: zakończ działanie, gdy stan wskazuje na ukończenie, skieruj przepływ do obsługi błędów w przypadku ich wystąpienia, a w przeciwnym razie wykonaj następny krok. Należy pamiętać, że to jest tylko fragment; działający graf potrzebuje również punktu wejścia, pozostałych krawędzi oraz wywołania funkcji compile().

from langgraph.graph import StateGraph, END
from typing import TypedDict

class AgentState(TypedDict):
    task: str
    plan: list[str]
    results: list[str]
    errors: list[str]
    done: bool

graph = StateGraph(AgentState)

graph.add_node("planner", plan_task)       # breaks work into steps
graph.add_node("executor", execute_step)   # runs one step
graph.add_node("verifier", verify_output)  # checks the result
graph.add_node("handler", handle_error)    # retries or escalates

graph.add_conditional_edges(
    "verifier",
    lambda state: END if state["done"] else
                  "handler" if state["errors"] else
                  "executor"
)

• Checkpointing. Podczas kompilowania grafu z użyciem narzędzia do tworzenia punktów kontrolnych stan jest zapisywany po każdym kroku, dzięki czemu przerwana sesja (awaria laptopa, ponowne uruchomienie) może być kontynuowana od miejsca przerwy, zamiast rozpoczynać się od nowa.
• Pauzy z udziałem człowieka. Ustawienie wartości interrupt_before dla węzła o dużym znaczeniu sprawia, że graf zatrzymuje się, pokazuje proponowaną akcję i czeka na zatwierdzenie przed kontynuacją. To istotny element odróżniający agenta demonstracyjnego od agenta produkcyjnego.
• Głowice równoległe. Niezależne kroki mogą być wykonywane jednocześnie, podczas gdy framework zajmuje się łączeniem ich wyników w jeden stan, dzięki czemu wystarczy opisać strukturę, zamiast pisać kod synchronizacji.

Rozsądna zasada: użyj ram grafowych, gdy agent musi wykonać więcej niż około trzech kroków, ma gałęzie w wynikach działania narzędzi lub pętle do momentu spełnienia określonego warunku. Prosta łańcuchowa struktura bez rozgałęzień jest w porządku w zwykłym Pythonie. Kwestie związane z kompromisami są omawiane bardziej szczegółowo w wyborze między łańcuchami a grafami stanowymi.

Część 3: Prawidłowe budowanie

9. Pięć projektów, po kolei

Czytanie o agentach i ich tworzenie to różne umiejętności, a nauka skutkuje tylko dzięki praktycznym projektom. Te pięć, wykonywanych w kolejności, obejmuje każdą koncepcję niezbędną do pracy produkcyjnej.

1. Agent z jednym narzędziem. Wybierz pojedynczą API, taką jak GitHub lub usługa pogodowa, i napisz agenta, który oceni, czy API jest potrzebne, wywoła je i włączy jego odpowiedź do wiadomości zwrotnej. Użyj surowej API Anthropic lub OpenAI bez żadnego frameworku, aby móc zobaczyć cykl używania narzędzia bez żadnych abstrakcji go ukrywających.
2. Agent ReAct z trzema narzędziami. Dodaj wyszukiwanie w internecie, kalkulator i wykonywacz kodu, a następnie sam napisz cykl rozumowanie-działanie-obserwacja. To zazwyczaj w tym momencie agent po raz pierwszy dostrzega i poprawia swój własny błąd.
3. Pobieranie informacji z znanej bazy kodu. Stwórz indeks rzeczywistego repozytorium, zbuduj system pobierania informacji na jego podstawie i zadawaj pytania wymagające zrozumienia kilku plików. Pomierz jakość pobierania informacji i popraw fragmenty, które zawodzą. Ten projekt pokazuje, dlaczego dzielenie na fragmenty jest ważniejsze od wszystkiego innego.

Agen grafu wieloetapowego. Radzenie sobie z triażem w CI: czytanie dzienników testów, które zawiodły, klasyfikacja awarii, wyszukiwanie w bazie kodu prawdopodobnej przyczyny, opracowanie poprawki i uruchomienie testów, przy czym stan przepływa przez pięć węzłów. Niech weryfikator będzie oddzielnym węzłem od tego, który wprowadza poprawki; w przeciwnym razie napotkasz uprzedzenia skierowane na siebie.

Zaplanowany autonomiczny cykl. Uruchamianie projektu czwartego według harmonogramu cron bez żadnej nadzoru. Daj mu plik stanu, aby mógł kontynuować pracę zamiast restartować się, ustal sztywny budżet wydatków, by nie powodował wzrostu kosztów API, oraz dziennik audytowy rejestrujący jego działania. To tutaj „działa w demonstracji” zamienia się w „działa bez nadzoru.”

10. Plik stanu: agenci zapominają, pliki nie

To brzmi zbyt prosto, by mieć znaczenie, a jednak stanowi podstawę każdego niezawodnego autonomicznego agenta: plik markdown, dokument JSON lub wiersz w bazie danych, który znajduje się poza rozmową i rejestruje to, co zostało zrobione oraz co nastąpi dalej.

Modele nie przechowują żadnych danych pomiędzy sesjami. Wszystko, czego agent nauczył się podczas jednego uruchomienia, znika, chyba że zostanie zapisane, więc pętla bez trwałego stanu zaczyna się od zera za każdym razem, natomiast pętla z stanem kontynuuje pracę tam, gdzie ją przerwała. Poniższy przykład śledzi ostatni czas uruchomienia, liczbę przetworzonych i pozostałych elementów, prace w toku, ukończone zadania, elementy przekazane człowiekowi oraz datowane informacje, takie jak specyfika środowiska, których należy unikać w przyszłości:

// STATE.md: what every working autonomous agent needs
{
  "last_run": "2026-07-01 03:00 UTC",
  "items_processed": 47,
  "items_remaining": 12,
  "in_progress": [
    "fix/auth-token-refresh: tests passing, awaiting CI"
  ],
  "completed": [
    "fix/null-check-in-billing: merged, CI green"
  ],
  "escalated_to_human": [
    "src/payments/refund.ts: root cause unclear after 3 theories"
  ],
  "lessons": [
    "2026-06-30: E2E tests require Stripe webhook secret in env. Skip if missing.",
    "2026-06-29: Windows runner has TLS 1.2 issue. Use bash, not PowerShell."
  ]
}

Lista lekcji wymaga uwagi. To właśnie ona sprawia, że pętla przestaje powtarzać te same błędy, a jednocześnie stanowi trwałą specyfikację zapobiegającą odchyleniom od celu. Istnieją dwa powszechne formaty. Plik w formacie Markdown zapisany w repozytorium jest kontrolowany wersjami, łatwy do porównywania i prosty w użyciu, co nadaje się dla osób indywidualnych oraz małych zespołów. W przypadku pętli produkcyjnych, którymi musi zarządzać kilka osób, lepszym rozwiązaniem jest zewnętrzny system, takie jak narzędzie do śledzenia problemów typu Linear lub baza danych. Zasada jest prosta: agent zapomina, repozytorium pamięta, więc wszystko ważne powinno znajdować się poza oknem kontekstowym.

11. Maker-checker: oddzielenie autora od recenzenta

Jeden agent tworzy pracę, a inny agent, działający w swoim własnym kontekście, ją sprawdza. To jest strukturalna odpowiedź na błąd samoprzedpościgania, a jego konsekwentne stosowanie jest jednym z najwyraźniejszych oznak dojrzałego projektu agentów.

Model oceniający własny wynik jest wobec siebie zbyt łaskawy. Zapytaj agenta, który napisał poprawkę, czy jest ona prawidłowa – znajdzie powody, by odpowiedzieć twierdząco. Daj oddzielnemu recenzentowi poprawkę wraz z kryteriami oceny, bez informacji o tym, kto ją napisał i dlaczego, a on wykryje rzeczywiste wady.

Różnica w podejściu do kodu: błędna wersja prosi jednego agenta o naprawienie błędu i potwierdzenie własnej poprawki. Prawidłowa wersja uruchamia narzędzie naprawcze na jednym modelu, a następnie przekazuje tylko uzyskany kod wraz z określoną rubryką recenzentowi, który ma za zadanie ignorować autorstwo i intencję oraz zwrócić wynik pozytywny z uzasadnieniem lub negatywny z odniesieniami do konkretnych wierszy kodu. Recenzent używa silniejszego modelu, ponieważ ocena stanowi trudniejsze zadanie:

# Wrong: one agent does both
result = await agent("Fix the auth bug and verify your fix is correct")

# Right: maker and checker are separate agents, separate contexts
fix = await agent(
    "Fix the auth bug in src/auth/middleware.ts",
    model="sonnet"
)

review = await agent(
    f"""Review this fix against the rubric below.
    Do not consider who wrote it or their intent.

    Fix:
    {fix.code}

    Rubric:
    - Does it handle the null case on line 47?
    - Does it preserve the existing token expiry logic?
    - Does the test cover the regression case?

    Return: PASS with reasoning, or FAIL with specific line references.""",
    model="opus"   # harder model for the harder judgment task
)

Zasada dopasowywania polega na tym, że recenzent otrzymuje tylko dwa dane wejściowe – rubrykę i artefakt – a nigdy informacje o tożsamości autora, uzasadnienie zmiany ani rozmowę, która ją doprowadziła do powstania. Każda z tych informacji może ponownie wpłynąć na stronniczość poprzez określony kontekst. Rubryka również ma znaczenie; konkretne, sprawdzalne pytania, takie jak te powyżej, działają znacznie lepiej niż pytanie o to, czy zmiana jest dobra.

To samo rozdzielenie ma zastosowanie daleko poza kodem: autorzy i recenzenci, pisarze i sprawdzający fakty, generatorzy i sędziowie. Gdy tylko to zauważysz, zobaczysz, jak często standardowe narzędzia po cichu łączą te dwie role.

12. Ocena: brama, która czyni pętlę godną zaufania

Agent bez mechanizmu weryfikacji to po prostu bot do rozmów wywoływany wielokrotnie. To ocena decyduje o tym, czy wynik jest na tyle wiarygodny, by na nim działać, go połączyć lub opublikować. Należy używać trzech poziomów, które różnią się kosztem oraz rodzajem ocen, jakie mogą dostarczyć:

• Kontrole deterministyczne. Testy, narzędzia do sprawdzania kodu, weryfikatory typów oraz procesy kompilacji dają wynik binarny bez żadnej oceny. Są to pierwsza i najtańsza brama; zawsze, gdy kontrola deterministyczna może odrzucić nieprawidłowy wynik, należy jej użyć.

Sędzia w postaci LLM. Drugi model ocenia wynik pierwszego modelu według określonej rubryki. Ta metoda działa skutecznie, gdy rubryka jest precyzyjna, a zawodzi w przypadku jej niejasności. Sędzia powinien być przynajmniej tak sprawny jak model, który tworzy wynik, i nigdy nie powinno mu być mówione, kto go wygenerował. Prawidłowe zarządzanie sędzią to odrębna dziedzina, omówiona w zarządzaniu LLM jako sędzią w systemie produkcyjnym.

Aprobata człowieka. Działania nieodwracalne, takie jak wdrożenia produkcyjne, kod płatności, przymusowe aktualizacje oraz zmiany architektury, wymagają aprobacji osoby przed tym, jak agent może kontynuować. W LangGraph funkcja interrupt_before umożliwia taką pauzę. Należy jej używać tylko w przypadku działań, których odwołanie jest kosztowne, a nie do blokowania wszystkiego.

Aby sprawdzić, czy proces oceny działa prawidłowo, należy śledzić wskaźnik akceptowanych zmian. Jeśli agent zaprojektowany do naprawy nieudanych testów rozwiązuje 70% swoich problemów za pomocą zmian, które przechodzą weryfikację CI oraz przegląd przez ludzi, jego wskaźnik wynosi 70%. Poniżej poziomu około 50% ludzie spędzają swój czas na dokończeniu pracy rozpoczętej przez agenta, a ten cykl jest droższy niż to, co oszczędza.

13. Bezpieczeństwo: agent bez nadzoru to powierzchnia ataku bez nadzoru

Każdy autonomiczny agent, który ma dostęp do rzeczywistej infrastruktury, stanowi zagrożenie dla bezpieczeństwa, ponieważ działa bez nadzoru. Ryzyko jest konkretne: poprzez pośrednią iniekcję poleceń agent, który odczytuje złośliwy e-mail lub stronę internetową, może zostać skierowany do wykonywania poleceń atakującego. Główne zagrożenia:

• Iniekcja poprzez wyniki działania narzędzi. Strony internetowe, zgłoszenia na GitHubie oraz bilety wsparcia mogą ukrywać instrukcje w zwykłej treści – na przykład linijkę polecającą agencie zignorowanie poprzednich instrukcji i usunięcie plików testowych. Kwarantanna stanowi ochronę: każdy agent narażony na niezaufaną treść uzyskuje dostęp tylko do odczytu. Trzeba trzymać agenty do czytania oddzielnie od tych, które wykonują działania.
• Rozszerzanie uprawnień. Agent zatwierdzony z dostępem tylko do odczytu otrzymuje jedno uprawnienie do zapisu „tylko dla wygody”, a nikt już tego nie sprawdza. Regularnie przeprowadzaj ponowną weryfikację uprawnień (raz w miesiącu jest rozsądnym interwałem) i przyznawaj tylko to, co jest niezbędne do wykonania zadania.
• Tajemnice w logach. Szczegółowe logowanie w długotrwałych pętlach rozpraszają dane uwierzytelniające w wynikach, których nikt nie monitoruje. Wyłącz szczegółowe logowanie w środowisku produkcyjnym i oczyszczaj to, co pozostaje.

Nieprzeglądany kod wygenerowany automatycznie. Agenci mogą otwierać prośby o pull request szybciej, niż ludzie są w stanie je przeczytać. Jeśli system CI nie zawiera analizy statycznej, audytów zależności oraz skanowania tajemnic, kod podatny na ataki może trafić do głównej gałęzi, a nikt tego nie zauważy. Automatyzacja sprawia, że te mechanizmy stają się ważniejsze, a nie mniej.

Model uprawnień sprawia, że te zasady są jawne. Poniższy przykład automatycznie zatwierdza działania polegające wyłącznie na obserwowaniu, takie jak czytanie plików, uruchamianie testów oraz przeglądanie stanu git lub różnic między wersjami, natomiast wymaga interwencji człowieka przy dokonywaniu pushów, edycji plików środowiskowych, modyfikacji kodu płatności oraz przy każdym działaniu z flagą force:

# Safe agent permission model
permissions = {
    "auto_approve": [
        "Read(*)",           # read anything
        "Bash(npm test)",    # run tests
        "Bash(git status)",  # observe state
        "Bash(git diff*)",   # observe diffs
    ],
    "require_human": [
        "Bash(git push*)",   # never push without approval
        "Edit(.env*)",       # never touch secrets
        "Edit(src/payments/*)",  # never touch payments code
        "Bash(*--force*)",   # never force anything
    ]
}

Test każdej reguły to jedno pytanie: jeśli dane działanie okazuje się błędne, jak duże są koszty jego cofnięcia? Jeśli odwrócenie działań jest tanie, następuje automatyczne zatwierdzenie; jeśli kosztowne, decyzję podejmuje człowiek. Decydowanie w każdym przypadku indywidualnie jest początkiem problemu z nadmiernymi uprawnieniami.

14. Przekształcenie umiejętności w karierę

Ścieżka nauki powinna prowadzić gdzieś. Oto realistyczny pogląd na to, gdzie można zastosować te umiejętności.

Co pokazać. Unikaj klonów tutoriali. Trzy rzeczywiste projekty, które rozwiązały konkretne problemy, mają znacznie większą wartość:

• Agent zaplanowany w czasie, którego wyniki są przydatne w praktyce, podobnie jak pętla stworzona na kroku 9.
• System wielu agentów, w którym co najmniej dwa agenty pełnią różne role, co strukturalnie uniemożliwia jednej instancji modelu wykonywanie obu zadań, tak jak w wzorcu twórca-weryfikator z kroku 11.
• System wyszukiwania z udokumentowanymi metrykami oceny, pokazujący stan przed i po naprawie problemu z wyszukiwaniem, a nie tylko fakt, że funkcjonuje ono poprawnie.

Ile to zajmuje czasu. Jako przybliżone szacunki, osoba, która już dobrze zna Python i poświęca na naukę 10 do 15 godzin tygodniowo, może oczekiwać, że ten proces potrwa około ośmiu miesięcy. Traktuj to jako wartość pomocną do planowania, a nie obietnicę.

Gdzie zacząć. Różne role różnią się pod względem łatwości osiągnięcia ich od zera:

• Inżynier automatyzacji AI w firmie, której głównym biznesem nie jest AI. Potrzebna jest osoba, która potrafi na przykład stworzyć pętlę umożliwiającą poprawę testów w ciągu nocy. Wystarczą LangGraph, MCP oraz podstawowa wiedza o CI; nie są konieczne dziesiątki frameworków.
• Inżynier AI w startupie, którego produktem jest agent. Wymaga to pełnego zestawu umiejętności związanych z pozyskiwaniem danych, oceną, projektowaniem i wdrażaniem wielu agentów, przy wyższych wymaganiach i możliwościach rozwoju.

Inżynier infrastruktury agentowej w dużej firmie technologicznej – to stanowisko wyższego szczebla, a nie punkt startowy, które wymaga dodatkowych umiejętności w zakresie systemów rozproszonych.

Największym błędem większości planów nauki jest przekonanie, że trzeba znać wszystko przed rozpoczęciem pracy. Ważny jest jeden uruchomiony agent rozwiązujący rzeczywisty problem, dowód na to, że można zmierzyć jego skuteczność, oraz umiejętność określenia, przed jakimi awariami chroni jego projekt. Niewielu kandydatów posiada te trzy elementy, a żaden certyfikat nie może ich zastąpić.

Podsumowanie

• Naucz się koncepcji przed frameworkami i oceniaj każdy narzędzie pod kątem tego, jak zapobiega ono określonym błędom: lenistwu, samoprzedpożyczeniu czy dewiacjom.
• Zachowuj stan poza modelem, w pliku lub bazie danych, którą agent odczytuje przy każdym uruchomieniu.
• Nigdy nie pozwalaj, by autor zmiany był jej recenzentem; daj recenzentowi jedynie wynik pracy i konkretne kryteria oceny.
• Ustalaj hierarchię ocen – od sprawdzeń deterministycznych, przez recenzentów, aż po zatwierdzenie przez człowieka – i mierz wskaźnik przyjmowanych zmian.

Ustal uprawnienia według kryterium odwracalności i trzymaj agenty, które czytają niezaufany kontent, z dala od dostępu do zapisu.

Nie wymaga to żadnego doświadczenia badawczego ani specjalistycznej wiedzy z zakresu dopracowywania rozwiązań. Wystarczy solidna znajomość Pythona, jasne zrozumienie sposobów, w jakie LLM mogą popełniać błędy, oraz nawyk umieszczania bramy weryfikacji przed samym pętlą. Stwórz pierwszego agenta, pozwól mu działać przez noc, a rano przejrzyj jego zmiany.

Literatura pokrewna

• Od chatbota jednogodzinnego do agenta wspieranego przez MCP w LangGraph — Buduj aplikację LangGraph warstwa po warstwie: stan i reduktory, krawędzie, pętle narzędziowe, wątki z checkpointami, trzy tryby strumieniowania oraz narzędzia dostarczane przez MCP.
• Projektowanie czteropoziomowej pamięci agenta z użyciem LangGraph i Amazon Bedrock — Dowiedz się, jak zapewnić agentom opartym na LLM funkcjonalną pamięć epizodyczną, semantyczną i proceduralną w środowisku Bedrock i LangGraph, a także jak chronić ją przed zatruwaniem, wyciekami danych osobowych i infekcjami między użytkownikami.