Делегирование агентов:
ваш dev-агент делегирует тест
Делегирование агентов позволяет вашему dev-агенту завершить фичу и передать валидацию отдельному QA-агенту. Dev продолжает писать код на модели, которой вы доверяете в сложных задачах. QA-агент запускает тест на более дешёвой модели. Оба общаются через MCP-серверы AgentsRoom, поэтому делегирование агентов работает от начала и до конца без необходимости что-либо копировать вручную.
Вы перестаёте платить по тарифу Opus за клики в браузере. Вы перестаёте раздувать контекст dev-агента скриншотами и DOM-дампами. Делегирование агентов направляет каждую задачу нужной модели по нужной цене, а когда QA-агент закончил, он пингует dev-агента обратно, и цикл закрывается сам по себе.
Делегирование агентов в действии: dev-агент Codex завершает фичу, вызывает run_qa_test, QA-агент открывает браузер на более дешёвой модели и отчитывается о результате.
Вот проблема, которую решает делегирование агентов. Вы запускаете мощного dev-агента (Claude Opus, Codex, модель, которая проектирует API или рефакторит стор). Агент выпускает фичу за 10 минут. Затем тратит следующие 8 минут, кликая по браузеру, чтобы убедиться, что фича работает. Тот же дорогой токен-рейт. Та же модель, которая только что серьёзно думала о вашей доменной логике, теперь читает надписи на кнопках.
Делегирование агентов это исправляет. Когда фича готова, dev-агент вызывает один инструмент MCP, run_qa_test, со сценарием. AgentsRoom поднимает эфемерного QA-агента на выбранной вами модели для QA: Claude Haiku, Codex mini, GPT-4 mini, любой какой захотите. QA-агент получает AgentsRoom Browser MCP, управляет страницей, проверяет результат и отвечает с вердиктом. Dev-агент читает вердикт и движется дальше.
Это и есть делегирование агентов, и это единственный цикл, который покрывает страница. Один dev, один QA, один MCP. Та же идея, что и старший инженер, делегирующий регрессионное тестирование младшему или QA: старший продолжает проектировать, младший проходит чек-лист. Делегирование агентов даёт вам ровно такой же разрыв между моделями.
Визуализация делегирования агентов: родительский dev-агент (Codex) и дочерний QA-агент (Claude) появляются в одном списке агентов с явной передачей от dev к QA.
Почему делегирование агентов стоит подключить
Во-первых, деньги. Прогон теста на Claude Opus и прогон теста на Claude Haiku стоят несопоставимо разные суммы. Тот же браузер, те же ассерты, те же скриншоты. Делегирование агентов позволяет дешёвой модели делать дешёвую работу. Те, кто это включил, рассказывают о падении счёта за токены в дни с большим объёмом QA в реальный, измеримый раз, а не на 5 или 10 процентов.
Во-вторых, контекст. Когда dev-агент сам запускает тест, каждый скриншот, каждый DOM-дамп, каждый лог консоли оказывается в окне контекста dev-агента. Двадцать минут кликания: это мегабайты шума, который dev-агент тащит сквозь оставшуюся сессию. Делегирование агентов изолирует этот шум внутри эфемерного QA-агента. Dev-агент получает обратно чистое сообщение 'pass' или 'fail', и ничего больше.
В-третьих, экологический угол. Каждое делегирование агента экономит реальные вычисления. Запуск Haiku там, где работал Opus, вдвое уменьшает энергетический след на этом шаге. Умножьте на всех в команде и на каждый цикл тестов за год, и делегирование агентов становится нетривиальным рычагом на углеродной стороне вашего стека.
В-четвёртых, надёжность. Dev-агент, который сам водит браузер, склонен отвлекаться. После двух скриншотов он забывает, что пытался валидировать. QA-агент в делегировании агентов имеет одну работу и один промпт. Он тестирует, отчитывается, умирает. Цикл короткий, предсказуемый и легко отлаживаемый.
Единственный поток, который покрывает делегирование агентов здесь
Один dev-агент. Один QA-агент. Один вызов MCP. Делегирование агентов от начала до конца.
Dev-агент выпускает фичу
Ваш dev-агент (Claude Opus, Codex high reasoning, любая дорогая модель, которой вы доверяете) завершает реализацию. Новый эндпоинт, новый экран, новый поток. Код написан, файлы сохранены.
Dev-агент вызывает run_qa_test
Вместо того, чтобы открывать браузер самому, dev-агент вызывает один инструмент 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 снижает ваш счёт за ИИ без снижения стандартов.
Браузерные тесты повторяющиеся. Открыть страницу, кликнуть кнопку, прочитать надпись, проверить тост. Модель за 50 долларов за миллион токенов делает эту работу не хуже модели за 3 доллара за миллион токенов. Возможно даже лучше, потому что дешёвой модели не скучно. Делегирование агентов сажает дешёвую модель на скучную половину работы.
Реальные цифры из реальных сессий: типичный сквозной тест сложного потока сжигает от 60 до 200 тысяч токенов между скриншотами, DOM-дампами и шагами рассуждения. На Opus это реальные деньги за тест. На Haiku это мелочь. Делегирование агентов превращает ежедневную привычку QA из бюджетной заботы в бесплатный рефлекс.
Умножьте на каждый цикл. Нормальный день разработки нетривиальной фичи запускает тест от пяти до двадцати раз. Делегирование агентов накапливается на этих повторах. Dev-агент остаётся дорогим (вы хотите, чтобы он был дорогим), QA-агент остаётся дешёвым, и разрыв: это чистая экономия.
Делегирование агентов также добрее к планете. Меньше вычислений на ту же работу: меньше энергии, меньше воды в дата-центре, меньше углерода. Не единственная причина подключать делегирование агентов, но честный побочный эффект маршрутизации задач к моделям правильного размера.
Реальное разделение моделей для делегирования агентов
Что люди реально подключают на dev-сторону и QA-сторону делегирования агентов.
Dev-сторона (намеренно остаётся дорогой)
- Claude Opus 4.7
- Claude Sonnet 4.6
- Codex high reasoning
- GPT-4 with deep reasoning
- Gemini 2.5 Pro
QA-сторона (делегирована более дешёвым)
- Claude Haiku 4
- Claude Sonnet 4 (low effort)
- Codex mini
- GPT-4 mini
- Gemini 2.5 Flash
Делегирование агентов не блокирует матрицу. Вы настраиваете QA-модель для каждого проекта. Вы даже можете делегировать агента совершенно другому провайдеру: Opus на dev, Codex mini на QA, без общего контекста, просто MCP-вызов.
Что делает делегирование агентов под капотом
Делегирование агентов сидит на стеке MCP AgentsRoom. Dev-агент работает внутри своего CLI (Claude Code, Codex, Gemini, OpenCode, Aider). AgentsRoom инжектит сервер Test Runner MCP в этого агента. Test Runner предоставляет один инструмент: run_qa_test. Это точка входа каждого вызова делегирования агентов.
Когда срабатывает run_qa_test, AgentsRoom поднимает новый процесс CLI в том же проекте с другой конфигурацией. В этой конфигурации подключён Browser MCP, подключён QA system prompt, и модель заменена на ту, которую вы установили на QA-стороне. Новый процесс: это эфемерный QA-агент, он живёт на время теста и умирает после submit_verdict.
Пока QA-агент работает, dev-агент приостановлен на вызове run_qa_test. AgentsRoom показывает QA-агента в том же списке агентов, с отступом под dev-агентом (видно на изображении выше). Когда QA-агент завершает работу, его вердикт возвращается как результат run_qa_test, и dev-агент возобновляется. Делегирование агентов: это один круговой обход MCP с точки зрения dev-агента.
Dev-агент никогда не получает браузерные инструменты. AgentsRoom вырезает инструменты browser_* из списка разрешённых dev-агенту при старте. Это та часть, которая делает делегирование агентов надёжным: dev-агент не может откатиться к выполнению теста самостоятельно, даже когда его инстинкт схватить скриншот. Единственный путь вперёд: run_qa_test. Делегирование агентов через удаление, а не через просьбу.
Где делегирование агентов работает сегодня и куда дальше
Делегирование агентов в AgentsRoom сегодня браузер-first. Та же форма, больше поверхностей на подходе.
Сегодня: делегирование браузерных тестов
QA-агент управляет встроенным браузером AgentsRoom через Browser MCP. Localhost dev-сервер, публичный preview-туннель, staging URL, всё что Chromium может отрендерить. Формы, модалки, drag and drop, диалоги, логи консоли, сетевые ошибки. Делегирование агентов покрывает всю поверхность, которую покрыл бы web QA-инженер.
Делегирование тестов Electron-приложений
Если вы сами выпускаете Electron-приложение, вы можете установить библиотеку AgentsRoom Electron MCP в свой проект. QA-агент подключается к вашему Electron-приложению так же, как и к вкладке Chromium. Делегирование агентов переходит в тестирование desktop-приложений без изменений на dev-стороне вообще.
Делегирование тестов React Native приложений (roadmap)
Та же форма делегирования агентов придёт к React Native. QA-агент будет управлять iOS или Android симулятором через AgentsRoom React Native MCP. Dev-агент выпускает экран, QA-агент тапает по нему. Тот же вызов run_qa_test, та же передача от dev к QA, мобильная цель.
Без делегирования агентов против с делегированием агентов
Та же фича, тот же прогон QA. Другой счёт, другой контекст, другая надёжность.
Без делегирования агентов
- : Dev-агент (дорогой) сам открывает браузер.
- : Каждый скриншот, каждый DOM-дамп и каждый лог консоли попадают в контекст dev-агента.
- : 20 минут кликания сжигают токены Opus на работу, которую сделала бы более дешёвая модель.
- : Dev-агент забывает, что он делал, после двух скриншотов.
- : Вы платите полную цену за клики в браузере, планета тоже платит полную цену.
С делегированием агентов
- : Dev-агент вызывает run_qa_test и ждёт.
- : Дешёвый QA-агент делает клики, ассерты, захват скриншотов.
- : До dev-агента доходит только вердикт (pass, fail, резюме).
- : QA-агент эфемерный: он умирает после submit_verdict, никакого раздувания контекста.
- : Счёт за токены падает, dev-агент остаётся сфокусированным, цикл закрывается сам.
Делегирование агентов: самый дешёвый выигрыш по надёжности, который можно подключить в связку с кодинг-агентом.
Как выглядит вызов делегирования агентов
Вот вся форма делегирования агентов от dev к QA. Dev-агент стреляет этим через Test Runner MCP и ждёт ответа.
Вызов MCP-инструмента (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
Что такое делегирование агентов в AgentsRoom?
Делегирование агентов: это передача от dev к QA между двумя ИИ-кодинг-агентами. Dev-агент завершает фичу, вызывает один инструмент MCP (run_qa_test), и эфемерный QA-агент запускает тест на другой модели. Dev-агент читает вердикт и движется дальше. Весь поток делегирования агентов проходит через MCP-серверы AgentsRoom.
Зачем мне вообще делегирование агентов?
Три причины. Деньги: QA-агент работает на более дешёвой модели, поэтому прогоны тестов стоят долю того, что они стоили бы на dev-модели. Контекст: dev-агент остаётся чистым, все скриншоты и DOM-дампы умирают вместе с QA-агентом. Надёжность: у QA-агента одна работа, поэтому он тестирует лучше, чем dev-агент, разрывающийся между задачами и кликами в браузере.
Какие модели работают для делегирования агентов?
Любая модель, которую поддерживает AgentsRoom: Claude (Opus, Sonnet, Haiku), Codex (high, mini), Gemini (Pro, Flash), OpenCode, Aider. Делегирование агентов кросс-провайдерное. Распространённое разделение: Claude Opus или Codex на dev-стороне и Claude Haiku или Codex mini на QA-стороне, но вы выбираете сами.
Делегирование агентов только для браузерных тестов?
Сегодня да, QA-агент управляет встроенным браузером Chromium AgentsRoom. Завтра та же форма делегирования агентов покроет приложения Electron (установите библиотеку AgentsRoom Electron MCP в свой Electron-проект) и приложения React Native (roadmap, симуляторы iOS и Android).
Как делегирование агентов избегает того, что dev-агент сам делает тест?
AgentsRoom вырезает инструменты browser_* у dev-агента при старте. Dev-агент буквально не может вызвать browser_navigate или browser_screenshot. Единственный путь к браузеру: run_qa_test, который запускает делегирование агентов. Ограничение механическое, а не вежливая просьба в промпте.
Делегирование агентов это облако или локально?
Local-first. Dev-агент, эфемерный QA-агент, MCP-мост и браузер: всё работает на вашей машине. Делегирование агентов использует облако только когда базовая модель (Claude, Codex, Gemini) общается со своим провайдером, ровно как при обычном прогоне агента.
Делегирование агентов экономит реальные деньги?
Да, в значимой степени для дней с большим QA. Сложный сквозной тест на Opus или Codex high против того же теста на Haiku или Codex mini: это примерно 10-кратная разница в стоимости. Делегирование агентов в течение дня разработки в команде быстро масштабирует этот разрыв.
Что dev-агент получает обратно от делегирования агентов?
Короткий структурированный вердикт: pass, fail или inconclusive, с резюме, опциональным путём скриншота и опциональными логами консоли. Никаких сырых скриншотов в контексте, никаких DOM-дампов. Это весь смысл делегирования агентов: изолировать QA-шум внутри QA-агента.
Может ли QA-агент завести тикет в бэклоге, когда он падает?
Да. Делегирование агентов даёт QA-агенту Backlog MCP. Сбой может приземлиться как тикет бэклога на проекте, со сценарием, скриншотом и логами консоли. Dev-агент читает вердикт, а тикет бэклога несёт длинные детали.
Где делегирование агентов вписывается относительно других фич AgentsRoom?
Делегирование агентов живёт поверх Browser Automation (который даёт QA-агенту браузер) и серверов AgentsRoom MCP (которые дают каждому агенту его инструментальную поверхность). Agent Teams: это более широкий редактор мультиагентного workflow: делегирование агентов это dev-к-QA-аромат этого workflow, но выставленный как единственный MCP-вызов, чтобы любой агент у любого провайдера мог использовать его без настройки графа.
Хорошо сочетается с
Browser Automation
Слой Chromium и Browser MCP, которым управляет QA-сторона делегирования агентов. Настоящий персистентный браузер на каждый проект.
Agent Teams
Визуальный редактор мультиагентного workflow. Делегирование агентов: это dev-к-QA-аромат, Agent Teams: это полная графовая версия с N узлами и петлями обратной связи.
AgentsRoom MCP
MCP-серверы, которые делают делегирование агентов возможным: Test Runner, Browser, Backlog, Terminal Commands, Prompt Library.
Multi-Provider
Запускайте Claude, Codex, Gemini, OpenCode и Aider бок о бок. Делегирование агентов: это кросс-провайдерный угол той же идеи.
Claude Code Token Usage
Живой счётчик токенов по сессии. Самый быстрый способ подтвердить долларовую экономию, которую делегирование агентов даёт вам на практике.
Public Backlog
Когда QA-агент проваливает прогон делегирования агентов, баг приземляется здесь. Клиенты и коллеги видят регрессию, dev-агент её подхватывает.
Хватит платить по цене Opus за QA-клики
Скачайте AgentsRoom и попробуйте делегирование агентов. Подключите своего dev-агента на модели, которой вы доверяете, своего QA-агента на более дешёвой модели, и пусть передача от dev к QA происходит сама через MCP.
Приложение-компаньон: следите за агентами на ходу
Используйте Claude, Codex, Gemini CLI или другого поставщика AI.
Отправляйте баги и запросы прямо в ваш публичный бэклог.