Один агент или команда: как довести задачу до результата

Когда мы обсуждаем команды AI-агентов, очень легко начать с устройства команды: кто будет аналитиком, кто ревьюером, кто координатором. Я предлагаю сначала задать другой вопрос: какую проблему мы хотим решить с помощью нескольких агентов и какую дополнительную цену готовы за это заплатить?

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

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

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

Это полезная инженерная возможность, но сама по себе новая роль не делает проверку независимой. Если в задании ревьюеру уже зашит ожидаемый ответ, он может просто подтвердить предположение координатора. Вместо «проверь, почему причина именно здесь» лучше оставлять пространство для самостоятельного исследования и требовать оснований для вывода.

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

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

Наконец, отдельные агенты дают отдельные точки наблюдения. Я могу посмотреть, какие инструменты использовал агент поиска, сколько потратил токенов, сколько времени работал. Если по условиям задачи он обязан искать во внешнем источнике, отсутствие соответствующего вызова — повод не принимать ответ и разобраться. Так мы проверяем выполнение необходимого действия; это ещё не доказывает, что найденная информация верна.

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

На встрече мы сравнивали это с затратами человеческих команд на коммуникацию и введение нового сотрудника в контекст. Для агента такое введение означает инструкции и данные, которые он должен получить. Если эти данные многократно копируются между участниками процесса, растут объём обработки и потенциальная стоимость. Токены — единицы текста, который модель получает и генерирует. Реальная цена зависит в том числе от модели и работы кэша, поэтому я бы считал её на своих запусках.

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

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

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

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

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

Поэтому несколько агентов — не только способ обойти ограничение контекста. Но и само число систем не даёт готового ответа о составе команды. Важно, какая информация нужна для решения и где она должна соединиться.

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

Здесь нужно разделить право на участие и наличие места. Подтверждённая оплата сама по себе не означает, что на выбранной сессии есть свободное кресло. А отсутствие места не означает, что оплата не поступила.

В нашем инциденте компания оплатила участие сотрудницы. Оплата была подтверждена в 10:03. В 10:07 сотрудница попыталась забронировать сессию, но получила отказ с сообщением payment pending. При этом она оставалась в списке участников корпоративной программы, а на сессии были свободные места.

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

Среди источников были сводные показатели, обращения в поддержку, подробные записи об оплате и участии, правила и логика бронирования, логи отказа. Учебный дашборд показывал 120 попыток, из которых 12 завершились отказом. Это попытки, а не 120 разных людей; и из этих чисел ещё нельзя заключить, что все отказы вызваны одной ошибкой.

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

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

Это особенно важно при исправлении ошибки. Можно устранить симптом в одном обращении и сломать соседнее правило. Набор проверок помогает удержать эту границу. Но сами ожидания тоже требуют понимания бизнеса: неясное правило нельзя сделать ясным одним только названием «тест».

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

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

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

До запуска многие участники выбрали C. Аргумент понятный: речь идёт об оплате и доступе, поэтому хочется больше проверок. Другие считали инцидент достаточно простым для одного агента. Я предложил оценивать прежде всего правильность ответа, а затем время и затраты на его получение.

В эфире мы запустили C и A. Вариант B был объяснён, но отдельного запуска B в записи не было. Все агенты в показанном исследовании имели доступ к одним и тем же шести источникам.

Команда C определила причину отказа: логика требовала, чтобы участник совпадал с покупателем по счёту. Для корпоративной программы это неверное требование: покупатель и участник могут различаться. При этом бронирование всё равно требует подтверждённой оплаты, активного доступа, назначенного участнику, и его имени в актуальном списке. Только затем проверяются существующая бронь и наличие мест. Сообщение payment pending при этом направляло расследование в сторону оплаты, хотя проблема была в проверке права на участие.

Команда вернула итог примерно за две с половиной минуты. Первый отчёт аналитика с этим диагнозом был готов примерно через 43 секунды. После него команда ещё проверяла и собирала окончательный ответ.

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

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

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

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

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

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

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

Я бы не фиксировал правило «всегда A» или «всегда C». Моя рабочая гипотеза — собирать характерные задачи продукта, сравнивать на них способы работы и на этой основе решать, когда нужна команда. В некоторых системах такой выбор можно оформить как маршрутизатор. Его полезность тоже нужно измерять.

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

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

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