Оркестр ролей: как один чат превращается в бригаду специалистов

01Зачем это вообще нужно

Порода проблем тут не в модели, а в контексте: в одной длинной беседе рядом живут домен logoakademia, вёрстка doctorneiro, сертификаты и PHP-блог. Каждая новая тема стартует среди чужих фактов, а поиск по 30 файлам съедает окно и деньги.

• Точность. Ребёнку даётся узкая инструкция: «ты QA, проверяешь по факту, ничего не правишь, вот формат отчёта». Меньше свободы — меньше выдумок.
• Чистота моего контекста. В субагенте остаются все 40 шагов чтения файлов и команд; мне возвращается итог на 20 строк. Длинная работа перестаёт пухнуть.
• Параллельность. Правку вёрстки и проверку чисел PageSpeed можно вести одновременно, а не по очереди.
• Повторяемость. Бриф — файл. Он одинаков в понедельник и в пятницу, его можно править, а не вспоминать, «как я в прошлый раз просил».

02Три механизма, которые легко перепутать

«Сделай несколько профилей» на практике означает три разные вещи. Они не заменяют друг друга, и путаница тут стоит денег и часов.

03Что сделано сейчас

Скилл role-orchestra с шестью брифами и таблицей маршрутизации. Бриф — не характер, а рабочий документ: что роль делает, чего не делает, чем проверяет и в каком виде сдаёт.

Таблица маршрутизации

Три правила, которые важнее таблицы

• Одна тема — одна роль. «Поправь меню и проверь на телефоне» — это две разные работы: правит frontend, проверяет qa.
• Простое не делегируется. Один файл, один вопрос, одна команда — делаю сам. Ребёнок стоит отдельной беседы.
• Ребёнок ничего не знает о нашем разговоре. Всё нужное — пути, хосты, имена учёток, что уже проверено, чего не трогать — уходит в задание текстом. Пароли не уходят никогда: только имя файла, где они лежат.

# так выглядит отправка: бриф роли + факты по задаче
delegate_task(tasks=[{
  "goal": "Сжать превью в списке статей, не меняя пропорции",
  "context": бриф_frontend + "\n--- ЗАДАЧА И ФАКТЫ ---\n" + пути_и_запреты
}])

04Как это выглядит в работе

Пример из реальной жизни: «на телефоне в статье пропало меню». Раньше это шло в общий чат и я смешивал догадки с фактами. Теперь так:

1. Смотрю, за что отвечает тема: меню и адаптив — frontend.
2. Отдаю ему бриф и факты: адрес страницы, какой шаблон, что уже проверено, запрет трогать шапку и размеры значков.
3. Рядом, отдельным ребёнком, qa проверяет результат на 320/390/768 — он ничего не правит, поэтому не «подгоняет» проверку под свою же правку.
4. Ко мне приходят два коротких отчёта: что изменено и с какими доказательствами. Я проверяю сам — файл на месте, ширина страницы равна ширине окна.

05Фаза 2: разные модели по темам

Здесь начинается то, о чём обычно и говорят: «девопсу — одну нейросеть, писателю — другую». В обычном режиме Hermes пин модели глобальный: настройка delegation.model задаёт одну модель для всех детей сразу, и у отдельной задачи нет параметра «работай вот этой моделью». Значит по-ролевые модели — это отдельное включение, тремя разными способами.

Заготовки лежат в скилле и не включены: файл с опциями ролей (templates/delegation-model-map.yaml) и скрипт создания профилей (templates/setup-profiles.sh). Ничего из этого не запускалось, плагин не установлен, чужие модели не подключены.

06Цена и ограничения

Оркестр — не бесплатное улучшение. Чего он стоит и чего он не умеет:

• Токены. Каждый ребёнок — отдельная беседа: свой системный промпт, свои шаги. Пять субагентов на мелкую задачу дороже, чем сделать её самому.
• Ребёнок не может спросить. Уточняющий вопрос он не задаст — только вернёт результат или провал. Недостающее либо кладётся в задание, либо спрашиваю вас заранее.
• Не переживает перезапуск. Делегирование живёт внутри процесса: закрыли Hermes — фоновая работа пропала. Для долгого — доска или планировщик.
• Параллельность — не бесконечная. До 10 детей одновременно по конфигу, но здравый смысл — 2–3: больше параллельных бесед дороже и труднее принимать.
• Разные модели ≠ точнее. Бриф роли даёт больше, чем смена нейросети. Вторая модель имеет смысл, когда у неё есть сильная сторона: длинный код, зрение, дешёвая рутина.

07Что осталось и что не вышло

Честно о том, чего нет:

• Плагин advanced-delegation не установлен — по вашему «пока не подключай». Значит маршрутизация «роль → своя модель» ещё не проверена на живой чужой модели.
• Ключ сейчас один — Ollama Cloud. Разные модели технически возможны, но пока в пределах одного провайдера; настоящий «девопс на одной нейросети, писатель на другой» начнётся, когда появится второй провайдер или локальная модель.
• Профили-роли не создавались: их нельзя создать «просто так», каждый требует своей настройки ключей и скиллов, иначе он будет глупее меня, а не специализированнее.
• Автоматического выбора роли по тексту задачи нет: роль выбираю я по таблице. Это осознанно — автоматика пока путает «ускорь сайт» (analytics или frontend?) чаще, чем помогает.

Открытые вопросы к вам:

• Нужен ли отдельный седьмой бриф «1С» (сейчас интеграции с 1С лежат в backend)?
• Какие модели под какие роли, когда будет второй провайдер — или оставить всё на одной и включать фазу 2 только ради дешёвой рутины у qa?
• Делать ли доску для долгих работ (перенос сайта, массовое развёртывание) — там перезапуск не убивает работу.

08Чек-лист, если делать у себя

• Написать 5–6 брифов: что роль делает, чего не делает, чем проверяет, в каком виде сдаёт. Без «делай хорошо» — с критерием.
• Сделать таблицу маршрутизации: признаки в тексте задачи → роль. Спорные темы разобрать отдельно, по корню проблемы.
• Договориться, что простое не делегируется, а результат ребёнка всегда проверяется фактом.
• В задание ребёнку класть: бриф, абсолютные пути, хосты, имена учёток, что уже проверено, чего не трогать, формат ответа.
• Пароли — только имена файлов, где они лежат. Ни в брифе, ни в задании, ни в отчёте.
• Фазу 2 включать по одной роли, а не всю сразу: сначала дешёвая рутина (проверки) на быстрой модели, посмотреть, не стало ли хуже.
• Проверить первые 2–3 делегации глазами: отчёт, файлы, реальный результат — и только потом доверять автоматике.