tekBlueprint

Наверняка многие уже используют различные инструменты для автоматизации своей деятельности, кто-то на L1 ещё, кто-то уже до L5 наверное добрался, но никому не рассказывает. Статья о L3 ➝ L4, полная автоматизация для подобных задач не очень применима, да и смысла нет. Иначе это превратится в очередной блог с нейрослопом и бесконечной лентой статей.

Введение

На этом сайте уже есть старая статья про использование ИИ, но там речь шла о более простых сценариях. Сейчас хочу поделиться опытом организации рабочего процесса с оркестрацией агентов – как это устроено, какие есть паттерны и почему это работает именно так.

Зачем нужна оркестрация?

Один агент, даже самый мощный, имеет свои ограничения:

• Лимит контекстного окна: даже для 256K токенов сложных задач может не хватить, а фокус LLM уже начинает размываться и количество галлюцинаций растёт.
• Есть определённое смешение ответственности (и потеря фокуса как следствие), когда агент делает всё, сложно отследить ошибки, сложно описать инструкции и так далее.
• Универсальный агент или модель хуже решает узкоспециализированные задачи.

Если речь идёт о ведении сайта и его разработки, то тут есть довольно много ручных действий, о которых можно забыть, пропустить или просто иногда не очень хочется делать. Мотивация автоматизации – это большое количество рутинных действий, которые со временем сформировались и выкристаллизовались определённые повторяющиеся шаблоны. Сначала это было организовано в простые навыки (skills), но всё равно требовалась ручная работа. Передача части задач на LLM с их оркестрацией между специализированными агентами решает часть этих проблем. Сейчас вместо набора скиллов и одного универсального агента создаётся команда специализированных агентов, каждый из которых отвечает за свою область.

Основные паттерны оркестрации

В целом было несколько вариантов из которых выбирал.

Паттерн “Супервайзер”

Один центральный агент (оркестратор) принимает все решения и распределяет задачи между исполнителями. Это наиболее распространённый подход, который используется в моём случае.

Паттерн “Конвейер”

Задачи проходят последовательно через цепочку агентов. Результат одного агента становится входом для следующего.

Паттерн “Параллельная обработка”

Несколько агентов работают параллельно над разными частями задачи, после чего результаты агрегируются.

Паттерн “Итеративная оптимизация”

Один агент создаёт черновик, второй его рецензирует, первый исправляет – цикл повторяется до достижения качества. Частично этот вариант тоже используется.

Как это устроено на практике

Гибрид Супервайзер + Итеративная оптимизация – основной процесс идёт через главный оркестратор, который вызывает сабагентов. При этом остаётся человек в цикле, который выполняет финальную ревизию результатов и может отправить на следующую итерацию доработок. Также в автоматическом режиме общаются агент реализации «намерения» и агент, выполняющий ревью результата — здесь цикл автоматизирован без участия человека.

Что даёт такая организация:

• Предсказуемость и прозрачность результатов. Я знаю, какой агент что делает, чего от него ждать.
• Контроль качества на каждом этапе, критические изменения проходят несколько уровней проверки. Плюс есть подтверждение внесений изменений и можно в любой момент всё остановить.
• Можно добавлять новых агентов без разрушения существующего процесса.
• Полная трассировка всех изменений – кто, что, когда и почему.

Две доменные области: CODE и CONTENT

На самом деле оркестраторов два, так как специфика работы отличается. Часть задач связаны чисто с разработкой сайта, а вторая часть с контентом.

Почему разделение критично? Потому что агент, пишущий статью, не должен случайно менять hugo.toml. А агент, работающий со скриптами, не должен трогать frontmatter статей. Плюс снижается размер контекста под правила. Дополнительно есть ещё отдельные навыки(skills) для более специфичной работы, о которых знают агенты.

Если интересует как организованно локальное развёртывание ИИ-моделей для таких задач, то у меня есть отдельная статья про использование локальных моделей в HomeLab. Там подробно описано железо и настройки, которые позволяют запускать несколько моделей одновременно.

CODE Orchestrator

Отвечает за всё, что касается кода сайта. Сначала писал всё вручную, чтобы создать определённый каркас сайта и примеры. Далее на них уже могла опираться LLM и делать по примеру.

Что делегируется:

• Hugo templates и компоненты.
• CSS и стилизация. Аналогично предыдущему пункту.
• JavaScript и клиентская логика.
• Инфраструктура (bash скрипты, CI/CD).
• Конфигурации.

CONTENT Orchestrator

Занимается поддержкой контента. Поначалу некоторые задачи выполнялись вручную, но постепенно процесс был автоматизирован.

Что делегируется:

• Ревью статей, проверка орфографии, пунктуации, соответствия стилю и правилам и так далее.
• Создание технических рецептов на основе готовых набросков и конфигураций — приведение хаотичных материалов в структурированный вид.
• Автоматический перевод (RU ↔ EN). Далеко не всегда хорошо получается, но что есть.
• Создание диаграмм для быстрой визуализации идей с последующей доработкой по принятому в проекте стилю.
• SEO-оптимизация – пробный агент.

Команда агентов

Важный момент, который нужно учитывать: статьи для сайта пишет человек. Ну почти :) Есть статьи, скелет которых был сгенерирован, а потом дописан/переписан (у них есть метка на карточках). Но в общем случае, как сказано ранее, агенты выполняют вспомогательные функции – проверку, перевод, ревью, создание черновиков диаграмм.

Оркестраторы

Это агенты верхнего уровня, которые не реализуют изменения напрямую. Они только планируют, делегируют и контролируют.

Эти оркестраторы используют модели с большим количеством параметров и контекстом, чтобы не попадать на этап сжатия контекста с потерей части информации.

Агенты (код)

Агенты для работы с кодом:

Агенты (контент)

Агенты для работы с контентом:

Здесь работает тот же принцип: оркестраторы и ревьюеры используют мощную модель для качества, а кодинговые агенты – более быструю модель для скорости.

Стандартный процесс

Теперь самое важное – как всё работает на практике. Процесс состоит из пяти фаз, и каждая фаза имеет чёткие правила.

Phase 1: Plan

Всё начинается с планирования. Оркестратор анализирует запрос и определяет, что нужно сделать. Для сложных задач создаётся .spec/FEATURE.md – документ с детализированным описанием требований. Для простых правок достаточно краткого плана. Главное правило: план всегда представляется пользователю до начала реализации. Никаких сюрпризов.

Пример плана:

План: правка опечаток в статье "Homelab AI"

1. Анализ существующего контента в статье
2. Создание спецификации .spec/AI-HOMELAB-FIX.md
3. Запустить content-reviewer для проверки
4. Показать diff для утверждения
5. Применить изменения

Phase 2: Implementation

После утверждения плана запускается специализированный агент через Task tool.

Для задач, связанных с кодом, отчёт может выглядеть так:

Изменения в templates:
- Обновлен layouts/partials/header.html
- Добавлена новая CSS-переменная для акцентного цвета
- Исправлена проблема с mobile menu на Safari

Тестирование:
- Проходит локальная сборка Hugo без ошибок
- Проверено на Chrome, Firefox, Safari

Важно: агент всегда должен возвращать не только результат, но и список изменений и принятых решений. Это помогает на этапе ревью понять, почему было сделано именно так.

Phase 3: Review

Важный этап после реализации изменений. Реализация попадает к ревьюверу, который видит изменения и выполняет двухэтапное ревью:

• Spec compliance – соответствует ли результат спецификации.
• Quality – качество кода/контента, стиль, форматирование.

Reviewer возвращает своё решение: APPROVED, NEEDS CHANGES, или BLOCKED.

Если NEEDS CHANGES – цикл повторяется. Агент вносит правки и снова проходит ревью.

Пример решения от content-reviewer:

Verdict: NEEDS CHANGES

Spec compliance: PASS
- Все разделы из спецификации присутствуют
- Internal links в правильном формате
- Frontmatter соответствует шаблону

Quality: NEEDS IMPROVEMENT
- Paragraphs слишком длинные в секции "Почему оркестрация нужна"
- Нет примеров для некоторых утверждений
- Описание агентов можно дополнить таблицей

Рекомендации:
1. Разбить длинные абзацы на 3-5 предложений
2. Добавить конкретные примеры из опыта
3. Включить таблицу с настройками temperature для разных агентов

Итерация: 1/3 (максимум 3 итерации перед escalation к человеку)

Пример решения от code-reviewer:

Verdict: APPROVED

Spec compliance: PASS
- Изменения соответствуют .spec/FEATURE.md
- Нет изменений в непредусмотренных файлах

Quality: PASS
- Код следует style guide проекта
- Нет security issues
- Добавлены комментарии к сложным участкам
- Тесты проходят успешно

Рекомендации на будущее:
- можно добавить unit tests для новых функций

Цикл итераций должен быть ограничен (в примере тремя попытками). Если после третьей итерации ревью всё ещё NEEDS CHANGES – задача эскалируется к человеку для ручного решения. Это предотвращает бесконечные циклы и задержки.

Phase 4: Human Approval

Здесь человек принимает решение. Оркестратор показывает:

• Полный diff всех изменений (опционально).
• Решение от ревьювера.
• Краткое описание того, что было сделано.

И ждёт явного ответа: yes, no, или revise (отложить).

Никаких автоматических коммитов без утверждения. Это не обсуждается.

Формат отчёта может варьироваться: явного стандарта пока нет, он формируется динамически. Единственный обязательный элемент — блок подтверждения изменений.

Три варианта ответа имеют разное значение:

• yes – изменения утверждаются, переходит к Phase 5 (Commit)
• no – изменения отклоняются, агент получает обратную связь и начинает заново
• revise – изменения сохраняются в staging, но не коммитятся. Можно вернуться позже.

Phase 5: Commit

После утверждения yes:

1. Коммит с conventional commit message:
   Text

   fix(content): исправлена статья об оркестрации ИИ-агентов

2. Удаление .spec/ если был создан файл спецификации
3. Отчёт о commit hash

Небольшой пример полного лога

+ Thought: 837ms

Я выполню ревью этой статьи. Сначала прочитаю файл, чтобы понять его содержимое.

→Read content/blog/ai/ai-orchestration-workflow/index.ru.md 

+ Thought: 910ms

Теперь я прочитаю статью и запущу content-reviewer для профессионального ревью.

✓Content-Reviewer Task -- Review article quality
↳ 2 toolcalls · 2m 46s
ctrl+x down view subagents

+ Thought: 1.5s

Ревью завершено. Вот результаты:
Итоги ревью
Verdict: NEEDS CHANGES
Статья имеет хорошую структуру и полезный контент, но содержит критические орфографические ошибки и проблемы с frontmatter.

---

Критические ошибки (обязательно исправить):

№	Проблема
1	"Ведение" → "Введение"
2	"выкристализовались" → "выкристаллизовались"
3	"повторяющие" → "повторяющиеся"
4	"скилло" → "скиллов"
5	"которой" → "который"
6	Отсутствует точка в конце предложения
7	"по началу" → "поначалу"
8	"как сказал" → "как сказано"
9	"больным" → "большим"
10	Дубликат заголовка "Агенты (код)" → "Агенты (контент)"
11	"кодинг агенты" → "кодинговые агенты"
12	Ссылка /blog/ai/homelab-ai/ (пропущен leading slash)

Frontmatter проблемы:
1. featuredTitle и featuredSubtitle на английском для русской статьи
2. Отсутствует description (SEO мета-описание)
3. Отсутствует author
4. Заголовок слишком короткий (40 символов, рекомендуется 50-60)

Рекомендации:
- Убрать сленг ("нейрослоп", "сабагентов", "фуллстек")
- Унифицировать термины ("оркестратор" vs "координатор")
- Расширить заключение
- Заполнить пустые ячейки в таблицах

Хотите, чтобы я запустил content-reviewer с инструкцией по исправлению этих ошибок?

... ВЫРЕЗАНО ...

Что сохранено без изменений:
- ✅ Frontmatter (не тронут)
- ✅ Сленг ("нейрослоп", "сабагентов", "фуллстек")
- ✅ Пустые ячейки в таблицах

Готово к утверждению

Изменения готовы. Хотите применить? (yes / no / revise)

Заключение

Вот такой небольшой «конвейер» выполнения получился. Цель сильно не усложнять — конечно, можно строить развесистые графы через n8n или Hermes, но хотелось остаться на привычных инструментах. При необходимости агенты и навыки переносятся между различными обвязками (или как там уже набивший оскомину harness переводится :)

Многоуровневое ревью снижает количество ошибок, хотя и не все. Иногда нужно несколько проходов, но это всё равно лучше, чем в одиночку проверять. Самое главное, что есть чёткая последовательность шагов и правил, о которых LLM меньше забывает. И всё ещё сохраняется вовлёчённость человека для принятия решений, что важно.