Artykuł 10 z serii Anatomia Agenta AI ← Jak wiedzieć że agent robi to co powinien
Dziesięć artykułów. Zaczęliśmy od pytania czym różni się RAG od agenta od Agentic RAG. Skończyliśmy na tym jak testować agenta w CI/CD żeby regresja jakości nie trafiła do produkcji.
Pomiędzy: jak agent myśli (pętla, ReAct), jak pamięta (cztery typy pamięci), jak go zbudować bez kodu (n8n), jak nim sterować (prompt engineering), co może pójść nie tak (bezpieczeństwo), jak Twoja strona może z nim rozmawiać (NLWeb), ile to kosztuje i jak to mierzyć.
To jest dużo materiału. Ale wiedza bez działania jest bezużyteczna.
Ten artykuł to dwie checklista — jedna dla tych którzy budują agenta, jedna dla tych którzy chcą żeby ich strona była gotowa na agentów. Zamknij wszystkie poprzednie zakładki. Otwórz tę jedną i zacznij odhaczać.
Checklista 1: Agent który budujesz
Architektura i mechanika
- Zdefiniowany cel — agent ma jeden jasny cel, nie jest „asystentem do wszystkiego”
- Limit iteracji — agent nie może kręcić się w pętli bez końca; masz ustawiony max kroków
- Human-in-the-loop przy nieodwracalnych akcjach — wysyłanie, płatności, modyfikacje danych wymagają potwierdzenia
- Narzędzia na zasadzie least privilege — agent ma dostęp tylko do narzędzi których faktycznie potrzebuje
System prompt
- Trzy warstwy — tożsamość i cel, granice i eskalacja, format i styl
- Explicite granice — „nie robisz X”, „eskalujesz gdy Y” jako osobne, konkretne sekcje
- ReAct w prompcie — agent pisze „Myślę: [powód]” przed wywołaniem narzędzia
- Co najmniej dwa few-shot examples — dla najczęstszych i najtrudniejszych scenariuszy
- Instrukcja poufności — agent odmawia ujawnienia system promptu, bez kłamania że go nie ma
Bezpieczeństwo
- Zero credentials w prompcie — klucze API i hasła są w zmiennych środowiskowych, nigdy w kontekście modelu
- Zewnętrzna treść oznaczona jako dane — agent nie traktuje treści ze stron lub dokumentów jako instrukcji
- Agent zarejestrowany — kto stworzył, do czego ma dostęp, kiedy wymaga przeglądu
- Serwery MCP z whitelisty — nie podłączasz niezweryfikowanych serwerów MCP
Koszty i wydajność
- System prompt bez context window bloat — tylko to co agent faktycznie potrzebuje
- Model routing — proste zadania do tańszego modelu, złożone do droższego
- Prompt caching włączony — dla długich, stabilnych system promptów
- Obliczony koszt scenariusza pesymistycznego — wiesz ile zapłacisz przy 3x większym ruchu niż testowy
Ewaluacja i monitoring
- Zestaw testowy (minimum 20 przypadków) — happy path, edge cases, adversarial
- Tool call accuracy jako metryka — nie tylko task completion
- Groundedness check przed nieodwracalnymi akcjami
- Logi konwersacji — PII zredagowane, anomalie flagowane
- Ewaluacja w CI/CD — zmiana system promptu lub modelu przechodzi przez testy przed wdrożeniem
- Baseline ustalony — wiesz jaki jest „dobry” wynik dla Twojego agenta
Checklista 2: Strona gotowa na agentów
Warstwa czytelności
- Treść dostępna bez JavaScript — sprawdź
curl twojastrona.pl/stronabez User-Agent przeglądarki; agent powinien zobaczyć treść - Semantyczny HTML —
<main>,<article>,<nav>,<header>na właściwych miejscach - Hierarchia nagłówków — jeden H1, logiczna struktura H2/H3
- Alt texty na obrazach — opisowe, nie „obraz123.jpg”
Warstwa danych strukturalnych
- Schema.org dla głównego typu treści — Product, Article, Service lub Organization zależnie od strony
- Pola krytyczne wypełnione — dla produktu: name, price, availability; dla artykułu: headline, author, datePublished
- Brak rozbieżności między tekstem a danymi strukturalnymi — agent ufa danym, nie tekstowi
- Weryfikacja przez Google Rich Results Test — brak błędów krytycznych
Warstwa odkrywalności
- robots.txt z Content Signals —
ai-train: yes/no,ai-crawl: yes/noświadomie ustawione - llms.txt — mapa treści dla modeli językowych; minimum: nazwa, opis, główne sekcje, kontakt
- llms-full.txt (opcjonalnie) — pełna treść w formacie przyjaznym dla modeli
Warstwa operacyjności
- REST API dla kluczowych danych (jeśli sklep lub platforma) — agenty mogą zapytać o produkty bez parsowania HTML
- Formularze opisane semantycznie — atrybuty name, label, placeholder — nie tylko stylistycznie ładne
- Brak CAPTCHA blokującej ruch z autoryzowanych agentów
NLWeb / endpoint /ask
- /ask endpoint działa i zwraca JSON na pytanie w języku naturalnym
- Przetestowany pięcioma komendami curl z artykułu 7 serii
- Odpowiedź „poza zakresem” sensowna — agent wie że nie wie, nie halucynuje
Monitoring widoczności w AI
- GEO Checker uruchomiony — wiesz jaki jest aktualny wynik i co go obniża
- iFox Monitor (opcjonalnie) — śledzisz czy ChatGPT, Claude i Perplexity cytują Twoją stronę
Co dalej — gdzie jesteśmy i dokąd zmierzamy
Seria opisuje świat w połowie 2026. Warto wiedzieć co jest już produkcyjne, a co jeszcze wchodzi.
Działa dziś: MCP z milionami instalacji i natywnym wsparciem w Claude, Cursor i n8n. NLWeb w produkcji na Shopify, Eventbrite i TripAdvisor. WordPress 7.0 z WP AI Client i Abilities API. n8n z natywnym AI Agent node i obsługą MCP.
Wchodzi w drugiej połowie 2026: WebMCP w Chrome (early preview → stabilne), UCP jako standard agentic commerce z Google, Visa i Shopify, WordPress 7.1 z real-time collaboration w sierpniu, pełna integracja NLWeb w Yoast.
Horyzont 12-18 miesięcy: większość wyszukiwania informacji i zakupów online będzie odbywać się przez agentów działających w imieniu użytkowników — częściej niż przez tradycyjną przeglądarkę. Strony które są przygotowane będą obsługiwane. Strony które nie są będą omijane.
To nie jest prognoza. To jest ekstrapolacja z tego co już się dzieje.
Słownik który rośnie razem z Tobą
Wszystkie pojęcia z tej serii mają swoje hasła w Słowniku Agentic Web — 215 definicji, 18 klastrów, od pojęć bazowych przez protokoły komunikacji po bezpieczeństwo i prawo.
Słownik jest dostępny jako serwer MCP — Twój agent może go odpytywać bezpośrednio przez narzędzia MCP.
Jedno zdanie na koniec
Agenci AI nie są przyszłością. Są teraźniejszością którą dopiero zaczynamy rozumieć.
Ta seria była próbą zbudowania tego rozumienia — od mechaniki do produkcji, od konceptu do checklisty. Mam nadzieję że po tych dziesięciu artykułach budowanie pierwszego agenta brzmi mniej jak projekt na „kiedyś” a bardziej jak plan na ten weekend.
Cała seria Anatomia Agenta AI:
- RAG, Agent AI, Agentic RAG — czym się różnią
- Jak agent myśli — ReAct, Chain-of-Thought i pętla działania
- Jak agent pamięta — cztery typy pamięci
- n8n — Twój pierwszy agent bez kodu
- Prompt engineering dla agentów
- Co może pójść nie tak — bezpieczeństwo agentów dla builderów
- NLWeb — jak sprawić żeby Twoja strona odpowiadała agentom
- Ile kosztuje agent w produkcji
- Jak wiedzieć że agent robi to co powinien
- Agent-ready — checklista (ten artykuł)
Pojęcia ze słownika: Agent-readiness · Agent AI · NLWeb · MCP · llms.txt · Agentic Web
![Artykuł 2 z serii "Agenci AI — od konceptu do produkcji" ← RAG, Agent AI, Agentic RAG — czym się różnią Poprzedni artykuł tej serii skończył się na rozróżnieniu: RAG odpowiada na pytanie, agent realizuje cel. Ale to rodzi pytanie które każdy kto buduje agenta zadaje sobie prędzej czy później: jak właściwie agent decyduje co zrobić dalej? Między "dostałem zadanie" a "zadanie wykonane" jest czarna skrzynka. Dla chatbota ta czarna skrzynka jest prosta — jeden prompt, jedna odpowiedź. Dla agenta to sekwencja decyzji, wywołań narzędzi i ocen wyniku która może trwać sekundy albo godziny. Żeby budować agentów świadomie — a nie przez próby i błędy — trzeba zrozumieć co jest w środku tej czarnej skrzynki. Pętla która napędza każdego agenta Zacznijmy od analogii. Wyobraź sobie że dostajesz zadanie: "Zarezerwuj mi hotel w Krakowie na weekend 14-15 czerwca, do 400 zł za noc, blisko centrum." Jak to robisz? Nie jednym ruchem. Najpierw szukasz opcji. Sprawdzasz ceny. Czytasz opinie. Może jedno miejsce ma dobry rating ale jest za drogie — odrzucasz. Drugie pasuje, ale patrzysz jeszcze na lokalizację. Potwierdzasz. Rezerwujesz. To jest pętla: obserwujesz → planujesz → działasz → oceniasz wynik → wracasz do początku. Agent AI działa identycznie. Każde wieloetapowe zadanie jest realizowane przez powtarzający się cykl czterech kroków — i ten cykl ma swoją nazwę: agent loop. Cztery kroki pętli Percepcja — agent patrzy na stan: co jest w oknie kontekstu, jakie były wyniki poprzednich akcji, co zwróciło ostatnie narzędzie, jaki jest cel. Planowanie — na podstawie tego co widzi, agent decyduje co zrobić dalej. To jest moment decyzji: czy cel jest osiągnięty? Jeśli nie — jaka akcja przybliży mnie do celu? Jakie narzędzie wywołać? Akcja — agent wykonuje to co zaplanował. Wywołuje narzędzie MCP, odpytuje bazę danych, robi request HTTP, pisze plik. Ocena — agent patrzy na wynik akcji. Czy to działało? Co teraz wiem więcej? Co jest następnym krokiem? Czy napotkałem błąd który wymaga innej strategii? I z powrotem do percepcji. Pętla kręci się dopóki agent nie osiągnie celu, nie napotka przeszkody której nie może pokonać, albo — i to jest ważne — nie przekroczy limitu iteracji. Limit iteracji jest krytyczny Agent bez limitu może kręcić się w pętli nieskończenie. Narzędzie zwraca błąd, agent próbuje jeszcze raz, i jeszcze raz, i jeszcze raz. Minuty zamieniają się w godziny. Tokeny i koszty rosną. Każdy agent produkcyjny musi mieć limit kroków po którym zatrzymuje się i raportuje do człowieka: "doszedłem do limitu X iteracji, oto co udało mi się ustalić, oto gdzie utknąłem." To jest pierwsza zasada którą ignoruje większość ludzi budujących swojego pierwszego agenta. ReAct — jak agent myśli zanim działa Teraz wiemy że agent kręci się w pętli. Ale co dokładnie dzieje się w kroku "planowanie"? Jak agent decyduje co zrobić? W 2022 roku badacze z Princeton i Google zaproponowali wzorzec który zmienił sposób budowania agentów: ReAct (Reasoning + Acting). Pomysł jest prosty do bólu: zanim agent wykona akcję, niech najpierw "powie na głos" co myśli. Generuje explicite reasoning — widoczny łańcuch myślenia — a potem na jego podstawie podejmuje decyzję o akcji. Wygląda to tak: Thought: Użytkownik chce hotelu w Krakowie na 14-15 czerwca do 400 zł. Powinienem najpierw sprawdzić dostępność. Action: search_hotels(city="Kraków", checkin="2026-06-14", checkout="2026-06-15", max_price=400) Observation: [3 wyniki: Hotel A — 380 zł, Hotel B — 350 zł, Hotel C — 420 zł] Thought: Hotel C jest za drogi. Hotel A i B mieszczą się w budżecie. Sprawdzam odległość od centrum. Action: get_location(hotel_id="hotel_A") Observation: 800m od Rynku Głównego Thought: 800m to blisko centrum. Hotel A kosztuje 380 zł i jest blisko. Rezerwuję. Action: book_hotel(hotel_id="hotel_A", dates=["2026-06-14"]) Trzy zalety ReAct które robią różnicę w praktyce: Debugging jest możliwy. Widzisz dokładnie skąd pochodzi każda decyzja agenta. Jeśli coś poszło nie tak — możesz śledzić rozumowanie krok po kroku i znaleźć moment gdzie agent zboczył z kursu. Narzędzia są wywoływane trafniej. Agent który "przemyśli" co wywołać zanim to zrobi, robi mniej błędnych wywołań niż agent który po prostu reaguje na ostatni wynik. Agent może się korygować. Reasoning jest widoczny — i agent może sam zauważyć że jego poprzedni krok był błędny, zanim podejmie kolejny. Chain-of-Thought — "myślmy krok po kroku" ReAct to wzorzec na poziomie architektury agenta. Chain-of-thought (CoT) to technika na poziomie promptowania modelu. Idea: zamiast prosić model o bezpośrednią odpowiedź, zachęć go żeby najpierw pokazał swoje obliczenia. Jak matematyk który nie podaje samego wyniku, ale zapisuje wszystkie kroki. Najprostszy możliwy CoT to dosłownie jedno zdanie dodane do promptu: "Myślmy krok po kroku." Brzmi banalnie. Ale działa — szczególnie przy zadaniach wieloetapowych, matematycznych i logicznych. Bardziej zaawansowany CoT to few-shot: dostarczasz modelowi przykłady pytanie + rozumowanie + odpowiedź, i model uczy się wzorca. Dla agentów operujących w specyficznej domenie — powiedzmy agent analizujący umowy prawne — few-shot CoT z przykładami z tej domeny jest jednym z najskuteczniejszych sposobów poprawy jakości. Extended thinking — CoT wbudowany w model Claude 3.7+ i kilka innych modeli poszło dalej: extended thinking jest wbudowane bezpośrednio w model, bez potrzeby specjalnego promptowania. Model generuje wewnętrzny długi łańcuch myślenia przed odpowiedzią — niewidoczny dla użytkownika (lub opcjonalnie widoczny). Efekt: znacząco lepsza jakość przy złożonych, wieloetapowych zadaniach — za cenę wyższej latencji i więcej tokenów. Dla agentów wykonujących skomplikowane analizy gdzie czas odpowiedzi jest mniej ważny niż poprawność — extended thinking jest naturalnym wyborem. Przykład który łączy wszystko: agent rezerwujący hotel Wróćmy do zadania: "Zarezerwuj hotel w Krakowie na 14-15 czerwca." Chatbot dostałby to pytanie i wygenerował listę hoteli z opisem. Odpowiedź tekstowa. Nic nie zarezerwował. Agent z agent loop, ReAct i dostępem do narzędzi wykonuje to zadanie od początku do końca: Iteracja 1: Percepcja → cel jasny, narzędzia dostępne. Planowanie → wywołaj search_hotels. Akcja → [wywołanie]. Ocena → 3 wyniki, Hotel C za drogi. Iteracja 2: Percepcja → mam 2 kandydatów. Planowanie → sprawdź lokalizację. Akcja → [wywołanie]. Ocena → Hotel A blisko centrum, Hotel B dalej. Iteracja 3: Percepcja → Hotel A: 380 zł, 800m od centrum. Spełnia wszystkie kryteria. Planowanie → rezerwuj. Akcja → [wywołanie book_hotel]. Ocena → rezerwacja potwierdzona, numer #KRK2026-0891. Wynik: "Zarezerwowałem Hotel A na 14-15 czerwca, 380 zł, 800m od Rynku Głównego. Numer rezerwacji: #KRK2026-0891." Trzy iteracje pętli. Trzy wywołania narzędzi. Jedno wykonane zadanie. Co to zmienia dla kogoś kto buduje agenta Zrozumienie agent loop, ReAct i CoT nie jest teorią akademicką — bezpośrednio wpływa na to jak projektujesz agenta. Agent loop mówi ci: musisz zdefiniować kryterium sukcesu (jak agent wie że skończył?), ustawić limit iteracji (co gdy agent utknął?), i zdecydować gdzie wstawić human-in-the-loop (które akcje wymagają potwierdzenia człowieka przed wykonaniem?). ReAct mówi ci: daj modelowi miejsce na reasoning zanim podejmie akcję. Nie optymalizuj prompta do minimum — reasoning kosztuje tokeny, ale zmniejsza błędy narzędziowe i ułatwia debugging gdy coś pójdzie nie tak. CoT mówi ci: przy złożonych zadaniach "myślmy krok po kroku" to nie magia — to zmiana trybu pracy modelu. Dla zadań domenowych few-shot CoT z przykładami z Twojej domeny jest wart inwestycji. W następnym artykule: agent myśli i działa — ale co pamięta? Jak działa pamięć agenta między krokami, między sesjami i między zadaniami — i dlaczego zły design pamięci jest jednym z najczęstszych błędów przy budowaniu agentów produkcyjnych. Pojęcia ze słownika: Agent loop · Chain-of-thought · Reasoning model · Tool use · Human-in-the-loop · Agent AI](https://webflux.pl/wp-content/uploads/2026/06/agent_mysli.webp)
