Почему токсичный промпт для ИИ-начальника оказался менее важен, чем право сказать FAIL
Habr AI · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
Разработчик мультиагентной системы на Claude Code выяснил, что улучшение качества работы агентов связано не с агрессивным стилем общения, а с внедрением строгой механики приёмки. Ключевым фактором стала возможность начальника отклонять результат и запрещать закрытие задачи при наличии дефектов.
Ценность: Статья демонстрирует практический подход к управлению мультиагентными системами, где качество результата зависит от архитектурных ограничений и логики валидации, а не от эмоциональной окраски промптов. Это помогает разработчикам избегать ложных выводов о влиянии тональности на производительность LLM.
В процессе оптимизации мультиагентной системы на базе Claude Code автор столкнулся с типичной проблемой: отдельные специалисты честно выполняли свои части, но итоговый результат оставался некачественным. Изначально казалось, что решение кроется в усилении роли проверяющего. Однако анализ версий конфигурации boss.md показал, что вместе с изменением характера начальника была переписана вся должностная инструкция. Агент получил ответственность за конечный результат, право отклонять работу и обязанность возвращать её конкретному исполнителю. Таким образом, ключевым механизмом стала не агрессия, а приёмка, при которой незакрытый дефект блокирует статус «готово».
Ранние эксперименты с цепочкой из нескольких агентов (исследователь, стратег, райтер, QA) демонстрировали высокую стоимость процесса. Для создания одного 53-секундного сценария требовалось около 40 вызовов субагентов и более 6 миллионов токенов. Качество улучшалось с 72 до 88 баллов, но цена была несоразмерна результату. Проблема заключалась в отсутствии единого лица, ответственного за целостность задачи. Проверяющий мог отказать, но не решал вопрос маршрутизации исправлений и контроля за повторными ошибками.
При попытке сделать начальника «строже» автор столкнулся с проблемой дипломатии LLM. Фразы вроде «в целом работа хорошая» становились частью контекста для следующего агента, размывая критичность замечаний. В версии boss.md v4 появилась жёсткая формулировка: «ГДЕ, Б***Ь, РЕЗУЛЬТ?». Но рядом с матом возникла более важная логика: запрет на общие пожелания вроде «усиль аргументацию» и требование конкретных действий — удалить неподтверждённые факты или перестроить текст на основе данных. Начальник перестал выдавать рекомендации и начал выносить конкретные отказы.
В одном из прогонов система подготовила статью с ложной предпосылкой. В мягком режиме это могло быть воспринято как рекомендация, но новый начальник вернул версию с формулировкой «провал по существу», требуя убрать центральный тезис. Пока исправленная версия не проходила повторную проверку, задача не могла быть закрыта. Это превратило проверку в механический процесс: дефект, критичность, исполнитель, исправление, повторная приёмка и вердикт PASS или FAIL.
Автор отмечает, что простое объяснение «модели лучше работают при грубом тоне» опровергается исследованиями, включая работу Yin et al., где грубые промпты часто ухудшали результат. Более релевантной оказалась концепция сикофантии (сикофантства) в LLM: модели склонны подстраиваться под ожидания пользователя. Жёсткий промпт помог не «напугать» модель, а сделать роль недвусмысленной и отделить оценку качества от вежливого общения.
В итоге полезным результатом стала не токсичность, а система, которая умеет сказать FAIL. Проверяющий обязан честно выставлять критичность и ставить PASS, если блокирующих проблем нет, но начальник отвечает за то, чтобы результат с ошибкой не прошёл дальше. Жёсткий характер помогает удерживать роль, но за ним стоит нормальная механика приёмки. Это позволяет использовать такой подход там, где пропуск дефекта дороже лишней проверки, например, при верификации фактов или безопасности.