Фреймворки для агентов

Короткая версия

В 2026 основные варианты удобно читать так:

• LangChain: быстрый старт и provider-agnostic агентный слой с сильной экосистемой.
• LangGraph: низкоуровневый orchestration runtime для сложных graph/stateful workflows.
• OpenAI Agents SDK: provider-native runtime с handoffs, guardrails, sessions, tracing и realtime agents.
• CrewAI: multi-agent и flow-first framework с упором на crews, flows и event-driven orchestration.
• Claude Code SDK: Anthropic-native agent harness с tools, permissions, MCP и coding/ops workflows.

Нужен агент для внутренней поддержки: 1 основной агент, 4 инструмента, traces, guardrails и возможность позже добавить handoff на specialist agent.

1. Как изменился ландшафт фреймворков

Раньше вопрос звучал так: “Что взять вместо ручной сборки агента?”

В 2026 вопрос точнее звучит так:

• нужен ли вам provider-native runtime;
• нужна ли portability между OpenAI / Anthropic / Google;
• насколько сложен ваш state graph;
• нужна ли вам multi-agent collaboration как first-class concept;
• нужны ли встроенные guardrails, tracing, sessions, HITL.

Это автоматически разводит инструменты по классам.

2. LangChain: быстрый provider-agnostic старт

LangChain в текущих docs позиционируется как самый быстрый способ собрать custom agents и agentic apps с единым интерфейсом к моделям и tools.

Что важно в current framing:

• это уже не только “цепочки” старой школы;
• LangChain рекомендует стартовать с prebuilt agent architecture;
• под капотом агентный слой опирается на LangGraph;
• docs прямо разводят LangChain и LangGraph по уровню абстракции.

Когда LangChain хорош:

• нужен быстрый старт;
• важна portability между провайдерами;
• у команды already есть LangChain ecosystem;
• нужен нормальный путь к LangSmith tracing/evals.

Когда он хуже:

• нужна очень жёсткая детерминированная orchestration-логика;
• вы не хотите зависеть от его abstraction layer;
• приложение маленькое, и framework overhead не окупается.

3. LangGraph: runtime для stateful и durable agent workflows

LangGraph сейчас лучше описывать не как “надстройку над LangChain”, а как отдельный orchestration/runtime слой для graph-based flows.

По docs важны такие свойства:

• durable execution;
• stateful workflows;
• human-in-the-loop;
• persistence;
• явное управление узлами, переходами и state transitions.

LangGraph особенно полезен, когда у вас:

• сложные branching flows;
• long-running tasks;
• resumable state;
• строгие control points;
• смесь deterministic и agentic steps.

Практически это уже ближе к workflow engine для agent systems, чем к “удобной обёртке над LLM”.

4. OpenAI Agents SDK: provider-native runtime

OpenAI Agents SDK — один из самых заметных сдвигов относительно старых обзорных статей. Его уже нельзя игнорировать в сравнении.

В current docs SDK позиционируется как lightweight, Python-first runtime с небольшим набором примитивов:

• Agent;
• Runner;
• tools;
• handoffs;
• guardrails;
• sessions;
• tracing;
• realtime agents.

Это важная рамка: SDK не пытается быть гигантским универсальным abstraction layer. Он intentionally ближе к provider-native runtime с хорошей ergonomics.

Когда он особенно силён:

• вы already on OpenAI stack;
• нужны native Responses, sessions, realtime, handoffs, guardrails;
• хочется меньше абстракций, чем в LangChain-style ecosystem;
• важны built-in tracing и естественный путь к OpenAI eval/fine-tune/distillation stack.

Ограничение очевидное: portability здесь ниже, чем у provider-agnostic frameworks.

5. CrewAI: crews и flows как first-class model

CrewAI уже нельзя описывать только как “простое multi-agent API”. В current docs сильный акцент сместился на:

• agents;
• crews;
• flows;
• memory;
• knowledge;
• guardrails;
• observability;
• event-driven workflow orchestration.

Особенно важен Flows слой:

• start/listen/router pattern;
• state management;
• persistence;
• resume;
• HITL outcomes;
• event-driven automation.

То есть CrewAI полезен не только для “команды агентов”, но и для builder'ов, которым нужен opinionated workflow framework поверх agent units.

Однако trade-off остаётся:

• abstraction layer довольно opinionated;
• сложные кастомные graph patterns контролировать тяжелее, чем в LangGraph;
• для simple single-agent apps он может быть избыточен.

6. Claude Code SDK: Anthropic-native harness

Anthropic current docs уже продвигают не абстрактный “Claude Agent SDK”, а Claude Code SDK как agent harness, на котором можно строить production-ready agents.

Что выделяет его в 2026:

• Anthropic-native integration;
• automatic prompt caching optimizations;
• file operations, code execution, web search;
• MCP extensibility;
• fine-grained permissions;
• session management и monitoring.

Это сильный выбор не для любой агентной задачи, а прежде всего для:

• coding agents;
• repo-aware assistants;
• SRE / oncall / security review workflows;
• Anthropic-native tool-rich environments.

Если задача general-purpose business automation и нужен multi-provider path, он уже не так универсален, как LangChain/LangGraph.

7. Как выбирать framework по типу системы

Если нужен простой single-agent app

Смотрите сначала на:

• OpenAI Agents SDK, если стек OpenAI вас устраивает;
• LangChain, если нужна portability.

Если нужен graph с контролем переходов

Смотрите на:

• LangGraph.

Если нужен multi-agent workflow и event routing

Смотрите на:

• CrewAI.

Если нужен repo/coding/SRE agent

Смотрите на:

• Claude Code SDK;
• иногда OpenAI Agents SDK + custom tool layer, если вы на OpenAI.

Если нужен максимум portability

Смотрите на:

• LangChain / LangGraph.

8. Framework vs no framework

Иногда правильный ответ — вообще не брать тяжёлый framework.

Без framework можно обойтись, если:

• у вас 1 агент;
• 2-5 tools;
• нет сложных handoff/graph patterns;
• state minimal;
• tracing и eval закрываются отдельно.

Framework стоит брать, если он сокращает:

• boilerplate;
• orchestration risk;
• observability gaps;
• state management complexity.

Если он просто заменяет 150 строк понятного кода на 5 новых абстракций и 3 hidden runtime layer, польза сомнительна.

9. Practical comparison

OpenAI Agents SDK: минимальный provider-native агент

from agents import Agent, Runner, function_tool


@function_tool
def get_ticket_status(ticket_id: str) -> str:
    return f"Ticket {ticket_id}: waiting for security review"


agent = Agent(
    name="Support triage",
    instructions="Ты помогаешь саппорту и используешь инструменты только когда это нужно.",
    model="gpt-5.4",
    tools=[get_ticket_status],
)

result = Runner.run_sync(agent, "Проверь статус тикета INC-4421")
print(result.final_output)

Хороший fit:

• короткий путь до runnable agent loop;
• handoffs и guardrails как first-class primitives;
• OpenAI-native tracing и sessions.

LangGraph: когда нужен явный state graph

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


class SupportState(TypedDict):
    question: str
    needs_tool: bool
    answer: str


def classify(state: SupportState):
    return {"needs_tool": "status" in state["question"].lower()}


def answer_direct(state: SupportState):
    return {"answer": "Отвечаю без внешних инструментов."}


graph = StateGraph(SupportState)
graph.add_node("classify", classify)
graph.add_node("answer_direct", answer_direct)
graph.set_entry_point("classify")
graph.add_edge("answer_direct", END)

Это уже не “магический агент”, а runtime, где вы сами проектируете control flow.

CrewAI: flow-first orchestration

В current CrewAI полезно смотреть не только на Crew, но и на Flow:

from crewai.flow.flow import Flow, start, listen


class IntakeFlow(Flow):
    @start()
    def receive_ticket(self):
        self.state["ticket"] = "INC-4421"
        return self.state["ticket"]

    @listen(receive_ticket)
    def enrich(self, ticket_id):
        self.state["summary"] = f"Enriched {ticket_id}"
        return self.state["summary"]

CrewAI удобен, когда event-driven flow и shared state важнее, чем low-level graph design.

Выбор как инженерное решение

Перед выбором framework полезно ответить на 5 вопросов:

1. Нужна ли portability между провайдерами?
2. Нужен ли сложный state graph?
3. Нужны ли built-in handoffs/guardrails/sessions?
4. Это реально multi-agent system или один агент с tools?
5. Насколько команда готова платить abstraction tax?

У нас coding agent для внутреннего monorepo, MCP tools, repo edits и approval policy. Что смотреть первым?

Проверьте себя