Делегування агентів:
ваш агент розробки делегує тест
Делегування агентів дозволяє вашому агенту розробки завершити функцію і передати валідацію окремому агенту QA. Розробник продовжує писати код з моделлю, якій ви довіряєте для складних задач. Агент QA виконує тест на дешевшій моделі. Обидва спілкуються через сервери MCP AgentsRoom, тому делегування агентів працює від початку до кінця без необхідності копіювати щось.
Ви перестаєте платити ціни Opus за кліки в браузері. Ви перестаєте перевантажувати контекст вашого агента розробки скріншотами і дампами DOM. Делегування агентів направляє кожне завдання до правильної моделі за правильною ціною, і коли агент QA завершує роботу, він повідомляє агента розробки, щоб цикл завершився самостійно.
Делегування агентів в дії: агент розробки Codex завершує функцію, викликає run_qa_test, агент QA відкриває браузер на дешевшій моделі і повідомляє назад.
Ось проблема, яку вирішує делегування агентів. Ви використовуєте потужного агента розробки (Claude Opus, Codex, модель, яка проектує API або рефакторить магазин). Агент випускає функцію за 10 хвилин. Потім він витрачає наступні 8 хвилин, клікаючи в браузері, щоб перевірити, чи працює функція. Така ж дорога ставка токенів. Така ж модель, яка думала про вашу доменну логіку, тепер читає мітки кнопок.
Делегування агентів це виправляє. Коли функція завершена, агент розробки викликає один інструмент MCP, run_qa_test, зі сценарієм. AgentsRoom створює тимчасового агента QA на моделі, яку ви вибрали для QA: Claude Haiku, Codex mini, GPT-4 mini, що завгодно. Агент QA отримує AgentsRoom Browser MCP, керує сторінкою, перевіряє результат і відповідає з вердиктом. Агент розробки читає вердикт і продовжує.
Це делегування агентів, і це єдиний цикл, який покриває сторінка. Один розробник, один QA, один MCP. Така ж ідея, як старший інженер делегує регресійне тестування молодшому або QA: старший продовжує проектувати, молодший виконує чек-лист. Делегування агентів дає вам такий же поділ між моделями.
Візуалізація делегування агентів: батьківський агент розробки (Codex) і дочірній агент QA (Claude) з'являються в одному списку агентів, з чіткою передачею від розробки до QA.
Чому варто впроваджувати делегування агентів
По-перше, гроші. Проходження тесту на Claude Opus і проходження тесту на Claude Haiku коштують значно різні суми. Той самий браузер, ті самі перевірки, ті самі скріншоти. Делегування агентів дозволяє дешевшій моделі виконувати дешевшу роботу. Люди, які це ввімкнули, повідомляють про зниження витрат на токени в дні з великою кількістю QA на реальний, вимірюваний фактор, а не на 5-10 відсотків.
По-друге, контекст. Коли агент розробки сам виконує тест, кожен скріншот, кожен дамп DOM, кожен лог консолі потрапляє у вікно контексту агента розробки. Двадцять хвилин кліків - це мегабайти шуму, які агент розробки має нести через решту сесії. Делегування агентів ізолює цей шум всередині тимчасового агента QA. Агент розробки отримує чисте повідомлення 'пройшов' або 'не пройшов', нічого більше.
По-третє, екологічний аспект. Кожне делегування агентів економить реальні обчислення. Виконання Haiku там, де працював Opus, зменшує енергетичний слід на цьому етапі вдвічі. Помножте на всіх у команді і на кожен тестовий цикл за рік, і делегування агентів стає нетривіальним регулятором на вуглецевій стороні вашого стека.
По-четверте, надійність. Агент розробки, який сам керує браузером, має тенденцію блукати. Через два скріншоти він забуває, що намагався перевірити. Агент QA в делегуванні агентів має одне завдання і один запит. Він тестує, повідомляє і завершує роботу. Цикл короткий, передбачуваний і легкий для налагодження.
Єдиний потік, який покриває делегування агентів тут
Один агент розробки. Один агент QA. Один виклик MCP. Делегування агентів від початку до кінця.
Агент розробки випускає функцію
Ваш агент розробки (Claude Opus, Codex з високими можливостями міркування, будь-яка дорога модель, якій ви довіряєте) завершує реалізацію. Новий кінцевий пункт, новий екран, новий потік. Код написано, файли збережено.
Агент розробки викликає run_qa_test
Замість того, щоб самостійно відкривати браузер, агент розробки викликає один інструмент MCP з сервера AgentsRoom Test Runner: run_qa_test, з простим англійським сценарієм. Це вся поверхня API делегування агентів.
AgentsRoom створює агента QA
AgentsRoom Test Runner запускає ефемерного QA агента на дешевшій моделі, яку ви налаштували (Claude Haiku, Codex mini, GPT-4 mini). QA агент отримує інструменти AgentsRoom Browser MCP: navigate, click, type, screenshot, evaluate, get_logs, get_state.
QA агент виконує тест
QA агент відкриває сторінку, проходить сценарій, перевіряє результат, робить скріншоти за потреби та читає журнали консолі, щоб виявити помилки виконання, які міг пропустити dev агент.
QA агент подає вердикт
Після завершення QA агент викликає submit_verdict з результатом pass, fail або inconclusive та коротким підсумком. Додаються скріншоти та журнали. Процес QA агента знищується. Його вікно контексту зникає разом з ним.
Dev агент читає вердикт і продовжує
Dev агент отримує вердикт у відповідь на run_qa_test. У разі pass, dev агент комітить або переходить до наступного завдання. У разі fail, dev агент читає підсумок помилки, виправляє баг і запускає новий цикл делегування агента. Цикл закривається самостійно.
Економіка делегування агентів
Чому розумний поділ dev і QA знижує ваші витрати на AI без зниження стандартів.
Тести браузера повторювані. Відкрити сторінку, натиснути кнопку, прочитати мітку, перевірити повідомлення. Модель за 50 доларів за мільйон токенів виконує цю роботу так само добре, як і модель за 3 долари за мільйон токенів. Можливо, навіть краще, тому що дешева модель не нудьгує. Делегування агентів ставить дешеву модель на нудну частину роботи.
Реальні цифри з реальних сесій: типовий end to end тест на складному потоці спалює від 60k до 200k токенів між скріншотами, дампами DOM і кроками міркування. На Opus це реальні гроші за тест. На Haiku це дрібниця. Делегування агентів перетворює щоденну звичку QA з бюджетного питання на безкоштовний рефлекс.
Помножте на кожен цикл. Звичайний день розробника на нетривіальній функції запускає тест від п'яти до двадцяти разів. Делегування агентів накопичується через ці повторення. Dev агент залишається дорогим (ви хочете, щоб він був дорогим), QA агент залишається дешевим, і різниця - це чиста економія.
Делегування агентів також є добрішим до планети. Менше обчислень на ту ж роботу означає менше енергії, менше води в дата-центрі, менше вуглецю. Це не єдина причина для впровадження делегування агентів, але справедливий побічний ефект від маршрутизації завдань до моделей відповідного розміру.
Реальний поділ моделей для делегування агентів
Що люди насправді підключають до dev і QA сторін делегування агентів.
Dev сторона (залишається дорогою навмисно)
- Claude Opus 4.7
- Claude Sonnet 4.6
- Codex high reasoning
- GPT-4 з глибоким міркуванням
- Gemini 3 Pro
QA сторона (делегується дешевшим)
- Claude Haiku 4
- Claude Sonnet 4 (низькі зусилля)
- Codex mini
- GPT-4 mini
- Gemini 3 Flash
Делегування агентів не блокує матрицю. Ви налаштовуєте модель QA для кожного проекту. Ви навіть можете делегувати агентів зовсім іншому постачальнику: Opus на dev, Codex mini на QA, без спільного контексту, лише виклик MCP.
Що насправді робить делегування агентів під капотом
Делегування агентів сидить на стеку AgentsRoom MCP. Dev агент працює всередині свого CLI (Claude Code, Codex, Antigravity, OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code). AgentsRoom впроваджує сервер Test Runner MCP у цього агента. Test Runner надає один інструмент: run_qa_test. Це точка входу для кожного виклику делегування агента.
Коли запускається run_qa_test, AgentsRoom створює новий процес CLI у тому ж проєкті, але з іншою конфігурацією. Ця конфігурація має підключений Browser MCP, підключений системний запит QA, і модель змінено на ту, яку ви встановили на стороні QA. Новий процес є ефемерним агентом QA: він існує протягом тесту і завершується після submit_verdict.
Поки агент QA працює, агент розробки призупиняється на виклику run_qa_test. AgentsRoom показує агента QA в тому ж списку агентів, відступаючи під агентом розробки (видно на зображенні вище). Коли агент QA завершує роботу, його вердикт повертається як результат run_qa_test, і агент розробки відновлює роботу. Делегування агентів є однією поїздкою MCP з точки зору агента розробки.
Агент розробки ніколи не отримує інструменти браузера. AgentsRoom видаляє інструменти browser_* зі списку дозволених агенту розробки під час створення. Це частина, яка робить делегування агентів надійним: агент розробки не може самостійно виконати тест, навіть якщо його інстинкт - зробити знімок екрана. Єдиний шлях вперед - це run_qa_test. Делегування агентів шляхом видалення, а не запитом.
Де сьогодні працює делегування агентів і куди далі
Делегування агентів в AgentsRoom сьогодні орієнтоване на браузер. Така ж форма, більше поверхонь у майбутньому.
Сьогодні: делегування тестів браузера
Агент QA керує вбудованим браузером AgentsRoom через Browser MCP. Локальний сервер розробки, публічний тунель попереднього перегляду, URL-адреса тестування, все, що може відобразити Chromium. Форми, модальні вікна, перетягування, діалоги, журнали консолі, помилки мережі. Делегування агентів охоплює всю поверхню, яку охопив би інженер веб-QA.
Делегування тестів Electron додатків
Якщо ви самостійно постачаєте додаток Electron, ви можете встановити бібліотеку AgentsRoom Electron MCP у свій проєкт. Агент QA підключається до вашого додатка Electron так само, як підключається до вкладки Chromium. Делегування агентів переходить у тестування настільних додатків без жодних змін на стороні розробки.
Делегування тестів додатків React Native (дорожня карта)
Така ж форма делегування агентів з'явиться для React Native. Агент QA керуватиме симулятором iOS або Android через AgentsRoom React Native MCP. Агент розробки відправляє екран, агент QA натискає на нього. Такий же виклик run_qa_test, така ж передача від розробки до QA, мобільна ціль.
Без делегування агентів проти з делегуванням агентів
Така ж функція, такий же прохід QA. Різний рахунок, різний контекст, різна надійність.
Без делегування агентів
- : Агент розробки (дорогий) відкриває браузер самостійно.
- : Кожен знімок екрана, кожен дамп DOM і кожен журнал консолі потрапляють у контекст агента розробки.
- : 20 хвилин кліків витрачають токени Opus на роботу, яку виконав би дешевший модель.
- : Агент розробки забуває, що робив, через два знімки екрана.
- : Ви платите повну ціну за кліки в браузері, планета теж платить повну ціну.
З делегуванням агентів
- : Агент розробки викликає run_qa_test і чекає.
- : Дешевий агент QA робить кліки, перевірки, захоплення знімків екрана.
- : Тільки вердикт (прохід, провал, підсумок) досягає агента розробки.
- : Агент QA є ефемерним: він завершується після submit_verdict, без перевантаження контексту.
- : Рахунок за токени знижується, агент розробки залишається зосередженим, цикл закривається самостійно.
Делегування агентів - це найдешевша перемога в надійності, яку ви можете інтегрувати в налаштування агента кодування.
Як виглядає виклик делегування агенту
Ось повна структура делегування агенту від розробника до QA. Агент розробника запускає це через Test Runner MCP і чекає на відповідь.
Виклик інструменту MCP (агент розробника)
run_qa_test({
scenario: "Відкрити http://localhost:3000/login.\n Ввести тестового користувача в поле електронної пошти.\n Відправити форму.\n Переконатися, що досягнуто URL панелі інструментів і ім'я користувача відображається в заголовку.\n Захопити скріншот у разі успіху, захопити журнали консолі у разі невдачі."
})FAQ
Що таке делегування агенту в AgentsRoom?
Делегування агенту - це передача від розробника до QA між двома AI агентами кодування. Агент розробника завершує функцію, викликає єдиний інструмент MCP (run_qa_test), і тимчасовий QA агент запускає тест на іншій моделі. Агент розробника читає вердикт і продовжує. Весь процес делегування агенту відбувається через сервери AgentsRoom MCP.
Чому я взагалі хочу делегування агенту?
Три причини. Гроші: QA агент працює на дешевшій моделі, тому проходження тестів коштує частку від того, що вони коштували б на моделі розробника. Контекст: агент розробника залишається чистим, всі скріншоти і дампи DOM зникають з QA агентом. Надійність: QA агент має одну задачу, тому він тестує краще, ніж агент розробника, що виконує багато завдань на кліках браузера.
Які моделі працюють для делегування агенту?
Будь-яка модель, яку підтримує AgentsRoom: Claude (Opus, Sonnet, Haiku), Codex (high, mini), Antigravity (Pro, Flash), OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code. Делегування агенту є крос-провайдерським. Звичайний розподіл - це Claude Opus або Codex на стороні розробника і Claude Haiku або Codex mini на стороні QA, але вибір за вами.
Чи є делегування агенту тільки для тестів браузера?
Сьогодні так, QA агент керує вбудованим браузером Chromium в AgentsRoom. Завтра та ж форма делегування агенту покриватиме додатки Electron (встановіть бібліотеку AgentsRoom Electron MCP у ваш проект Electron) і додатки React Native (дорожня карта, симулятори iOS і Android).
Як делегування агенту уникає того, щоб агент розробника сам виконував тест?
AgentsRoom видаляє інструменти browser_* з агента розробника під час запуску. Агент розробника буквально не може викликати browser_navigate або browser_screenshot. Єдиний шлях через браузер - це run_qa_test, який запускає делегування агенту. Обмеження є механічним, а не ввічливим проханням у підказці.
Чи є делегування агенту хмарним чи локальним?
Локально-першим. Агент розробника, тимчасовий QA агент, міст MCP і браузер працюють на вашій машині. Делегування агенту використовує хмару лише тоді, коли базова модель (Claude, Codex, Antigravity) спілкується зі своїм провайдером, точно як звичайний запуск агента.
Чи дійсно делегування агенту економить реальні гроші?
Так, за значущим фактором для днів з великою кількістю QA. Складний кінець-до-кінця тест на Opus або Codex high проти того ж тесту на Haiku або Codex mini - це приблизно 10-кратна різниця у вартості. Делегування агенту протягом дня розробки в команді швидко масштабує цей розрив.
Що отримує агент розробника від делегування агенту?
Короткий структурований вердикт: пройдено, не пройдено або непереконливо, з резюме, необов'язковим шляхом до скріншоту і необов'язковими журналами консолі. Ніяких сирих скріншотів у контексті, ніяких дампів DOM. Це вся суть делегування агенту: ізолювати шум QA всередині QA агента.
Чи може QA агент створити завдання в беклозі, коли він не вдається?
Так. Делегування агенту дає QA агенту Backlog MCP. Невдача може стати завданням у беклозі проекту, з прикріпленим сценарієм, скріншотом і журналами консолі. Агент розробника читає вердикт, а завдання в беклозі містить деталі у довгій формі.
Де делегування агенту розташовується відносно інших функцій AgentsRoom?
Делегування агенту знаходиться поверх Автоматизації Браузера (яка дає QA агенту браузер) і серверів AgentsRoom MCP (які надають кожному агенту його інструментальну поверхню). Agent Teams - це ширший редактор робочих процесів з багатьма агентами: делегування агенту - це передача від розробника до QA в цьому робочому процесі, але представлена як єдиний виклик MCP, щоб будь-який агент у будь-якому провайдері міг використовувати його без налаштування графу.
Добре поєднується з
Автоматизація Браузера
Шар Chromium і Browser MCP, яким керує QA сторона делегування агенту. Реальний постійний браузер для кожного проекту.
Agent Teams
Візуальний редактор робочих процесів з кількома агентами. Делегування агентів: це передача від розробника до QA, Agent Teams: це повна графова версія з N вузлами та зворотними зв'язками.
AgentsRoom MCP
Сервери MCP, які роблять можливим делегування агентів: Test Runner, Browser, Backlog, Terminal Commands, Prompt Library.
Багатопровайдерність
Запускайте Claude, Codex, Antigravity, OpenCode, Aider, Grok Build, Mistral Vibe та Kimi Code одночасно. Делегування агентів: це крос-провайдерний аспект тієї ж ідеї.
Використання токенів Claude Code
Живий лічильник токенів на сесію. Найшвидший спосіб підтвердити економію коштів, яку на практиці дає делегування агентів.
Публічний Backlog
Коли агент QA не проходить делегування агентів, помилка потрапляє сюди. Клієнти та колеги бачать регресію, агент розробки бере її на себе.
Припиніть платити ціни Opus за кліки QA
Завантажте AgentsRoom і спробуйте делегування агентів. Підключіть свого агента розробки до моделі, якій довіряєте, агента QA: до дешевшої моделі, і нехай передача від розробника до QA відбувається самостійно через MCP.
Додаток-компаньйон: контролюйте своїх агентів на ходу
Використовуйте свого: Claude, Codex, Antigravity CLI або іншого AI-провайдера.
Надсилайте баги та запити прямо у свій публічний беклог.
Погляд на AgentsRoom в дії.