EvolCode
треки/ИИ-агенты·01 / 07
12 мин чтения

Когда дробить задачу на подагентов — а когда не надо

Тренд 2026 — «команды AI-агентов»: один планирует, второй пишет, третий проверяет. Звучит круто, но в реальной жизни мультиагентная архитектура часто хуже одного хорошего агента. Больше LLM-вызовов = дороже. Больше шагов = медленнее. Больше точек коммуникации = выше шанс что что-то перепутается. Разбираемся когда мульти-агенты дают плюс, а когда это карго-культ.

Базовый принцип — не дробить пока не больно

Простое правило: один агент с 10 инструментами почти всегда лучше 5 агентов с 2 инструментами каждый. Причины: (1) общий контекст — один агент видит всю картину, мульти-агенты передают друг другу резюме и теряют детали; (2) дешевле — не дублируешь системный промпт между LLM-вызовами; (3) надёжнее — меньше точек отказа. Дробить начинаешь когда ОДИН из этих симптомов: контекст не помещается, специализация требует разных промптов, или нужна параллельность.

Паттерн 1: Orchestrator + Workers

Главный агент-оркестратор получает задачу, разбивает на подзадачи, передаёт подагентам, собирает их результаты, формирует финальный ответ. Подагенты не знают друг о друге, общаются только с оркестратором. Когда подходит: задача параллелится (анализ 10 PDF-ов одновременно), или подзадачи требуют разной специализации (один пишет SQL, другой пишет тексты). Минусы: orchestrator должен заранее знать что делать (плохо для исследовательских задач), и сборка результатов — отдельный навык.

Паттерн 2: Planner + Executor

Сначала агент-планировщик расписывает план: 1. Сделать X. 2. Если результат Y, то Z. И т.д. План кладётся в текстовом виде. Дальше агент-исполнитель идёт по плану, выполняет каждый пункт. Иногда между ними сидит «критик» который сомневается в плане. Когда подходит: задача с длинной последовательностью шагов, где важно не сбиться (миграция БД, аудит безопасности). Без планера обычный агент может уйти в дебри. С планером он держится дороги.

Паттерн 3: Specialist agents

Несколько агентов с РАЗНЫМИ системными промптами под разные роли. Маршрутизация решает к кому идти — либо роутер-агентом, либо классификатором (faster-cheaper модель типа Haiku). Когда подходит: разные задачи требуют диаметрально разных правил (агент техподдержки vs агент продаж: разный тон, разные инструменты, разная политика возвратов). Минусы: маршрутизатор может ошибиться, и тогда на запрос про возврат деньги отвечает агент продаж который не знает политику.

Антипаттерны — чего не делать

Мульти-агентные косяки которые вижу регулярно: (1) «AI swarm» из 7 агентов которые «обсуждают» решение — стоит в 7 раз дороже одного агента, при этом качество как у одного. (2) Агент-критик который судит по принципу «ну всегда что-то да исправим» — наводит шум вместо пользы. (3) Передача через JSON между агентами с потерей нюансов — лучше передавать фрагменты исходного контекста чем сжатые JSON-резюме. (4) Цикл «обсуждения» без явного стоп-условия — два агента могут переписываться часами. Всегда фиксируй max rounds.

примерtypescript
import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic();

// Worker — анализирует один документ независимо
async function analyzeDocument(doc: { title: string; content: string }) {
  const r = await client.messages.create({
    model: 'claude-haiku-4-5-20251001', // дешёвая модель
    max_tokens: 1024,
    system: 'Ты аналитик. Кратко суммаризируй документ в 3-5 пунктах.',
    messages: [
      { role: 'user', content: `Документ "${doc.title}":\n\n${doc.content}` },
    ],
  });
  const text = r.content.find((c: any) => c.type === 'text')?.text ?? '';
  return { title: doc.title, summary: text };
}

// Orchestrator — раздаёт документы воркерам параллельно, собирает результаты
async function summarizeMany(docs: { title: string; content: string }[]) {
  // 1. Параллельный fan-out
  const summaries = await Promise.all(docs.map(analyzeDocument));

  // 2. Финальный синтез умной моделью
  const synthesis = await client.messages.create({
    model: 'claude-sonnet-4-6',
    max_tokens: 2048,
    system: 'Ты главный аналитик. Найди общие темы и противоречия между документами.',
    messages: [
      {
        role: 'user',
        content: `Резюме ${docs.length} документов:\n\n${
          summaries.map(s => `# ${s.title}\n${s.summary}`).join('\n\n')
        }\n\nНайди общие темы и противоречия.`,
      },
    ],
  });

  return synthesis.content.find((c: any) => c.type === 'text')?.text ?? '';
}

// Использование:
// const result = await summarizeMany([
//   { title: 'Q1 report', content: '...' },
//   { title: 'Q2 report', content: '...' },
//   { title: 'Q3 report', content: '...' },
// ]);

Простой Orchestrator+Workers — параллельный анализ нескольких документов

главное
  • 01Один агент с правильными инструментами почти всегда лучше пяти агентов. Дроби только при явном симптоме: переполнение контекста, нужна разная специализация, или параллельность даёт скорость.
  • 02Паттерн Orchestrator+Workers рулит когда задача параллелится. Воркеры на Haiku, оркестратор на Sonnet — экономит деньги.
  • 03Planner+Executor для длинных последовательностей шагов где важно не сбиться. План — текстовый, executor по нему идёт.
  • 04Specialist agents — когда роли диаметрально разные (поддержка vs продажи). Иначе один агент с большим промптом справится.
  • 05Без max_rounds мульти-агентные обсуждения уходят в бесконечность. Всегда фиксируй потолок.
проверь себя
01Когда мультиагентная архитектура реально нужна?
02В Orchestrator+Workers — кого посадить на дорогую модель?
03Главная проблема цикла «обсуждения» между двумя агентами?
следующий урок: Цикл агента — что происходит внутри