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

​
Узел — это состояние, а не скрипт

Когда агент входит в узел, Агентика настраивает LLM специально для этого узла:
  • Prompt узла, объединенный с prompt global node, становится system prompt и говорит LLM, что здесь нужно сказать и сделать.
  • Исходящие ребра узла становятся единственными доступными выходами. LLM не может перепрыгнуть куда-то еще.
Поэтому узел лучше понимать как состояние разговора: сфокусированная инструкция плюс небольшой набор выходов. Граф никогда не “бежит вперед” — ничего в последующем узле не происходит, пока агент действительно не перешел в него.

​
Conditions — это то, как LLM выбирает выход

У каждого исходящего ребра есть condition: описание на естественном языке, когда должен произойти переход. Пока агент говорит внутри узла, LLM постоянно сопоставляет live-разговор с condition каждого исходящего ребра. Когда модель решает, что condition выполнен, она вызывает это ребро, и Агентика переключает агента на целевой узел.
Под капотом каждое исходящее ребро предлагается LLM как вызываемая function (tool). condition ребра становится описанием функции — текстом, по которому модель решает, стоит ли ее “вызвать”. Поэтому четкое и конкретное condition так важно: оно полностью определяет routing-решение.

​
Что происходит во время перехода

Когда ребро срабатывает, Агентика выполняет три действия по порядку, прежде чем следующий узел заговорит:
  1. Извлечение переменных — если в узле, из которого агент уходит, включено извлечение данных, настроенные переменные сначала извлекаются из разговора.
  2. Transition speech — если у ребра есть необязательный transition_speech, агент произносит его или проигрывает запись перед переходом.
  3. Активация целевого узла — целевой узел становится текущим: загружаются его prompt и его исходящие ребра, затем цикл повторяется.
Если целевой узел — End Call, звонок завершается вместо ожидания нового выхода.

​
Почему это так устроено

Разговоры недетерминированы. Нельзя жестко прописать “после второго ответа перейти к узлу Y”: реальный абонент может ответить не по порядку, передумать или уйти от сценария. Решение о том, когда переходить дальше, должно исходить из live-разговора, а LLM уже понимает этот разговор. Поэтому естественный способ — дать модели каждый возможный выход как функцию, которую можно вызвать. Граф — это guardrail. В каждый момент LLM доступны только исходящие ребра текущего узла. Она может пойти только туда, куда позволяет граф, поэтому структура ограничивает свободу модели и удерживает звонок в спроектированном сценарии. У конечных узлов просто нет выходов. End Call node не регистрирует исходящие переходы, поэтому у LLM нет “двери”, через которую можно выйти. Единственный результат — завершить звонок. Завершение моделируется отсутствием ребер, а не специальной runtime-командой. Global node никогда не бывает destination. У него нет ребер, и вы никогда не переходите в него. Вместо этого его prompt объединяется с каждым узлом, что контролируется полем add_global_prompt. Поэтому в нем хранятся общие инструкции: персона, тон и guardrails.

​
Как писать условия, которые надежно маршрутизируют

Поскольку condition — это то, над чем рассуждает LLM, формулировка напрямую влияет на точность routing:
  • Пишите полный предикат, а не тег. Используйте "The caller confirmed they want to book a demo", а не "interested". Модели нужно достаточно информации, чтобы сопоставить условие с live-разговором.
  • Делайте ветки взаимоисключающими. Если два исходящих condition могут быть истинны одновременно, агент может выбрать не то ребро. Дайте каждому выходу отдельный, непересекающийся trigger.
  • Держите labels короткими и различимыми. label — краткий идентификатор в call logs и builder. Делайте labels короткими и уникальными внутри узла. Логика маршрутизации живет в condition, а не в label.
  • Одна задача на узел. Узел с двумя-тремя ясными выходами маршрутизирует намного лучше, чем узел, который пытается ветвиться в десяток сторон. Объединяйте там, где можно.

​
См. также

  • Workflows и агенты — обзор модели графа
  • Workflow Definition Schema — полный справочник полей узлов и ребер
  • Global Node — инструкции, общие для всех узлов
  • End Call Node — как завершаются звонки