Когда агент — это граф:
как устроена оптимизация процессов на лету

Как разные подходы оптимизируют рабочие процессы LLM‑агентов — от фиксированных шаблонов до динамических графов, которые собираются и меняются на лету.

Статья From Static Templates to Dynamic Runtime Graphs: A Survey of Workflow Optimization for LLM Agents разбирает важный вопрос о том, как сегодня строят системы на базе LLM. Сегодня это уже не один промт, а целый исполняемый рабочий процесс: модель ищет данные, вызывает инструменты, запускает код, пишет в память, проверяет себя верификаторами и при необходимости переделывает шаги. В программировании это выглядит особенно наглядно: ассистент читает файлы, предлагает правки, прогоняет тесты и решает — продолжать или остановиться.

Исследователи из IBM предлагают смотреть на такие системы как на вычислительный граф, где узлы — действия (вызов LLM, retrieval, вызов инструментов валидация, обмен сообщениями), а рёбра — зависимости и потоки информации. Это помогает обсуждать архитектуру процесса: сколько шагов, кто с кем общается, где стоят проверки, сколько это стоит по токенам, времени и деньгам.

В чём проблема

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

Зачем авторы всё это систематизируют

Цель обзора — дать общий фреймворк, с помощью которого можно сравнивать подходы к оптимизации процессов, даже если они выглядят очень разными: от компиляции промтов в фиксированном пайплайне до генерации нового графа под каждый запрос. Для этого вводится понятие agentic computation graph (ACG) и подчёркивается важное разделение трёх уровней:

Во‑первых, шаблон графа — переиспользуемый дизайн до запуска.

Во‑вторых, realized graph — то, что реально собралось и исполнилось в конкретном прогоне (включая ветвления, отключённые узлы и добавленные проверки).

И в‑третьих, execution trace — фактическая история шагов, наблюдений и затрат.

Эта тройка полезна тем, что позволяет честно разделить то, что мы задизайнили и то, что реально произошло на инференсе.

От статических шаблонов к графам

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

Динамические методы, наоборот, выбирают, генерируют или редактируют граф под конкретный запуск — до исполнения или прямо во время него.

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

Что получилось в итоге

Авторы собрали 77 релевантных работ и отдельно разложили 27 материалов, которые можно использовать для оценки подходов к оптимизации процессов. При этом оценивать нужно не только итоговое качество, но и свойства графа и исполнения — стоимость, глубину, объём коммуникации, число правок, вариативность структуры на разных входах и устойчивость к сбоям инструментов и дрейфу API.

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

Что это значит для разработчиков LLM‑агентов

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