LlamaIndex Agents против LangGraph: что выбрать под задачу

Если вы строите приложение поверх LLM сложнее, чем «промпт — ответ», рано или поздно упрётесь в выбор оркестратора. Два очевидных кандидата в экосистеме Python — LlamaIndex с его агентными абстракциями и LangGraph от команды LangChain. Их часто ставят рядом, хотя они выросли из разных задач: LlamaIndex начинался как инструмент для RAG¹ и работы с индексами документов, а LangGraph — как низкоуровневый движок для описания рабочих процессов в виде графа. Отсюда и практическая разница, которую видно уже на второй неделе разработки.

Откуда растут корни

LlamaIndex решает проблему «у меня есть тонна данных, дайте LLM отвечать по ним точно». Индексация, чанкинг, векторный поиск, реранкинг, query engines — это его родная территория. Агенты появились как надстройка: дать модели набор инструментов (в первую очередь — те самые query engines) и позволить ей самой решать, куда идти за ответом.

LangGraph заходит с другого конца. Здесь агент — это граф: узлы (nodes) выполняют работу, рёбра (edges) описывают переходы, а состояние (state) прокидывается между ними. Никакой магии «модель сама разберётся»: вы явно проектируете, кто кого вызывает, где цикл, где условное ветвление и где человек вмешивается в процесс.

LlamaIndex спрашивает «что модель должна знать», LangGraph — «как модель должна действовать». Большинство реальных проектов упираются в оба вопроса сразу.

Модель управления: неявная против явной

В LlamaIndex базовый агентный цикл — это ReAct или function-calling поверх набора инструментов. Вы описываете инструменты, отдаёте их агенту, а дальше он в цикле «мысль — действие — наблюдение» сам решает, когда остановиться. Это быстро для типовых сценариев, но управляемость ограничена: как только логика ветвится нетривиально, вы начинаете бороться с абстракцией.

LangGraph заставляет описать граф руками. Это больше кода на старте, но у вас появляется то, чего в неявном цикле нет: детерминированные переходы, встроенные чекпоинты состояния, возможность прервать выполнение и возобновить с середины, human-in-the-loop без костылей. Для длинных многошаговых процессов и агентов, которые должны переживать перезапуск сервиса, это решающий фактор.

Пример: минимальный ReAct-агент в LlamaIndex

from llama_index.core.agent import ReActAgent
from llama_index.core.tools import FunctionTool
from llama_index.llms.openai import OpenAI

def multiply(a: int, b: int) -> int:
    """Перемножить два числа."""
    return a * b

tool = FunctionTool.from_defaults(fn=multiply)
llm = OpenAI(model="gpt-4o-mini")

agent = ReActAgent.from_tools([tool], llm=llm, verbose=True)
resp = agent.chat("Сколько будет 21 умножить на 2?")
print(resp)

Здесь вы не описываете поток управления вообще — агент сам решает, вызвать ли инструмент. API LlamaIndex активно менялось между версиями (класс ReActAgent и путь импорта в новых релизах могут отличаться), поэтому сверяйтесь с документацией под вашу версию пакета.

Тот же принцип в LangGraph

from langgraph.graph import StateGraph, END
from typing import TypedDict

class State(TypedDict):
    query: str
    result: str

def call_model(state: State) -> State:
    # здесь вызов LLM или инструмента
    return {"result": f"обработано: {state['query']}"}

def should_continue(state: State) -> str:
    return END if state["result"] else "call_model"

graph = StateGraph(State)
graph.add_node("call_model", call_model)
graph.set_entry_point("call_model")
graph.add_conditional_edges("call_model", should_continue)
app = graph.compile()

print(app.invoke({"query": "привет", "result": ""}))

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

Где что сильнее

Как выбирать под задачу

Разложим по типичным ситуациям, без универсального «берите вот это».

• Чат-бот по вашей документации или базе знаний. LlamaIndex почти всегда быстрее к результату: индексация, поиск и агент поверх них — один стек, минимум клея.
• Многошаговый бизнес-процесс с ветвлениями и одобрениями. LangGraph: явный граф, чекпоинты, возможность вставить проверку человеком между узлами.
• Долгоживущий агент, который должен переживать рестарт сервиса. LangGraph с чекпоинтерами. В LlamaIndex это придётся собирать вручную.
• Прототип на выходные, где важна скорость проверки гипотезы. LlamaIndex, если задача крутится вокруг данных.
• Сложная координация нескольких агентов с общим состоянием. LangGraph композирует подграфы естественнее.

Их можно совмещать

Ложная дилемма — думать, что нужно выбрать одно навсегда. Оба фреймворка живут в общей Python-экосистеме и не конкурируют на уровне примитивов. Рабочая связка: LlamaIndex отвечает за retrieval-слой (индексы, query engines, реранкинг), а LangGraph оркеструет процесс и вызывает эти движки как инструменты внутри узлов графа. Вы получаете сильный слой данных и явный контроль над потоком одновременно.

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

¹ RAG (Retrieval-Augmented Generation) — подход, при котором LLM перед ответом подтягивает релевантные фрагменты из внешних источников (векторной базы, документов) и генерирует ответ с опорой на них, а не только на знания из обучения. Снижает галлюцинации и позволяет отвечать по актуальным и приватным данным.