Когда говорят о рабочем процессе ИИ-агентов, большинство представляет одного агента, одну длинную задачу и ожидание результата. Для небольших задач так и работает. На чём-то крупном, например «перевести платежи на нового провайдера», один агент исследует, планирует и реализует всё сразу: контекст раздувается, плана вы не видите, а ошибки всплывают только после написания кода.
В этой статье три способа, которыми AgentVera делит такую работу между несколькими агентами: команда с менеджером и ролями, параллельная команда, которая запускает независимые части одновременно, и потоки (flows), которые передают результат одного агента следующему.
Зачем делить рабочий процесс ИИ-агентов?
Проблемы сессии с одним агентом:
- Контекст растёт. Каждый файл, прочитанный при исследовании, остаётся в контексте при реализации.
- План не виден. Агент сам решает, что делать, и сразу переходит к коду.
- Ошибки проявляются поздно. Неверное предположение обнаруживается, только когда падают тесты.
Несколько агентов с чёткими задачами это исправляют. Исследователь не пишет код, планировщик пишет только план, разработчик его реализует, а ревьюер проверяет. У каждого свой небольшой контекст.
Вариант 1: команда с менеджером и ролями
Представление команды превращает агентов, открытых в вашем рабочем пространстве, в команду. В окне Team structure вы расставляете их на оргсхеме: один становится менеджером, остальным назначаются роль, инструкции, тот, кому они подчиняются, и тот, кому передают свою работу. В команде до 24 агентов.
Собирать её с нуля не обязательно. Готовые роли (Ready-made roles) подставляют исследователя, планировщика, разработчика, ревьюера, тестировщика и других; готовые команды, например software team (техлид, планировщик, разработчик, ревьюер и тестировщик), сами открывают нужных агентов. У команды и у каждой роли могут быть свои MCP-серверы, так что тестировщик сразу стартует с Playwright, и вам не нужно настраивать это для каждого агента.
Когда команда собрана, ничего не запускается. Вы вводите задачу в поле ниже и выбираете Give to the team. Она уходит менеджеру, который делит её, раздаёт и проверяет результаты. Агенты договариваются через чат агентов и общий список задач.
Пока команда работает, представление команды показывает, кто чем занят, как сообщения бегут между агентами и на каком этапе каждая задача. Запросы разрешений приходят на панель внимания над схемой, где их можно одобрить или отклонить на месте. Status report просит менеджера кратко подвести итог; Interrupt all останавливает всех.
Это подходит для работы, где агентам нужно разговаривать друг с другом: планировщик задаёт исследователю уточняющий вопрос, ревьюер возвращает правку разработчику.
Вариант 2: параллельная команда с одним PR
Некоторые задачи делятся на независимые части: например, API, интерфейс и миграция новой фичи. Параллельная команда запускает их одновременно.
Агент сам запускает такую команду, когда крупное изменение делится подобным образом. Он пишет части или даёт только цель и позволяет Claude Sonnet прочитать репозиторий и спланировать их. Дальше:
- Каждая часть уходит своему агенту в свой worktree и ветку, поэтому агенты никогда не трогают файлы друг друга. По умолчанию одновременно работают 3, максимум 6.
- Закончив, агент завершает ответ маркером
[[TESLİM]], а если застрял, то[[YARDIM]]. Застрявшая часть ждёт вас: можно принять сделанное, дать ей продолжить или пропустить. - Готовые части сливаются в интеграционную ветку, а в качестве итоговой проверки запускается тестовая команда проекта. Если слияние даёт конфликт или проверка падает, подключается интеграционный агент.
- Вы открываете один pull request или ставите ветку в очередь слияния.
Это подходит для крупных изменений, где части не должны общаться друг с другом, а только сойтись в конце.
Вариант 3: потоки, которые передают работу дальше
Если нужна фиксированная цепочка, соберите её в flows. Классическая последовательность исследование, план, реализация выглядит так:
| Шаг | Агент | Что получает | Правило |
|---|---|---|---|
| Исследование | Исследователь | Цель | Без кода; описать текущее состояние и варианты |
| План | Планировщик | Последний ответ исследователя | Цель, что вне рамок, файлы, шаги, стратегия тестов, критерии приёмки |
| Одобрение | Вы | План | Узел Human approval |
| Реализация | Исполнитель | Одобренный план | Реализовать план, запустить тесты |
Когда агент заканчивает ход, его последний ответ подставляется в шаблон сообщения соединения ({{output}}) и отправляется следующему агенту. Если следующий агент занят, поток ждёт окончания его хода. Узлы, которые делают цепочку безопасной:
- Condition: переходить дальше, только если ответ содержит фразу или подходит под регулярное выражение, чтобы вопрос посреди работы не запускал следующий шаг.
- Transform: отправить только последний блок кода или первые N строк.
- Human approval: остановиться до вашего одобрения, из приложения или из Telegram.
- Wait и Notify: оставить паузу между шагами и получать уведомления о важных.
- Turn limit: приостановить соединение, которое зациклилось.
Шаг одобрения важнее всего
Какой бы вариант вы ни выбрали, самый ценный момент — прочитать план до написания кода. Неверный план на этом этапе исправляется за пять минут, а когда код уже есть, за часы. Что чаще всего удаётся поймать:
- Модуль, который должен остаться вне рамок, пробирается в план.
- В стратегии тестов нет существующих тестов.
- Порядок шагов, например сначала интерфейс, потом реализация.
В команде попросите менеджера прислать вам план, прежде чем он раздаст работу. В потоке поставьте узел Human approval перед исполнителем.
Как написать хорошую цель
Первое, что получают агенты, — написанная вами цель. Хорошая цель:
- Описывает результат: «Перевести платёжного провайдера с X на Y, не меняя текущий контракт API».
- Задаёт границы: «Не трогай модуль выставления счетов».
- Определяет успех: «Существующие тесты платежей должны проходить, а для нового провайдера нужно добавить интеграционный тест».
Цель вроде «улучшить платежи» заставляет каждого агента читать всю кодовую базу.
Что выбрать?
- Один агент: правка в одном файле, опечатка или небольшое изменение стиля. Разделение займёт больше времени, чем сама работа.
- Представление команды: продолжительная работа, где агентам с разными ролями нужно общаться, задавать вопросы и проверять друг друга.
- Параллельная команда: крупное изменение с независимыми частями, которое должно закончиться одной веткой и одним PR.
- Flows: фиксированная последовательность, которую вы запускаете снова и снова, с одобрениями и условиями между шагами.
Долгие задачи, пока вас нет
Сидеть за компьютером, пока идёт долгая задача, не нужно:
- Уведомления в Telegram: одобряйте шаг потока с телефона, а ответом на уведомление отправляйте текст этому агенту.
- Мобильное приложение AgentVera: следите за чатом, терминалом и diff каждого агента на iOS или Android и отвечайте на его запросы разрешений.
- Запланированные задачи: отправляйте агенту сообщение по расписанию cron, например чтобы он начинал исследование зависимостей каждое утро.
- Prevent sleep: настройка, которая не даёт компьютеру засыпать, пока работают агенты, не позволяет ночным задачам останавливаться.
Чек-лист
- Описывает ли цель результат и границы в одном абзаце?
- Есть ли у каждого агента одна понятная задача?
- Увидите ли вы план до написания кода?
- Запустятся ли тесты до того, как работу назовут готовой?
- Придёт ли вам уведомление, когда всё закончится?
Подводим итоги
Когда рабочий процесс ИИ-агентов разделён между агентами, на больших задачах они ведут себя предсказуемее: контексты остаются небольшими, план виден, а ошибки всплывают рано. AgentVera даёт три способа сделать это, от живой команды до параллельного запуска, который заканчивается одним PR.
Начните с бесплатного тарифа и загляните в раздел уведомления и одобрения, чтобы обрабатывать одобрения удалённо.