Параллельные AI-агенты: что проверил на практике и когда они действительно полезны

Когда в работе появляется несколько независимых задач, возникает очевидная идея – “почему бы не поручить их разным AI-агентам одновременно, вместо того чтобы ждать, пока один агент закончит все по очереди?”

И у этой идеи сразу два преимущества:

• работа завершится быстрее,

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

Но у такого подхода есть обратная сторона – несколько агентов могут потреблять больше токенов, стоить дороже и оставлять после себя результаты, которые еще нужно правильно собрать и проверить.

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

В статье разберу – как был устроен эксперимент, чем отличались три тестируемых процесса, что показали цифры и какие проблемы обнаружились во время самого запуска.

Что именно я сравнивал

В эксперимент вошли три независимые задачи из одного рабочего сценария:

• подготовка текста посадочной страницы для регистрации;

• подготовка письма по базе;

• подготовка программы часового эфира.

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

Сравнивал три процесса:

• Первый процесс – последовательный. Один агент получает все три задачи и выполняет их одну за другой – самый базовый и распространенный вариант. Сначала он готовит посадочную страницу, затем письмо, затем программу эфира.

• Второй процесс – параллельный запуск через доску. Каждая задача уходит в отдельную изолированную ветку. Они стартуют одновременно, а оркестратор следит за состоянием веток и собирает результаты.

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

Такое разделение было нужно не только для сравнения «один агент против трех», оно позволяло отдельно посмотреть, что дает сама параллельная работа, а что добавляет именно доска как инструмент управления.

Как оценивал процессы

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

Результаты 3 процессов передал отдельному агенту-судье, которого я заранее подготовил. Он не знал, какой ответ был получен последовательным способом, какой через доску, а какой при ручном параллельном запуске. Это и называется слепой оценкой, когда судья сравнивает сами материалы, а не способ их создания.

Важно понимать ограничение этой цифры. Я провел один эксперимент на одном наборе задач, а не серию повторных тестов, поэтому 52 против 44 (эти цифры будут ниже) это результат именно этого сценария, а не доказательство того, что параллельные агенты всегда создают материалы лучше.

Теперь пройдемся по каждому процессу отдельно.

Как работал последовательный процесс

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

Главное преимущество такого подхода – единый контекст. Агент видит всю историю своей работы и может использовать результаты предыдущих этапов. То есть, не нужно отдельно передавать данные между ветками и решать, какой файл считать актуальным.

Но единый контекст одновременно становится ограничением – пока агент переходит от первой задачи ко второй, а затем к третьей, в его рабочем окне накапливается все больше информации – это очевидно, но мне было важно зафиксировать именно по установленным метрикам для сравнения с другими процессами. В моем эксперименте последней выполнялась программа часового эфира и она получила наиболее низкие оценки качества – 6,7/10.

Последовательный процесс занял 7 минут 3 секунды, то есть 423 секунды. По прайсу модели он стоил 2,74$. Эту сумму нужно воспринимать как расчетный эквивалент потребления модели, потому что многие работают по подписке, поэтому речь не о прямом списании 2,74$ с карты, а о понятной метрике расхода лимита.

Для последовательного запуска время ожидания и машинное время совпали. Агент был один, поэтому все 423 секунды работы складывались в общий срок выполнения.

Как работал параллельный запуск через доску

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

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

Именно поэтому параллельный запуск в моем случае дал более высокую оценку качества. Речь не о том, что несколько агентов стали «умнее» одного. У каждой задачи просто было отдельное рабочее пространство, без накопленной истории других задач.

На выполнение самой длинной ветки ушло 307 секунд (5 минут 7 секунд). Столько пришлось ждать до завершения всего параллельного процесса, потому что короткие ветки закончили работу раньше, а итог определила самая длинная.

При этом суммарное машинное время оказалось больше, чем в последовательном варианте. Все ветки вместе работали 499 секунд – 70 секунд первая, 122 секунды вторая и 307 секунд третья. Поэтому параллельный путь суммарно работает дольше – 499 секунд машинного времени против 423 у последовательного. Но ждать приходится меньше – 307 секунд против 423, потому что ветки работают одновременно.

Стоимость параллельного запуска через доску составила 6,15$ против 2,74$ у последовательного. Разница объясняется не только самой работой агентов, но и контекстом. В параллельном варианте в контекст записалось 532 128 токенов против 141 383 в последовательном. Один и тот же исходный набор файлов пришлось передать трем независимым веткам, поэтому контекст фактически использовался несколько раз.

Если сравнивать этот вариант с последовательным, параллельный запуск через доску оказался в 2,24 раза дороже по прайсу модели, но ожидание сократилось с 423 до 307 секунд – примерно в 1,38 раза.

Как работал ручной параллельный запуск

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

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

Этот вариант нужен был, чтобы не приписывать весь эффект доске. Если ручной параллельный запуск дает примерно такой же результат, как запуск через оркестратор, значит, основное ускорение и изменение качества связаны с разделением задач между независимыми ветками. Доска в таком случае добавляет не “более сильную” работу модели, а удобство управления процессом.

Ручной параллельный запуск занял 6 минут 1 секунду (361 секунду). Его расчетная стоимость составила 5,73$. По времени, цене и качеству он в рамках этого эксперимента оказался близок к варианту с доской.

При этом для ручного варианта я не фиксировал сумму машинного времени по всем веткам. Поэтому его 361 секунду можно сравнивать с 423 секундами последовательного пути и 307 секундами ожидания при запуске через доску. Сравнивать его с 499 секундами суммарной машинной работы параллельного запуска нельзя, такой показатель для ручного варианта не собирался по протоколу (хотя такое можно было сделать).

Сколько стоил сам эксперимент

На эксперимент я потратил 23,47$ в расчетном эквиваленте модели. При этом только отдельная оценка качества обошлась в 8,85$ за 12 прогонов.

Для разовой небольшой задачи это важное предупреждение. Можно потратить больше денег на проверку того, стоит ли вообще запускать несколько агентов, чем на саму рабочую задачу. Поэтому перед экспериментом стоит ответить на простой вопрос – “результат потом будет использоваться один раз или этот процесс станет шаблоном для десятков и сотен запусков?”

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

Что показал эксперимент

По итогам оценки параллельный путь набрал 52 балла, последовательный 44. Эти цифры стали понятны только после того, как я описал все три процесса и сравнил их результаты. Это не проценты и не количество правильных ответов, а суммарные баллы по нескольким материалам и критериям.

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

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

По итогу для каждого из этих трех процессов можно зафиксировать следующие сценарии применения:

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

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

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

Доска сама по себе не сделала ответы качественнее. В моем эксперименте ее польза была в том, что она помогает видеть состояние веток, изолировать задачи и вмешиваться в процесс, не собирая все вручную.