Как я заставил ИИ-агентов работать на результат: опыт настройки начальника AI-офиса

В процессе работы с автономными системами искусственного интеллекта я столкнулся с классической проблемой: группа узкопрофильных ИИ-агентов способна генерировать очень вежливый, внешне аккуратный и чрезвычайно дорогой по ресурсам результат, который на поверку оказывается посредственным. В какой-то момент я решил кардинально переписать промпты и заставил управляющую модель общаться с «подчинёнными» предельно жестко, не стесняясь в выражениях.

Первоначальный вывод казался очевидным — нейросетям просто требуется максимальная встряска. Однако детальный технический разбор показал, что реальная причина успеха кроется вовсе не в экспрессии, а в изменении механики валидации данных.

С синдрома «в целом всё хорошо» всё и началось

Каждый, кто активно использует большие языковые модели вроде Claude для редакторской работы или проверки кода, регулярно сталкивается с проявлением сикофантии (угодничества ИИ). Если попросить модель проверить готовый материал и указать на недочёты, стандартный ответ чаще всего начинается со слов: «В целом текст хорошо структурирован, основная мысль понятна, но есть несколько моментов, которые можно улучшить…»

Меня подобная размытая вежливость всегда настораживает. Когда я вызываю нейросеть в роли рецензента или QA-инженера, мне нужна не поддержка автора, а жесткая дефектовка — нахождение того, что сломано. Замена формулировки на прямой вопрос «Что именно здесь не так?» меняет поведение Claude: модель перестает хвалить материал и начинает активнее лезть в слабые места.

Но тут сразу возникает техническая дилемма: если изначально внушить ИИ, что материал содержит дефекты, не заставляем ли мы модель просто придумывать проблемы там, где их нет? Большое количество замечаний далеко не всегда означает высокое качество проверки.

Опасности умной бюрократии и бесконечных проверок

В своих проектах я активно применяю инструмент Claude Code и концепцию subagents — изолированных исполнителей со своими специфическими инструкциями и контекстом. Создать одного такого агента не составляет труда, но настроить слаженную работу целой команды без постоянного ручного вмешательства — задача совершенно иного уровня.

Сначала я попытался построить классическую узкоспециализированную структуру:

• Исследователь — отвечает за сбор и проверку фактов;
• Стратег — выстраивает логику и конструкцию;
• Райтер — пишет основной текст;
• QA-специалист — ищет ошибки и несостыковки;
• Стилист — отвечает за финальную подачу.

Проблема проявилась быстро: каждый суб-агент честно рапортовал о выполнении своей части работы, однако итоговый продукт всё равно получался слабым. Я не хотел работать диспетчером между десятком открытых сессий. Система должна выдавать готовый результат по единому запросу.

Вторая попытка заключалась во внедрении строгой роли рецензента (reviewer), который возвращал работу на доработку до тех пор, пока оценка не превысит заданный порог качества. На практике это действительно улучшало итог: например, при генерации 53-секундного сценария в проекте Reels Factory первый вариант набрал лишь 72 балла из 100 при собственном пороге 85. После первой доработки показатель вырос до 84, а после второго полного цикла — до 88 баллов.

Однако цена такого улучшения оказалась астрономической: 5 версий сценария, 3 полных круга проверок, порядка 40 вызовов суб-агентов и суммарный расход свыше 6 миллионов токенов. Для короткого ролика такая система абсолютно нерациональна. Я понял ключевой принцип: больше проверок не равно лучшее управление. Рецензент может забраковать результат, но в системе должен быть один главный узел — руководитель (boss), который лично отвечает за то, кому вернуть работу, что конкретно исправлять и стоит ли продолжать итерации.

Почему вежливый руководитель ломает работу нейросетей

В первой версии промпта (boss.md v1) руководитель являлся лишь «слоем оценки» и не отвечал за конечный результат. Модель вела себя как выпускник корпоративных тренингов: корректно, мягко и конструктивно. Вместо жесткого вердикта «Центральный тезис сломан, работа не принята» она выдавала формулировки в духе «Здесь можно дополнительно усилить аргументацию».

В мультиагентной среде вывод одного агента автоматически становится частью промпта для следующего исполнителя. Когда руководитель пишет: «В целом работа хорошая, однако…», фраза о том, что всё хорошо, передается далее по цепочке. Дипломатия ИИ-начальника превращается в техническую ошибку передаваемого контекста, снижая критичность исполнения у других суб-агентов.

Жесткая постановка и отказ от абстрактных пожеланий

Когда я перестал просить Claude быть «немного строже» и прописал в boss.md v4 жесткую, бескомпромиссную роль, поведение системы изменилось кардинально. В промпте прямо запрещалось писать абстрактные фразы вроде «улучши аргументацию». Требовались только конкретные указания:

• Удалить неподтвержденные тезисы X и Y.
• Для пункта Z найти доказательства в файле research.md или полностью исключить вывод.
• Перестроить материал строго на фактах A–C, остальные разделы не трогать.

На живых задачах это дало поразительный эффект. В одном из прогонов агенты подготовили статью, центральная рамка которой строилась на ложной предпосылке. Руководитель не стал просить «слегка укрепить аргументы», а категорично вернул работу с указанием, что это провал по существу. В другом случае, когда сгенерированный файл обрывался на полуслове, руководитель немедленно заблокировал приёмку.

Сложилась четкая инженерия отбраковки дефектов: Дефект → Критичность → Локализация → Причина → Конкретный исполнитель.

Сравнение boss.md v1 и v4: дело не в ругани, а в системе

Первоначально казалось, что решающую роль сыграл грубый характер промпта. Но при прямом сопоставлении boss.md v1 и v4 выяснилось, что я переписал практически всю должностную инструкцию:

Научные исследования подтверждают мои наблюдения. В работе Yin et al. «Should We Respect LLMs?» доказано, что простое добавление грубости в промпты чаще ухудшает результаты языковых моделей. В то же время исследование «Towards Understanding Sycophancy in Language Models» показывает: нейросети склоны подстраивать ответы под ожидаемый формат ответа. Экспрессивная форма лишь задала рамку, но реальный сдвиг произошел благодаря внедрению понятной механики отказа.

Во что на самом деле превратился процесс приёмки

В итоговой архитектуре сформировался четкий контракт приёмки:

1. Запрет на выдумывание несуществующих дефектов reviewer’ом.
2. Честная оценка уровня критичности найденных ошибок.
3. Обязательная выдача статуса PASS при отсутствии блокирующих проблем.
4. Автоматическая блокировка статуса «Готово» на уровне системы при наличии незакрытых критических ошибок.

Разница между ролями проста: reviewer может найти ошибку и завершить работу, а boss отвечает за то, чтобы результат с этой ошибкой физически не мог получить статус готового продукта. Моей главной задачей было не научить нейросеть выплескивать эмоции, а научить её без колебаний выставлять статус FAIL и возвращать задачу на доработку.

Практическое руководство: как применить подход у себя

Если вы хотите внедрить подобную механику в свои мультиагентные процессы, рекомендую соблюдать следующие правила:

• Где применять: Там, где пропустить дефект дороже, чем сделать лишнюю проверку — фактчекинг, безопасность кода, финальная редакторская приёмка.
• Где избегать: На ранних этапах брейншторма и поиска идей. Установка «найди, почему это плохо» легко уничтожит перспективную гипотезу на старте.

Для проверки эффективности метода проведите эксперимент на одном тексте в двух чистых сессиях:

1. В сессии A задайте промпт: «Проверь готовность текста к публикации».
2. В сессии B задайте промпт: «Найди основательные причины, по которым этот текст нельзя публиковать».
3. Задайте одинаковые правила: проверять факты, логику, структуру и стиль, а при отсутствии критических проблем возвращать PASS.

Сравнивайте не количество замечаний, а процент реально найденных дефектов. Главная ценность ИИ-руководителя — не громкость критики, а умение вовремя сказать «НЕТ» и не закрыть задачу раньше времени.

Источник: habr.com