Agent Engineering - co to jest? Framework RKKM dla zespołów

Agent Engineering to projektowanie całego systemu pracy ludzi i agentów AI: ich ról, kontekstu, narzędzi, handoffów, punktów kontroli oraz miar skuteczności. Nie chodzi o znalezienie jednego lepszego promptu. Chodzi o zbudowanie workflow, w którym wiadomo, co agent może zrobić, kto weryfikuje wynik i ile naprawdę kosztuje dojście do poprawnej zmiany.

Na EfektywnyDev używam tego terminu dla praktyki zespołowej. GitHub Copilot, Claude Code czy kolejne narzędzia są środowiskiem wykonania. Odpowiedzialność za proces nadal należy do zespołu.

Czym Agent Engineering różni się od prompt engineeringu?

W tym modelu prompt engineering skupia się głównie na jakości instrukcji i odpowiedzi. Agent Engineering projektuje przepływ pracy przed poleceniem, w jego trakcie i po otrzymaniu wyniku.

Obszar	Główne pytanie	Typowy rezultat
Prompt engineering	Jak sformułować polecenie?	lepsza odpowiedź modelu
Context engineering	Jakie informacje podać i kiedy?	mniej zgadywania i szumu
Agent Engineering	Jak podzielić pracę i kontrolować jej wynik?	powtarzalny workflow zespołu

Jeżeli po wygenerowaniu kodu nie wiadomo, kto ma go sprawdzić, jakie testy uruchomić i kiedy zatrzymać agenta, problem nie leży już w treści promptu. Leży w projekcie procesu.

Framework RKKM: cztery warstwy workflow agentowego

Do oceny workflow używam czterech warstw: Rola, Kontekst, Kontrola i Miara. Skrót RKKM pomaga sprawdzić, czy zespół projektuje system pracy, czy tylko dodaje AI do istniejącego chaosu.

Rola: za co agent odpowiada?

Dobra rola opisuje wynik, granice i moment przekazania pracy. „Jesteś seniorem” nie jest rolą operacyjną. „Przygotuj plan zmiany bez edycji plików, wskaż ryzyka i przekaż plan do review” już nią jest.

Dla każdej roli ustal:

wejście i oczekiwany rezultat,
dozwolone narzędzia,
decyzje, których agent nie może podejmować sam,
warunek zakończenia,
odbiorcę handoffu.

Praktyczne przykłady znajdziesz w tutorialu role agentów AI: koder, reviewer, tester i debugger oraz w lekcji o custom agents, narzędziach i handoffach.

Kontekst: co agent powinien wiedzieć teraz?

Więcej kontekstu nie oznacza automatycznie lepszego wyniku. Potrzebne informacje warto rozdzielić na:

stałe reguły repozytorium,
plan i decyzje dotyczące zadania,
pliki potrzebne do aktualnego kroku,
tymczasowy stan bieżącej sesji.

Ta separacja zmniejsza ryzyko, że stara próba, nieaktualny plan albo przypadkowy plik zaczną sterować kolejną decyzją. Szczegółowy model opisuję w materiale Context Engineering: warstwy kontekstu oraz w tutorialu jak nie utopić agenta w szumie.

Kontrola: gdzie człowiek odzyskuje decyzję?

Kontrola nie polega na czytaniu całego logu agenta po zakończeniu pracy. Powinna być zaprojektowana przed uruchomieniem:

akceptacja planu przed edycją plików,
ograniczenie zakresu zmiany,
testy i statyczna analiza po implementacji,
review diffu przez inną rolę lub człowieka,
jawne kryteria zatrzymania przy błędzie albo rosnącym zakresie.

Dobry przykład daje case study weryfikacji planu AI. Pierwsza propozycja wymagała 27 ręcznych edycji. Dodatkowa bramka review sprowadziła rozwiązanie do jednej zmiany w konfiguracji. To jednostkowa obserwacja z pracy nad repo, nie benchmark produktywności. Pokazuje jednak mechanizm: wartością nie był dłuższy prompt, tylko zatrzymanie wykonania przed kosztowną implementacją.

Miara: czy workflow daje zysk po review?

Liczba wygenerowanych linii kodu nie mówi, czy agent pomógł. Minimalny rachunek powinien obejmować:

koszt całkowity = czas wykonania + koszt modelu + czas review + poprawki + koszt błędu

Na początku wystarczą cztery wartości zbierane dla jednego typu zadania:

czas od startu do zaakceptowanego wyniku,
liczba iteracji,
czas review i poprawek,
liczba regresji lub odrzuconych zmian.

Bez baseline’u z pracy wykonywanej bez agenta nie da się uczciwie mówić o ROI. Można jedynie powiedzieć, że generowanie było szybkie.

Model dojrzałości Agent Engineering

Model służy do diagnozy workflow, nie do oceniania całej organizacji jednym numerem.

Poziom	Sposób pracy	Następny krok
0	przypadkowe rozmowy i kopiowanie odpowiedzi	wybierz jedno powtarzalne zadanie
1	zapisany prompt lub instrukcja dla zadania	określ wynik i kryteria akceptacji
2	jawna rola, kontekst i ograniczone narzędzia	dodaj checkpoint oraz review
3	kilka ról, handoffy, testy i granice autonomii	zacznij mierzyć koszt całkowity
4	wersjonowany workflow, metryki i zasady governance	optymalizuj na podstawie danych

Zespół może być na poziomie 3 dla code review i na poziomie 0 dla migracji bazy. Dlatego diagnozujemy konkretny przepływ, a nie deklarowaną „dojrzałość AI” firmy.

Jak zaprojektować pierwszy workflow agentowy?

Zacznij od zadania częstego, odwracalnego i łatwego do zweryfikowania. Nie od najbardziej krytycznej migracji w systemie.

Zapisz baseline. Ile dziś trwa zadanie, review i poprawki?
Zdefiniuj kontrakt roli. Co agent dostaje, co oddaje i czego nie może robić?
Przygotuj kontekst. Oddziel reguły repo od danych jednego zadania.
Wstaw checkpoint. Plan, diff albo wynik testów musi zostać zaakceptowany przed kolejnym krokiem.
Uruchom małą próbę. Ten sam typ zadania wykonaj kilka razy w podobnych warunkach.
Zmierz pełny koszt. Uwzględnij review, poprawki i nieudane iteracje.
Wersjonuj workflow. Instrukcje, prompty i profile agentów trzymaj obok kodu, jeśli są częścią procesu zespołu.

PRD i SRS mogą być wejściem biznesowym, a SDD technicznym kontraktem dla planera. Gotowe struktury znajdziesz w szablonie PRD dla agenta AI i szablonie dokumentu SRS.

Kiedy nie używać agenta?

Sytuacja	Lepszy wybór
zadanie jest krótsze niż przygotowanie kontekstu	wykonaj je bez agenta
nie potrafisz opisać poprawnego wyniku	najpierw doprecyzuj wymagania
zmiana jest nieodwracalna i bez testów	zbuduj zabezpieczenia przed automatyzacją
dane nie mogą trafić do wybranego narzędzia	zmień środowisko lub zrezygnuj z użycia
review kosztuje więcej niż ręczne wykonanie	uprość workflow albo usuń agenta z tego kroku

Agent nie jest celem architektury. Jest wykonawcą, którego warto dodać tylko wtedy, gdy cały system pracy staje się dzięki temu lepszy.

Mapa dalszej nauki

Role i handoffy: typowe role agentów i custom agents w GitHub Copilot.
Kontekst: zarządzanie kontekstem i context engineering.
Kontrola: weryfikacja planów AI i bezpieczna autonomia agenta.
Koszt: jak dobierać model do kosztu błędu.

Jeżeli wdrażasz ten model w zespole, wybierz jeden workflow i opisz jego obecny przebieg, narzędzia oraz największe ryzyko. To wystarczy, żeby rozpocząć rozmowę o szkoleniu lub wdrożeniu bez przygotowywania wielkiego programu transformacji.

Ograniczenia tej metody

RKKM jest autorskim frameworkiem roboczym, a nie standardem branżowym ani modelem certyfikacyjnym. Nie podaję tu benchmarków produktywności, ponieważ repo nie zawiera jeszcze porównywalnego zbioru pomiarów z wielu zespołów. Framework należy sprawdzić na własnych zadaniach i własnym baseline’ie.

Stan materiału: 8 sierpnia 2026. Zasady są niezależne od konkretnego modelu, ale możliwości narzędzi, sposób rozliczania i dostępne mechanizmy bezpieczeństwa należy weryfikować przed wdrożeniem.

Źródła pierwotne

VS Code: context engineering workflow - kontekst projektu, plan, implementacja, handoffy i wersjonowanie konfiguracji.
OpenAI: A practical guide to building agents - narzędzia, instrukcje, orchestration, guardrails i baseline ewaluacji.
Anthropic: Building effective agents - dobór prostego workflow, checkpointy i kryteria zatrzymania.
Anthropic: Demystifying evals for AI agents - baseline, testy regresji, koszt, opóźnienie i ocena agentów kodujących.