Проблема координации — не в модели
Большинство команд, строящих мультиагентные системы, исходят из того, что узкое место — это возможности модели. Это редко так. Модели достаточно хороши для подзадач. Первым ломается слой координации: как агенты разделяют состояние, как решают, кто действует следующим, и как система восстанавливается, когда один из них выдаёт то, что остальные не могут использовать.
Один агент — это цикл. Рой — это распределённая система с ненадёжными узлами, общающимися на естественном языке. Именно вторая формулировка точно предсказывает режимы отказа.
Почему передачи на естественном языке хрупки
Когда один агент передаёт работу другому, передача обычно представляет собой неструктурированный текст. Это удобно при прототипировании и дорого в продакшене по трём причинам.
Во-первых, передачи на естественном языке теряют информацию. Принимающий агент должен заново выводить намерение из прозы. Если отправляющий агент опустил ограничение, получатель не может его восстановить. Нет схемы, по которой можно валидировать.
Во-вторых, они недетерминированы. Один и тот же выход вышестоящего агента может интерпретироваться по-разному в разных запусках, что затрудняет воспроизведение отказов.
В-третьих, они скрывают частичный отказ. Агент, возвращающий правдоподобный, но неполный результат, выглядит так же, как успешный, если что-то ниже по потоку это не проверит.
Решение не в том, чтобы устранить естественный язык. Оно в том, чтобы ограничить поверхность передачи. Определите типизированный конверт для межагентных сообщений: идентификатор задачи, созданный артефакт, ограничения, которые должны соблюдаться, и явный статус. Проза агента может жить внутри поля, но оркестратор маршрутизирует и валидирует по конверту.
Конкретный механизм: типизированные конверты и шлюзы валидации
Рассмотрим конвейер исследования и черновика с планировщиком, несколькими ретриверами, синтезатором и критиком. Без структуры синтезатор получает кучу текста и угадывает, что важно.
С типизированными конвертами поток выглядит так:
{
"task_id": "r-014",
"produced_by": "retriever-2",
"status": "partial",
"artefact": { "claims": [ { "text": "...", "source": "..." } ] },
"constraints": ["no claims without a source", "max 12 claims"],
"missing": ["coverage of the cost dimension"]
}
Оркестратор не читает прозу. Он читает status, constraints и missing. Если status — partial, он может перенаправить отсутствующее измерение, а не передавать деградировавший артефакт дальше. Синтезатор получает только конверты, ограничения которых соблюдены.
Это шлюз валидации, и это единственное наиболее эффективное дополнение для большинства роёв. Он превращает тихую деградацию в явное решение о маршрутизации. Он также делает систему тестируемой: вы можете воспроизвести записанный набор конвертов через оркестратор, не вызывая ни одной модели.
Выбор топологии и её издержки
Не существует универсально правильной формы роя. Три распространены, и каждая чем-то жертвует.
Паттерн супервизора. Один агент-оркестратор распределяет задачи рабочим и агрегирует результаты. Легко рассуждать, легко логировать, и он централизует обработку отказов. Издержка — узкое место: контекст супервизора должен вмещать достаточно для правильной маршрутизации, и он становится единственной точкой, ошибки которой распространяются повсюду.
Паттерн конвейера. Агенты выстроены в цепочку, каждый преобразует выход предыдущего. Просто и предсказуемо. Издержка — хрупкость: ранняя ошибка накапливается, и нет ветки, чтобы её поглотить. Конвейеры подходят для хорошо специфицированных преобразований, а не для открытых исследований.
Одноранговый паттерн или паттерн дебатов. Агенты обмениваются напрямую и сходятся к ответу. Он может выявить разногласия, которые супервизор сгладил бы. Издержка в том, что его трудно ограничить: расход токенов, задержка и условия завершения становятся нетривиальными. Без явного лимита ходов и критерия сходимости он может работать бесконечно, производя уверенно звучащий шум.
На практике большинство продакшен-систем — это супервизор с типизированными конвертами и одной-двумя специализированными подконвейерами, а не полностью связанная сетка.
Честный компромисс: параллелизм покупает задержку и стоит согласованности
Запуск агентов параллельно сокращает время настенных часов и увеличивает пропускную способность. Он также удаляет последовательный контекст, который позволяет более позднему агенту видеть, что узнал более ранний. Два ретривера, работающие параллельно, могут вернуть пересекающиеся или противоречивые утверждения; последователь
Компромисс реален, и его нельзя обойти инженерией. Что можно сделать — это сделать шаг слияния явным. Параллельные ветви должны выдавать типизированные конверты, а слияние должно разрешать конфликты по определённому правилу, например, предпочитая источник с более высоким показателем происхождения или помечая конфликт для агента-критика. Без политики слияния параллелизм производит большую кучу непроверенного текста быстрее.
Второй компромисс — наблюдаемость. Каждый дополнительный агент добавляет переход, который нужно трассировать. Если оркестратор не выдаёт структурированную трассировку на каждый конверт, отладка роя становится догадками. Стоимость инструментирования платится заранее и окупается при первом же отказе запуска, который не воспроизводится вручную.
Оценка должна нацеливаться на швы
Оценка отдельных агентов изолированно необходима, но недостаточна. Отказы, которые важны в рое, происходят на швах: передача, которая потеряла ограничение, слияние, которое неправильно разрешило конфликт, повтор, который дублировал работу.
Практический подход — оценивать на трёх уровнях.
- Уровень агента. Удовлетворяет ли агент своему контракту при корректном входе? Это самое лёгкое для тестирования и наименее предсказательное для поведения системы.
- Уровень передачи. При заданных записанных конвертах вышестоящего агента производит ли нижестоящий агент конверт, удовлетворяющий заявленным ограничениям? Это ловит дрейф схемы и тихий частичный отказ.
- Уровень траектории. При заданной полной задаче достигает ли система приемлемого результата за ограниченное число шагов и токенов? Именно здесь фактически проверяются топология и политика слияния.
Оценка траектории требует определения приемлемого результата, независимого от собственных самоотчётов агентов. Иначе система сама себе ставит оценку.
Что строить в первую очередь
Если рой отказывает, порядок исправлений важнее изощрённости любого отдельного.
- Введите типизированные конверты для каждого межагентного сообщения. Уже это делает отказы видимыми.
- Добавьте шлюзы валидации на каждой передаче, с явным статусом
partialи путём перенаправления. - Определите политику слияния для параллельных ветвей, включая то, как обнаруживаются и разрешаются конфликты.
- Инструментируйте структурированную трассировку на каждый конверт, чтобы запуски можно было воспроизводить.
- Только затем настраивайте промпты или меняйте модели.
Большинство команд делают это в обратном порядке, хватаясь за более сильную модель прежде, чем слой координации вообще сможет выразить, что пошло не так.
Заключение
Масштабирование роя LLM-агентов — это проблема распределённых систем в костюме машинного обучения. Модели обычно адекватны; передачи, политики слияния и наблюдаемость — обычно нет. Типизированные конверты, шлюзы валидации и оценка на уровне траектории адресуют режимы отказа, которые действительно появляются в продакшене. Компромиссы, особенно между параллелизмом и согласованностью, структурны, а не случайны, и честный ход — выбирать их осознанно и инструментировать последствия.