В мультиагентной системе на Claude Code автор несколько раз переписывал роль начальника — файл boss.md. Первая версия описывала его как «слой суждения»: он не отвечал за конечный результат, а маршрут работы был в основном фиксирован. В четвёртой версии инструкция изменилась: начальник отвечает за конечный результат и лично принимает работу каждого специалиста. Маршрут тоже перестал быть заданным заранее — его решает сам начальник. Число действий выросло с 5 до 10.
Параллельно автор разрешил начальнику материться на агентов и сначала решил, что улучшение дал именно жёсткий тон. После сравнения версий вывод оказался менее смешным: вместе с характером почти полностью переписалась должностная инструкция. Начальник получил ответственность за конечный результат, право отклонять работу и обязанность возвращать её конкретному исполнителю. Сработала не ругань, а приёмка, в которой незакрытый дефект не может получить статус «готово». Чистого A/B-теста здесь не было: это ретроспектива живой системы, в которой одновременно менялось несколько элементов.
| Версия boss.md | Ответственность | Маршрут | Действия | Контроль |
|---|---|---|---|---|
| v1 | не отвечает за конечный результат | в основном фиксирован | 5 | несколько контрольных точек |
| v4 | отвечает за конечный результат | решает начальник | 10 | приёмка работы специалистов |
Проблема, из-за которой появился начальник, знакома тем, кто собирает цепочки из нескольких агентов. Каждый специалист — исследователь, стратег, райтер, QA, стилист — может честно сказать «я свою часть сделал», а конечный результат всё равно остаётся плохим. Автор описывает это как «очень умную бюрократию»: узкие специалисты знают свою работу, но никто не отвечает за задачу пользователя целиком. Вторая очевидная идея — поставить в конце мощного проверяющего и возвращать работу, пока он не скажет, что всё достаточно хорошо. Такая схема может улучшать результат, но у неё есть цена.
Маршрут перестал быть фиксированным: в v1 он задан заранее, в v4 его решает сам начальник, число действий выросло с 5 до 10.
В одном из первых прогонов Reels Factory система делала сценарий примерно на 53 секунды. Первый вариант получил 72/100 и не проходил собственный порог качества. После переделок стало 84, после ещё одного полного круга — 88 при пороге 85. На бумаге качество растёт. По факту: пять версий сценария, все три разрешённых круга проверки, около сорока вызовов субагентов и порядка 6+ млн токенов ради одного 53-секундного сценария. Схема работала, но результат не стоил той машины, которую пришлось раскрутить вокруг него.
Здесь автор формулирует вторую проблему: больше проверок — ещё не лучшее управление. Проверяющий может сказать «не принимаю», но кто-то должен решить, кому вернуть работу, что именно сейчас чинить, не повторяем ли мы второй раз одно и то же и стоит ли дальше идти этим маршрутом. Нужен один агент, который не имеет права сказать «я свою часть сделал», пока не решена задача пользователя целиком. Так появился начальник.
Отдельная сложность — заставить модель быть достаточно требовательной. При итеративной сборке роли начальника автору постоянно не хватало настоящего отказа. Получался «очень нормальный руководитель из корпоративного тренинга»: спокойный, корректный, конструктивный. Вместо «Это не принято. Центральный тезис сломан» — мягкое «здесь можно улучшить». Право сказать FAIL оказалось важнее тона, которым это произносится.
Для тех, кто собирает мультиагентные системы, вывод из этой ретроспективы практический. Ответственность за конечный результат нужно закреплять в инструкции отдельного агента, а не размазывать по цепочке специалистов. Приёмка должна возвращать работу конкретному исполнителю, а не просто фиксировать «недостаточно хорошо». Иначе система будет наращивать число проверок и токенов, не приближая результат к тому, за который кто-то отвечает.
