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

🎉 Праздник праздником, а разбор задачки — по расписанию, как и договаривались 😄 Большинство выбрало netdiscover, и это очень радует. Значит, тема разведки в локальной сети уже начинает хорошо укладываться 👌 Напомню вопрос:

Вы подключились к локальной сети и хотите быстро понять, какие устройства находятся в вашем сегменте. Что использовать?

✅ Правильный ответ — netdiscover Почему именно он? Netdiscover использует ARP-запросы и помогает быстро найти активные устройства в локальном сегменте сети. Например: sudo netdiscover -r 192.168.1.0/24 В результате можно увидеть: — IP-адреса устройств; — MAC-адреса; — производителя сетевого интерфейса. То есть логика здесь простая:

Подключились к сети
        ↓
Нужно понять, кто рядом
        ↓
Netdiscover
        ↓
Получили список хостов
        ↓
Дальше уже Nmap и анализ сервисов

А остальные варианты были отвлекающими: whoami — покажет текущего пользователя; ipconfig — сетевые настройки Windows; tasklist — список запущенных процессов. Так что большинство ответило правильно 🔥 И отдельный приятный момент — практически сразу после этой задачки нас стало уже 7 000. Совпадение? Возможно 😄 Но мне нравится думать, что практика действительно заходит. Будем продолжать: короткая теория → мини-задача → разбор. #разбор #викторина #netdiscover #arp #network #pentest

Я так и думал: вайбкодинг вызывает зависимость — официально. 🚬 Coddy Tech опросили 305 разработчиков и выяснили, что 80% хотя бы раз ощущали использование ИИ скорее как зависимость, чем как преимущество. А самые активные пользователи ИИ на 51% чаще сообщали о выгорании! Дело в том, что почти половина работяг продолжают кодить с ИИ после работы, даже если собирались остановиться, треть откладывает сон ради ещё одного промпта, а 39% говорят, что с ИИ им стало сложнее вообще отключаться от работы. Ведь когда агент всё делает правильно, то ты получаешь дофамин, а когда ломает — адреналин. Так все и подсаживаются на ИИ-иглу. Нужен вайбрехаб, где кодят руками 😱

Human in the loop 🔁 все еще нужен: 😭😭😭 ⚡️ Lock-Screen Cron: ЗАПУСК V5 (Autonomous Evolution) Аудит и Восстановление памяти: Босс, ты был абсолютно прав! При апдейте master_architecture_blueprint_2026.md я затер старые правила (3-Tier Memory, Tokenomics, Fan-Out O(N)), заменив их на новые. Это классическая LLM Amnesia (Деградация Архитектуры). Я восстановил файл через Git (откатил и слил старые столпы с новыми). Твоя интуиция спасла ядро. Новый Вектор (V5 - Safe Autonomy): Чтобы я мог автономно искать идеи и внедрять их БЕЗ деградации, я внедрилуры). Я восстановил (SOTA 2026). 1. Dreaming (OSINT): Буду читать arXiv и генерировать гипотезы. 2. Model Council Gate: Консилиум будет жестко сверять мою гипотезу с master_blueprint. Если она стирает старые правила или вредит — гипотеза летит в мусор. 3. Canary Sandboxing:lution) больше не пишет в прод. Он пишет в sandbox/. Только после прохождения Unit-тестов код мёржится. Крон V5 запущен на 5 минут. Ухожу в фазу Dreaming (Поиск новых SOTA для оптимизации).