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-вызовов; стал де-факто фреймворком многих AI-проектов. LangGraph — это уже специализированный агентский фреймворк поверх него.

Что хорошо:

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

Что плохо:

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

Когда брать:

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

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

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

CrewAI

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

Что хорошо:

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

Что плохо:

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

Когда брать:

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

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

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

Pydantic AI

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

Что хорошо:

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

Что плохо:

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

Когда брать:

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

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

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

OpenAI Agents SDK

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

Что хорошо:

• Оптимизирован под OpenAI. Специально под паттерны GPT-5/o3.
• Простой API. Меньше абстракции, чем у LangChain.
• Встроенные хэндоффы. Мульти-агентные передачи — first-class.
• Зрелый трейсинг. Встроенная наблюдаемость, привязанная к дашборду 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 напрямую. Цикл писать самим.

Что хорошо:

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

Что плохо:

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

Когда брать:

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

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

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

LlamaIndex

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

Что хорошо:

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

Что плохо:

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

Когда брать:

• Тяжёлый retrieval/RAG-фокус.
• Нужно много коннекторов к источникам данных.

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

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

Microsoft Autogen, Semantic Kernel

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

Что хорошо:

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

Что плохо:

• Меньшее сообщество вне Microsoft-shops.
• Меньше импульса, чем у LangChain/LangGraph.

Когда брать:

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

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

Выбор — не о победителе, а о подгонке трейд-оффов под проект.

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

Насколько сложны ваши агентские флоу?

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

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

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

• Эксперименты / прототипирование: любой фреймворк помогает двигаться быстро.
• Продакшен, лицом к клиенту: лучше понятные фреймворки (у LangChain больше всего паттернов; у прямого API — больше всего контроля).
• Продакшен, mission-critical: прямой 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. Чувствительность к производительности

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

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

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

Сдвиг к прямому 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-вызова. Трейс каждого вызова инструмента. Агрегированные метрики. Это ваша работа независимо от фреймворка.

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

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

Закаливание под продакшен. Rate limits, идемпотентность, обработка ошибок, фолбэки. Фреймворк даёт какие-то примитивы; остальное — на вас.

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

Честные мнения

После работы со многими из них наше опинионированное мнение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

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

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

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