Параллельные агенты: где выигрыш реален

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

Почему условия именно такие

Ключевое свойство, из которого следует всё остальное: подагент не помнит разговор, из которого его запустили. Он получает только тот текст, который ему передали, и возвращает только то, что написал в отчёте.

Это не ограничение реализации, а следствие устройства: контекст — не память, а то, что вы заново положили во вход. Подробнее — в «Контекстное окно — это не память».

Отсюда три условия по порядку.

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

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

Короткий отчёт. Если результат подагента — это тысяча строк, они приедут в контекст главного, и вы потеряете на входных токенах больше, чем выиграли на времени.

Что делится хорошо

Список короткий и почти исчерпывающий:

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

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

Что делится плохо

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

Изменения в общем состоянии. Две ветки правок в одних файлах.

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

Сколько запускать

Больше трёх-четырёх одновременно почти никогда не окупается, и причина не в мощности.

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

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

Условие несогласия

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

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

Чего я делать не стал бы

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

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

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

Открытый вопрос

Решение о делимости принимает модель — на основании описания инструмента и собственного понимания задачи. То есть она же решает, независимы ли части, а это ровно то, в чём она ошибается: зависимость между частями часто не видна из формулировки и вскрывается на середине работы.

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