MAS vs SAS: границы применимости (1/4)
Мультиагентные системы в целом и для разработки в частности - штука, с которой сообщество агентной инженерии давно экспериментирует, и уже даже вендоры добавляют всякие Agent Teams и Swarms в свои продукты.
Однако повсеместным стандартом они до сих пор не стали.
Почему?
В этой серии постов будем разбираться:
1. Границы применимости - когда хватает одного агента или параллельных агентов, а когда нужна команда
2. Как именно команды ломаются - потеря контекста, одинаковость, хрупкое доверие и конфликты
3. Почему это закономерность, а не невезение - теория информации и законы человеческих организаций
4. Что со всем этим делать сейчас и чего ждать от следующих поколений моделей
Копаться в этом стоит отнюдь не только из академического интереса: всё идёт к тому, что мультиагентность станет нормой - включая гибридные коллективы из людей и агентов.
И часть сегодняшних проблем, судя по всему, никуда не денется в ближайших поколениях моделей, так что лучше бы о них знать.
На эту тему за последние полгода вышло два примечательных исследования: Google измерил, когда команда агентов выигрывает у одиночки (и наоборот), а Anthropic разобрала, почему агенты пока так себе по части кооперации.
Сначала о понятиях
Просто количество агентов нам говорит примерно ничего.
Архитектуру задаёт топология: кто с кем связан, кто чем владеет и как организованы потоки информации (контекста).
Для этой серии будем различать три режима:
● одиночный агент (SAS) решает задачу целиком
● независимые агенты (independent MAS) работают параллельно, не общаются, а их ответы в конце просто собираются вместе
● координирующаяся команда (coordinated MAS) обменивается промежуточными результатами напрямую или через оркестратора
Главное различие между двумя последними: независимые агенты не меняют работу друг друга, а внутри команды сообщение может изменить чужой план, границы работы или общее состояние.
Исследование Google
Мотивация апрельской работы Google Towards a Science of Scaling Agent Systems - проверить на прочность популярную эвристику "чем больше агентов, тем лучше" (потому что в литературе есть буквально More Agents Is All You Need).
Цель - посчитать и понять, когда добавление агентов помогает, когда вредит и можно ли предсказать это заранее по свойствам задачи.
Дизайн экспериментов
Пять канонических архитектур: одиночный агент, независимые параллельные, централизованная (оркестратор и воркеры), децентрализованная (peer-to-peer с раундами дебатов) и гибридная.
Гоняли это всё на нескольких агентных бенчмарках и семействах моделей от разных вендоров.
Результаты
🟢 Настоящий параллелизм окупается
На хорошо декомпозируемом финансовом анализе команда с оркестратором дала +80.8% точности в сравнении с одиночным агентом.
🔴 Последовательные задачи штрафуют команду
К примеру, на PlanCraft, где нужно последовательно выполнять зависящие друг от друга действия, все командные архитектуры выполняли успешно на 39-70% меньше задач, чем одиночный агент.
🟡 Сильному одиночке команда уже мешает
Когда одиночный агент может решить больше ~45% задач, дополнительная координация чаще даёт убывающую отдачу.
Это, к слову, самый статистически устойчивый вывод работы.
🟡 Оркестратор тут - пример полезного руководителя
Независимые агенты усиливали ошибки до x17.2, а в схеме с оркестратором - до x4.4: он работает фильтром/валидатором и гасит распространение ошибок, которые неизбежно накапливаются в мультиагентных средах.
🟡 Архитектуру можно выбирать заранее (ну почти)
По свойствам задачи и метрикам координации авторы предсказывают, какая архитектура окажется лучшей, - внутри изученных доменов модель угадывает в 87% случаев.
До универсального калькулятора "сколько агентов брать" пока далеко (перенос между доменами заметно слабее), но направление интересное.
А в целом - ну надо же, кто бы мог подумать: вдумчивая работа одного бывает полезнее, чем собрать митинг на десятерых и хорошенько поговорить.
Никогда такого не было, и вот опять!
Где проходит граница
Как можно видеть из экспериментов, дело не в количестве агентов, а в графе зависимостей задач.
Если работу можно разнести по независимым веткам - исследование вширь, отдельные ревью, разные модули или worktrees - команда даёт скорость и покрытие.
Если всем нужен один контекст, общее состояние и постоянные синки, налог на координацию начинает съедать выигрыш.
Мой опыт сводится к тому же: команда агентов работает, когда задача заранее декомпозирована, подзадачи не конфликтуют и роли чётко прописаны.
А если бросить в команду задачу "как есть", самый воспроизводимый результат - спалить пятичасовой лимит Claude Max за полчаса - проверено лично, работает надёжно :)
Дальше - что происходит, когда агенты всё-таки вынуждены работать вместе.
#ai #agents #research #mas_sas
Мультиагентные системы в целом и для разработки в частности - штука, с которой сообщество агентной инженерии давно экспериментирует, и уже даже вендоры добавляют всякие Agent Teams и Swarms в свои продукты.
Однако повсеместным стандартом они до сих пор не стали.
Почему?
В этой серии постов будем разбираться:
1. Границы применимости - когда хватает одного агента или параллельных агентов, а когда нужна команда
2. Как именно команды ломаются - потеря контекста, одинаковость, хрупкое доверие и конфликты
3. Почему это закономерность, а не невезение - теория информации и законы человеческих организаций
4. Что со всем этим делать сейчас и чего ждать от следующих поколений моделей
Копаться в этом стоит отнюдь не только из академического интереса: всё идёт к тому, что мультиагентность станет нормой - включая гибридные коллективы из людей и агентов.
И часть сегодняшних проблем, судя по всему, никуда не денется в ближайших поколениях моделей, так что лучше бы о них знать.
На эту тему за последние полгода вышло два примечательных исследования: Google измерил, когда команда агентов выигрывает у одиночки (и наоборот), а Anthropic разобрала, почему агенты пока так себе по части кооперации.
Сначала о понятиях
Просто количество агентов нам говорит примерно ничего.
Архитектуру задаёт топология: кто с кем связан, кто чем владеет и как организованы потоки информации (контекста).
Для этой серии будем различать три режима:
● одиночный агент (SAS) решает задачу целиком
● независимые агенты (independent MAS) работают параллельно, не общаются, а их ответы в конце просто собираются вместе
● координирующаяся команда (coordinated MAS) обменивается промежуточными результатами напрямую или через оркестратора
Главное различие между двумя последними: независимые агенты не меняют работу друг друга, а внутри команды сообщение может изменить чужой план, границы работы или общее состояние.
Исследование Google
Мотивация апрельской работы Google Towards a Science of Scaling Agent Systems - проверить на прочность популярную эвристику "чем больше агентов, тем лучше" (потому что в литературе есть буквально More Agents Is All You Need).
Цель - посчитать и понять, когда добавление агентов помогает, когда вредит и можно ли предсказать это заранее по свойствам задачи.
Дизайн экспериментов
Пять канонических архитектур: одиночный агент, независимые параллельные, централизованная (оркестратор и воркеры), децентрализованная (peer-to-peer с раундами дебатов) и гибридная.
Гоняли это всё на нескольких агентных бенчмарках и семействах моделей от разных вендоров.
Результаты
🟢 Настоящий параллелизм окупается
На хорошо декомпозируемом финансовом анализе команда с оркестратором дала +80.8% точности в сравнении с одиночным агентом.
🔴 Последовательные задачи штрафуют команду
К примеру, на PlanCraft, где нужно последовательно выполнять зависящие друг от друга действия, все командные архитектуры выполняли успешно на 39-70% меньше задач, чем одиночный агент.
🟡 Сильному одиночке команда уже мешает
Когда одиночный агент может решить больше ~45% задач, дополнительная координация чаще даёт убывающую отдачу.
Это, к слову, самый статистически устойчивый вывод работы.
🟡 Оркестратор тут - пример полезного руководителя
Независимые агенты усиливали ошибки до x17.2, а в схеме с оркестратором - до x4.4: он работает фильтром/валидатором и гасит распространение ошибок, которые неизбежно накапливаются в мультиагентных средах.
🟡 Архитектуру можно выбирать заранее (ну почти)
По свойствам задачи и метрикам координации авторы предсказывают, какая архитектура окажется лучшей, - внутри изученных доменов модель угадывает в 87% случаев.
До универсального калькулятора "сколько агентов брать" пока далеко (перенос между доменами заметно слабее), но направление интересное.
А в целом - ну надо же, кто бы мог подумать: вдумчивая работа одного бывает полезнее, чем собрать митинг на десятерых и хорошенько поговорить.
Никогда такого не было, и вот опять!
Где проходит граница
Как можно видеть из экспериментов, дело не в количестве агентов, а в графе зависимостей задач.
Если работу можно разнести по независимым веткам - исследование вширь, отдельные ревью, разные модули или worktrees - команда даёт скорость и покрытие.
Если всем нужен один контекст, общее состояние и постоянные синки, налог на координацию начинает съедать выигрыш.
Мой опыт сводится к тому же: команда агентов работает, когда задача заранее декомпозирована, подзадачи не конфликтуют и роли чётко прописаны.
А если бросить в команду задачу "как есть", самый воспроизводимый результат - спалить пятичасовой лимит Claude Max за полчаса - проверено лично, работает надёжно :)
Дальше - что происходит, когда агенты всё-таки вынуждены работать вместе.
#ai #agents #research #mas_sas