LangGraph против Google ADK в 2026 году: явная оркестрация или композиция агентов

Любой, кто сегодня разрабатывает производственных агентов, сталкивается с одинаково перенасыщенной нишей: LangGraph, Google ADK, OpenAI Agents SDK, PydanticAI, CrewAI, AutoGen, LlamaIndex, а также, вероятно, ещё какой-то фреймворк, появившийся к моменту написания этого списка. Инстинктивный вопрос заключается в том, какой из них лучше, но это неверный подход. Лучше спросить, где должны находиться решения фреймворка, а где — контроль в приложении.

Если сформулировать вопрос именно так, сравнение LangGraph и разработочного набора Google для агентов (ADK) в 2026 году оказывается более интересным, чем может показаться с точки зрения старой формулы «графы против агентов». Оба инструмента способны создавать сложных агентов. Различие между ними заключается в том, где находится контроль, какие настройки встроены по умолчанию и насколько сложной является оркестрация действий командой.

Два фреймворка сближаются

Более ранние сравнения проводились четко: LangGraph представляет собой инструмент низкого уровня для оркестрации графов, тогда как ADK — это фреймворк более высокого уровня для работы с несколькими агентами. Это соотношение до сих пор частично верно, но оно не учитывает множество аспектов.

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

ADK теперь также поддерживает несколько стилей оркестрации:

• рабочие процессы на основе графов
• динамические рабочие процессы
• совместные рабочие процессы с участием нескольких агентов
• узлы детерминистического выполнения
• делегирование задач агентами

В ADK 2.x одна графика может объединять агентов LLM, обычные функции, инструменты, логику маршрутизации, состояние и ввод от человека. Поэтому выбор больше не сводится к графике или агентам, поскольку каждая платформа может выполнять оба этих задачи. Различие заключается в способе построения системы.

Как работает LangGraph

LangGraph сначала воспринимается как движок оркестрации. Проектирование начинается с набора вопросов: каково текущее состояние? Что его изменяет? Куда дальше может перейти выполнение? В визуальном представлении поток выглядит следующим образом:

State
  ↓
Node
  ↓
Decision
 ↙   ↘
A     B
↓     ↓
Tool  Agent
 \     /
  ↓   ↓
 Validation
     ↓
    End

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

• паузы и ожидания одобрения кем-либо
• повторной попытки выполнения неудачной операции
• восстановления после сбоя инструмента
• продолжения работы с сохраненного состояния
• разветвления на основе структурированных данных
• запуска обычного кода между вызовами моделей
• сохранения состояния во время длительных операций

LangGraph делает каждую из этих проблем явной, что является сильной стороной модели. Однако это означает, что команда несет большую ответственность за проектирование оркестрации.

Как мыслит ADK

ADK ближе к фреймворку приложений-агентов. Вместо того чтобы начинать с машины состояний, проектирование может начинаться с агентов:

Coordinator
├── Specialist Agent
├── Specialist Agent
├── Specialist Agent
└── Specialist Agent

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

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

Центральный вопрос: кто контролирует рабочий процесс?

Вероятно, это первый момент, который необходимо уточнить при выборе между двумя подходами. Представьте два крайних случая.

В основном детерминистический

Процесс уже известен шаг за шагом:

Receive request
→ validate
→ retrieve information
→ classify
→ call service
→ validate result
→ human approval if necessary
→ respond

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

В основном управление осуществляется агентами

Здесь цель известна, но не порядок шагов:

User goal
   ↓
Coordinator
   ↓
Which specialist is needed?
   ↓
Delegate
   ↓
Maybe call another specialist
   ↓
Synthesize

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

Преимущество LangGraph: явное состояние

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

What has already happened?What did the previous agent produce?Which tools were executed?What has been validated?What still needs approval?Where should execution resume?What should the next node actually see?

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

Преимущество ADK: составление агентов

Лучшей абстракцией ADK является возможность легко превращать специализированные агенты в строительные блоки. Вместо одного огромного агента с объемным системным промптом обязанности делятся на отдельные компоненты:

                Coordinator
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
    Research       Domain        Action
     Agent          Agent         Agent
        │             │             │
        └─────────────┼─────────────┘
                      ↓
                  Validation

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

Большее количество агентов не означает лучшую систему

Очень распространённой ошибкой является предположение, что существует такая арифметика:

1 agent = simple
5 agents = sophisticated
20 agents = extremely sophisticated

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

Прежде чем добавлять нового агента, спросите, какая функциональность значимо улучшится, поскольку ответственность за это должна быть изолирована. Убедительные причины — это отдельный набор инструментов, более строгие права доступа, отдельный контекст, другая модель, независимая оценка, специализация, пригодная для повторного использования, или задачи, которые можно выполнять параллельно. Фраза «архитектура с несколькими агентами звучит лучше» не должна входить в этот список.

Вывод

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