Как графы помогают ИИ-агентам работать вместе

Когда одного агента уже мало

За последний год у индустрии появилась странная привычка: если агент проваливает задачу, ему просто добавляют ещё инструментов, памяти, увеличивают контекст и дают второй шанс. Иногда это помогает. Но только до момента, когда задача становится похожа не на разговор с умной моделью, а на работу маленькой команды.

Например, починить баг в большом репозитории. Или собрать исследовательский пайплайн. Или провести длинную бизнес-процедуру с проверками, согласованиями и откатами. В таких задачах один ИИ-агент быстро упирается в потолок. Он вынужден держать всё в одной голове: план, промежуточные результаты, ошибки, проверку, взаимодействие с инструментами и память о том, что уже произошло.

Авторы новой большой работы предлагают смотреть на проблему иначе. Следующий шаг в развитии ИИ-агентов — система из нескольких специализированных агентов с явной структурой связей между задачами, ролями и состояниями. Для этого они вводят термин графовая инженерия.

Идея практичная: если вы хотите, чтобы агентная система работала на длинных и сложных задачах, вам нужно явно описывать:

🟠 что именно надо сделать

🟠 кто именно это делает

🟠 в каком состоянии сейчас находится вся система

Именно это, по мысли авторов, отличает просто набор агентов от системного интеллекта.

Переход от интеллекта модели к системному интеллекту: от промтов и контекста к обвязке, циклам и графовой инженерии.

От модели к агенту, от агента к системе

Логика статьи строится как лестница.

Сначала у нас есть интеллект модели. Это базовые способности LLM: понимать текст, отвечать, писать код, рассуждать. Они появляются из предобучения и дообучения, а на этапе инференса усиливаются промтами и контекстом.

Потом появляется индивидуальный интеллект. Это уже не просто вызов модели, а агент с обвязкой: доступом к инструментам, памяти, навыкам и циклом действий. Он может планировать, запускать команды, смотреть на результат, исправлять себя и идти дальше.

Но на длинных задачах этого мало.

Один агент почти всегда работает в одном основном цикле. Из-за этого параллельные ветки превращаются в последовательную цепочку. Роли смешиваются. Проверка результата часто делается тем же агентом, который этот результат и создал. А состояние задачи размазывается по контексту, журналам и случайным заметкам.

Авторы формулируют это жёстко: многие реальные задачи архитектурно не помещаются в одного агента. Дело уже не в том, что агенту не хватает ещё одного инструмента или чуть большего окна контекста. Ему не хватает организации.

Коротко проблема выглядит так:

🟣 сложные задачи состоят из зависимых подзадач

🟣 часть шагов надо выполнять параллельно

🟣 для разных шагов нужны разные специализации

🟣 результаты нужно независимо проверять

🟣 состояние должно жить дольше одного цикла агента

Отсюда и главный переход статьи: от индивидуального интеллекта к системному интеллекту.

Как способности модели превращаются в агента: промты, контекст, обвязка и циклы исполнения.

Что такое графовая инженерия

Под графовой инженерией авторы понимают не просто использование графов как структуры данных. Речь о том, чтобы сделать графы рабочим слоем управления агентной системой.

В этой схеме есть три главных графа, или три главных вида структур.

1. Организация задач

Первый вопрос: что делать.

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

Это особенно заметно в задачах по программированию, исследовательских пайплайнах и бизнес-процессах. Там редко бывает одна линейная траектория. Обычно есть дерево или ориентированный граф: собрать данные, проверить гипотезу, запустить тест, сравнить результаты, вернуться назад, если проверка не прошла.

Авторы перечисляют два ключевых механизма:

🟠 декомпозиция цели — разбиение общей задачи на подзадачи с зависимостями

🟠 оптимизация пайплайна — превращение этих подзадач в исполняемую схему с агентами, инструментами и проверками

Здесь обзор собирает много работ последних лет: от систем, которые явно раскладывают задачи по подэтапам, до методов, которые прямо ищут лучший агентный пайплайн как объект оптимизации.

Важно другое: задача перестаёт быть «цепочкой рассуждений в голове модели» и становится внешней структурой, с которой можно работать.

Организация задач: как цель раскладывается на подцели, зависимости и исполняемый пайплайн.

2. Координация агентов

Второй вопрос: кто делает работу.

Если у вас несколько агентов, этого ещё недостаточно. Нужна явная модель способностей, ролей и каналов общения. Иначе получается толпа, а не система.

Авторы делят координацию на три слоя:

🟣 граф способностей — кто что умеет, к каким инструментам имеет доступ, где надёжен

🟣 граф команды — какие роли назначены, кто кому делегирует, кто кого проверяет

🟣 граф коммуникации — кто с кем и когда обменивается информацией

Это важное различие. Один и тот же агент может быть хорош в анализе журналов, но не годиться для написания исправления. Другой — отлично пишет код, но не умеет надёжно проверять регрессии. Третий нужен не для генерации, а для верификации.

В обычном одиночном агенте всё это слипается. В мультиагентной системе эти различия надо фиксировать явно.

Авторы приводят много примеров структур:

🟠 цепочки ролей, где результат одного этапа переходит к следующему

🟠 маршрутизация, где диспетчер отправляет подзадачи нужным специалистам

🟠 веерные схемы, где несколько агентов работают параллельно, а потом ответы агрегируются

🟠 динамические топологии, которые перестраиваются по ходу задачи

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

Координация агентов: способности, командная структура и потоки сообщений между агентами.

3. Управление состоянием во время выполнения

Третий вопрос: что сейчас происходит.

Это, пожалуй, самая недооценённая часть статьи. В агентных системах любят говорить о планировании и ролях, но намного реже — о состоянии выполнения.

Если система работает долго, параллельно и с внешними инструментами, ей нужен не просто журнал. Нужен понятный, проверяемый слой состояния:

🟣 какие шаги уже завершены

🟣 какие результаты подтверждены

🟣 какие изменения ещё только предложены

🟣 где именно случилась ошибка

🟣 от какого корректного состояния можно восстановиться

Авторы называют это управлением состоянием во время выполнения. Внутри три задачи:

🟠 запись состояния

🟠 локализация сбоев

🟠 восстановление после сбоев

Это уже очень близко к тому, как устроены обычные надёжные системы: транзакции, контроль версий, откаты, проверка инвариантов, воспроизведение истории. Только теперь всё это нужно перенести в мир ИИ-агентов.

И это важно, потому что длинные агентные задачи проваливаются не только из-за «плохих рассуждений». Они проваливаются потому, что система не понимает, где именно свернула не туда, какой кусок работы ещё валиден и что можно переиспользовать при восстановлении.

Управление состоянием во время выполнения: запись истории, поиск сбоев и восстановление системы.

Почему это важно сейчас

Работа важна не новым названием, а тем, что она точно описывает сдвиг в отрасли.

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

Проблема в системе.

Это видно сразу в нескольких направлениях:

🟠 в задачах по программированию нужно вести параллельные ветки, тесты, ревью и откаты

🟠 в научных задачах нужно разделять генерацию гипотез, критику, анализ данных и проверку

🟠 в корпоративных процессах нужны роли, права доступа, согласования и журнал изменений

🟠 в медицине нужны длинная история, источник каждого вывода и контроль ответственности

Во всех этих кейсах «один очень умный агент» — просто неудобная единица сборки.

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

Как авторы собирают картину поля

Это не экспериментальная статья с одной новой моделью и таблицей результатов. Это большой обзор поля.

Авторы проходят по всей цепочке:

🟣 базовые модели и дообучение

🟣 промты и контекст

🟣 обвязка агента: инструменты, память, навыки

🟣 циклы выполнения и обратная связь

🟣 пределы одиночного агента

🟣 графовая инженерия как следующий уровень

🟣 бенчмарки, библиотеки и прикладные кейсы

🟣 открытые проблемы: приватность, оценка, семантика, инфраструктура

Отдельно полезно, что они не ограничиваются теорией. В статье есть большой срез по прикладным системам: программирование, исследования, медицина, корпоративные пайплайны, персональные агенты, социальные симуляции. Из этого видно, что многие практические команды уже двигаются в сторону системной организации, даже если не называют это графовой инженерией.

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

Что дальше

В конце авторы смотрят чуть дальше графовой инженерии и поднимают ещё один слой — онтологическую инженерию. Идея простая: мало нарисовать граф задач и ролей, нужно ещё договориться, что именно означают узлы и связи.

Что считается завершением задачи? Что такое подтверждённое доказательство? Кто имеет право менять состояние? Какие действия допустимы? Когда две разные подсистемы говорят одно и то же разными словами?

Без общей семантики даже хорошо организованная система начинает путаться в собственных структурах.

Это уже похоже на будущую инфраструктуру для агентных систем: не просто пайплайны и оркестраторы, а что-то вроде операционной системы для агентов, где задачи, способности, состояние и правила являются объектами первого класса.

Вывод

Граница сейчас проходит не между «моделью» и «агентом», а между одиночным агентом и системой агентов.

Строить длинные и сложные агентные пайплайны без явной структуры становится всё труднее. Нужно отдельно описывать работу, роли и состояние. Нужно уметь локализовать сбои и восстанавливаться без полного перезапуска. Нужно понимать, какие организационные решения улучшают систему, а какие просто добавляют шум.

Если коротко, главный тезис статьи такой:

🟠 сложные задачи требуют распределённого интеллекта

🟠 распределённый интеллект требует явной структуры

🟠 графы становятся способом задать эту структуру

🟠 следующий шаг — научиться не только исполнять такие структуры, но и безопасно улучшать их со временем

Для всех, кто строит ИИ-агентов, это сдвиг фокуса: меньше думать о «магии промта» и больше — о проектировании системы.