Ещё полтора года назад разработка AI-агента выглядела, мягко говоря, кустарно: цикл ReAct писали руками, вызовы инструментов склеивали на честном слове, а состояние приложения держалось до первого неловкого чиха в демо. Сейчас картина другая. К марту 2026 года у команд, которые занимаются разработкой AI-агентов и автоматизацией, уже не дефицит инструментов, а почти обратная проблема — выбрать из нескольких зрелых фреймворков, каждый со своим характером, ограничениями и архитектурной логикой.
LangGraph вышел в 1.0 ещё осенью 2025 года и к марту 2026 года дорос до версии 1.0.10. CrewAI перевалил за 44,6 тыс. звёзд на GitHub и выпустил 1.10.1 с нативной поддержкой MCP и A2A. OpenAI развивает Agents SDK, который уже работает не только с собственными моделями, а с сотней+ LLM через единый API. Anthropic вывела Claude Agent SDK, а Google — свой ADK. Вариантов много. Даже слишком.
Поэтому здесь — не абстрактный обзор, а нормальное, приземлённое сравнение. Все фреймворки мысленно прогоняются через одну и ту же задачу: агент для triage электронной почты. Он читает входящие письма, определяет, что срочно, что рутинно, а что спам, черновиком отвечает на обычные сообщения и передаёт критичные письма человеку. Одна задача. Разные подходы. И вот тут уже становится видно, кто на что годится.
Зачем вообще нужны фреймворки для AI-агентов
Если у вас один вызов модели и один инструмент, никакой магии не требуется. Обычный API-вызов часто оказывается быстрее, дешевле и понятнее. Но как только появляются хотя бы два-три слоя логики — всё, начинается веселье.
- Многошаговая оркестрация с ветвлениями и условиями
- Память между сессиями и сохранение контекста
- Работа с инструментами, MCP-серверами и function calling
- Восстановление после ошибок, если LLM или внешний сервис упал посреди процесса
- Human-in-the-loop для решений, где цена ошибки неприятно высокая
- Наблюдаемость и трассировка — кто что вызвал, почему и в какой момент всё поехало
Вот тут фреймворк и начинает окупаться. Он берёт на себя рутину: состояние, маршрутизацию, повторные попытки, координацию шагов, иногда — безопасность и контроль исполнения. По сути, это та же история, что когда-то случилась с веб-разработкой: можно, конечно, писать всё на низком уровне, но зачем, если есть инструменты, которые закрывают инфраструктурную возню.
Если говорить совсем по-человечески: фреймворки для AI-агентов — это как Django, Rails или Express, только для агентных систем. Они не делают продукт за вас, нет. Но снимают с команды массу скучной механики, чтобы вы занимались логикой бизнеса, а не латали очередной переход состояния в три часа ночи.
LangGraph: когда агент — это граф, а не импровизация
Версия: 1.0.10
GitHub: 24.6K stars
PyPI: 38M+ загрузок в месяц
LangGraph строит агента как ориентированный граф: узлы — это функции или шаги, рёбра — переходы между ними, а состояние проходит через весь процесс как типизированная структура данных. Подход очень инженерный. Не самый короткий по коду, зато прозрачный.
Как устроен LangGraph
Базовая сущность здесь — StateGraph. Разработчик описывает схему состояния, добавляет узлы, связывает их переходами, задаёт условные ветвления и компилирует всё это в исполняемый объект. Важный плюс: checkpointing встроен из коробки. То есть состояние сохраняется на каждом переходе, и если агент упал посреди workflow, его можно поднять почти с того же места, а не запускать заново с молитвой.
В версии 1.0 у LangGraph появились durable state, память между потоками исполнения и механизм Command, позволяющий строить более динамичные сценарии без жёстко прописанных рёбер. Для команд, которым нужна архитектура AI-агентов с предсказуемым поведением, это очень сильный аргумент.
Email triage в LangGraph
from langgraph.graph import StateGraph, END
from typing import TypedDict, Literal
class EmailState(TypedDict):
email: str
category: Literal["urgent", "normal", "spam"] | None
draft_response: str | None
escalated: bool
def classify_email(state: EmailState) -> EmailState:
category = llm.invoke(f"Classify this email: {state['email']}")
return {"category": category}
def draft_response(state: EmailState) -> EmailState:
response = llm.invoke(f"Draft a reply to: {state['email']}")
return {"draft_response": response}
def escalate(state: EmailState) -> EmailState:
return {"escalated": True}
def route_email(state: EmailState) -> str:
if state["category"] == "urgent":
return "escalate"
elif state["category"] == "normal":
return "draft_response"
return END
graph = StateGraph(EmailState)
graph.add_node("classify", classify_email)
graph.add_node("draft_response", draft_response)
graph.add_node("escalate", escalate)
graph.set_entry_point("classify")
graph.add_conditional_edges("classify", route_email)
graph.add_edge("draft_response", END)
graph.add_edge("escalate", END)
app = graph.compile(checkpointer=MemorySaver())
Сильная сторона подхода очевидна: маршрут выполнения виден заранее. Не после инцидента. До него. Для production-систем, где важны аудит, воспроизводимость и контроль, это прямо золото, без преувеличения.
Ещё одна полезная штука — interrupt_before. С её помощью можно остановить выполнение перед критическим узлом и передать решение человеку. Для сценариев с дорогой ошибкой — финансовые операции, юридические согласования, чувствительные клиентские кейсы — это почти обязательная функция.
Когда LangGraph подходит лучше всего
Если у вас сложный stateful workflow, много условий, циклы, точки согласования и строгие требования к управляемости — берите LangGraph и не мучайтесь. Он особенно хорош там, где важны долговечное состояние, агентная память, контроль переходов и надёжная оркестрация.
Под такие задачи часто попадают системы с требованиями к AI compliance и соответствию требованиям, внутренние корпоративные ассистенты, автоматизация заявок, согласований, инцидентов и другие enterprise-сценарии.
Когда LangGraph будет лишним
Если задача простая, а агент один, графовая модель может оказаться тяжеловесной. Код получается подробнее, порог входа выше, а команде нужно время, чтобы начать мыслить графами, а не линейными скриптами. Иногда это оправдано. Иногда — нет, и это тоже нормально.
CrewAI: когда агентная система похожа на команду людей
Версия: 1.10.1
GitHub: 44.6K stars
PyPI: 12M+ загрузок в месяц
CrewAI идёт от другой метафоры. Не граф. Не машина состояний. Здесь агентная система описывается как команда специалистов: у каждого есть роль, цель, контекст, зона ответственности. И, надо признать, для многих задач это ощущается удивительно естественно.
Как устроен CrewAI
Основные сущности — это Agents, Tasks и Crews. Агенту задают роль, цель, иногда предысторию; задаче — описание и ожидаемый результат; crew координирует выполнение, делегирование и передачу контекста между участниками. Плюс есть Flows API для событийной оркестрации в enterprise-среде.
Отдельно стоит отметить нативную поддержку MCP и A2A. Для компаний, которые строят мультиагентные системы и хотят не просто прототип, а расширяемую платформу, это серьёзный плюс. CrewAI умеет работать с несколькими транспортами MCP, автоматически управляет соединениями и упрощает подключение инструментов.
Email triage в CrewAI
from crewai import Agent, Task, Crew
classifier = Agent(
role="Email Classifier",
goal="Accurately categorize emails as urgent, normal, or spam",
backstory="Senior executive assistant with 10 years of experience managing high-volume inboxes.",
llm="gpt-4.1",
)
responder = Agent(
role="Email Responder",
goal="Draft professional, contextually appropriate email responses",
backstory="Communications specialist who writes concise, friendly replies.",
llm="gpt-4.1",
)
classify_task = Task(
description="Classify this email: {email}. Return: urgent, normal, or spam.",
agent=classifier,
expected_output="One word: urgent, normal, or spam",
)
respond_task = Task(
description="If the classification is 'normal', draft a response. If 'urgent', output 'ESCALATE'. If 'spam', output 'DISCARD'.",
agent=responder,
expected_output="A draft response, ESCALATE, or DISCARD",
context=[classify_task],
)
crew = Crew(
agents=[classifier, responder],
tasks=[classify_task, respond_task],
verbose=True,
)
result = crew.kickoff(inputs={"email": email_content})
Код читается почти как оргструктура маленькой команды. И в этом весь фокус. CrewAI очень удобен для быстрого старта, особенно когда бизнес-логика естественно раскладывается по ролям: исследователь, аналитик, редактор, маршрутизатор, оператор поддержки и так далее.
Когда CrewAI особенно хорош
Когда нужно быстро собрать рабочий прототип, показать демо, протестировать гипотезу или развернуть мультиагентный сценарий без долгого проектирования графа. Он отлично подходит для клиентской поддержки, контентных конвейеров, внутренних copilot-систем, командных workflow и агентной автоматизации, где роли выражены явно.
Когда CrewAI может ограничивать
Если вам нужен очень точный контроль над тем, какой шаг выполняется после какого условия, abstractions CrewAI могут показаться слишком «высокоуровневыми». Иногда это удобно. Иногда бесит. Ну, бывает.
OpenAI Agents SDK: минимум обвязки, быстрый старт
Версия: 0.10.2
GitHub: 19K stars
PyPI: 10.3M загрузок в месяц
OpenAI Agents SDK — это, пожалуй, самый прямолинейный вариант в сравнении. Он опирается на четыре базовых примитива: Agents, Handoffs, Guardrails и Tools. Всё. Без лишней философии.
Как устроен OpenAI Agents SDK
Агент здесь — это модель плюс инструкции, инструменты и, при необходимости, логика передачи задачи другому агенту. Если один агент понимает, что запрос лучше обработает другой, он делает handoff и передаёт контекст дальше. История при этом упаковывается компактно, а не тащится сырым логом сообщений. Это удобно и экономит контекстное окно.
SDK небольшой по объёму, его реально можно прочитать и понять без археологии по исходникам. В новых версиях появились WebSocket-транспорт, sessions и поддержка Python 3.14. Для команд, которым нужна быстрая разработка AI-агентов без тяжёлой инфраструктуры, это очень практичный выбор.
Email triage в OpenAI Agents SDK
from agents import Agent, Runner, handoff, InputGuardrail
spam_filter = Agent(
name="Spam Filter",
instructions="You discard spam. Reply with 'SPAM_DETECTED' for spam emails.",
)
responder = Agent(
name="Email Responder",
instructions="Draft a professional response to normal emails.",
)
escalator = Agent(
name="Urgent Handler",
instructions="Flag urgent emails for human review. Output the urgency reason.",
)
triage_agent = Agent(
name="Email Triage",
instructions="Classify incoming emails. Hand off to the appropriate specialist.",
handoffs=[
handoff(spam_filter, "Email is spam"),
handoff(responder, "Email needs a routine response"),
handoff(escalator, "Email is urgent and needs human attention"),
],
)
result = Runner.run(triage_agent, input=email_content)
Кода мало. Очень мало. И это не недостаток. Если ваш сценарий естественно строится вокруг делегирования — один агент сортирует, другой отвечает, третий эскалирует — SDK ощущается почти очевидным выбором.
Когда подходит лучше всего
Для быстрого прототипирования, пилотов, MVP и сценариев, где не хочется тащить тяжёлую оркестрацию. Особенно если команда хочет сохранить прямой контроль над логикой и не погружаться в сложную архитектурную модель.
Когда начнутся ограничения
Если нужны встроенный persistence, сложная агентная память, возобновление после сбоев и длинные stateful workflow, SDK придётся серьёзно дополнять своими слоями. Сам по себе он лёгкий — а значит, часть enterprise-функций вы будете достраивать вручную.
Claude Agent SDK: сильный вариант для MCP-ориентированных сценариев
Версия: 0.1.48
Языки: Python, TypeScript
Статус: Alpha
Claude Agent SDK вырос из Claude Code SDK и теперь позиционируется шире: не только как инструмент для программирования, а как полноценная среда для агентных сценариев с глубоким доступом к инструментам, файловой системе и внешним операциям.
Что в нём главное
Главная фишка — нативная работа с MCP. Инструменты можно поднимать как in-process MCP-серверы, без лишних процессов и сетевой прослойки. Плюс есть hooks жизненного цикла: до вызова инструмента, после него, при ошибке. Это удобно, если вам нужны логирование, контроль, ручное подтверждение действий и безопасность AI-агентов на уровне исполнения.
Когда Claude Agent SDK уместен
Если команда уже плотно сидит на Anthropic, активно использует MCP и хочет тонко контролировать жизненный цикл вызовов, вариант очень сильный. Особенно в сценариях, где важны hooks, контроль инструментов и предсказуемое поведение при ошибках.
Ограничение, о котором лучше помнить сразу
Это не multi-model платформа. Если вам нужна маршрутизация между Claude, GPT, Gemini и другими моделями, придётся строить дополнительный слой оркестрации. То есть сам SDK хорош, но не универсален.
Google ADK и Microsoft Agent Framework: ещё два серьёзных игрока
Google ADK
Версия: 1.26.0
GitHub: около 18K stars
Языки: Python, Java, TypeScript, Go
Google ADK особенно интересен тем, что сочетает model-agnostic подход с явной оптимизацией под экосистему Gemini. Его сильные стороны — мультимодальность, встроенная поддержка A2A и удобные workflow-агенты для последовательных, параллельных и циклических сценариев. Плюс dev UI для локальной отладки — мелочь, а приятно. Правда, очень приятно.
Microsoft Agent Framework
Microsoft объединила наработки AutoGen и Semantic Kernel в единый Agent Framework. Он предлагает графовую оркестрацию, поддержку MCP и A2A, streaming, checkpointing и human-in-the-loop паттерны. Для Azure-ориентированных корпоративных команд это, по сути, естественный кандидат. Особенно если инфраструктура уже живёт в экосистеме Microsoft и никто не хочет изобретать велосипед с квадратными колёсами.
Сравнение фреймворков AI-агентов
Если упростить до сути, картина выглядит так:
| Критерий | LangGraph | CrewAI | OpenAI Agents SDK | Claude Agent SDK | Google ADK | MS Agent Framework |
|---|---|---|---|---|---|---|
| Архитектурная модель | Графы состояний | Роли и команды | Handoff-цепочки | Инструменты + hooks | Workflow-агенты | Графовая оркестрация |
| Сильная сторона | Контроль и persistence | Скорость prototyping | Простота | MCP-native исполнение | Мультимодальность | Enterprise/Azure |
| Поддержка multi-agent | Через композицию графов | Встроена | Через handoff | Ограниченно | Есть | Есть |
| Поддержка MCP | Через экосистему | Нативная | Интеграция есть | Нативная in-process | Через адаптеры | Встроенная |
| Когда брать | Сложные production workflow | Командные сценарии | Быстрый запуск | MCP-heavy процессы | Gemini и мультимодальность | Корпоративный стек Microsoft |
Если совсем коротко: универсального победителя нет. И это, честно говоря, даже хорошо. Значит, рынок взрослеет.
Как выбрать фреймворк под свою задачу
Обычно решение упирается в четыре вопроса.
1. Насколько сложен workflow
Если всё решается одним вызовом модели и парой инструментов, фреймворк может быть не нужен вовсе. Для средней сложности — несколько агентов, условная маршрутизация, базовая автоматизация — CrewAI и OpenAI Agents SDK дают быстрый старт. Если же у вас циклы, параллельные ветки, контрольные точки, долговечное состояние и строгая логика переходов, тогда LangGraph выглядит сильнее остальных.
2. Есть ли зависимость от конкретного вендора
Если весь стек уже завязан на Anthropic — Claude Agent SDK даст самую тесную интеграцию. Если вы глубоко в Google Cloud — логично смотреть на ADK. Если нужна гибкость по моделям и поставщикам, лучше выбирать более нейтральные варианты вроде LangGraph или CrewAI.
3. Нужна ли настоящая мультиагентная система
Для выраженного multi-agent взаимодействия CrewAI чувствует себя очень уверенно. LangGraph тоже умеет, но требует более аккуратного проектирования. OpenAI Agents SDK хорош для делегирования, но не всегда удобен, когда нужна полноценная кооперация нескольких агентов в сложной схеме.
4. Что важнее — скорость или долговечность решения
Нужно показать рабочий результат к пятнице? Берите что-то лёгкое. Нужно строить систему на годы, с аудитом, памятью, безопасностью и требованиями enterprise-уровня? Тогда уже стоит смотреть на архитектуру серьёзнее, включая агентную память и RAG, checkpointing, observability и контроль исполнения.
Когда фреймворк нужен, а когда — нет
Фреймворк почти точно нужен, если:
- агент должен хранить состояние между сессиями;
- в системе несколько агентов или много инструментов;
- нужны human-in-the-loop сценарии;
- важны трассировка, аудит и отказоустойчивость;
- над системой работает не один разработчик, а команда.
Фреймворк, скорее всего, не нужен, если:
- задача решается одним вызовом LLM;
- это одноразовый скрипт или эксперимент;
- абстракция фреймворка не совпадает с формой задачи;
- вам нужен полный ручной контроль над каждым токеном и вызовом;
- обвязки получается больше, чем пользы.
И вот тут важный момент. Очень важный. Худшее, что можно сделать, — выбрать фреймворк, который не соответствует природе вашей системы. Потом начинается болезненная миграция, переписывание логики, переделка инструментов, пересборка памяти, и все делают вид, что так и было задумано. Не было.
Практичный способ подстраховаться — проектировать инструменты как MCP-сервисы независимо от выбранного фреймворка. Это повышает переносимость и даёт больше свободы, если через полгода архитектура изменится.
Итог
К 2026 году рынок фреймворков для AI-агентов уже не выглядит хаотичным. Ниши постепенно оформились. LangGraph силён там, где нужна сложная оркестрация, долговечное состояние и строгий контроль. CrewAI отлично подходит для мультиагентных сценариев и быстрого запуска. OpenAI Agents SDK выигрывает в простоте и скорости старта. Claude Agent SDK интересен как MCP-native вариант с хорошим контролем жизненного цикла. Google ADK и Microsoft Agent Framework особенно заметны в своих экосистемах и enterprise-контексте.
Если выбирать практично, без фанатизма, то картина примерно такая: для сложной архитектуры AI-агентов — LangGraph; для командной мультиагентной логики — CrewAI; для быстрого MVP — OpenAI Agents SDK. Всё остальное зависит от инфраструктуры, требований к безопасности, памяти, соответствию требованиям и того, насколько долго эта система должна жить в production.
А базовые паттерны всё равно важнее конкретного бренда фреймворка: function calling, MCP, A2A, агентная память, RAG, безопасность AI-агентов, observability. Фреймворки меняются быстро. Паттерны — куда медленнее. И, наверное, именно их стоит учить в первую очередь.
Частые вопросы
Чем графовый фреймворк отличается от ролевого?
Графовый подход, как в LangGraph, задаёт явную структуру переходов и состояний. Ролевой, как в CrewAI, описывает систему через участников, цели и делегирование. Если процесс можно нарисовать как блок-схему — граф обычно удобнее. Если задача больше похожа на работу команды специалистов — ролевой подход ощущается естественнее.
Как реализовать human-in-the-loop в agent workflow?
Обычно через точки остановки, checkpointing и внешний сигнал на продолжение. В LangGraph для этого есть удобные механизмы вроде interrupt_before. В других фреймворках это решается через hooks, guardrails или специальные approval-паттерны. Ключевой принцип один: состояние должно сохраняться на время паузы.
Когда вообще не стоит использовать agent framework?
Когда задача слишком проста. Если всё решается одним вызовом модели и парой инструментов, фреймворк только утяжелит систему. Иногда лучший агент — это вообще не агент, а аккуратный pipeline. Да, звучит скучно. Зато работает.
Почему MCP стал таким важным?
MCP стандартизирует подключение инструментов и делает их переносимыми между разными агентными платформами. Для бизнеса это означает меньше привязки к одному стеку и более устойчивую архитектуру интеграций. А для команд разработки — меньше боли при масштабировании и смене фреймворка.