Мультиагентная система в работе компании: одна модель планирует, другая делает, третья проверяет

Модель генерирует ответ, а ИИ-агент использует модель, инструкции и инструменты, чтобы выполнить поручение: прочитать файлы, изменить код, запустить проверку. В мультиагентной системе таких исполнителей связывают передачей задач. Отдельная роль ещё не требует отдельного поставщика модели.

Планировщик переводит просьбу бизнеса в границы работы и критерии готовности, исполнитель делает изменения, проверяющий ищет расхождения. Например, для выдачи доступа после оплаты план должен учитывать повтор платежа, исполнение должно его обработать, а проверка должна воспроизвести повтор.

В нашей машине используются Claude Code и Codex. Роль назначают под задачу: название продукта не закрепляет за ним право всегда планировать или всегда проверять. Кто выбирает задачи и принимает риск, разобрано в статье «Руководитель разработки и агенты».

Следующий агент должен получить исходное требование и сам результат. Если ему передали только пересказ «всё сделано», он проверяет рассказ автора. Для задачи с оплатой проверяющему нужны условия выдачи доступа, изменения и возможность воспроизвести сценарий, а не одобрительный итог чата.

В исследовательской системе Anthropic ведущий агент задаёт подзадаче цель, формат результата и границы. Результаты сохраняют отдельно, чтобы их можно было передать дальше без нового пересказа. Для кода этим результатом может быть изменение в рабочей ветке с указанием версии, которую проверяли.

Заранее зафиксируйте владельца участка и то, что нельзя менять. Подробная форма поручения есть в статье «Постановка задач ИИ-агенту», общие ограничения в «Правилах для ИИ-агентов». Здесь важен договор между ролями: что получить, куда положить и кому вернуть при отказе.

Разные агенты могут одновременно искать источники или править разделённые участки. Если оба меняют общий интерфейс, один результат начинает зависеть от другого. Здесь планировщик должен сначала согласовать интерфейс, а затем раздать работу.

В машине vibecoding.ru параллельная работа столкнулась с общими файлами, выпуском версий и ресурсами компьютера. Каждая такая поломка добавила правило координации. Больше запущенных сессий само по себе не закрыло ни одну из этих проблем.

Anthropic отдельно отмечает, что исследовательский поиск легче разделить, чем многие задачи разработки с зависимостями. Поэтому обещание продавца «всё выполняется параллельно» стоит проверять на общей сборке вашего продукта, где результаты должны сойтись.

Отдельный проверяющий получает критерии и результат исполнителя, затем ищет ошибки. Другая модель может заметить то, что автор пропустил. При этом обе модели могут разделять неверное предположение: нужно требовать воспроизведение замечания, а не согласие ещё одного чата.

Наши проверки находили пропуски вокруг писем и доступа к курсу. В этих историях результат ревью превратился в изменение правила или кода. Написанное агентом «критичных ошибок нет» не завершало работу.

Ответственность за ошибки ИИ остаётся частью управления разработкой. Инженер проверяет находки, задаёт допустимые действия и принимает риск выпуска. Проверяющей модели нельзя поручить окончательное решение о последствиях для бизнеса.

После исправления проверяют ту версию, которую собираются принять. Если исполнитель изменил код после ревью, прежнее одобрение не распространяется на новые изменения. Для оплаты повторяют сценарий целиком: платёж, право доступа, письмо, повтор события.

Замечание проверяющего тоже может оказаться ошибочным. Полезный отчёт показывает, где расходится поведение, как это повторить и какой критерий нарушен. Без такого следа исполнитель может зря менять рабочий код.

У возврата есть предел расхода и условие остановки. Если роли спорят, повторяют одинаковые правки или исчерпали бюджет, задачу возвращают инженеру с текущим результатом и нерешённым вопросом. Бесконечная переписка агентов не считается принятым результатом.

На публичном счётчике API-стоимости окно с 1 июля по 7 октября 2026: 99 календарных дней. По API-прайсам расход оценивается в $57 780, по учёту подписок в $1 621. Счётчик распределяет подписки по дням, скидок и чеков не учитывает.

По категориям сессий главные дают $45,1 тыс., сабагенты $12,7 тыс. Главная сессия тоже может выполнять работу, а сабагент может проверять. Это распределение расчётного расхода между категориями сессий, а не цена планирования отдельно от исполнения.

Расход по инструментам показывает другую группировку тех же данных. Claude Code и Codex нельзя прибавлять к главным сессиям и сабагентам. О том, что ещё видно в наших измерениях, есть отдельная статья «Агентная разработка в цифрах».

Счётчик предупреждает: для gpt-6.1-sol цена ещё не задана, 422 млн токенов учтены по $0. Поэтому API-эквивалент неполный. Такое ограничение должно сопровождать число, если вы сравниваете его с предложением поставщика.

Из этого счётчика нельзя вывести окупаемость. В нём нет стоимости человеческой приёмки, сравнения одинаковых задач и эффекта для компании. Разрыв между API-прайсом и подписками также не переносится автоматически на ваши условия использования.

Для пилота попросите связать расход с принятой задачей. Считайте запуски, возвраты и человеческую проверку, включая неудачные попытки. Тогда станет видно, сколько стоит результат, которым можно пользоваться, а не только успешный ответ модели.

До покупки платформы выберите реальную задачу с проверяемым результатом. Например, исправление выдачи доступа после повторного платежа. Перед запуском зафиксируйте входные данные, версию системы и критерии приёмки, чтобы разные схемы решали одну задачу.

Сначала получите результат с базовой схемой исполнения, затем попробуйте разделение на план, работу и проверку. Сравните время до принятия, расход и участие инженера. Это наш способ проверки предложения, а не опубликованный замер превосходства нескольких моделей.

Попросите показать не только удачный путь. В пилот должны попасть отказ проверяющего, исправление и повторная проверка, а также остановка по пределу расхода. Если продавец не может восстановить этот след, вам трудно будет разобраться в следующем сбое.

Если пока непонятно, кто в компании ставит критерии и принимает работу, начните с теста для руководителя. Он помогает определить, какие функции управления остаются у вашей команды до делегирования разработки.

Для задач нескольких проектов в подписке на агентную разработку есть тариф «Все проекты»: 500 000 ₽ в месяц, три параллельных потока. В каждом потоке выполняется одна задача, следующая ждёт очереди. Инженер ведёт машину агентов; количество потоков услуги не задаёт количество агентов.

Архитектурные решения по вашему продукту остаются у вашей команды. Подписка даёт исполнение задач в согласованных границах, а устройство собственной платформы требует отдельного определения объёма работ. Наш публичный проект показывает механизм передач и ошибок; пользу для вашей компании должен показать её пилот.

1. Назначайте роль по результату, который она должна передать: критерии, изменения или проверяемые замечания.

2. Разделяйте независимую работу; общие изменения и выпуск версий ставьте в очередь.

3. Возвращайте подтверждённую ошибку исполнителю и повторно проверяйте исправленную версию.

4. Считайте расход до принятия задачи вместе с неудачными попытками и работой инженера.

5. До покупки сравните схемы на своей задаче и потребуйте сохранённый след передачи, отказа и исправления.