Главное про AI - Вадим Жартун

DAG (directed acyclic graph). Агенты образуют направленный ациклический граф: выходы нескольких агентов сходятся в узел-агрегатор. Подходит для задач, где несколько параллельных потоков анализа сходятся в финальный синтез. Сложнее в отладке, чем Pipeline, но эффективнее, когда подзадачи действительно независимы.

Swarm (рой). Агенты общаются друг с другом напрямую, без центрального оркестратора, по принципу стаи. Подходит для исследовательских задач, где невозможно заранее предсказать, какие агенты понадобятся. Минус — отладка превращается в расследование: какой агент, кому и что передал, и в каком порядке.

КООРДИНАЦИЯ: ОРКЕСТРАЦИЯ ПРОТИВ СОБЫТИЙНОЙ МОДЕЛИ

Координация между агентами бывает двух типов, выбор между ними — выбор между предсказуемостью и гибкостью.

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

Событийная координация — децентрализованная схема. Агенты общаются через общие события или шину сообщений, без центрального координатора. Событийная координация даёт гибкость (можно добавить нового агента без правки оркестратора) и устойчивость (выход из строя одного агента не валит всю систему). Цена — сложность отладки и неочевидные гонки состояний между агентами.

Практическое правило: если задача линейна и редко меняется — оркестрация. Если задача эволюционирует, появляются новые типы запросов, состав агентов меняется чаще, чем раз в квартал — событийная координация. Команда Databricks в 2025 году описала реальный случай гонки состояний в своей мультиагентной системе: два агента одновременно пытались обновить одну запись в общем хранилище признаков — базе данных с подготовленными признаками для ML-моделей, — один из них видел устаревшую версию. Решение — переход на архитектуру, где каждое изменение записывается как последовательность событий, с атомарными операциями и явными блокировками. Фактически это элемент оркестрации, встроенный в событийную координацию.

ПРИЗНАКИ ЗАДАЧИ, КОТОРОЙ НУЖНА МУЛЬТИАГЕНТНАЯ АРХИТЕКТУРА

– Задача разбивается на 3+ чётко различных подзадачи, каждая со своей экспертизой (поиск + анализ + проверка качества).

– Подзадачи можно выполнять параллельно (экономия задержки).

– Каждая подзадача требует своего контекста, который не должен попадать в общий промпт (например, юридический анализ и технический анализ с разной терминологией).

– Результат одной подзадачи — вход для другой, и связь между ними предсказуема.

– Команда разработки может разделиться по подзадачам и работать параллельно.

ПРИЗНАКИ ИЗБЫТОЧНОСТИ МУЛЬТИАГЕНТНОЙ АРХИТЕКТУРЫ

– Задача может быть решена одним агентом с 5–10 инструментами.

– Все «агенты» будут использовать одну и ту же модель (нет выигрыша от специализации).

– Координация между агентами требует сложного workflow, который сам становится источником багов.

– Стоимость и задержка от мультиагентной системы превышают выигрыш от параллелизма.

– Отладка занимает больше времени, чем сама задача.

Мультиагентные системы в реальной работе без инфраструктуры оценки качества дают долю сбоев (failure rate) от 41 до 86,7%. Anthropic в материалах 2025 года о многоагентных системах описал реальную нагрузку, в которой мультиагентная система тратит в 15 раз больше токенов на задачу, чем одиночный агент с хорошим промптом.

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

Самый распространённый паттерн мультиагентной системы в 2026 году — «ведущий плюс рабочие» (lead agent + worker agents). Один «ведущий» принимает запрос от пользователя, разбивает его на подзадачи, распределяет между «рабочими», собирает результаты и формирует финальный ответ. У каждого «рабочего» своя роль, свои инструменты, свой системный промпт, а «ведущий» не выполняет работу сам — только координирует. Anthropic в 2025 году выпустил фреймворк Claude Projects + Skills, который реализует этот паттерн «из коробки». Начинать стоит с двух агентов (supervisor + worker) и наращивать итеративно по мере отладки: три агента в рабочей эксплуатации без наблюдения — три отдельных источника сбоев, не один. И ещё одна рекомендация, которую разработчики мультиагентных систем обычно формулируют уже после первого провала: не стройте мультиагентную систему, пока один агент с пятью инструментами не упёрся в свой потолок. Переход к мультиагентности — не апгрейд, это смена класса задачи.

РЕЗЮМЕ

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

Выбор платформы идёт не по принципу «какая модель лучше», а по тому, где живут данные и какие регуляторные требования. Пять корпоративных платформ закрывают разные ниши через интеграцию с экосистемами. Для разработчиков — Claude Code, OpenClaw и Hermes Agent с разными акцентами. В любой платформе живут три уровня расширений: skill, plugin и MCP-сервер.

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

MCP стал отраслевым стандартом подключения инструментов: одна интеграция работает с любой моделью, поддерживающей протокол. Progressive discovery сокращает расход токенов на порядок. Модель без инфраструктуры — чат, инфраструктура без дисциплины выбора — сожжённый бюджет.

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

Что толку от платформы и агента, если непонятно, в какой процесс их вообще ставить? Следующая глава переводит разговор из технической плоскости в управленческую: какие процессы в офисе первыми отдавать AI, какие не отдавать ни в коем случае, и как собрать воркфлоу вокруг модели, чтобы он ускорял рутину, а не ломал то, что работает. Там же — десятиминутный тест «брать или не брать», балльная оценка кандидата и три метрики, по которым ROI считается без сложных финансовых моделей.

Глава 8. AI в бизнесе: какие процессы отдавать модели

В мае 2025 года McKinsey в State of AI 2025 зафиксировала: 88% организаций используют AI хотя бы в одной функции, но только 6% вышли за пределы пилотов. Провал — не в технологии. Провал — в выборе процесса.