AI agents dla programisty. Co to jest, jak zbudować pierwszy w produkcji i czego nauczyłem się na własnych błędach

Rok temu wszyscy mówili “AI agents zmienią pracę”. Kilkanaście startupów w Y Combinatorze pokazywało AutoGPT jako proof-of-concept. Twitter pełen był “look, mój agent napisał całą aplikację sam”.

Rok później wiem coś, czego wtedy nie mówiono. 80% projektów z agentami umiera w pierwszym miesiącu produkcji. Nie dlatego, że modele są słabe. Dlatego, że agent to nie magiczna funkcja “napisz mi X, załatw resztę”. Agent to system, który wymaga inżynierii, tak jak każda inna aplikacja.

W agencji zbudowałem dla klientów 6 agentów, którzy działają w produkcji. Wszyscy zaczynali od prototypu, który wyglądał magicznie. Trzech potem trafiło do produkcji, trzech nie. Ten post pokazuje różnicę.

Co to jest AI agent (bez marketingu)

Agent AI to program, który:

Ma cel (przekazany przez usera albo zdefiniowany na starcie)
Ma dostęp do narzędzi (tools) - funkcje, które może wywołać
Ma model językowy jako “mózg” (Claude, GPT, Gemini)
Iteruje: myśli, wybiera narzędzie, wykonuje, obserwuje wynik, myśli dalej

Pętla: Reason → Act → Observe → Repeat, dopóki cel nie zostanie osiągnięty (albo iteracje nie skończą się limitem).

To wszystko. Agent to nie AGI. To nie magia. To pętla plus narzędzia plus prompt.

Konkretny przykład: klient prosi mnie o “znajdź informacje o firmie X i przygotuj raport”. Ludzki asystent zrobi Google search, otworzy 5 stron, przeczyta, streści. Agent robi to samo, tylko z tools zamiast rąk.

Skąd bierze się różnica między agentem, chatem i workflow

Trzy kategorie systemów, często mylone.

Chat: user pyta, model odpowiada raz. Jeden krok, brak stanu między pytaniami (poza kontekstem konwersacji). To ChatGPT, Claude.

Workflow: sztywna sekwencja kroków, model wykonuje predefiniowane akcje. Kod steruje flow, model wypełnia luki. Przewidywalne, ale mniej elastyczne.

Agent: model decyduje, co robić dalej, na podstawie obserwacji. Elastyczne, ale mniej przewidywalne.

Reguła kciuka: workflow, jeśli można. Agent, jeśli musisz.

Dlaczego 80% projektów agentowych umiera

Konkretnie, co widziałem w projektach klientów.

Problem 1: brak jasno zdefiniowanego celu. Klient mówi “agent do customer support”. Co znaczy “customer support”? Odpowiadanie na FAQ? Rozwiązywanie problemów? Eskalacja do człowieka? Bez ostrego celu agent jest zbyt szeroki i błądzi.

Problem 2: za dużo narzędzi. Agent z 50 narzędziami nie wie, którego użyć. Model gubi się w wyborze. Odpowiedź: max 10-15 narzędzi na jednego agenta. Więcej = decompose na kilka mniejszych.

Problem 3: brak observability. Agent robi 12 kroków, klient dostaje wynik. Coś jest źle, klient pyta “co poszło nie tak”. Bez logów każdego kroku nie wiemy. Bez wiedzy nie naprawimy.

Problem 4: brak guardrails. Agent ma narzędzie “wyślij email”. Agent w kółku wysyła 500 emaili do klienta. Klient dzwoni z pretensjami. Rate limits, human-in-the-loop, spending caps od dnia 1.

Problem 5: nierealne oczekiwania. Klient chce “agenta jak człowiek”. Model dostępny w 2026 nie jest jak człowiek. Ma 80% dokładności w typowych zadaniach. Te 20% błędów muszą być obsłużone systemowo.

Kiedy agent ma sens (a kiedy nie)

Ma sens:

Zadania z niepewnym flow (research, discovery)
Automatyzacje wymagające decyzji “co dalej”
Zadania konsumujące różne systemy z różnymi API
Rzeczy, które junior robiłby ręcznie 30-60 minut

Nie ma sensu:

Zadania deterministyczne (pisanie faktury z template) - lepszy workflow n8n
Zadania wymagające 100% dokładności (płatności, medycyna) - agent musi mieć human review
Zadania wymagające dużo kontekstu, którego nie da się dostarczyć modelowi
Prostsze automatyzacje (2-3 kroki) - overhead agent nie zwraca się

Wybieraj świadomie. Agent to nie zawsze najlepsze rozwiązanie, nawet jeśli modny.

Mój pierwszy agent w produkcji

Dla klienta z e-commerce zbudowałem agenta do email supportu. Cel: klasyfikacja przychodzącego maila, przygotowanie draftu odpowiedzi, escalation do człowieka.

Architektura:

Trigger: nowy email w skrzynce support
Model: Claude Sonnet 4
Tools:
- get_order_by_id(order_id) - pobiera zamówienie z bazy
- get_customer_history(email) - historia klienta
- search_kb(query) - wyszukiwanie w knowledge base
- create_draft_reply(email_id, content) - tworzy draft w Gmail
- assign_to_human(email_id, reason) - eskalacja
Guardrails: max 10 iteracji, brak akcji “wyślij email” (tylko draft)
Logging: każde thinking, każde tool call, każdy response

Prompt systemowy (uproszczony):

Jesteś asystentem customer support dla sklepu X.
Twój cel: przeanalizować przychodzący email, zebrać kontekst, przygotować draft odpowiedzi.
Nigdy nie wysyłaj emaila sam. Zawsze przez `create_draft_reply`.
Jeśli sprawa jest złożona (refund, komplikacja techniczna, klient sfrustrowany), eskaluj przez `assign_to_human`.

Wyniki po 3 miesiącach:

68% emaili obsłużone bez ludzkiej interwencji (draft OK, tylko wysyłka)
25% wymagało edycji draftu przez człowieka (2 min zamiast 15 min)
7% eskalowane do człowieka od razu
Zero incydentów typu “agent wysłał coś głupiego” (bo guardrails)

Klient zaoszczędził 30h tygodniowo pracy juniora. Agent kosztuje 200 USD miesięcznie w API. ROI liczony w tygodniach.

Stack techniczny, którego używam

Framework: Vercel AI SDK (dla TypeScript) lub LangGraph (dla Pythona). Vercel AI SDK ma lepsze DX, LangGraph więcej opcji.

Model: Claude Sonnet 4 dla większości. GPT-4o jako fallback (via OpenRouter).

Observability: LangSmith (od LangChain) albo Braintrust. Loguje każde thinking, tool call, response. Bez tego nie zbudujesz nic produkcyjnego.

Guardrails: własne. Rate limits per iteration, timeout per call, spending cap per user session.

Vector search (dla knowledge base): Pinecone albo pgvector (Postgres extension). Postgres w większości przypadków wystarczy.

Queue: BullMQ (Node) albo Celery (Python) dla async agent runs.

Prompt engineering dla agentów

To inna sztuka niż zwykłe prompty. Kilka lekcji.

Bardzo jasny cel. Nie “pomóż klientowi”, tylko “przeanalizuj email, zbierz kontekst z bazy, przygotuj draft odpowiedzi zgodny z tonem X, decyduj o eskalacji według kryteriów Y”.

Opis każdego toola precyzyjny. Model musi wiedzieć, kiedy użyć którego. Bad description = bad tool use.

Przykłady w prompt (few-shot). Pokazujesz modelowi 2-3 przykłady “wejście → decyzja → tools → wynik”. Dramatycznie polepsza konsystencję.

Explicit stop conditions. “Jeśli osiągnąłeś cel, wywołaj finish z podsumowaniem”. Bez tego agent iteruje w nieskończoność.

Instrukcje anti-hallucination. “Jeśli nie masz informacji, powiedz to. Nie zgaduj.” Zwłaszcza dla knowledge-heavy zadań.

Pisałem szerzej o promptowaniu w osobnym poście. Agent prompty to nadbudowa na tamtych fundamentach.

Multi-agent systems

Trend: zamiast jednego agenta z 20 tools, wielu wyspecjalizowanych agentów.

Orchestrator (główny agent) deleguje do workerów (specialist agents). Każdy worker ma węższy scope, mniej tools, większą trafność.

Przykład dla mojego support agenta rozbudowany do multi-agent:

Orchestrator agent: klasyfikuje email, wybiera specjalistę
Order agent: obsługuje pytania o zamówienia (ma dostęp do order tools)
Refund agent: obsługuje zwroty (specyficzne policies, escalation rules)
Technical agent: obsługuje problemy techniczne (dostęp do KB)

Plusy: każdy specjalista lepiej wyszkolony, mniejsze prompty, lepsze debugowanie.

Minusy: overhead koordynacji, wolniejsze (kilka model calls zamiast jednego), droższe.

Reguła: zacznij od jednego agenta. Rozbijaj na multi-agent, kiedy jednym agentom trudno się utrzymać.

Koszty: uważaj

Agent wywołuje model wielokrotnie w jednej sesji. Koszty rosną szybko.

Konkretny przykład: mój support agent na email:

8 iteracji średnio
Każda iteracja: 5000 tokenów input (kontekst rośnie), 500 tokenów output
Total per email: 40k tokens input + 4k tokens output
Cost Claude Sonnet: $0.12 + $0.06 = $0.18

To wygląda tanio. Ale 1000 emaili miesięcznie = 180 USD. Skalowanie w gorsze scenariusze robi 1000 USD miesięcznie za jednego agenta.

Techniki obniżania kosztów:

Cache prompt prefixes (Anthropic wspiera prompt caching)
Krótsze system prompty (usuwaj gadulstwo)
Mniejsze modele dla prostych kroków (Haiku zamiast Sonnet dla klasyfikacji)
Ogranicz max iteracji (10, nie 50)
Zbieraj tokeny (batch podobne requesty)

Bez tych optymalizacji koszty pożerają ROI.

Testing agentów

Najtrudniejsza rzecz w agentowej inżynierii. Bo wynik jest nondeterministyczny.

Podejście:

1. Unit testy narzędzi (tools). Każde narzędzie testowane jak każda funkcja. Dobrze pokryte, deterministyczne.

2. Integration testy z mocked model. Symulujesz odpowiedzi modelu, sprawdzasz, czy agent wywołuje odpowiednie narzędzia w odpowiedniej kolejności.

3. E2E testy z realnym modelem, na złotym datasecie. Zbierasz 50-100 realnych przypadków (input, expected output). Regression tests na każdym release.

4. Production monitoring. Loguj wszystko. Sample’uj konwersacje do manual review. Zbieraj feedback od userów.

Testing 100% deterministyczny agenta jest niemożliwy. Cel: 95% coverage typowych ścieżek plus reagowanie na incydenty.

Human-in-the-loop: musisz mieć

Wszystkie moje produkcyjne agenty mają checkpoint z człowiekiem. Konkretnie:

Draft, nie send (email support): agent tworzy draft, człowiek akceptuje
Sugestia, nie action (financial ops): agent sugeruje, człowiek klika
Escalation triggers: agent wykrywa “wysokie ryzyko” i eskaluje

Full autonomy = niebezpieczeństwo. Ludzki checkpoint = safety net.

Trade-off: mniejsza automatyzacja, mniejsze savings. Ale znacznie mniejsze ryzyko incydentu, który zabija projekt.

Częste błędy

Startowanie od “wielkiego agenta”. MVP powinien być minimalny: 1 agent, 3 tools, 1 use case. Rozbudowa iteracyjna.

Pomijanie observability. Bez logów każdego kroku nie zbudujesz produkcji. Zainwestuj w LangSmith/Braintrust od dnia 1.

Ignorowanie kosztów. Prototype działa, radość, wypuszczasz do 1000 userów, dostajesz $5000 bill. Dodaj spending caps od początku.

Brak fallback’ów. Model API pada. Agent leci na error. User dostaje 500. Zawsze fallback (inny model, cache, graceful degradation).

Trust bez verification. Agent mówi “zrobiłem X”. Ale czy naprawdę? Weryfikuj przez side effects (czy email został wysłany, czy record w bazie się zmienił).

Nadmiar narzędzi. Agent ma 30 tools “na wszelki wypadek”. Model wybiera źle. Trzymaj set minimalny, focused.

MCP: nowy standard dla tools

Pisałem osobno o Model Context Protocol. Skrót: MCP standardowy protokół definicji tools dla agentów.

Dlaczego to matter dla agentów:

Portability: napisz raz, użyj z każdym agent framework
Standard: mniej boilerplate w Twoim kodzie
Ekosystem: dziesiątki gotowych MCP servers do popularnych narzędzi

W 2026 wszystkie moje nowe agenty budujemy z MCP jako tool layer. Framework agent może się zmienić (Vercel AI SDK dziś, coś innego jutro), MCP zostanie.

Co czytać dalej

Anthropic Cookbook (dokumentacja na Anthropic): oficjalne przykłady agentów.
Simon Willison’s blog: najlepszy obserwator praktyk AI w produkcji.
LangChain docs: nawet jeśli nie używasz LangChain, koncepcje są uniwersalne.
Building effective agents (Anthropic blog): najlepszy jednosupostowy overview z 2024.

Unikaj YouTuberów promising “agent builds SaaS in 5 minutes”. To hype, nie inżynieria.

Od czego zacząć

Jeśli chcesz zbudować pierwszego agenta w produkcji:

Zdefiniuj wąski cel (1 use case, konkretny). “Klasyfikacja emaili według typu”, nie “customer support”.
Zdefiniuj max 5 narzędzi dla tego use case’u.
Zbuduj prototyp w Vercel AI SDK (TypeScript) albo pure Python.
Dodaj observability (LangSmith) od dnia 1.
Dodaj guardrails: max iterations, spending cap, human-in-the-loop.
Test na 20-30 realnych przypadkach.
Deploy z monitoring. Pilnuj pierwsze 2 tygodnie ręcznie.

Agent nie jest magią. Jest inżynierią. Programiści, którzy potraktują to jak każdą inną system design task, zbudują agentów, którzy działają. Programiści, którzy oczekują “magii”, stracą 3 miesiące na debug.

Pisałem o AI tooling z perspektywy consumera w Cursor i Claude Code. Ten post to widok z drugiej strony: jak sam budujesz systemy AI dla klientów.

Rynek AI agents rośnie 10x rocznie. W 2027 to będzie oczekiwana kompetencja dla senior programistów. Zacznij dziś, będziesz przygotowany, kiedy zacznie się wyścig.