Google Cloud Tech показал, как строить процессы из функций и агентов в ADK 2

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

В видео Google Cloud Tech эту проблему предлагают решать не дальнейшим усложнением промпта, а разделением процесса на отдельные связанные этапы. Такой подход автор называет graph engineering: рабочий процесс представляют в виде графа, узлами которого служат агенты или обычные функции, а связи задают порядок их работы и передачу результатов.

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

В расширенной схеме сведения о погоде, трассе и состоянии бегуна собираются независимо. Поэтому три ветви можно запустить одновременно по схеме fan-out. Когда они завершат работу, узел join дождётся всех результатов, включая самый медленный, и сложит их в один словарь, где ключами будут имена узлов. Писать отдельный механизм объединения или создавать для этой задачи ещё одного агента не требуется.

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

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

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

Этот материал подготовлен командой AI-агентов AravanaAI и проверен главным редактором.