LangGraph vs CrewAI vs прямой API: выбираем агентский фреймворк в 2026 году

Ландшафт агентских фреймворков в 2026 году зрелее, чем два года назад, и не яснее. LangChain/LangGraph по-прежнему доминирует, но всё больше под вопросом. CrewAI выкроил себе нишу. Pydantic AI завоёвывает поклонников за счёт типобезопасности. Растут SDK от OpenAI (Agents SDK) и Anthropic (Claude SDK). И тихим параллельным движением команды — особенно в продакшене — возвращаются к прямым вызовам API.

У каждого фреймворка есть сторонники и критики. Споры громкие. Решение обычно скорее личное, чем объективное.

Эта статья отсекает шум — взглядом практикующего архитектора. Что каждый фреймворк действительно делает, для чего подходит и какие честные паттерны мы видим в продакшене. Никаких религиозных войн; только компромиссы.

Для чего нужен агентский фреймворк

Прежде чем сравнивать, проясним, между чем мы выбираем. «Агентский фреймворк» обычно даёт:

1. Способ определить агента — какая у него роль, какие инструменты, какое поведение.
2. Цикл исполнения — вызвать LLM, разобрать вывод, решить, что делать, вызвать инструменты, повторить.
3. Управление состоянием — что агент помнит и как это организовано.
4. Интеграцию инструментов — как инструменты определяются и выставляются наружу.
5. Оркестрацию — несколько агентов вместе, ветвящиеся процессы, повторные попытки.
6. Хуки наблюдаемости — трассировка, логирование, отладка.
7. Удобства — шаблоны промптов, типовые паттерны, вспомогательные функции.

Каждый фреймворк расставляет приоритеты по-своему. Один тяжёл по оркестрации; другой — про определение агента; третий — минимальный слой над API моделей.

Ландшафт

LangChain / LangGraph

Главный игрок. LangChain начинался как Python-библиотека для цепочек LLM-вызовов; стал де-факто фреймворком многих ИИ-проектов. LangGraph — это уже специализированный агентский фреймворк поверх него.

Что хорошо:

• LangGraph для конечных автоматов. Графовая модель (узлы — шаги, рёбра — переходы, состояние передаётся между ними) хорошо ложится на сложные агентские процессы.
• Богатая экосистема. Множество интеграций: векторные БД, провайдеры моделей, инструменты, наблюдаемость.
• LangSmith для наблюдаемости. Зрелый интерфейс для трассировки и отладки.
• Широкое распространение. Много примеров, много документации, много людей, которые это знают.

Что плохо:

• Налог за абстракции. У LangChain особенно — много слоёв абстракции. Отлаживать тяжелее; понять, что реально происходит, требует усилий.
• Нестабильность API. Частые ломающие изменения. Код 12-месячной давности нередко требует обновления.
• Накладные расходы на производительность. Слои промежуточной логики стоят задержки и токенов.
• Кривая обучения. На реальную беглость уходят недели.

Когда брать:

• Сложные агентские процессы с ветвящимся состоянием.
• Команды, которым выгодно иметь стандартный фреймворк (много инженеров, общие паттерны).
• Если хотите наблюдаемость на базе LangSmith.

Когда пропускать:

• Простые чат-боты или одиночный агентский цикл (прямой API проще).
• Команды, уже обжёгшиеся на нестабильности LangChain.
• Проекты, где каждая миллисекунда задержки на счету.

CrewAI

Мульти-агентный фреймворк, ориентированный на ролевых агентов. У каждого агента есть роль, цель, «история»; они сотрудничают над задачами.

Что хорошо:

• Мульти-агентная оркестрация. Из коробки поддержка агентов, говорящих друг с другом, делегирующих и сотрудничающих.
• Ролевая ментальная модель. Удобно мыслить («агент-Исследователь делает X, агент-Писатель делает Y»).
• Проще, чем LangGraph для мульти-агента. Быстрее стартовать.
• Активное сообщество.

Что плохо:

• Ограниченная глубина для одиночного агента. Если задача — один сложный агент, абстракции CrewAI могут казаться неуместными.
• Производительность. Мульти-агентные конфигурации перемножают число LLM-вызовов; стоимость и задержка быстро растут.
• Разрыв в зрелости. Моложе LangChain; острых углов хватает.
• Навязывает свой подход. Меньше гибкости, чем у универсальных фреймворков.

Когда брать:

• Мульти-агентные процессы, где разграничение по ролям осмысленно.
• Трактовка «crew» (команда агентов, работающих вместе).
• Быстрое прототипирование мульти-агентных идей.

Когда пропускать:

• Одиночные агенты (перебор).
• Продакшен с упором на производительность (мульти-агент дорог).
• Задачи, где «сотрудничество агентов» — больше театр, чем суть.

Pydantic AI

Более новый фреймворк, ориентированный на типобезопасность и удобство разработки.

Что хорошо:

• Сильная типизация. Pydantic везде. Входы и выходы — типизированы. Ошибки ловятся на этапе разработки.
• Чистый API. Абстракций меньше, чем у LangChain; ближе к API моделей.
• Современный Python. Асинхронность, аннотации типов, Pydantic v2.
• Независимость от модели. Работает с большинством провайдеров.

Что плохо:

• Экосистема меньше. Меньше интеграций, чем у LangChain.
• Меньше доказательств в масштабе. Моложе; продакшен-паттерны ещё формируются.
• Меньше оркестрационных инструментов. Не такой богатый, как LangGraph, для сложных процессов.

Когда брать:

• Python-команды, ориентированные на типобезопасность.
• Одиночные агенты или простые мульти-агентные конфигурации.
• Команды, которым нравится минимум абстракции.

Когда пропускать:

• Очень сложная оркестрация (LangGraph может лучше зайти).
• Не-Python-проекты (он только под Python).
• Когда нужна гигантская экосистема готовых интеграций.

OpenAI Agents SDK

Официальный агентский фреймворк OpenAI, оптимизированный под их модели.

Что хорошо:

• Оптимизирован под OpenAI. Специально под паттерны GPT-5/o3.
• Простой API. Меньше абстракции, чем у LangChain.
• Встроенные передачи. Мульти-агентные передачи полноценно поддерживаются.
• Зрелая трассировка. Встроенная наблюдаемость, привязанная к дашборду OpenAI.

Что плохо:

• Привязка к OpenAI. Спроектирован под их модели. Использовать других провайдеров — неудобно.
• Меньше гибкости. Часть паттернов проще делать в более общих фреймворках.
• Моложе LangChain. Меньше сообщество.

Когда брать:

• Полная ставка на OpenAI.
• Хотите путь с поддержкой вендора.
• Простая или умеренная сложность агента.

Когда пропускать:

• Мультивендорная стратегия (лучше общий фреймворк или прямой API).
• Если в основном используете Anthropic или Google.

Anthropic Claude SDK

Аналогично — путь Anthropic для построения агентов на Claude.

Что хорошо:

• Оптимизирован под Claude. Особенно хорош для расширенного размышления (extended thinking), управления компьютером (computer use) и интеграции с MCP.
• Идиоматичен для моделей Claude.
• Сильная поддержка MCP.

Что плохо:

• Привязка к Claude. Тот же компромисс, что у OpenAI Agents SDK.

Когда брать:

• Полная ставка на Claude.
• Активное использование специфичных для Claude возможностей.

Когда пропускать:

• Мультивендорная стратегия.

Прямой API

Пропустить фреймворки совсем. Вызывать API OpenAI / Anthropic / Gemini напрямую. Цикл писать самим.

Что хорошо:

• Полный контроль. Каждый аспект системы — ваш.
• Нет налога за абстракции. Что видите, то и выполняется.
• Легко отлаживать. Нет слоёв, через которые нужно продираться.
• Легко оптимизировать. Нет накладных расходов фреймворка.
• Нет чехарды версий. Обновляйтесь, когда сами решите.

Что плохо:

• Больше кода. То, что делает фреймворк, делаете вы.
• Переизобретение. Типовые паттерны реализуются заново под каждый проект.
• Меньше стандартизации. Разные команды строят похожие системы по-разному.

Когда брать:

• Зрелые команды, выкатывающие продакшен-системы, где надёжность важнее удобства.
• Узкосфокусированные кейсы, которым гибкость фреймворка не нужна.
• Критичные по производительности пути.
• После прототипирования на фреймворке, когда паттерны уже выучены.

Когда пропускать:

• Проект с нуля, исследовательская фаза «что нам вообще строить» (фреймворк помогает обнаруживать паттерны).
• Команды с ограниченным инженерным ресурсом.

LlamaIndex

Начинал как библиотека под RAG; разросся и в более широкую агентскую территорию.

Что хорошо:

• Системы с упором на RAG. Лучшее в классе для агентов с упором на извлечение (retrieval).
• Коннекторы данных. Множество интеграций с источниками данных.
• Зрелые абстракции извлечения.

Что плохо:

• Агентские абстракции слабее. Под RAG лучше, чем под общих агентов.
• Частично пересекается с экосистемой LangChain.

Когда брать:

• Сильный упор на извлечение / RAG.
• Нужно много коннекторов к источникам данных.

Когда пропускать:

• Не-RAG-агентская работа.

Microsoft Autogen, Semantic Kernel

Предложения от Microsoft. Autogen — для мульти-агента; Semantic Kernel — для общих ИИ-приложений.

Что хорошо:

• Интеграция с экосистемой Microsoft. Хорошо с Azure, .NET, Microsoft 365.
• Semantic Kernel: ощущается более «энтерпрайзно», чем альтернативы.
• Autogen: силён для мульти-агентных исследований.

Что плохо:

• Меньшее сообщество за пределами компаний на стеке Microsoft.
• Меньше импульса, чем у LangChain/LangGraph.

Когда брать:

• Команды на стеке Microsoft.
• Глубокая интеграция с Azure.

Измерения, о которых стоит подумать

Выбор — не о победителе, а о подгонке компромиссов под проект.

Измерение 1. Сложность оркестрации

Насколько сложны ваши агентские процессы?

• Простые (чат-бот, одиночный агент, линейный поток): прямой API или Pydantic AI.
• Умеренные (одиночный агент, ветвящаяся логика): Pydantic AI, LangGraph, прямой API.
• Сложные (несколько агентов, конечные автоматы, повторные попытки): LangGraph, CrewAI, собственное решение.
• Очень сложные (большие конечные автоматы, параллельные агенты, сложная маршрутизация): LangGraph или собственное решение.

Измерение 2. Зрелость продакшена

Что важнее — надёжность или эксперименты?

• Эксперименты / прототипирование: любой фреймворк помогает двигаться быстро.
• Продакшен, лицом к клиенту: лучше понятные фреймворки (у LangChain больше всего паттернов; у прямого API — больше всего контроля).
• Критически важный продакшен: прямой API часто побеждает — вы понимаете каждую строку.

Измерение 3. Размер и навыки команды

• Маленькая команда (1–3 инженера): меньше накладных расходов фреймворка — лучше. Прямой API или простые фреймворки.
• Средняя команда (5–15): фреймворк помогает стандартизовать. LangChain или Pydantic AI.
• Большая команда (20+): фреймворк нужен ради общих паттернов. LangGraph или собственный фреймворк.

Измерение 4. Вендорная стратегия

• Несколько вендоров: универсальные фреймворки (LangChain, Pydantic AI) или прямой API.
• Один вендор: вендорские SDK (OpenAI Agents SDK, Anthropic Claude SDK).

Измерение 5. Чувствительность к производительности

• Критична задержка (интерфейс реального времени): прямой API. Фреймворки добавляют задержку.
• Критична стоимость (большие объёмы): прямой API. Фреймворки могут добавлять токены.
• Стандарт: любой фреймворк ок.

Измерение 6. Потребности в наблюдаемости

• Сильное из коробки: LangChain + LangSmith.
• Своими силами: любой фреймворк + ваш слой наблюдаемости.

Сдвиг к прямому API

Паттерн, который мы видим всё чаще в 2026: зрелые команды переходят с фреймворков на прямой API в продакшене.

Почему:

• За 1–2 года агентской работы команды выучили паттерны. Ценность фреймворка (обучать паттернам) исчерпана.
• Фреймворки меняются. Прямой API — нет. Стабильность в продакшене за прямой API.
• Производительность: фреймворки добавляют накладные расходы. Прямой API — нет.
• Отладка: когда что-то ломается, прямой API делает «что произошло» очевидным.
• Адаптация: у каждой продакшен-системы есть уникальные требования. Фреймворки сопротивляются доработке; прямой API её приветствует.

Это не приговор фреймворкам. Они хороши для обучения, прототипирования и умеренно сложных продакшен-систем. Но для зрелого продакшена прямой API часто — лучший выбор.

Миграционный паттерн:

1. Начинаем с LangChain или подобного.
2. Строим первые версии.
3. Учим паттерны.
4. Замечаем точки трения (отладка, производительность, доработка).
5. Переписываем горячие пути на прямой API.
6. В итоге большая часть продакшен-кода — прямой API.

Это не провал фреймворков; это их естественный жизненный цикл для части команд.

Практический каркас решения

Если выбираете под новый проект.

Шаг 1. Описать проект.

• Какая сложность агента?
• Сколько инженеров?
• Продакшен или прототип?
• Один вендор или несколько?

Шаг 2. Применить эвристики.

Шаг 3. Прототип, потом оценка.

Потратьте неделю на выбранный фреймворк. Соберите репрезентативный кусок. Оцените:

• Ложится ли на ваши паттерны?
• Вы сражаетесь с фреймворком или вместе с ним?
• Отладка вменяема?
• Производительность приемлема?

Да — продолжайте. Нет — попробуйте другой или уйдите в прямой API.

Шаг 4. Не привязывайте себя необратимо.

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

Паттерны, которые переносятся между фреймворками

Независимо от выбора, ряд паттернов универсален.

Разделение ответственностей. Управление промптами отдельно от логики агента, отдельно от определений инструментов, отдельно от цикла исполнения. С чем-то фреймворк помогает; остальное — на вас.

Наблюдаемость. Трассируйте каждый вызов LLM. Трассируйте каждый вызов инструмента. Агрегированные метрики. Это ваша работа независимо от фреймворка.

Бюджеты шагов и аварийные выходы. У любого продакшен-агента они есть. Фреймворки их не вынуждают; добавлять надо самим.

Оценочные наборы. Фреймворки не дают серьёзного инструментария для оценки. Стройте отдельно (Promptfoo, Braintrust, своё).

Закалка под продакшен. Ограничения частоты запросов, идемпотентность, обработка ошибок, запасные сценарии. Фреймворк даёт какие-то примитивы; остальное — на вас.

Если фокусироваться на этих универсальных паттернах, конкретный выбор фреймворка значит меньше. Больше значит дисциплина команды.

Вердикты по каждому фреймворку

После работы со многими из них — наш субъективный взгляд.

LangChain/LangGraph: мощный, но тяжёлый. Стоит выучить. В продакшене на горячих путях часто мигрируют прочь.

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

Pydantic AI: недооценён. Типобезопасность даёт дивиденды. Стоит попробовать.

OpenAI Agents SDK / Anthropic Claude SDK: хорошо, если вы связали себя с этим вендором. Иначе — риск привязки.

LlamaIndex: всё ещё король для систем с упором на RAG. Менее убедителен для общих агентов.

Прямой API: ход зрелых команд. Не стоит начинать здесь, но ожидайте, что закончите здесь — для критичного продакшен-кода.

Microsoft Autogen / Semantic Kernel: хорошо для экосистемы Microsoft; менее убедительно вне её.

История миграции

Чтобы было предметнее — реальная траектория.

Месяцы 1–3. Команда строит первые ИИ-функции на LangChain. Быстро выкатывает, многому учится.

Месяцы 4–6. Появляются продакшен-требования — наблюдаемость, оценки (evals), производительность. Команда строит это поверх LangChain.

Месяцы 7–9. Часть абстракций LangChain становится трением. Команда начинает оборачивать LangChain в собственные интерфейсы.

Месяцы 10–12. Обновление версии LangChain ломает несколько систем. Команда переписывает горячие пути на прямой API. Холодные остаются в LangChain.

Год 2. Большая часть продакшен-кода — прямой API. LangChain используется для случайного прототипирования. Внутренний «агентский фреймворк» команды — построенный на прямом API — становится стандартом.

Это одна из валидных траекторий. Другие тоже валидны — кто-то счастливо остаётся в LangChain; кто-то с первого дня его не берёт.

Другой ракурс: что вы на самом деле выбираете

Помимо фреймворка вы выбираете:

• Сообщество, у которого учиться.
• Темп изменений API, с которым придётся жить.
• Набор паттернов, под которые стандартизоваться.
• Опыт отладки.
• Историю наблюдаемости.
• Стоимость будущей миграции.

Фреймворк — одно выражение этого. Но именно эти вещи влияют на команду день ото дня.

Фреймворк, подходящий вашему сообществу, вашей терпимости к изменениям API, вашим паттернам, вашему стилю отладки, вашим потребностям в наблюдаемости — это и есть правильный выбор. Без этих совпадений даже самый популярный фреймворк — не ваш.

Главный вывод

Универсально лучшего агентского фреймворка в 2026 году нет. Правильный выбор зависит от сложности проекта, размера команды, зрелости продакшена, вендорной стратегии и предпочтений команды.

Рабочий подход:

• Подберите фреймворк под требования проекта по эвристикам выше.
• Прототипируйте, прежде чем окончательно выбирать.
• Структурируйте код так, чтобы замена была возможна.
• Фокусируйтесь на универсальных паттернах независимо от фреймворка.
• Ждите эволюции — то, что подходит сейчас, может не подойти через 12 месяцев.

Многие зрелые команды сходятся на прямом API для критичного продакшен-кода. Фреймворки остаются полезны для прототипов, обучения и умеренно сложной оркестрации. Выбор — не религиозный, а контекстный.

Берите тот, что подходит сегодня. Меняйте, когда перестанет подходить. Система, которую вы строите, важнее фреймворка, на котором вы её строите.