Аргументы против того, чтобы по умолчанию выбирать рои агентов
Распространённый режим отказа в агентной инженерии — тянуться к рою раньше, чем к функции. Задача декомпозируется на роли, добавляется супервизор, и система объявляется «агентной». На деле построена распределённая система с языковой моделью в контуре, и её издержки — это знакомые издержки распределённости плюс незнакомые издержки недетерминизма.
Каждый дополнительный агент вводит передачу. На каждой передаче производящий агент сериализует своё состояние в текст, а потребляющий агент десериализует его обратно в контекст. Этот круговой обмен теряет информацию. Структурированный результат с оценкой уверенности, ссылкой на источник и флагом частичного отказа превращается в прозе в предложение, которое опускает все три. Потеря не случайна; она коррелирует ровно с той информацией, которая нужна нижестоящему агенту, чтобы решить, продолжать, повторять или эскалировать.
Накладные расходы на координацию также растут быстрее, чем экономит декомпозиция. Если задача требует T единиц работы и делится на n подзадач, идеальная экономия составляет примерно T/n. Стоимость координации — не T/n; это сумма передач, каждая из которых требует промпта, вызова модели, разбора и валидации. На практике добавление агентов за точку, где подзадачи действительно независимы, даёт систему, которая медленнее, дороже и сложнее в отладке, чем единственный вызов, который она заменила.
Самая глубокая проблема — тестируемость. Детерминированный код можно покрыть юнит-тестами. Функция, принимающая типизированный вход и возвращающая типизированный выход, имеет контракт, против которого можно писать утверждения. Промпт оркестратора — нет. Вы можете оценивать его выходы на наборе данных, и должны это делать, но вы не можете написать тест, который падает, когда оркестратор молча меняет свою политику маршрутизации между версиями модели. Промпт — это спецификация, выраженная на языке без компилятора.
Это не аргумент против мультиагентных систем. Это аргумент против того, чтобы считать их выбором по умолчанию. Паттерн chief-of-staff, как описано в этой статье об оркестрации сессий Claude Code, полезен именно потому, что называет условия, при которых координирующий слой оправдывает себя.
Сигналы, оправдывающие оркестрацию
На практике три сигнала отличают задачу, которой нужен оркестратор, от задачи, которой нужен скрипт.
Непересекающиеся наборы инструментов или непересекающиеся контексты
Если подзадаче A нужен доступ на чтение к кодовой базе, а подзадаче B — доступ на запись к цели развёртывания, им нужны разные наборы инструментов. Единый агент, владеющий обоими инструментами, должен пользоваться доверием для обоих, и его контекст должен нести схемы, учётные данные и режимы отказа обоих. Разделение означает, что контекст каждого агента меньше, а его полномочия уже. Тот же аргумент применим к контекстным окнам: если исходный материал для одной подзадачи занял бы большую часть окна, а для другой — остаток, единый агент будет усекать или суммировать, а суммирование — это и есть место, где живёт потеря информации.
Подлинная независимость
Второй агент оправдывает свою стоимость, когда он действительно независим, а не когда он переформулирует первого. Независимость означает, что он не разделяет контекст первого агента, его допущения или его режимы отказа. Верификатор, который читает тот же контекст и те же рассуждения, будет склонен соглашаться с производителем, потому что он прогоняет то же распределение по тем же токенам. Верификатор, который читает только артефакт и имеет собственные инструменты для его проверки, может не согласиться. Это несогласие и есть ценность.
Задачи с длинным горизонтом
Некоторые задачи имеют настолько длинный горизонт, что один контекст не может их удержать. Миграция, затрагивающая сотни файлов, исследовательская задача, накапливающая источники в течение часов, реагирование на инцидент, охватывающее несколько систем: всё это превышает то, что может удержать одно окно, и режим отказа здесь — не неверный ответ, а забытый. Здесь работа оркестратора — не рассуждать о задаче, а вести реестр того, что сделано и что осталось.
Если ни один из этих трёх сигналов не присутствует, честный инженерный ответ — скрипт. Скрипт, который вызывает одну модель, валидирует выход против схемы и повторяет при отказе, тестируем, наблюдаем и дёшев. В большинстве случаев он ещё и быстрее.
Реализация паттерна
Когда оркестрация оправдана, детали реализации определяют, работает ли она. Три механизма важнее выбора фреймворка.
Единый авторитетный реестр задач
Агенты должны читать и писать один общий реестр, а не передавать друг другу прозаические резюме. Реестр — источник истины о том, что было предпринято, что удалось и что заблокировано. Каждая запись — это запись: идентификатор задачи, статус, входы, выходы и любая ошибка. Агенты захватывают задачи, обновляют статус и добавляют результаты. Оркест
Это инвертирует обычный паттерн. Вместо того чтобы оркестратор держал состояние в своём контексте и суммировал его для исполнителей, состояние живёт вне любого контекста и читается по требованию. Исполнитель, которому нужно знать, удалась ли зависимость, читает реестр, а не доверяет резюме. Контекст оркестратора остаётся малым, и в этом суть.
Контракты передачи как типизированные полезные нагрузки
Передача должна быть типизированной полезной нагрузкой, а не прозаическим резюме. Определите схему один раз, валидируйте с обеих сторон и громко падайте при несоответствии. Минимальный контракт для результата субагента может выглядеть так:
{
"task_id": "string",
"status": "succeeded | failed | blocked",
"artefacts": [{"path": "string", "hash": "string"}],
"claims": [{"text": "string", "evidence": "string"}],
"open_questions": ["string"]
}
Схема делает две вещи. Она заставляет производящего агента различать то, что он сделал, и то, во что он верит, — а это разные вещи. И она даёт потребляющему агенту стабильный интерфейс, так что изменение в рассуждениях производителя не меняет молча вход потребителя. Там, где поле не может быть заполнено, агент обязан сказать об этом, и blocked — допустимый статус. Прозаические резюме скрывают именно этот случай.
Инструментируйте задержку передачи и потерю информации
Задержка передачи измерима: время от завершения производителя до старта потребителя и время, потраченное на валидацию и повторы. Потерю информации измерить сложнее, но не невозможно. Инструментируйте её, сравнивая то, что выдал производитель, с тем, на что действовал потребитель. Если полезная нагрузка производителя содержала три открытых вопроса, а следующее действие потребителя не адресует ни один из них, это потеря, и её стоит логировать. На множестве прогонов распределение этих потерь показывает, где контракты слишком тонки.
Считайте оба показателя первоклассными метриками наряду с долей успешных задач и стоимостью на задачу. Система оркестрации, которая корректна, но чьи передачи занимают больше времени, чем работа, которую они координируют, — это система, которую следует свернуть обратно в скрипт.
Честный компромисс
Паттерн chief-of-staff не бесплатен и не всегда правилен. Его издержки реальны: больше движущихся частей, больше промптов для поддержки, больше режимов отказа для наблюдения и опыт отладки, охватывающий несколько контекстов вместо одного. Его выгоды тоже реальны, но условны. Они появляются, когда подзадачам нужен разный контекст, разные инструменты или независимая проверка, и в значительной степени исчезают, когда нет.
Практическая дисциплина — начинать со скрипта. Напишите единственный вызов, валидируйте его выход, измерьте, где он падает. Когда он падает из-за слишком большого контекста, или конфликта инструментов, или не независимой проверки, добавьте оркестратор. Не раньше. Паттерн — это ответ на конкретный набор ограничений, и применение его без этих ограничений создаёт видимость сложности ценой самой сути.