Статьи
Хватит бездумного fan-out: четырёхуровневая архитектура оркестрации на Claude Haiku 5.5 на практике
Claude Haiku 5.5 быстрый и дешёвый, но если параллельно скормить ему все задачи подряд, вы лишь усилите ошибочные суждения, предвзятость оценщика и риски Supply Chain. В статье разбирается многоуровневая архитектура: решение Fable, оркестрация Opus, реализация Sonnet и Haiku, проверка в CI, приёмка Opus — и какие задачи действительно стоит отдавать в fan-out.
· 1 мин чтения
Claude Haiku 5.5 вышел 7 октября 2026 года. При промпте до 100 тысяч токенов он стоит в двадцать раз дешевле Sonnet 5.5, а по задержке это самая быстрая модель Claude текущего поколения.
Дёшево и быстро — отсюда легко возникает соблазн: разбить все coding-задачи на части, параллельно бросить их стае Haiku, и дело сделано.
На прототипе это, возможно, и сработает. В реальной инженерной среде вы быстро упрётесь в три проблемы:
- Маленькие модели плохо справляются с неоднозначностью. Официальное позиционирование Haiku 5.5 — массовые задачи с низкой задержкой: классификация, извлечение, маршрутизация и subagent. Когда в требованиях есть бизнес-неопределённость и нужен контекст всей системы, он легко выдаёт результат, который выглядит законченным, но на деле угадан не в ту сторону.
- Когда модель выбирает ответ, возникает предвзятость оценщика. Если отдать большой модели на чтение несколько десятков результатов, она склонна выбирать вариант, у которого «красивая архитектура», а не тот, чья логика и исполнение действительно верны.
- Права растут вместе с числом Worker. Если параллельным subagent разрешено самим устанавливать пакеты или менять конфигурацию, то с N Worker вы получаете N потенциальных точек входа для вредоносных пакетов.
Поэтому я перешёл на многоуровневую оркестрацию (Hierarchical Orchestration): каждый уровень делает только то, что умеет, а параллелизм Haiku используется лишь там, где он действительно нужен.
Сначала вывод: Fable отвечает за то, чтобы всё продумать, Opus — за распределение и приёмку, Sonnet — за основную реализацию, а Haiku занимается только механическими задачами и поисковыми задачами, результат которых можно проверить автоматически. Кандидаты сначала проходят CI, и только потом их смотрит модель.
Четыре уровня: суждение, оркестрация, проверка, приёмка#
Входящее требование
│
▼
【Уровень суждения】Fable: архитектурные решения, разбиение задач, критерии приёмки
│
▼
【Уровень оркестрации】Opus Main Session: только распределяет, заново не разбивает
├─► Путь A: сложно, но границы чёткие ──► реализация Sonnet
├─► Путь B: механические задачи ──► один Haiku
├─► Путь C: поисковые задачи, много решений ──► несколько Haiku, каждый в своём Git Worktree
│
▼
【Уровень проверки】Build, Type Check, Test, Benchmark (для пути C остаются только 2–3 лучших)
│
▼
【Уровень приёмки】Opus сводит результат по критериям приёмки
при неудаче — эскалация: Haiku исправляет 2 раза и всё равно неудача ➔ Sonnet ➔ возврат к Opus
Какую модель на какой уровень поставить, определяется официальным позиционированием и ценой. Ниже — данные из официальной документации Anthropic на 8 октября 2026 года; цены указаны в долларах США за миллион токенов:
| Модель |
Официальное позиционирование |
Задержка |
Цена Input / Output |
| Claude Fable 5.1 |
Сложные рассуждения и длительная агентная работа |
Выше |
$10 / $50 |
| Claude Opus 5.5 |
Длительный agentic coding и работа со знаниями |
Средняя |
$4 / $20 |
| Claude Sonnet 5.5 |
Лучшее сочетание скорости и возможностей |
Быстро |
$2 / $10 |
| Claude Haiku 5.5 |
Массовые задачи с низкой задержкой: классификация, извлечение, маршрутизация и subagent |
Самая быстрая |
от $0.10 / $0.50 |
У Haiku 5.5 цена двухступенчатая: если промпт превышает 100 тысяч токенов, она становится $0.50 / $2.50.
Уровень суждения: Fable отвечает за архитектурные решения и критерии приёмки#
Не каждому требованию нужен Fable. Это самый дорогой и самый медленный уровень, и я подключаю его, только когда требование неоднозначно, затрагивает интеграцию нескольких систем или нужно принять ключевое архитектурное решение.
Fable должен выдать три вещи:
- проектное решение
- разбиение на задачи
- критерии приёмки (Acceptance Criteria) для каждой подзадачи, которые можно проверить тестами
Рассуждение и разбиение должен выполнять один и тот же уровень. Только тот, кто сумел продумать слепые зоны системы, способен выделить подзадачи с чистыми границами; если архитектуру отдать A, а разбиение — B, определение интерфейсов обычно размывается.
Исключение — задачи по безопасности. У всех моделей Claude текущего поколения есть классификаторы безопасности, и когда запрос блокируется, возвращается stop_reason: "refusal"; легитимная работа по безопасности тоже может быть заблокирована по ошибке. Классификатор Fable 5.1 охватывает большую часть тем информационной безопасности, и, по официальным пояснениям, модель не предназначена для этой области; Opus 5.5 же разрешает искать уязвимости в исходном коде. Поэтому для требований вроде исправления уязвимостей предварительный анализ я сразу отдаю Opus.
Уровень оркестрации: Opus только распределяет, заново не разбивает#
Opus — это Main Session, он отвечает за маршрутизацию и раздачу работы. На этом уровне архитектуру не пересматривают и второго разбиения не делают.
- Путь A, сложно, но границы чёткие: задачи со сложной логикой, но с уже чётко определёнными границами интерфейсов отдаются Sonnet. Это основная рабочая лошадка реализации.
- Путь B, простые механические задачи: шаблонный код (Boilerplate), переименование переменных, простые юнит-тесты, дополнение документации — один Haiku.
- Путь C, поисковые задачи и оптимизация: настройка производительности, разные варианты сложного SQL или Regex, поиск причин Flaky Test — вот тогда запускается Fan-out: несколько Haiku, каждый в отдельном Git Worktree, пробуют разные решения.
Какой бы путь ни был выбран, результат должен пройти уровень проверки.
Уровень проверки: сначала машина, потом модель#
Очень распространённая практика — отдать весь параллельно полученный код Opus или Sonnet и попросить проверить его через промпт.
Проблема в том, что при чтении кода модель легко поддаётся ответам с аккуратным форматированием и полными объявлениями типов, а это не значит, что они прошли граничные тесты. Поэтому кандидаты сначала проходят машинный фильтр:
- Build и Type Check: компилируется, типы корректны
- Unit / Integration Tests: юнит- и интеграционные тесты проходят
- Benchmark / Profiling: измерение производительности и памяти
Не прошедшие автоматические тесты сразу отсеиваются. Из кандидатов пути C Opus смотрит только 2–3 лучших, прошедших проверки и показавших лучшие метрики, что заодно экономит context window и токены.
Уровень приёмки: Opus сводит результат, при неудаче — эскалация вверх#
В конце Opus сводит результат по критериям приёмки, определённым на уровне суждения. Когда Worker застревает, происходит эскалация вверх по цепочке (Escalation Path):
- Haiku не справился: после 2 автоматических исправлений проверка всё ещё не пройдена — повторные попытки прекращаются.
- Исправление берёт на себя Sonnet.
- Если и Sonnet не проходит приёмку, это обычно означает противоречие в разбиении задачи или в исходных допущениях. Задача возвращается Opus, и тот решает, нужно ли отправить её обратно Fable на повторное разбиение.
Три правила перед выходом в продакшен#
Не делайте fan-out вслепую#
Простым задачам несколько Worker не нужны, а сильно неоднозначные задачи маленькая модель не решит. Запускать несколько Haiku параллельно стоит только для поисковых задач, у которых «пространство решений велико» и которые «можно быстро проверить автоматическими тестами».
Изолируйте среду, фиксируйте Lockfile#
Git Worktree изолирует изменения кода, чтобы параллельные Worker не перезаписывали файлы друг друга; он не ограничивает сеть и не ограничивает то, к чему программа может получить доступ. Для защиты от Supply Chain Attack нужен ещё и sandbox, а также запрет Worker самостоятельно устанавливать непроверенные пакеты или менять Lockfile. Если вольно раздавать права на установку, Agent сможет затащить в репозиторий пакеты и скрипты неизвестного происхождения.
Принимайте по измеренным данным, а не по отзывам модели#
Результаты тестов, покрытие, потребление памяти и задержка — вот воспроизводимая и сопоставимая основа. Текстовой оценкой модели можно руководствоваться, но принимать по ней качество кода нельзя.
Дешёвые модели нужно использовать к месту#
Haiku 5.5 делает параллелизм дешёвым, но сам по себе параллелизм не делает результат верным. Сначала разделите суждение, распределение, проверку и приёмку — тогда дешевизна и скорость превратятся в настоящее преимущество.
Эта многоуровневая схема — по сути тот самый Graph, о котором я писал в статье AI Agent — это на самом деле гибкая agile-команда: кто делает первым, кому передаёт после завершения, куда переправляет при проблемах.