Когда выбирать LangGraph vs CrewAI vs AutoGen для мульти-агентных систем?

LangGraph для продакшен stateful workflows с human-in-the-loop и персистентностью. CrewAI для быстрых role-based прототипов за 1-2 дня. AutoGen на Microsoft/Azure stack при многораундовых дебатах агентов.

Зачем деплоить мульти-агентную оркестрацию на Mac cloud вместо laptop или Linux VPS?

Cursor и Claude Desktop требуют нативные macOS STDIO подпроцессы и launchd uptime 7×24. Laptops засыпают; Linux VPS без macOS Host совместимости. Узлы VPSMAC Mac cloud дают bare-metal macOS с PostgreSQL checkpointing и OpenTelemetry tracing.

Мульти-агентная AI-архитектура на практике: паттерны проектирования, фреймворки и продакшен-гид (2026)

Q: В чём разница MCP и A2A в мульти-агентной архитектуре?

MCP — вертикальный слой: Agent к внешним tools, БД и API. A2A — горизонтальный слой: делегирование задач и discovery возможностей через Agent Cards и JSON-RPC 2.0. Оба под Linux Foundation Agentic AI Foundation в 2026.

Если один LLM-агент упирается в лимиты контекста, сериальную латентность или каскадные галлюцинации при масштабировании—нужна оркестрация, а не более крупная модель. Этот гид для AI-инженеров, backend-архитекторов и tech leads, выпускающих агентные системы в 2026. Вы изучите шесть паттернов оркестрации, матрицу LangGraph vs CrewAI vs AutoGen, dual-протокольный стек MCP+A2A, observability, пять продакшен-ловушек (включая LangGraph defer=True parallel sync), 5-шаговый Runbook и цитируемые бенчмарки AdaptOrch и Agent Bake-Off Google.

Ключевые боли: почему монолитные агенты ломаются при масштабировании

Потолки context window. Сложные задачи заполняют контекст; качество reasoning падает; ошибки handoff накапливаются незаметно.
Размывание «мастера на все руки». Один агент для retrieval, code и audit не делает ничего хорошо—и не обновляется по ролям без переписывания цепочки.
Сериальная латентность без параллелизма. Общая латентность — сумма шагов; независимые sub-задачи не параллелятся без явной оркестрации.
Single point of failure и невидимые ошибки. Плохой model call останавливает workflow; галлюцинации каскадируют при HTTP 200 и зелёных dashboards.

1. Почему одного агента недостаточно

«Монолитный агент»—один LLM для reasoning, routing и execution—обманчиво легко прототипировать и хрупок в продакшене при любой значимой нагрузке. Проблемы структурные, а не модельные.

Потолки context window — Сложные задачи заполняют контекст и ухудшают reasoning.
Проблема «мастера на все руки» — Агент для retrieval, code и audit не делает ничего особенно хорошо.
Нет параллелизма — Sequential execution: общая латентность = сумма латентностей шагов.
Single point of failure — Один плохой model call роняет весь workflow.

Мульти-агентные архитектуры — ответ. Внутренний Agent Bake-Off Google (гид MLflow 2026) показал: декомпозированные мульти-агентные архитектуры сократили время обработки с часа до десяти минут—ускорение 6×—с независимо обновляемыми sub-агентами.

AdaptOrch (2026) формально доказал: топология оркестрации—как вы компонуете и координируете агентов—сильнее влияет на performance системы, чем выбор модели, давая 12–23% на coding, reasoning и RAG бенчмарках.

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

2. Что такое мульти-агентная система?

Мульти-агентная система (MAS) — набор независимых AI-агентов, сотрудничающих через определённые протоколы и механизмы оркестрации для задач, которые один агент не справится эффективно.

Свойство	Значение
Single-responsibility	Одна чётко определённая роль: retrieval, reasoning, generation, validation
Tool-equipped	Доступ к tools, нужным для роли
State-isolated	Собственный context и memory, без загрязнения других агентов
Replaceable	Независимо обновляемый при появлении лучших моделей

Три топологии управления

Centralized                    Decentralized               Hierarchical

   [Orchestrator]               A ←→ B ←→ C              [Top Orchestrator]
  /      |      \                  ↕       ↕               /            \
[A]    [B]    [C]               D ←→ E ←→ F         [Team Lead-1]  [Team Lead-2]
                                                      /    \           /    \
Плюсы: auditable, controllable  Плюсы: resilient, fast  [a] [b]        [c] [d]
Минусы: bottleneck at center     Минусы: hard to debug
                                                     Плюсы: balances both

3. Шесть паттернов оркестрации

Эти шесть паттернов покрывают подавляющее большинство продакшен-систем. Понимание, когда какой применять — ключевой архитектурный навык agentic AI engineering.

Паттерн 1: Sequential Pipeline

Идея: выход Agent A становится входом Agent B. Строго линейное выполнение.

[User Input] → [Retrieval Agent] → [Analysis Agent] → [Writer Agent] → [Review Agent] → [Output]

Когда: строгие зависимости между шагами; фиксированный предсказуемый workflow без dynamic routing. Кейсы: content pipelines, compliance review, обработка документов.

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

class PipelineState(TypedDict):
    query: str
    retrieved_docs: str
    analysis: str
    final_report: str

def retrieval_agent(state: PipelineState):
    docs = search_knowledge_base(state["query"])
    return {"retrieved_docs": docs}

def analysis_agent(state: PipelineState):
    result = llm.invoke(f"Analyze the following: {state['retrieved_docs']}")
    return {"analysis": result.content}

def writer_agent(state: PipelineState):
    report = llm.invoke(f"Write a report based on: {state['analysis']}")
    return {"final_report": report.content}

builder = StateGraph(PipelineState)
builder.add_node("retriever", retrieval_agent)
builder.add_node("analyzer", analysis_agent)
builder.add_node("writer", writer_agent)
builder.add_edge(START, "retriever")
builder.add_edge("retriever", "analyzer")
builder.add_edge("analyzer", "writer")
builder.add_edge("writer", END)
pipeline = builder.compile()

Плюсы	Минусы
Просто реализовать и отлаживать	Общая латентность = сумма латентностей шагов
Предсказуемое поведение	Сбой одного шага блокирует всё downstream
Легко аудировать	Не поддерживает dynamic branching

Паттерн 2: Parallel Fan-Out / Fan-In

Идея: несколько независимых sub-агентов работают параллельно. Collector агрегирует результаты. Общая латентность — max(T1, T2, ..., Tn) вместо T1 + T2 + ... + Tn.

                    ┌──→ [Research Agent A] ──┐
[Supervisor] ───────├──→ [Research Agent B] ──┼──→ [Synthesizer] → [Output]
                    └──→ [Research Agent C] ──┘

Когда: sub-задачи действительно независимы; критично снижение латентности. Кейсы: multi-source research, параллельная оценка рисков, конкурентный анализ.

from langgraph.types import Send
from typing import TypedDict, Annotated
import operator

class ResearchState(TypedDict):
    query: str
    research_results: Annotated[list, operator.add]
    final_synthesis: str

def supervisor(state: ResearchState):
    return [
        Send("research_worker", {"query": state["query"], "source": "academic"}),
        Send("research_worker", {"query": state["query"], "source": "industry"}),
        Send("research_worker", {"query": state["query"], "source": "news"}),
    ]

def research_worker(state: dict):
    result = search_by_source(state["query"], state["source"])
    return {"research_results": [result]}

Деталь: API Send LangGraph dispatchит sub-графы с реальной параллельностью. Reducer Annotated[list, operator.add] автоматически сливает результаты параллельных веток—без ручных locks.

Паттерн 3: Hierarchical Supervisor-Worker

Идея: supervisor-агент распознаёт intent, декомпозирует задачи и роутит. Специализированные workers выполняют. Synthesizer агрегирует результаты.

           [User Request]
                ↓
         [Supervisor Agent]  ← Plans tasks and routes
        /         |         \
[Code Agent] [Search Agent] [Data Agent]
        \         |         /
         [Synthesizer Agent]
                ↓
           [Final Output]

Двухуровневый routing (keyword fast path + LLM fallback):

KEYWORD_ROUTING = {
    "code": "code_agent", "debug": "code_agent",
    "search": "search_agent", "find": "search_agent",
    "data": "data_agent", "analyze": "data_agent",
}

def supervisor_with_fast_path(state):
    query = state["query"].lower()
    for keyword, agent_name in KEYWORD_ROUTING.items():
        if keyword in query:
            return {"next": agent_name}  # <1ms, no LLM call
    decision = llm.invoke(f"Route this request: {state['query']}")
    return {"next": decision.content.strip()}

Паттерн 4: Swarm (peer-to-peer)

Идея: агенты передают задачи напрямую без центрального координатора. Остановка по правилу терминации (раунды, консенсус, timeout).

Когда: многораундовые переговоры и дебаты (code review, оценка proposals). Осторожно: высокая недетерминированность—большинство swarm-кандидатов в итоге иерархичны. В продакшене — редко.

groupchat = autogen.GroupChat(
    agents=[human_proxy, reviewer_1, reviewer_2],
    messages=[],
    max_round=6  # Hard termination cap — always required
)

Паттерн 5: Blackboard Architecture

Идея: все агенты делят структурированный workspace. Читают/пишут на blackboard автономно при выполнении preconditions—без явного scheduling.

Когда: долгие асинхронные задачи (часы–дни); гетерогенные сервисы разных команд; сложные условные workflows без pre-routing.

                    ┌─────────────────────────────────────┐
                    │           Blackboard (Доляd State)  │
                    │  task_status: "research_done"        │
                    │  research_data: { ... }              │
                    │  analysis_result: null               │
                    └──────┬─────────────────────┬────────┘
                           ↑ writes              ↓ reads (when precondition met)
                    [Research Agent]          [Analysis Agent]

Паттерн 6: Hybrid

Идея: комбинировать несколько паттернов. Частый hybrid: supervisor plus pipeline—иерархический routing сверху, sequential execution в каждой ветке.

[User Request] → [Intent Router]
      ├──→ [Simple query] → Direct answer
      └──→ [Complex report] → [Supervisor]
         /                              \
[Parallel Research Fan-Out]    [Quality Pipeline: Review → Human Approval → Publish]
  ↙      ↓      ↘
[A]    [B]    [C]  →  [Synthesizer]

4. Сравнение фреймворков: LangGraph vs CrewAI vs AutoGen

Измерение	LangGraph	CrewAI	AutoGen (Microsoft)
Architecture model	State machine graph	Role-based crews	Conversation-based groups
Languages	Python / JS/TS	Python	Python / .NET
Learning curve	Steep	Gentle	Moderate
Native state management	Yes	Limited	Limited
Human-in-the-loop	Native `interrupt()`	Custom implementation	Supported
Observability	LangSmith (commercial)	Limited	Azure Monitor
Production readiness	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐
Prototyping speed	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
Azure/Microsoft stack	⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐
Best for	Complex stateful workflows	Role-based content pipelines	Conversational multi-agent

LangGraph когда: нужна продакшен-надёжность (регулируемые отрасли), сложный state management и persistence, fine-grained human-in-the-loop checkpoints, conditional branches и dynamic routing.

CrewAI когда: рабочий прототип за 1–2 дня, команда мыслит «агентами с должностями», низкая сложность state management.

AutoGen когда: Microsoft/Azure stack и нужны многораундовые дебаты агентов через conversation.

LangGraph наиболее готов к продакшену для workflows с надёжностью, observability и human oversight. Детерминированное выполнение графа, native persistence и LangSmith tracing — стандарт для регулируемых отраслей.

5. Dual-протокольный слой: MCP + A2A

В 2026 мульти-агентная коммуникация стандартизировалась вокруг двух дополняющих протоколов под Linux Foundation Agentic AI Foundation.

┌─────────────────────────────────────────────────────────┐
│                   Multi-Agent System                    │
│    Agent-1 ←────── A2A Protocol ──────→ Agent-2        │
│       │                                     │           │
│    MCP Protocol                       MCP Protocol      │
│       ↓                                     ↓           │
│  [Tools / DBs / APIs]            [Tools / DBs / APIs]  │
└─────────────────────────────────────────────────────────┘

MCP (vertical layer): Agent ↔ external tools and data
A2A (horizontal layer): Agent ↔ Agent

Как TCP и HTTP—разные слои одного стека. MCP — руки; A2A — разговор между коллегами.

MCP (Model Context Protocol)

Инициирован Anthropic, под Linux Foundation. MCP стандартизирует доступ агента к внешним tools, БД и API—написать интеграцию раз, любой MCP-совместимый агент использует.

from mcp.server import Server
from mcp.types import Tool, TextContent

app = Server("customer-data-mcp")

@app.list_tools()
async def list_tools():
    return [Tool(name="query_customer_db", description="Query by id, name, or email", ...)]

@app.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "query_customer_db":
        result = db.query(arguments["field"], arguments["value"])
        return [TextContent(type="text", text=str(result))]

A2A (Agent-to-Agent Protocol)

Запущен Google в апреле 2025, v1.0 начало 2026, 50+ партнёров включая Atlassian, Salesforce, SAP. A2A стандартизирует делегирование задач и discovery возможностей через JSON-RPC 2.0 по HTTP. Каждый A2A-агент публикует Agent Card на /.well-known/agent.json.

async def discover_and_delegate(agent_url: str, task: str):
    card = (await httpx.get(f"{agent_url}/.well-known/agent.json")).json()
    skills = [s["id"] for s in card["skills"]]
    if "web_research" not in skills:
        raise ValueError(f"Agent {card['name']} does not support web_research")
    payload = {"jsonrpc": "2.0", "method": "message/send", "id": "task-001",
               "params": {"message": {"role": "user", "parts": [{"type": "text", "text": task}]}}}
    return (await httpx.post(card["url"], json=payload)).json()

6. Продакшен engineering essentials

6.1 Персистентность состояния и recovery

from langgraph.checkpoint.postgres import PostgresSaver

with PostgresSaver.from_conn_string("postgresql://user:pass@localhost/agentdb") as checkpointer:
    graph = builder.compile(checkpointer=checkpointer)
    config = {"configurable": {"thread_id": "user-session-12345"}}
    result = graph.invoke({"query": "Analyze Q2 financial report"}, config)

6.2 Human-in-the-Loop checkpoints

from langgraph.types import interrupt

def high_risk_action_agent(state):
    proposed_action = plan_action(state)
    human_decision = interrupt({
        "proposed_action": proposed_action,
        "risk_level": "HIGH",
        "message": "This action will modify the production database. Confirm to proceed."
    })
    if human_decision["approved"]:
        return execute_action(proposed_action)
    return {"status": "cancelled", "reason": human_decision.get("reason")}

6.3 Circuit Breaker pattern

@CircuitBreaker(failure_threshold=3, recovery_timeout=30)
async def call_external_agent(task):
    return await agent_client.send(task)

6.4 Управление token budget

Неконтролируемые расходы на tokens — частый продакшен-сюрприз. Инструментировать с первого дня: budgets per agent, hard caps и TokenBudgetManager с BudgetExceededException до спирали расходов.

7. Observability: открыть чёрный ящик

Анализ MAST 1 642 multi-agent traces: 57% организаций запускают агентов в продакшене, только 8% завершили observability. Следствие: каскадные галлюцинации, retry loops, зелёные HTTP 200 на dashboards.

Категория	Доля	Что ломается
Ошибки проектирования системы	41.77%	Step repetition, wrong tool selection, context overflow, missing termination
Рассогласование между агентами	36.94%	Context lost at handoffs; one agent's hallucination becomes the next agent's ground truth
Ошибки верификации задач	21.30%	Premature termination, incomplete verification, tasks that look done but aren't

def traced_agent_call(agent_name: str, task: dict, correlation_id: str = None):
    with tracer.start_as_current_span(f"agent.{agent_name}") as span:
        span.set_attribute("agent.name", agent_name)
        span.set_attribute("correlation.id", correlation_id or str(uuid.uuid4()))
        result = agent_registry[agent_name].run(task)
        span.set_attribute("tokens_used", result.get("tokens", 0))
        return result

Ключевые метрики: task_success_rate (цель >85%), e2e_latency_p95 (<30s), cost_per_task, error_rate per agent (alarm >5%), retry_count, качество через LLM-as-Judge.

8. Типичные ловушки и как их избежать

Ловушка 1: Загрязнение контекста (каскадные галлюцинации)

Agent A генерирует галлюцинированный «факт». Неверный output передаётся B и C. Итог строится на ложной предпосылке—каждый HTTP 200. Fix: валидация на каждом handoff: JSON Schema, confidence <0.7, обязательные поля.

Ловушка 2: Бесконечные циклы и взрывные расходы

Агент входит в retry loop или tool-calling spiral. Счёт за задачу с $0.02 до $47. Fix: hard caps—MAX_ITERATIONS = 10, MAX_TOOL_CALLS_PER_AGENT = 20, MAX_TOTAL_TOKENS_PER_REQUEST = 50_000, interrupt_before=["high_cost_tool"].

Ловушка 3: Over-engineering

Простую двухшаговую LLM-цепь дробят на восемь агентов ради «agentic». Правило: начать с sequential pipeline. Добавлять агентов только с измеримыми доказательствами. Sweet spot: 3–8 агентов.

Ловушка 4: Разрыв demo-to-production

Внутреннее demo впечатляет. Через две недели edge cases вызывают каскадные сбои. Fix: guardrails с первого дня—лимиты длины, prompt injection detection, PII redaction, harmful content classification.

Ловушка 5: Игнорирование синхронизации параллельных веток

В LangGraph конкретно: параллельные ветки через Send API. Разная длительность. Supervisor перезапускается до завершения медленных веток—дубликаты и неполные результаты.

Fix — deferred execution:

# The defer=True parameter creates an explicit synchronization barrier.
# The supervisor node won't execute until ALL parallel branches have completed.
builder.add_node("supervisor", supervisor_node, defer=True)

9. Framework принятия решений

Does your task have strict sequential dependencies between steps?
├─ YES → Can any of those steps run in parallel?
│         ├─ NO  → [Sequential Pipeline]
│         └─ YES → [Hybrid: Sequential Pipeline + Parallel Fan-Out]
│
└─ NO  → Does one agent have clear decision-making authority?
          ├─ YES → Does scale require sub-teams?
          │         ├─ NO  → [Supervisor-Worker Hierarchical]
          │         └─ YES → [Hierarchical (Supervisors of Supervisors)]
          │
          └─ NO  → Is the task long-running and async (hours to days)?
                   ├─ YES → [Blackboard Architecture]
                   └─ NO  → Agent count ≤ 5 and termination is well-defined?
                            ├─ YES → [Swarm — with hard round/time limits]
                            └─ NO  → [Refactor into Hierarchical instead]

10. Заключение и что дальше

Ключевые выводы

Топология оркестрации важнее выбора модели. Доказательство AdaptOrch: композиция агентов важнее модели под ними.
Начинать просто, добавлять агентов по необходимости. Sequential pipelines сначала. Лучшие продакшен-системы: 3–8 агентов.
MCP + A2A — emerging standard. Оба протокола под Linux Foundation с широкой поддержкой индустрии.
Observability не опциональна. Разрыв 49 п.п. между агентами в продакшене и реализованной observability — источник счетов $47K.
Каждый agent handoff как versioned API. Schema validation и confidence thresholds на каждой границе предотвращают каскадные сбои.

Тренды 2026

Federated orchestration: команды с независимыми sub-orchestrators, делящими learned routing policies
Multimodal multi-agent systems: vision и audio агенты с text агентами быстро созревают
Adaptive topology selection: системы автоматически выбирают оптимальный паттерн (направление AdaptOrch)
EU AI Act compliance: EU-регуляция требует полных audit trails—traceability на уровне агента обязательна

Пятиступенчатый продакшен Runbook

Шаг 1 — Выбрать топологию и фреймворк

Пройти дерево решений в разделе 9. Начать с sequential pipeline; fan-out или supervisor-worker только при измеримых доказательствах. LangGraph для регулируемого продакшена, CrewAI для прототипов за 1–2 дня.

Шаг 2 — Подключить MCP tools и A2A delegation

Экспонировать tools через MCP Servers. Публиковать Agent Cards на /.well-known/agent.json. Оркестраторы делегируют через JSON-RPC 2.0 message/send.

Шаг 3 — Добавить персистентность и guardrails

Настроить PostgresSaver checkpointing, лимиты TokenBudgetManager, circuit breakers на внешние вызовы, interrupt() перед рискованными DB-записями.

Шаг 4 — Инструментировать observability

Развернуть OpenTelemetry с correlation IDs. Отслеживать task_success_rate, e2e_latency_p95, error rates per agent. LLM-as-Judge sampling для качества и галлюцинаций.

Шаг 5 — Хостить на Mac cloud с launchd

Для STDIO workflows Cursor и Claude Desktop: оркестраторы и MCP Servers на Mac cloud узле с launchd KeepAlive, лимитами ресурсов и PostgreSQL checkpointing 7×24.

Цитируемые факты (2026)

Топология > модель: AdaptOrch (arXiv 2602.16873): 12–23% на SWE-bench и RAG—больше, чем смена модели.
6× throughput: Agent Bake-Off Google (MLflow 2026): время с 1 часа до 10 минут с декомпозированной мульти-агентной архитектурой.
Observability gap: MAST (1 642 traces): 57% запускают агентов, 8% завершили observability; 41,77% сбоев — system design.
Protocol standard: MCP и A2A под Linux Foundation Agentic AI Foundation; A2A v1.0 (2026) — 50+ партнёров включая Atlassian, Salesforce, SAP.

Заключение

Мульти-агентная архитектура больше не эксперимент—это дефолтный паттерн продакшен agentic систем в 2026. Шесть паттернов, стек MCP+A2A и observability дают полный blueprint от прототипа до продакшена.

LangGraph на laptop или Linux VPS валидирует идеи, но sleep, отсутствие macOS STDIO Host и Docker делают 7×24 workflows хрупкими. PostgreSQL checkpointing и OpenTelemetry требуют persistent infrastructure. Командам с Cursor, Claude Desktop и MCP Servers рядом с оркестраторами аренда узла VPSMAC Mac cloud — стабильнее: native macOS, launchd KeepAlive, bare-metal без разрыва demo-to-production.