AGINE Guides

Мультиагентные системы

Один Claude — ассистент. Несколько Claude — команда.

Агент = Claude с доступом к инструментам и чётко поставленной ролью. Когда задача слишком большая для одного контекста или требует параллельной работы — оркестратор запускает специалистов. Вот как это устроено.

Для кого этот гайд

Это про Claude Code — терминальный инструмент (claude.ai/code). Агенты запускаются через Task tool внутри сессии. Если только начинаешь — сначала фишки Claude Code или 10 шагов настройки.

Что такое агент

Роль + инструменты + изолированный контекст.

Роль

Чётко описанная задача: «ты code-reviewer, проверяешь только security и стиль». Не «сделай всё».

Инструменты

MCP-серверы, bash, файловая система — то что нужно именно этому агенту. Не весь стек подряд.

Изоляция

Агент работает в своём контексте. Не засоряет главный. Возвращает только summary результатов.

# Почему агенты, а не один большой промпт

  • Параллельность — code-architect и code-explorer работают одновременно. Скорость как у одного, глубина как у двух.
  • Специализация — агент с ролью «security reviewer» находит уязвимости лучше, чем «посмотри на код в целом».
  • Контекст под контролем — каждый агент несёт только свой контекст. Главный агент не раздувается от промежуточных результатов.
  • Независимая верификация — разные агенты могут проверить одно решение с разных углов без предвзятости первого ответа.

4 базовых паттерна

Каждая система — комбинация этих четырёх.

Orchestrator + Specialists

Orchestrator ├── Specialist A (параллельно) ├── Specialist B (параллельно) └── Specialist C (параллельно) ↓ summary x3 Orchestrator синтезирует → результат

Когда: основной паттерн для большинства задач. Один агент раздаёт работу, собирает результаты.

Пример: /feature-dev: orchestrator запускает code-architect + code-explorer параллельно, потом code-reviewer.

Каждый specialist видит только свою задачу — не знает о других. Orchestrator синтезирует всё.

Pipeline (последовательный)

Agent A ↓ output A Agent B (получает output A) ↓ output B Agent C (получает output B) ↓ финальный результат

Когда: когда каждый шаг зависит от предыдущего. Нельзя параллелить.

Пример: /smm: trend-researcher → content-writer → art-director → publisher. Каждый берёт результат предыдущего.

Pipeline медленнее параллели, но неизбежен когда output A = input B.

Verifier (двойная проверка)

Writer Agent ↓ черновик Reviewer Agent (независимый) ↓ замечания Writer Agent (финальный pass) ↓ результат

Когда: критические задачи где первый черновик нельзя отдать без проверки. Security, финансы, публичный контент.

Пример: Генерация документации → независимый reviewer проверяет точность → writer исправляет.

Reviewer не видит process, только результат. Избегает confirmation bias оркестратора.

Fan-out (массовая обработка)

Orchestrator ├── Agent(item_1) ─→ result_1 ├── Agent(item_2) ─→ result_2 ├── Agent(item_3) ─→ result_3 └── Agent(item_N) ─→ result_N ↓ Orchestrator агрегирует

Когда: один и тот же тип задачи применяется ко многим элементам. Перевод, рефакторинг N файлов, генерация контента для N платформ.

Пример: Локализация на 5 языков: 5 агентов параллельно, каждый берёт оригинал и переводит.

Самый большой выигрыш по скорости. N задач за время одной.

Как используем в AGINE

Реальные цепочки, не теория.

/smm

Pipeline

trend-researcher → content-writer → art-director → publisher

Почему так: Контент нельзя параллелить: тема выбирается до написания, визуал — после текста.

/feature-dev

Orchestrator + Specialists

code-architect + code-explorer (параллельно) → code-reviewer

Почему так: Архитектуру и исследование кода можно делать одновременно. Ревью — только после написания кода.

/review

Fan-out

security-agent + performance-agent + style-agent (параллельно)

Почему так: Три угла ревью независимы. Нет смысла ждать результатов security перед style.

Explore agent

Orchestrator + Specialist

main → Explore(поиск по codebase) → main получает summary

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

Как построить свою систему

Пять вопросов перед стартом.

  • 01

    Что повторяется каждый день?

    Начни с задачи которую делаешь вручную регулярно. Агенты = ROI только на повторяющихся задачах.

  • 02

    Шаги зависят друг от друга?

    Да → Pipeline. Нет → Fan-out или Orchestrator+Specialists. Это определяет архитектуру.

  • 03

    Нужна независимая проверка?

    Критический результат (публикация, деплой, финансы) — добавь Verifier agent. Он не видел процесс и не предвзят.

  • 04

    Что каждый агент должен знать?

    Минимальный контекст. Не давай код всего проекта агенту который проверяет только один файл.

  • 05

    Как оркестратор получает результат?

    Каждый subagent возвращает только summary — не полный контекст. Иначе main-контекст раздувается.