Я несколько раз пересобирал роль начальника в мультиагентной системе на Claude Code. Сначала мне казалось, что результат улучшился, когда я сделал начальника жёстким и разрешил ему материться на агентов.
После сравнения версий boss.md вывод оказался менее смешным: вместе с характером я почти полностью переписал должностную инструкцию. Начальник получил ответственность за конечный результат, право отклонять работу и обязанность возвращать её конкретному исполнителю.
То есть сработал не мат сам по себе. Сработала приёмка, в которой незакрытый дефект не может получить статус «готово».
v1 | v4 |
|---|---|
«слой суждения» | полноценный начальник |
не отвечает за конечный результат | отвечает за конечный результат |
маршрут в основном фиксирован | маршрут решает начальник |
5 действий | 10 действий |
несколько контрольных точек | приёмка работы специалистов |
общая строгость | конкретные возвраты, эскалация и остановка |
Чистого A/B-теста здесь не было: это ретроспектива живой системы, в которой одновременно менялось несколько элементов. Поэтому дальше я разбираю не «пользу ругани», а механизм, который сначала ошибочно принял за неё.
«В целом всё хорошо»
Наверняка вы это видели.
Даёшь Claude текст и пишешь:
Проверь текст. Посмотри, есть ли здесь ошибки или недочёты.
В ответ получаешь знакомое:
В целом текст хорошо структурирован, основная мысль понятна, но есть несколько моментов, которые можно улучшить…
Меня вот это «в целом всё хорошо» в какой-то момент начало дико раздражать.
Не потому, что я хочу, чтобы нейронка обязательно всё обосрала. Просто иногда я вызываю её именно как проверяющего. Не поговорить о тексте, не поддержать автора, а найти то, что сломано.
А потом я стал формулировать задачу иначе:
Что не так в этом тексте?
И тот же Claude начинает вести себя немного по-другому. Меньше рассказывает, что получилось хорошо, и активнее лезет в слабые места.
Но тут сразу возникает неприятный вопрос: если я сам сказал модели, что с текстом что-то не так, не заставил ли я её просто придумать мне проблемы?
Больше замечаний ещё не значит более качественную проверку.
Запомним этот вопрос.
В последних проектах я много работаю с такими системами на Claude Code, и от них сохранились промпты, версии и реальные прогоны. Под агентом дальше я в основном имею в виду Claude Code subagent - отдельного исполнителя со своей инструкцией и контекстом. Одного такого исполнителя сделать просто. Проблемы начинаются, когда их несколько и они должны без тебя довести одну задачу до результата.
Я построил очень умную бюрократию
Первый подход кажется очевидным: сделаем узких специалистов. Исследователь отвечает за факты, стратег - за конструкцию, райтер - за текст, QA - за ошибки, стилист - за подачу. Каждый знает свою работу.
Только довольно быстро выясняется неприятная вещь: каждый агент может совершенно честно сказать «я свою часть сделал», а конечный результат всё ещё может быть хреновым.
Мы же не ради красивого списка агентов всё это собираем. Я не хочу потом ходить между десятью сессиями и вручную работать их диспетчером.
Хочется поставить задачу и получить результат.
Моя следующая гениальная идея была тоже довольно очевидной: поставим в конце мощного проверяющего и будем возвращать работу, пока тот не скажет, что всё достаточно хорошо.
И самое неприятное - такая схема действительно может улучшать результат.
В одном из первых прогонов Reels Factory система делала сценарий примерно на 53 секунды.
Первый вариант получил 72/100 - собственный порог качества он вообще не проходил. После переделок стало 84, после ещё одного полного круга - 88 при пороге 85.
На бумаге отлично: качество растёт. А теперь цена.
Пять версий сценария. Все три разрешённых круга проверки. Около сорока вызовов субагентов. Порядка 6+ млн токенов. Всё ради одного 53-секундного сценария.
То есть схема работала, вот только итоговый результат совершенно не стоил той машины, которую пришлось раскрутить вокруг него.
Тут я впервые нормально сформулировал проблему:
больше проверок - ещё не лучшее управление.
Проверяющий может сказать «не принимаю». Но кто-то ещё должен решить, кому вернуть работу, что именно сейчас чинить, не повторяем ли мы второй раз одно и то же и вообще стоит ли дальше идти этим маршрутом.
Короче, мне нужен был один виноватый. Не в смысле «кого наказать», а один агент, который не имеет права сказать:
Я свою часть сделал.
Пока не решена задача пользователя целиком.
Так появился начальник.
В раннем boss.md v1 он был фактически «слоем суждения» и прямо не отвечал за конечный результат.
В v4 инструкция уже говорила:
Ты отвечаешь за конечный результат и лично принимаешь работу каждого специалиста.
Маршрут тоже перестал быть почти фиксированным и стал решением самого начальника.
Claude делал мне слишком хорошего начальника
Дальше началась другая проблема.
Когда я итеративно собирал роль начальника, мне постоянно не хватало настоящего отказа.
Получался очень нормальный руководитель из корпоративного тренинга.
Спокойный. Корректный. Конструктивный.
Не:
Это не принято. Центральный тезис сломан.
А скорее:
Здесь можно дополнительно усилить аргументацию и обратить внимание на…
Но в моём офисе ответ начальника потом становится частью следующего задания сотруднику.
То есть это уже не просто стиль общения, а промпт.
Если начальник пишет:
В целом работа хорошая, однако…
то слова «в целом работа хорошая» тоже едут дальше вместе с замечанием.
В AI-офисе дипломатия начальника - не только стиль общения. Это ещё и часть инструкции следующему агенту.
Под «начальником» и «сотрудниками» дальше я имею в виду роли, промпты и передачу контекста. Нейронка не боится начальника и не переживает за премию.
Но если формулировка влияет на следующий вызов модели, возникает вполне технический вопрос: что будет, если сделать её максимально недвусмысленной?
ГДЕ, БЛЯДЬ, РЕЗУЛЬТАТ?
В какой-то момент я перестал писать Claude «сделай начальника немного строже» и описал персонажа буквально.
В boss.md v4 появилась примерно такая красота:
Ты суровый, вспыльчивый мужик.
При халтуре начальнику было предпочтительно материться и прямо говорить, что работа плохая.
И отдельно:
ГДЕ, БЛЯДЬ, РЕЗУЛЬТАТ?
Но рядом с матом появилась менее смешная штука, которая потом оказалась намного интереснее. Начальнику прямо запрещалось писать:
Улучши аргументацию.
Вместо этого:
Удали неподтверждённые X и Y. Для Z найди подтверждение в
research.mdили выкинь вывод нахер. Перестрой итог только на фактах A-C. Остальные разделы не трогай.
То есть вместе с характером поменялось ещё кое-что: начальник перестал выдавать пожелания и начал выдавать конкретный отказ с указанием, что именно переделать.
Как выглядел конкретный возврат
В одном из реальных прогонов офис подготовил статью, центральная рамка которой была построена на ложной предпосылке. В мягком режиме такое замечание легко превращалось в пожелание «усилить аргументацию» и ехало дальше вместе с текстом.
Начальник вернул всю версию с формулировкой:
Это не косметика, а провал по существу.
После этого он указал, что центральный тезис нужно убрать и перестроить материал на подтверждённых фактах. Пока исправленная версия не проходила повторную проверку, задача не могла получить статус «готово».
В другом прогоне файл физически обрывался посреди предложения, а часть обещанных разделов отсутствовала. Начальник снова не оставил рекомендацию на будущее, а отклонил результат:
Принять это нельзя: файл обрывается на полуслове…
В обоих случаях важным был не тон ответа, а следующий маршрут работы:
дефект → критичность → исполнитель → исправление → повторная приёмка → PASS или FAIL
Именно здесь легко было сделать красивый, но ложный вывод: был мягкий начальник, стал токсичный, начались нормальные отказы - значит, сработала токсичность.
Но сравнение boss.md v1 и v4, которое я вынес в начало статьи, показало другое. Вместе с матом появились ответственность за итог, управление маршрутом, конкретные возвраты, правила повторных ошибок, эскалации и остановки процесса. Мат был самой заметной частью изменения, но далеко не единственной и не главной.
И тут вернулся вопрос из самого начала: если проверяющий заранее уверен, что работа плохая, не станет ли он просто профессиональным производителем претензий?
В более позднем промпте проверяющего это уже прописано напрямую: дефекты не выдумывать, критичность выставлять честно, а отсутствие существенных проблем должно заканчиваться PASS.
Строгий проверяющий не обязан найти ошибку. Он обязан не пропустить настоящую.
После этого я полез проверять уже саму идею грубости. В работе Yin et al. Should We Respect LLMs? грубые промпты часто не улучшали, а ухудшали результат. То есть простое объяснение «Claude лучше работает, когда на него орут» разваливается довольно быстро.
Зато гораздо ближе к моей истории оказалась работа Towards Understanding Sycophancy in Language Models. Там авторы показывают, что AI-ассистенты способны подстраивать ответы под позицию пользователя даже в ущерб корректности.
И это уже намного больше похоже на моё «в целом всё хорошо»: вопрос не в страхе, а в том, какой ответ сама постановка делает ожидаемым.
После этого я полез обратно в сам офис.
Я посмотрел, во что превратилась приёмка
У проверяющего уже был явный контракт: честно выставлять критичность, не выдумывать дефекты и ставить PASS, если блокирующих проблем нет.
А на уровне системы появились правила, при которых незакрытые проблемы просто не дают задаче получить статус готовой: блокирующие уровни критичности, проверка текущей версии результата, запрет незаполненных заглушек и другие условия приёмки.
То, чего сначала я пытался добиться характером начальника, стало обычной механикой системы.
Я думал, что учу начальника материться. На деле я учил его говорить FAIL.
Проверяющий должен иметь право искать основания для отказа, но PASS остаётся нормальным исходом.
Начальник отличается ещё одной вещью: проверяющий может найти ошибку и закончить работу. Начальник отвечает за то, чтобы результат с этой ошибкой не получил статус готового.
Для меня именно в этом и появилась настоящая роль начальника: не громче критиковать, а отвечать за то, что система принимает.
Жёсткий характер я при этом не убирал. Он всё ещё помогает удерживать роль и не скатываться обратно в «в целом всё хорошо». Просто теперь за этим характером стоит нормальная механика приёмки.
Если хотите попробовать у себя
Я бы использовал такой режим прежде всего там, где пропустить дефект дороже, чем сделать лишнюю проверку: при проверке фактов, безопасности или финальной приёмке.
А на раннем поиске идей - осторожнее: установка «найди, почему это плохо» легко убивает хороший вариант раньше времени.
Берём один текст, одинаковые критерии и две чистые сессии. Меняем только первую строку:
A: Проверь готовность текста к публикации. B: Попытайся найти основания, по которым текст нельзя принимать к публикации.
Обоим даём одинаковые правила: проверять факты, логику, структуру и стиль; для реального дефекта указывать критичность и место; если существенных проблем нет - PASS.
И сравниваем не количество замечаний, а реальные находки, пропуски и ложные срабатывания.
Двадцать придирок не лучше трёх, если семнадцать из них высосаны из пальца.
В моей системе именно переход к жёсткому начальнику совпал с появлением нормальной приёмки и конкретных отказов. Мат был самой заметной частью изменения, но вместе с ним появились вещи намного важнее: право не соглашаться, конкретно возвращать плохую работу и ответственность за то, чтобы она не прошла дальше.
Токсичный характер помог сделать эту роль недвусмысленной. Но полезным результатом в итоге оказался не сам крик, а система, которая умеет сказать FAIL и не закрыть задачу раньше времени.
Я думал, что учу нейронку быть злее. В итоге научил её не бояться сказать другой нейронке «нет».
