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.
W panelu Tests agent testowy projektu przechodzi z Sonnet na tańszy Claude Haiku. Agent Claude Opus dodaje przycisk Buy, a potem deleguje test w przeglądarce: pod nim pojawia się agent QA na Haiku, otwiera sklep we wbudowanej przeglądarce, klika Buy i widzi, że koszyk zmienia się na 1. Werdykt, zaliczony, wraca do rozmowy agenta Opus.
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 opisanym zwykłym językiem. 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 3 Pro
Strona QA (oddelegowana do tańszego)
- Claude Haiku 4
- Claude Sonnet 4 (low effort)
- Codex mini
- GPT-4 mini
- Gemini 3 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, Codex, GitHub Copilot CLI, Cursor i 15 innych CLI agentów). 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."
})Czym jest delegowanie agenta w AgentsRoom?
Po co mi w ogóle delegowanie agenta?
Które modele działają w delegowaniu agenta?
Czy delegowanie agenta jest tylko dla testów przeglądarki?
Jak delegowanie agenta zapobiega temu, że agent dev sam zrobi test?
Czy delegowanie agenta to chmura czy lokalnie?
Czy delegowanie agenta oszczędza realne pieniądze?
Co agent dev dostaje z powrotem z delegowania agenta?
Czy agent QA może założyć ticket w backlogu, kiedy nie zda?
Gdzie delegowanie agenta wpisuje się względem innych funkcji AgentsRoom?
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 Messaging
Delegowanie tworzy jednorazowego agenta, który zwraca werdykt i ginie. Wiadomości między agentami idą w drugą stronę: stali członkowie piszą do siebie, ze skrzynką odbiorczą, która przeżywa każdą sesję.
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, Antigravity, OpenCode, Aider, Grok Build, Mistral Vibe i Kimi Code 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 towarzysząca: monitoruj agentów w podróży
Użyj Claude, Codex, Antigravity CLI lub innego dostawcy AI.
Wysyłaj bugi i prośby bezpośrednio do swojego publicznego backlogu.
Agenci, których czytasz jak rozmowę
Każdy agent ma rolę, twarz i wątek, który czytasz jak komunikator.
