Delegowanie agenta:
twój agent dev deleguje test
Delegowanie agenta pozwala twojemu agentowi dev skończyć funkcję i przekazać walidację osobnemu agentowi QA. Dev dalej dostarcza kod na modelu, któremu ufasz przy trudnych problemach. Agent QA uruchamia test na tańszym modelu. Obaj rozmawiają przez serwery MCP AgentsRoom, więc delegowanie agenta działa od początku do końca bez kopiowania czegokolwiek ręcznie.
Przestajesz płacić stawkę Opus za kliknięcia w przeglądarce. Przestajesz zapychać kontekst agenta dev zrzutami ekranu i dumpami DOM. Delegowanie agenta kieruje każde zadanie do właściwego modelu po właściwej cenie, a kiedy agent QA skończy, pinguje agenta dev z powrotem, więc pętla zamyka się sama.
Delegowanie agenta w akcji: agent dev Codex kończy funkcję, wywołuje run_qa_test, agent QA otwiera przeglądarkę na tańszym modelu i raportuje wynik.
Oto problem, który rozwiązuje delegowanie agenta. Uruchamiasz mocnego agenta dev (Claude Opus, Codex, model który projektuje API albo refaktoruje store). Agent dostarcza funkcję w 10 minut. Potem spędza kolejne 8 minut klikając w przeglądarce, żeby zweryfikować, że funkcja działa. Ta sama droga stawka za tokeny. Ten sam model, który właśnie intensywnie myślał o twojej logice domenowej, teraz czyta etykiety przycisków.
Delegowanie agenta to naprawia. Kiedy funkcja jest gotowa, agent dev wywołuje jedno narzędzie MCP, run_qa_test, ze scenariuszem. AgentsRoom spawnuje efemerycznego agenta QA na modelu, który wybrałeś do QA: Claude Haiku, Codex mini, GPT-4 mini, cokolwiek chcesz. Agent QA dostaje AgentsRoom Browser MCP, prowadzi stronę, weryfikuje wynik i odpowiada werdyktem. Agent dev czyta werdykt i idzie dalej.
To jest delegowanie agenta i to jedyna pętla, którą obejmuje ta strona. Jeden dev, jeden QA, jeden MCP. Ten sam pomysł co senior delegujący testy regresji juniorowi albo QA: senior dalej projektuje, junior idzie przez checklistę. Delegowanie agenta daje ci dokładnie taki sam podział między modelami.
Delegowanie agenta zwizualizowane: rodzic agent dev (Codex) i dziecko agent QA (Claude) pojawiają się na tej samej liście agentów, z wyraźnym przekazaniem z dev do QA.
Dlaczego warto podpiąć delegowanie agenta
Po pierwsze, pieniądze. Przebieg testu na Claude Opus i przebieg testu na Claude Haiku kosztują nieporównywalnie różne kwoty. Ta sama przeglądarka, te same asercje, te same zrzuty ekranu. Delegowanie agenta pozwala taniemu modelowi robić tanią robotę. Ludzie, którzy to włączyli, raportują spadek rachunku za tokeny w dni z dużą liczbą QA o realny, mierzalny czynnik, a nie o 5 czy 10 procent.
Po drugie, kontekst. Kiedy agent dev sam uruchamia test, każdy zrzut ekranu, każdy dump DOM, każdy log konsoli ląduje w oknie kontekstu agenta dev. Dwadzieścia minut klikania to megabajty szumu, które agent dev musi nieść przez resztę sesji. Delegowanie agenta izoluje ten szum wewnątrz efemerycznego agenta QA. Agent dev dostaje z powrotem czyste 'pass' albo 'fail', nic więcej.
Po trzecie, aspekt ekologiczny. Każde delegowanie agenta oszczędza realne obliczenia. Uruchamianie Haiku tam, gdzie biegało Opus, zmniejsza o połowę ślad energetyczny tego kroku. Pomnóż przez wszystkich w zespole i przez każdą pętlę testową w roku, a delegowanie agenta staje się nietrywialnym pokrętłem po stronie węglowej twojego stacku.
Po czwarte, niezawodność. Agent dev, który sam prowadzi przeglądarkę, ma tendencję do błądzenia. Po dwóch zrzutach ekranu zapomina, co próbował zwalidować. Agent QA w delegowaniu agenta ma jedną robotę i jeden prompt. Testuje, raportuje, ginie. Pętla jest krótka, przewidywalna i łatwa do debugowania.
Jedyny przepływ, który obejmuje delegowanie agenta tutaj
Jeden agent dev. Jeden agent QA. Jedno wywołanie MCP. Delegowanie agenta od początku do końca.
Agent dev dostarcza funkcję
Twój agent dev (Claude Opus, Codex high reasoning, jakikolwiek drogi model, któremu ufasz) kończy implementację. Nowy endpoint, nowy ekran, nowy flow. Kod napisany, pliki zapisane.
Agent dev wywołuje run_qa_test
Zamiast samemu otwierać przeglądarkę, agent dev wywołuje jedno narzędzie MCP z serwera AgentsRoom Test Runner: run_qa_test, ze scenariuszem po angielsku. To cała powierzchnia API delegowania agenta.
AgentsRoom spawnuje agenta QA
AgentsRoom Test Runner spawnuje efemerycznego agenta QA na skonfigurowanym przez ciebie tańszym modelu (Claude Haiku, Codex mini, GPT-4 mini). Agent QA dostaje narzędzia AgentsRoom Browser MCP: navigate, click, type, screenshot, evaluate, get_logs, get_state.
Agent QA uruchamia test
Agent QA otwiera stronę, przechodzi przez scenariusz, weryfikuje wynik, robi zrzuty ekranu jeśli trzeba i czyta logi konsoli, żeby złapać błędy runtime, które agent dev by pominął.
Agent QA wystawia werdykt
Po zakończeniu agent QA wywołuje submit_verdict z wynikiem pass, fail albo inconclusive i krótkim podsumowaniem. Zrzuty ekranu i logi są dołączone. Proces agenta QA jest niszczony. Jego okno kontekstu odchodzi razem z nim.
Agent dev czyta werdykt i idzie dalej
Agent dev dostaje werdykt z powrotem jako odpowiedź na run_qa_test. Przy pass agent dev commituje albo przechodzi do kolejnego ticketu. Przy fail agent dev czyta podsumowanie błędu, naprawia buga i odpala nowy cykl delegowania agenta. Pętla zamyka się sama.
Ekonomia delegowania agenta
Dlaczego mądry podział dev i QA obniża twój rachunek za AI bez obniżania standardów.
Testy przeglądarkowe są powtarzalne. Otwórz stronę, kliknij przycisk, przeczytaj etykietę, sprawdź toast. Model za 50 dolarów za milion tokenów robi tę robotę tak samo dobrze jak model za 3 dolary za milion tokenów. Może nawet lepiej, bo tani model się nie nudzi. Delegowanie agenta sadza tani model na nudnej połowie roboty.
Realne liczby z realnych sesji: typowy test end-to-end złożonego flow pali od 60 do 200 tysięcy tokenów między zrzutami ekranu, dumpami DOM i krokami rozumowania. Na Opus to realne pieniądze za test. Na Haiku to drobne. Delegowanie agenta zmienia codzienny nawyk QA z troski budżetowej w darmowy odruch.
Pomnóż przez każdą pętlę. Normalny dzień developera na nietrywialnej funkcji uruchamia test od pięciu do dwudziestu razy. Delegowanie agenta kumuluje się na tych powtórzeniach. Agent dev pozostaje drogi (chcesz, żeby był drogi), agent QA pozostaje tani, a różnica to czysta oszczędność.
Delegowanie agenta jest też przyjaźniejsze dla planety. Mniej obliczeń na tej samej robocie znaczy mniej energii, mniej wody w datacenter, mniej węgla. Nie jedyny powód, żeby podpiąć delegowanie agenta, ale uczciwy efekt uboczny kierowania zadań do modeli właściwego rozmiaru.
Realny podział modeli dla delegowania agenta
Co ludzie naprawdę podpinają po stronie dev i po stronie QA delegowania agenta.
Strona dev (celowo utrzymywana droga)
- Claude Opus 4.7
- Claude Sonnet 4.6
- Codex high reasoning
- GPT-4 with deep reasoning
- Gemini 2.5 Pro
Strona QA (oddelegowana do tańszego)
- Claude Haiku 4
- Claude Sonnet 4 (low effort)
- Codex mini
- GPT-4 mini
- Gemini 2.5 Flash
Delegowanie agenta nie blokuje macierzy. Konfigurujesz model QA dla każdego projektu. Możesz nawet oddelegować agenta do zupełnie innego dostawcy: Opus na dev, Codex mini na QA, bez wspólnego kontekstu, tylko jedno wywołanie MCP.
Co delegowanie agenta naprawdę robi pod maską
Delegowanie agenta siedzi na stosie MCP AgentsRoom. Agent dev działa wewnątrz swojego CLI (Claude Code, Codex, Gemini, OpenCode, Aider). AgentsRoom wstrzykuje serwer Test Runner MCP do tego agenta. Test Runner wystawia jedno narzędzie: run_qa_test. To punkt wejścia każdego wywołania delegowania agenta.
Kiedy run_qa_test odpala, AgentsRoom spawnuje nowy proces CLI w tym samym projekcie, z inną konfiguracją. Ta konfiguracja ma podpięty Browser MCP, podpięty system prompt QA i model podmieniony na ten, który ustawiłeś po stronie QA. Nowy proces jest efemerycznym agentem QA: żyje przez czas trwania testu i ginie po submit_verdict.
Podczas gdy agent QA działa, agent dev jest wstrzymany na wywołaniu run_qa_test. AgentsRoom pokazuje agenta QA na tej samej liście agentów, z wcięciem pod agentem dev (widać na obrazku powyżej). Kiedy agent QA kończy, jego werdykt jest zwracany jako wynik run_qa_test, a agent dev wznawia działanie. Delegowanie agenta to pojedyncza wymiana MCP z punktu widzenia agenta dev.
Agent dev nigdy nie dostaje narzędzi przeglądarki. AgentsRoom zdejmuje narzędzia browser_* z listy dozwolonych agentowi dev w momencie spawnu. To jest ta część, która sprawia, że delegowanie agenta jest niezawodne: agent dev nie może spaść z powrotem do robienia testu sam, nawet kiedy jego instynkt mówi mu, żeby chwycić zrzut ekranu. Jedyna droga naprzód to run_qa_test. Delegowanie agenta przez usunięcie, nie przez prośbę.
Gdzie delegowanie agenta działa dzisiaj i co dalej
Delegowanie agenta w AgentsRoom jest dzisiaj browser-first. Ta sama forma, więcej powierzchni nadchodzi.
Dzisiaj: delegowanie testów przeglądarki
Agent QA prowadzi wbudowaną przeglądarkę AgentsRoom przez Browser MCP. Localhost dev server, publiczny tunel preview, URL staging, wszystko co Chromium potrafi wyrenderować. Formularze, modale, drag and drop, dialogi, logi konsoli, błędy sieciowe. Delegowanie agenta pokrywa całą powierzchnię, którą pokrywałby inżynier QA webowy.
Delegowanie testów aplikacji Electron
Jeśli sam wydajesz aplikację Electron, możesz zainstalować bibliotekę AgentsRoom Electron MCP w swoim projekcie. Agent QA łączy się z twoją aplikacją Electron tak samo jak łączy się z kartą Chromium. Delegowanie agenta przechodzi w testowanie aplikacji desktopowych bez żadnej zmiany po stronie dev.
Delegowanie testów aplikacji React Native (roadmap)
Ta sama forma delegowania agenta nadchodzi do React Native. Agent QA będzie prowadził symulator iOS albo Android przez AgentsRoom React Native MCP. Agent dev dostarcza ekran, agent QA stuka po nim. To samo wywołanie run_qa_test, to samo przekazanie z dev do QA, cel mobilny.
Bez delegowania agenta kontra z delegowaniem agenta
Ta sama funkcja, ten sam przebieg QA. Inny rachunek, inny kontekst, inna niezawodność.
Bez delegowania agenta
- : Agent dev (drogi) sam otwiera przeglądarkę.
- : Każdy zrzut ekranu, każdy dump DOM i każdy log konsoli ląduje w kontekście agenta dev.
- : 20 minut klikania pali tokeny Opus na robocie, którą zrobiłby tańszy model.
- : Agent dev zapomina co robił po dwóch zrzutach ekranu.
- : Płacisz pełną cenę za kliknięcia w przeglądarce, planeta też płaci pełną cenę.
Z delegowaniem agenta
- : Agent dev wywołuje run_qa_test i czeka.
- : Tani agent QA robi kliknięcia, asercje, łapanie zrzutów ekranu.
- : Do agenta dev trafia tylko werdykt (pass, fail, podsumowanie).
- : Agent QA jest efemeryczny: ginie po submit_verdict, żadnego puchnięcia kontekstu.
- : Rachunek za tokeny spada, agent dev pozostaje skupiony, pętla zamyka się sama.
Delegowanie agenta to najtańsza wygrana niezawodności, jaką można podpiąć do setupu z agentem do kodowania.
Jak wygląda wywołanie delegowania agenta
Oto cała forma delegowania agenta z dev do QA. Agent dev odpala to przez Test Runner MCP i czeka na odpowiedź.
Wywołanie narzędzia MCP (agent dev)
run_qa_test({
scenario: "Open http://localhost:3000/login.\n Type the seeded test user in the email field.\n Submit the form.\n Assert the dashboard URL is reached and the user's name is shown in the header.\n Capture a screenshot on success, capture console logs on failure."
})FAQ
Czym jest delegowanie agenta w AgentsRoom?
Delegowanie agenta to przekazanie z dev do QA między dwoma agentami AI do kodowania. Agent dev kończy funkcję, wywołuje jedno narzędzie MCP (run_qa_test), a efemeryczny agent QA uruchamia test na innym modelu. Agent dev czyta werdykt i idzie dalej. Cały flow delegowania agenta dzieje się przez serwery MCP AgentsRoom.
Po co mi w ogóle delegowanie agenta?
Trzy powody. Pieniądze: agent QA biega na tańszym modelu, więc przebieg testu kosztuje ułamek tego, ile kosztowałby na modelu dev. Kontekst: agent dev pozostaje czysty, wszystkie zrzuty ekranu i dumpy DOM giną razem z agentem QA. Niezawodność: agent QA ma jedną robotę, więc testuje lepiej niż agent dev rozpraszający się na kliknięciach w przeglądarce.
Które modele działają w delegowaniu agenta?
Każdy model, który wspiera AgentsRoom: Claude (Opus, Sonnet, Haiku), Codex (high, mini), Gemini (Pro, Flash), OpenCode, Aider. Delegowanie agenta jest cross-providerowe. Typowy podział to Claude Opus albo Codex po stronie dev i Claude Haiku albo Codex mini po stronie QA, ale wybierasz sam.
Czy delegowanie agenta jest tylko dla testów przeglądarki?
Dzisiaj tak, agent QA prowadzi wbudowaną przeglądarkę Chromium AgentsRoom. Jutro ta sama forma delegowania agenta pokryje aplikacje Electron (zainstaluj bibliotekę AgentsRoom Electron MCP w swoim projekcie Electron) i aplikacje React Native (roadmap, symulatory iOS i Android).
Jak delegowanie agenta zapobiega temu, że agent dev sam zrobi test?
AgentsRoom zdejmuje narzędzia browser_* z agenta dev w momencie spawnu. Agent dev dosłownie nie może wywołać browser_navigate ani browser_screenshot. Jedyna droga do przeglądarki to run_qa_test, który odpala delegowanie agenta. Ograniczenie jest mechaniczne, nie grzeczna prośba w prompcie.
Czy delegowanie agenta to chmura czy lokalnie?
Local-first. Agent dev, efemeryczny agent QA, most MCP i przeglądarka wszystkie działają na twojej maszynie. Delegowanie agenta używa chmury tylko wtedy, gdy bazowy model (Claude, Codex, Gemini) rozmawia ze swoim dostawcą, dokładnie tak jak normalny przebieg agenta.
Czy delegowanie agenta oszczędza realne pieniądze?
Tak, o znaczący czynnik w dni z dużą liczbą QA. Złożony test end-to-end na Opus albo Codex high kontra ten sam test na Haiku albo Codex mini to mniej więcej 10-krotna różnica kosztów. Delegowanie agenta w ciągu dnia pracy i przez cały zespół szybko skaluje tę różnicę.
Co agent dev dostaje z powrotem z delegowania agenta?
Krótki ustrukturyzowany werdykt: pass, fail albo inconclusive, z podsumowaniem, opcjonalną ścieżką zrzutu ekranu i opcjonalnymi logami konsoli. Żadnych surowych zrzutów ekranu w kontekście, żadnych dumpów DOM. To cały sens delegowania agenta: izolować szum QA wewnątrz agenta QA.
Czy agent QA może założyć ticket w backlogu, kiedy nie zda?
Tak. Delegowanie agenta daje agentowi QA Backlog MCP. Niepowodzenie może wylądować jako ticket backlogu na projekcie, ze scenariuszem, zrzutem ekranu i logami konsoli dołączonymi. Agent dev czyta werdykt, a ticket backlogu niesie długie szczegóły.
Gdzie delegowanie agenta wpisuje się względem innych funkcji AgentsRoom?
Delegowanie agenta żyje na wierzchu Browser Automation (która daje agentowi QA przeglądarkę) i serwerów AgentsRoom MCP (które dają każdemu agentowi jego powierzchnię narzędzi). Agent Teams to szerszy edytor wieloagentowego workflow: delegowanie agenta jest wariantem dev do QA tego workflow, ale wystawionym jako jedno wywołanie MCP, żeby każdy agent u każdego dostawcy mógł go używać bez konfigurowania grafu.
Dobrze współgra z
Browser Automation
Warstwa Chromium i Browser MCP, którą prowadzi strona QA delegowania agenta. Prawdziwa, trwała przeglądarka na każdy projekt.
Agent Teams
Wizualny edytor wieloagentowego workflow. Delegowanie agenta to wariant dev do QA, Agent Teams to pełna wersja grafowa z N węzłami i pętlami sprzężenia zwrotnego.
AgentsRoom MCP
Serwery MCP, które umożliwiają delegowanie agenta: Test Runner, Browser, Backlog, Terminal Commands, Prompt Library.
Multi-Provider
Uruchamiaj Claude, Codex, Gemini, OpenCode i Aider obok siebie. Delegowanie agenta to kąt cross-providerowy tej samej idei.
Claude Code Token Usage
Licznik tokenów na żywo na sesję. Najszybszy sposób, żeby potwierdzić oszczędności w dolarach, które delegowanie agenta daje ci w praktyce.
Public Backlog
Kiedy agent QA oblewa przebieg delegowania agenta, bug ląduje tutaj. Klienci i koledzy z zespołu widzą regresję, agent dev ją podchwytuje.
Przestań płacić cenę Opus za kliknięcia QA
Pobierz AgentsRoom i wypróbuj delegowanie agenta. Podłącz agenta dev do modelu, któremu ufasz, agenta QA do tańszego modelu i pozwól, żeby przekazanie z dev do QA działo się samo przez MCP.
Aplikacja towarzyszaca: monitoruj agentów w podrozy
Użyj Claude, Codex, Gemini CLI lub innego dostawcy AI.
Wysyłaj bugi i prośby bezpośrednio do swojego publicznego backlogu.