Ранас Мукминов – Оркестрация ИИ-агентов. Claude Opus 4.7 (страница 3)

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

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

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

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

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

Хрупкость длинной цепочки. Чем длиннее последовательность шагов, тем выше вероятность, что один из них сорвётся и потянет за собой остаток. Длинная сессия одного агента — это длинная цепочка зависимых шагов без отсеков (см. главу 71): отказ на шаге N обесценивает работу шагов с первого по N-й, потому что состояние не изолировано и откатить часть нельзя. Распределение по независимым исполнителям локализует такой отказ одной веткой.

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

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

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

Предел | Что насыщается | Характерный отказ | Что обходит распределение

Контекст | Объём релевантной информации в одном окне | Вытеснение, context rot, потеря при сжатии | Узкое чистое окно на каждого исполнителя

Специализация | Число ролей в одном промпте и наборе прав | Усреднение качества, отсутствие независимого взгляда, максимум привилегий | Разные роли, инструменты и права у разных исполнителей

Последовательность | Число шагов в одном потоке исполнения | Линейный рост времени, простой на ожидании, хрупкость цепочки | Параллельное прохождение независимых веток

Оси ортогональны: задача может упираться в одну, две или все три сразу, и комбинация определяет архитектуру. Задача с огромным объёмом разнородного входа, но по сути последовательной логикой упирается в контекст и специализацию, но не в параллелизм — ей подойдёт конвейер специализированных стадий (см. главу 10), а не широкий fan-out. Задача из множества независимых однотипных единиц упирается в последовательность, но не обязательно в специализацию — ей подойдёт оркестратор с пулом одинаковых воркеров (см. главу 8). Задача, требующая взгляда с разных сторон на один и тот же предмет, упирается в специализацию и независимость — ей подойдут состязательные или ревью-конфигурации (см. главы 64 и 65). Архитектура роя — это ответ на вопрос, по какой оси задача вышла за предел, а не универсальный шаблон.

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

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

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

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

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

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

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