LangGraph, CrewAI, AutoGen: как выбрать фреймворк под форму своей задачи

«LangGraph или CrewAI?» — этот вопрос прилетает мне почти каждую неделю. За ним обычно стоит другой: с чего начать, чтобы через месяц не выбрасывать всё и не писать заново. Отвечаю так, как ответил бы себе год назад.

Начните с вопроса, который экономит две недели

Посчитайте шаги вашего сценария и посмотрите, сколько из них ветвятся.

Сценарий линейный — забрать письмо, вытащить сущности, положить в CRM, отправить ответ? Тогда фреймворк агентов вам, скорее всего, не понадобится. Хватит скрипта с вызовом модели и парой условий. Одна команда полтора месяца воевала с оркестратором ради пайплайна из четырёх шагов. Потом выкинула его и уложилась в 200 строк.

Фреймворк начинает окупаться, когда появляется хотя бы одно из этого:

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

Чем эти три реально отличаются

Описания на лендингах у всех похожи. Разницу задаёт метафора, которую фреймворк вам навязывает. Она решает, что пойдёт легко и что придётся выламывать через колено.

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

CrewAI мыслит командой. Роли, цели и задачи описываются почти декларативно, рабочий прототип получается быстро. Хорошо ложится на «исследователь → аналитик → редактор». Хуже, когда нужен жёсткий контроль над каждым переходом: роль — абстракция мягкая, и в момент, когда понадобится точный маршрут, придётся спускаться уровнем ниже.

AutoGen мыслит диалогом. Агенты обмениваются сообщениями, логика рождается из разговора. Сильно там, где решение ищется обсуждением: код-ревью, поиск ошибки, спор двух точек зрения. Здесь же и главный риск — разговор умеет не сходиться, и бюджет токенов уходит в круги.

Как выбирать по форме задачи

Соответствие, которое у меня работает:

• Детерминированный маршрут с ветвлениями и человеком в контуре — LangGraph.
• Конвейер из ролей, где важна скорость прототипа — CrewAI.
• Задача решается обсуждением между несколькими ролями — AutoGen.
• Всё завязано на интеграции с внешними сервисами, «агентность» вторична — посмотрите в сторону n8n и подобных визуальных оркестраторов. Часто половина работы там уже сделана коннекторами.

История про 344 звезды

Разбирал готовые решения для холодных рассылок и наткнулся на репозиторий на LangGraph — sales-outreach-automation-langgraph. 344 звезды, внятный README, с виду готовое решение.

Проверил по API GitHub: лицензии нет вообще, последний коммит — январь 2025. И главное: пайплайн доводит дело до черновиков писем, дальше человек всё равно работает руками.

Сам репозиторий нормальный. Плохо было бы взять его в основу продукта, поверив звёздам. Поэтому теперь, прежде чем копировать чужую архитектуру, я смотрю три вещи:

1. Лицензия. Её отсутствие означает, что использовать код в своём продукте юридически нельзя.
2. Дата последнего коммита. В экосистеме, где API моделей меняются каждый квартал, полтора года тишины — это археология.
3. Что пайплайн реально отдаёт на выходе. Черновик и отправленное письмо — разные продукты. Разница между ними живёт как раз в той части, которую никто не публикует.

Осторожнее со сравнительными статьями

Большая часть материалов формата «X vs Y vs Z» написана людьми, которые продают что-то четвёртое. Схема узнаваемая: три фреймворка честно разбираются, у каждого находится критичный недостаток, в финале появляется вывод «поэтому мы отказались от фреймворков» или «поэтому мы используем нашу платформу».

Такие тексты всё равно полезны. Читайте их как аргументацию заинтересованной стороны: берите факты про API и ограничения, вывод пропускайте.

Что я делаю на практике

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

Дальше переношу это в фреймворк, чья метафора совпала с формой прототипа. Перенос занимает день: логика уже проверена. Выбор получается по факту, и обсуждение «что лучше в 2026 году» отпадает само.

И последнее. Выбор фреймворка обратим. Необратимое лежит в другом месте: формат данных, схема памяти агента, способ хранить историю запусков. Вот на них и стоит потратить те два дня, которые вы собирались убить на сравнение оркестраторов.