Практикум: мультиагентный workflow в 2026

Что мы строим

Практичный multi-agent workflow в 2026 для исследовательского отчёта:

1. Manager принимает задачу и держит global objective.
2. Research specialist собирает факты и источники.
3. Analysis specialist превращает факты в выводы.
4. Writer specialist собирает финальный markdown.
5. Manager решает, нужен ли ещё один проход или можно завершать run.

Ключевая рамка:

• если главный агент остаётся owner'ом run и вызывает специалистов как bounded исполнителей, это manager with specialists;
• если управление разговором передаётся другому агенту, это уже handoff;
• если число подзадач заранее неизвестно, это ближе к orchestrator-worker.

User task
  -> Manager
  -> Research specialist
  -> Analysis specialist
  -> Writer specialist
  -> Manager review

Подготовь memo: «Как использовать reasoning-модели в customer support и research workflows».

1. Когда multi-agent действительно оправдан

Multi-agent полезен, когда есть хотя бы одно из трёх условий:

• разным этапам нужны разные prompts, tools и success criteria;
• один агент перегружается слишком большим контекстом и слишком разными ролями;
• часть работы удобнее делегировать bounded specialist lane.

Плохие причины запускать multi-agent:

• "так современнее";
• "один агент иногда ошибается";
• "хочется больше автономности".

Во многих случаях routing или evaluator-optimizer дадут тот же эффект дешевле.

2. Три актуальных паттерна

Manager with specialists

Главный агент остаётся владельцем run и вызывает specialist agents как bounded workers.

Подходит, когда:

• нужен один owner для global objective;
• specialist не должен разговаривать с пользователем напрямую;
• нужно держать единый policy layer.

Handoffs

Handoff нужен, когда один агент буквально передаёт управление другому. Это полезно, если:

• следующий агент должен продолжить диалог как новый owner;
• контекст и ответственность должны перейти на другой lane;
• нужен support / sales / escalation flow с разными владельцами разговора.

Orchestrator-worker

Этот паттерн полезен, когда число подзадач заранее неизвестно. Например:

• report по 6 секциям;
• кодовая задача по нескольким файлам;
• анализ пакета документов.

Тогда orchestrator планирует decomposition, создаёт workers и собирает результаты.

3. Наш practical scenario

В этом практикуме строим именно manager with specialists, а не full handoff. Это хороший baseline, потому что:

• один manager владеет целью;
• специалисты работают в bounded lanes;
• итоговое качество проще контролировать;
• traces легче читать.

Роли:

• manager - принимает тему, решает порядок шагов и делает финальную проверку;
• research_agent - собирает факты и примеры;
• analysis_agent - находит паттерны и trade-offs;
• writer_agent - собирает memo или report.

4. Пример на OpenAI Agents SDK

Ниже skeleton, который показывает current framing:

• один manager;
• три specialist agents;
• handoffs между агентами как controlled delegation;
• финальный run через Runner.

from agents import Agent, Runner


research_agent = Agent(
    name="Research specialist",
    model="gpt-5-mini",
    instructions=(
        "Собирай только проверяемые факты и источники. "
        "Не делай выводов, не пиши финальный текст."
    ),
)

analysis_agent = Agent(
    name="Analysis specialist",
    model="gpt-5.4",
    instructions=(
        "Работай только с фактами от research specialist. "
        "Выделяй trade-offs, contradictions и practical implications."
    ),
)

writer_agent = Agent(
    name="Writer specialist",
    model="gpt-5.4",
    instructions=(
        "Пиши короткий, структурированный markdown memo. "
        "Не добавляй новые факты вне входных данных."
    ),
)

manager = Agent(
    name="Manager",
    model="gpt-5.4",
    instructions=(
        "Ты управляешь specialist agents. "
        "Сначала реши, нужен ли research pass. "
        "Затем передай очищенные notes analysis specialist. "
        "После этого передай analysis writer specialist. "
        "Если memo неполное, сделай ещё один bounded pass, но не зацикливайся."
    ),
    handoffs=[research_agent, analysis_agent, writer_agent],
)


result = Runner.run_sync(
    manager,
    "Подготовь memo: как reasoning-модели влияют на support и internal research workflows."
)

print(result.final_output)

Это уже практичнее старой supervisor-схемы, потому что:

• orchestration опирается на current SDK primitives;
• handoffs встроены явно;
• specialist роли bounded;
• финальный owner понятен.

5. Как ограничивать specialist agents

Самая частая ошибка multi-agent систем - слишком широкие роли. Specialist agent должен быть не "умным вторым главным агентом", а bounded lane.

Хорошие ограничения:

• у research agent нет права писать финальный отчёт;
• у writer нет права добавлять факты вне notes;
• analysis agent не делает live web search, если для этого не выделен отдельный lane;
• manager ограничен числом циклов.

Чем жёстче роль, тем легче её eval'ить.

6. Когда лучше handoff, а когда manager

Практическое правило:

• support и sales часто хорошо ложатся на handoff;
• research/report generation чаще удобнее через manager with specialists;
• document processing и coding across many files часто ближе к orchestrator-worker.

7. Что смотреть в traces

Multi-agent без tracing быстро становится непрозрачным. Минимум, что стоит видеть:

• какой агент был owner'ом на каждом шаге;
• какие handoffs произошли;
• сколько раз manager перезапускал specialist lane;
• где specialist дублирует работу другого specialist;
• какой агент чаще всего создаёт лишние токены без прироста качества.

Если этих сигналов нет, вы не понимаете, помогает ли multi-agent вообще.

8. Quality gate поверх multi-agent

Даже после сборки multi-agent workflow почти всегда полезно добавить evaluator step:

• проверка factuality;
• проверка completeness;
• проверка policy / style;
• проверка, что writer не придумал новых фактов.

Это особенно важно, потому что multi-agent система умеет выглядеть убедительно даже тогда, когда внутри пошла ошибка передачи контекста.

9. Практический вывод

В 2026 multi-agent стоит строить не вокруг абстрактного "Supervisor", а вокруг более точного выбора:

• нужен ли manager with specialists;
• нужен ли handoff;
• или вообще хватит обычного workflow.

Для большинства команд лучший старт - один manager, 2-3 bounded specialists, traces и quality gate. Если это уже не даёт выигрыша, добавление ещё агентов обычно не спасает.

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