Microsoft Agent Framework чи LangGraph: як обрати runtime

Microsoft Agent Framework варто перевіряти першим, коли команда хоче спільний SDK для agents, harnesses і типізованих workflows, має AutoGen або Semantic Kernel estate, потребує Microsoft ecosystem integrations чи кількох model providers через одну agent surface. LangGraph варто перевіряти першим, коли головною вимогою є явний довгий stateful process із мінімально нав’язаною agent architecture, granular graph control, persistence, interrupts і replay. Це гіпотези для однакового prototype, а не рейтинг продуктів.

Порівняння не є симетричним. Microsoft Agent Framework охоплює model clients, agent sessions, middleware, MCP, готові orchestration patterns і workflow runtime. LangGraph позиціонує себе як low-level orchestration runtime; agent loops, prompts та integrations команда може брати з LangChain або будувати сама. Якщо задачу надійно виконує функція чи звичайний job orchestrator, обидва варіанти можуть бути зайвою складністю.

• AutoGen/Semantic Kernel migration або Microsoft-integrated stack → почніть з Agent Framework.
• Bespoke durable state machine і контроль transitions → почніть з LangGraph.
• Deterministic business process → лишіть звичайний workflow обов’язковим baseline.

Agent Framework розділяє agent і workflow. Agent дає моделі динамічно обирати tools і наступні кроки; workflow з’єднує agents та звичайні functions через executors, edges, conditions і events. Graph API підтримує fan-out/fan-in та type-validated message routing, а Python також має experimental functional API з native control flow. Готові sequential, concurrent, handoff, group-chat і magentic patterns прискорюють prototype, але не доводять, що multi-agent coordination потрібна задачі.

LangGraph StateGraph починається з application-defined state, nodes і edges. Він не абстрагує prompt або agent architecture, тому команда явно вирішує, де працює deterministic code, де model, як оновлюється state і чому завершується цикл. Subgraphs ізолюють підпроцеси. Такий контроль корисний для bespoke workflow, але команда успадковує відповідальність за state schema, reducers, routing, termination і сумісність кожного node contract.

Agent Framework graph виконується supersteps і може створювати checkpoint після завершення superstep. Документація описує executor state, pending messages, requests/responses і shared state у checkpoint; functional workflow кешує результати на межах steps. LangGraph checkpointer зберігає snapshot graph state у thread, а pending writes дозволяють не перезапускати успішні parallel nodes, якщо інший node того самого superstep впав. Ці деталі перевіряйте на обраній мові, storage adapter і runtime.

Checkpoint не є transaction log зовнішньої системи. Якщо node створив invoice або ticket, а process упав до durable transition, resume може повторити дію в обох frameworks. Write tool має приймати idempotency key, повертати authoritative operation ID і підтримувати read-after-write reconciliation. У checkpoint зберігайте schema, framework і workflow versions та references; order, entitlement і payment залишайте в domain system of record.

Agent Framework реалізує HITL через request/response у workflow, approval-required tools і checkpointed requests. LangGraph interrupt зберігає state та повертає керування reviewer-у до resume через Command. Важлива runtime-різниця LangGraph: після resume node виконується від початку, тому side effects перед interrupt повинні бути idempotent. Для Agent Framework окремо протестуйте межу superstep, pending request і повтор executor-а після failure.

Жоден pause primitive не видає business authority. Approval record прив’язується до authenticated actor, tenant, resource, exact payload hash, tool version, scopes, expiry та свіжих preconditions. Перед write після resume policy перевіряється повторно. Model, document або agent message не можуть розширити permission через текст; policy outage для consequential action завершується fail-closed terminal state.

Agent Framework має agent abstractions, sessions, context providers, middleware, MCP clients і documented providers, серед яких Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic та Ollama. Це зручно, якщо команда хоче один Microsoft-oriented application layer і готовий шлях від AutoGen або Semantic Kernel. Проте provider interface не гарантує однакові structured outputs, parallel tools, streaming, safety settings, retries або usage accounting.

LangGraph лишає model і tool layer модульним: його часто поєднують із LangChain integrations, але graph може викликати власні clients і services. Це зменшує coupling до одного agent API, водночас збільшуючи integration surface. Для обох створіть ModelProfile і ToolContract з capability flags, data region, timeout, schema, idempotency та explicit unsupported state замість тихого fallback до тексту.

Microsoft називає Agent Framework прямим successor AutoGen і Semantic Kernel та підтримує migration guides. Це сильна причина включити його в shortlist для наявного Microsoft agent estate. Але migration не слід змішувати з greenfield comparison: спочатку зафіксуйте agents, teams або plugins, message types, termination, state, models, middleware, telemetry та deployment bindings старої системи.

Перенесіть один read-only slice в Agent Framework і доведіть behavioral parity на незмінному corpus. Окремо реалізуйте той самий TaskContract у LangGraph. Якщо одночасно замінити framework, model, prompt і tools, attribution буде неможливою. Старий route залишається rollback path до verified cutover; in-flight state проходить explicit migration, а не завантажується в новий runtime навмання.

Agent Framework має middleware, events і telemetry surfaces; Microsoft ecosystem може спростити identity, hosting та operations для вже стандартизованої команди. LangGraph є open-source runtime, тоді як LangSmith додає tracing, evaluation і managed deployment. Порівнюйте library та hosted platform окремо: package не визначає IAM, network, region, retention, queueing, scaling або exit behavior production середовища.

Зберігайте framework-neutral RunEvent: task/run ID, tenant, framework і workflow revision, active executor або node, state version, model, tool fingerprint, policy verdict, usage, latency, retry, checkpoint ID, terminal reason і verified outcome. Traces можуть містити PII, secrets і retrieved content, тому до pilot перевірте redaction, sampling, tenant isolation, retention, export і telemetry outage. Trace пояснює trajectory, але не засвідчує correctness.

Візьміть 30–50 representative cases як engineering corpus, не як універсально достатню статистичну вибірку. Побудуйте read-heavy flow `intake → retrieve → draft → policy check → human review`. Prototype A використовує мінімальний Agent Framework graph; prototype B — мінімальний LangGraph StateGraph. Залиште однаковими model де можливо, tools, fixtures, budgets, TaskContract, PolicyDecision і acceptance rubric.

Інжектуйте malformed tool result, prompt injection, parallel-node failure, timeout до і після side effect, process restart, incompatible checkpoint, expired approval, credential revocation, telemetry outage і non-terminating loop. Вимірюйте verified completion, severe errors, duplicate actions, recovery time, corrections, operator load, latency і full cost per accepted outcome. Feature count та кількість рядків prototype не є production KPI.

Rollout: offline replay → shadow → read-only canary → bounded reversible writes. Promotion потребує нуль unauthorized actions, відтворюваного resume, terminal-state SLO та rollback drill. Виконайте exit test: зупиніть нові runs, reconcile in-flight work і продовжте один task через framework-neutral contracts. Capability snapshot перевірено 2026-08-24; перед рішенням повторіть тест на pinned versions.

Обирайте Agent Framework як першого кандидата, якщо потрібні agents і workflows в одній surface, typed routing, готові orchestration patterns, middleware, Microsoft integrations або контрольована міграція з AutoGen і Semantic Kernel. Обирайте LangGraph, якщо graph runtime є ядром продукту, команда хоче явно володіти architecture, потрібні thread checkpoints, interrupts, subgraphs, replay і тонкий контроль recovery.

Обирайте простіший workflow, якщо модель виконує лише один вузький крок або шлях повністю детермінований. Остаточне рішення має пояснювати state ownership, authority, failure semantics, deployment boundary, повну операційну вартість і exit path. Саме failure-tested proof, а не бренд чи feature matrix, показує відповідність вашому task shape.