В графах вроде LangGraph узлы выполняют работу, а edges соединяют их между собой. Обычный edge ведет из одного узла в другой всегда. Conditional edge добавляет развилку: функция маршрутизации читает state и возвращает имя следующего узла.
Например, агент получил вопрос клиента. Если уверенность высокая, он готовит ответ. Если не хватает данных, идет в RAG-поиск. Если запрос про возврат денег, отправляет задачу на approval. Если найден риск безопасности, переводит сценарий в guardrail-ветку и не выполняет действие.
Главный плюс conditional edge - управляемость. Вместо одного большого промпта с фразой "реши сам" команда явно описывает возможные ветки и условия перехода. Так проще тестировать, логировать, ограничивать опасные действия и понимать, почему агент выбрал именно этот маршрут.
Главный риск - неявные или неполные условия. Если нет fallback-ветки, агент может застрять. Если условие слишком размытое, workflow начнет ходить по неверным узлам. Поэтому conditional edges нужно покрывать тестами, trace-логами и лимитами на повторные циклы.
Примеры
- Если state содержит needs_human_approval=true, граф отправляет задачу в узел approval, а не выполняет действие сразу.
- После RAG-поиска conditional edge проверяет, найдены ли источники. Если источников нет, агент просит уточнение вместо уверенного ответа.
- Если tool call завершился ошибкой 429, workflow идет в узел retry_with_backoff, а не падает полностью.
- В multi-agent системе router выбирает следующего агента: researcher, coder, reviewer или support.
- Если классификатор пометил запрос как dangerous, граф переводит сценарий в guardrails-ветку.
- После code review агент проверяет, есть ли critical findings. Если есть, PR нельзя одобрять автоматически.
Где используется
- маршрутизация шагов в LangGraph
- ветвление agent workflow по state
- выбор следующего инструмента после tool calling
- переход к human-in-the-loop approval
- fallback при ошибке API или пустом результате
- разделение задач между несколькими агентами
- guardrails для опасных действий
- повторная попытка с лимитом циклов
- проверка качества ответа перед публикацией
- логирование причин выбора ветки
Связанные термины
Частые вопросы
Чем conditional edge отличается от обычного edge?
Обычный edge всегда ведет в один следующий узел. Conditional edge сначала проверяет условие или state и только потом выбирает, в какой узел перейти.
Где чаще всего используют conditional edge?
В графах агентских workflow: LangGraph, Flowise, n8n и похожих системах, где сценарий должен ветвиться по результату модели, инструмента или проверки.
Что хранить в state для условного перехода?
Флаги, результат классификации, статус инструмента, уровень уверенности, найденные источники, ошибки, счетчик попыток и признаки, что нужно подтверждение человека.
Почему нельзя все ветвление оставить промпту?
Промпт сложнее тестировать и контролировать. Conditional edge делает маршруты явными: видно, какие ветки существуют, когда они срабатывают и где нужен fallback.
Какая типичная ошибка в conditional edges?
Нет fallback-ветки или лимита повторов. Из-за этого агент может застрять в цикле, уйти в неверный узел или завершить задачу без понятной причины.
Как тестировать conditional edge?
Нужно создать набор state-примеров для каждой ветки, проверить ожидаемый следующий узел, отдельно протестировать ошибки, пустые данные и пограничные случаи.
