# Субагенты и оркестрация

← [Раздел](README.md) · [Главная](../README.md)

## Цель

Научиться **координировать** несколько агентов: последовательные и параллельные workflow, типичные пайплайны ECC.

## Предварительно

- [Что такое agents](chto-takoe-agents.md)
- [Ментальные модели](../01-vvedenie-v-ai/mentalnye-modeli.md) — модель «оркестратор»

## Время

**60–90 минут**

---

## Проблема контекста

Один агент на задаче «спроектируй, реализуй, протестируй, поревьюй, обнови docs»:

- переполняет context window;
- смешивает роли (architect + coder + reviewer);
- теряет детали из начала чата.

**Решение:** декомпозиция + **субагенты** с узкими промптами.

---

## Базовый pipeline (feature)

```mermaid
sequenceDiagram
  participant U as Вы
  participant P as planner
  participant D as Dev Agent
  participant T as tdd-guide
  participant R as code-reviewer
  U->>P: Epic description
  P-->>U: Plan + phases
  U->>D: Phase 1 only + @files
  D->>T: (optional) tests first
  T-->>D: Test scaffold
  D-->>U: Implementation diff
  U->>R: Review diff
  R-->>U: Findings
  U->>D: Fix HIGH/CRITICAL
```

Вы — **точка принятия решений** между фазами.

---

## Параллельная оркестрация

Независимые задачи — **параллельно** (ECC common-agents: ALWAYS parallel Task):

| Поток A | Поток B |
|---------|---------|
| security-reviewer на auth/ | explore на legacy module |
| typescript-reviewer | doc-updater на README |

**Условие:** нет конфликта файлов (git worktrees / разные папки).

ECC `tmux-worktree-orchestrator` — продвинутый паттерн для parallel instances (раздел 13).

---

## Multi-perspective review

Для спорных изменений ECC советует **split role subagents**:

- factual reviewer;
- senior engineer;
- security expert;
- consistency checker.

Не один «super-reviewer», а 2–4 узких прогона — меньше blind spots.

---

## Iterative retrieval pattern

Когда субагенту нужен большой codebase:

1. Широкий `explore` — список кандидатов.
2. Узкий dev-agent с 3–5 `@` файлами.
3. Reviewer только на diff.

Skill ECC `iterative-retrieval` формализует это.

---

## Observer и continuous learning (обзор)

ECC `continuous-learning-v2`:

- hooks наблюдают сессию;
- извлекают **instincts** → будущие skills;
- observer agents с guard от loops.

Для курса 06 достаточно знать: оркестрация **не только в момент задачи**, но и **между сессиями** через hooks (раздел 07).

---

## Антипаттерны оркестрации

| Плохо | Хорошо |
|-------|--------|
| Planner + dev + review в одном чате | Три сессии/субагента |
| Два dev-агента правят одни файлы | Worktree или sequential |
| Reviewer без diff | Явный scope: branch / files |
| Игнор CRITICAL от security | Stop the line |

---

## Шаблон промпта для оркестратора (вы)

```markdown
Роль: я оркестратор. Ты — dev agent только для Phase 2 из плана ниже.

План (от planner):
[paste]

Scope Phase 2:
- @src/feature/x
- Do not touch y

После завершения — STOP. Review будет отдельным subagent.
```

---

## Council pattern (ECC skill)

Skill **`council`** — четыре «голоса» для ambiguous decisions. Используйте до больших commits, не для каждого typo.

---

## Практика: мини-оркестрация

На учебном репо:

1. Poprosite planner: «Plan adding health check endpoint» (Plan mode или planner subagent).
2. Выполните **только шаг 1** dev-agent.
3. code-reviewer на diff.
4. Запишите: сколько контекста сэкономили vs monolithic chat.

---

## Метрики оркестрации

| Метрика | Зачем |
|---------|-------|
| Time to green CI | Качество pipeline |
| CRITICAL после review | Эффективность reviewer |
| Parallel wall time | Окупаемость parallel |
| Rework iterations | Качество planner/dev handoff |

---

## Самопроверка

1. Зачем три фазы вместо одного чата?
2. Когда parallel Task оправдан?
3. Что делает explore перед dev?
4. Когда использовать council?

## Дальше

→ [Выбор модели и режимов](vybor-modeli-i-rezhimov.md)