Когда я рассказываю, что в моём агенте есть роли, первый вопрос всегда один: это же просто другой системный промпт? Да. И именно поэтому вопрос хороший. Если роль это текст, чем она отличается от «представь, что ты сеньор» в начале чата, и почему я считаю её главной особенностью агента.
Сначала о том, что про роли известно из исследований, потому что там есть неудобные результаты. Потом о том, как роль устроена у меня и где проходит её настоящая граница.
Что известно из исследований
Ожидание у всех одно: скажи модели «ты эксперт», и она станет отвечать лучше. Данные это ожидание не поддерживают.
Чжэн с соавторами проверили 162 персоны на 2 410 фактических вопросах в четырёх семействах моделей и не нашли улучшения по сравнению с контролем без персоны вообще. На закрытых вопросах с проверяемым ответом роль ничего не добавляет: знание либо есть в модели, либо нет, и костюм эксперта его не создаёт.
Конг с соавторами показали обратное на другом классе задач: на двенадцати бенчмарках рассуждения ролевой промпт обошёл обычный zero-shot на большинстве наборов. На AQuA точность выросла с 53,5% до 63,8%, на задаче с последними буквами слов с 23,8% до 84,2%. Роль здесь работала как спусковой крючок для пошагового рассуждения, причём лучше прямой инструкции «думай по шагам».
Самое точное измерение, которое я видел, вышло в мае этого года. Сяо с соавторами разобрали 1 140 открытых вопросов, 38 экспертных ролей и шесть областей. Роль систематически повышала глубину экспертизы и одновременно снижала ясность ответа. Выигрыш был заметен на советующих вопросах, медицина, психология, а на концептуальных вопросах в финансах, праве, науке и технологиях лучше отвечала модель без роли.
И четвёртый результат, который объясняет, почему роли так часто разочаровывают. Лус де Араужо с соавторами прогнали девять моделей через 27 задач: экспертная персона обычно даёт нейтральный или положительный эффект, а нерелевантные детали персоны роняют качество почти на 30 процентных пунктов. Модель чувствительна к тому, что в описании роли лишнее.
Если сложить это вместе, картина такая. Роль не добавляет знаний и не делает модель умнее в целом. Роль меняет суждение: что модель замечает, как формулирует, что считает достаточным доказательством и что считает сделанной работой. Это меньше, чем обещает маркетинг, и ровно столько, сколько мне нужно.
Роль как процедура
У меня семь встроенных ролей, и когда я перечитываю их подряд, видно: ни в одной нет ни строки про характер, биографию или тон голоса. Каждая описывает процедуру.
Роль senior начинается с лестницы, по которой надо пройти до того, как писать код: нужно ли это вообще; есть ли уже в кодовой базе; делает ли это стандартная библиотека; закрывает ли платформа; решает ли установленная зависимость; можно ли одной строкой; и только потом минимальный код, который работает. Отдельным правилом: баг чинится в корне, и перед правкой надо найти всех вызывающих функции, которую собираешься тронуть. Описания человека здесь нет. Есть порядок действий.
Роль qa устроена вокруг фразы «чеклист и есть артефакт». Каждая проверка производит чеклист по фиксированной структуре, основной сценарий, граничные случаи, ошибки, точки интеграции, регрессия, и роль пишет только в каталог отчётов, никогда в исходники и тесты. Роль researcher требует триангулировать: один источник это утверждение, два независимых ближе к факту; предпочитать первичку; вести провенанс по ходу, потому что подставлять ссылки из памяти в конце значит возвращать ту самую проблему, ради которой ссылки существуют. Роль assistant прямо говорит модели, что инструменты это техническая деталь, и большинство вопросов не требуют ни файла, ни команды.
Наведи senior и qa на один и тот же коммит, и они посмотрят в разные места. Первый спросит, нужен ли этот код вообще и нет ли такого рядом. Второй начнёт перечислять, что случится с пустым вводом, с очень длинной строкой, при отказе внешнего сервиса, и назовёт задачу незакрытой, пока список не пройден. Инструменты у обоих одни и те же. Разное у них представление о том, что значит «готово».
Есть исследование ровно про эту конструкцию. Руангтанусак с соавторами сравнивали варианты ролевого промпта для агента с инструментами и получили лучший результат, 0,571 против 0,519 у zero-shot, в условии, где роль дополнена явными правилами: когда и как вызывать функции. Ярлыка роли недостаточно. Работает роль плюс процедура. Вместе с результатом про вред лишних деталей это и есть мой рецепт: писать роль через обязанности, стандарты доказательств и критерии завершения, и вычищать всё, что похоже на театр.
Где проходит граница
Теперь о том, что отличает роль в агенте от роли в чате. Роль в чате это только текст. Роль у меня это текст плюс политика возможностей, и вторую часть проверяет код.
Роль это markdown-файл с frontmatter. Помимо имени и описания там могут стоять tools, список встроенных инструментов, которые роли доступны; skills, какие навыки она может подгружать; mcp, какие внешние серверы ей видны; subagents и subagentTypes, может ли она делегировать и кому. Каждое из этих полей применяется в цикле до запроса к модели: инструмент, которого нет в списке роли, не попадает в описание инструментов, отправляемое провайдеру. Модель его не видит. Ей нечего вызывать.
Это принципиально другой механизм, чем строка «не трогай базу данных» в промпте. Я уже писал в «Инструкции по недоверию» о случае, когда режим планирования обещал read-only, а ssh оставался доступен: промпт был инструкцией, и модель могла её нарушить. С тех пор я считаю, что у роли две части с разной природой. Текст это вероятностное управление: он меняет, куда модель смотрит и что считает достаточным. Список инструментов это детерминированная граница: он определяет, что физически возможно. Первое делает ревью от qa другим по содержанию. Второе гарантирует, что qa не запишет в src/, даже если очень захочет.
Пара деталей про устройство границ. Ограничение по MCP работает на уровне серверов, не отдельных инструментов, потому что человек думает в терминах «может ли эта роль трогать postgres», а отдельные имена вроде pg_query_v2 он не помнит и помнить не должен. Ограничение по типам субагентов наследуется: роль, которой нельзя что-то делать, не может породить субагента, которому можно, иначе граница обходилась бы делегированием. И порядок приоритета: роль из папки проекта перекрывает глобальную, глобальная перекрывает встроенную, та же схема, что для навыков.
И одно решение, которое выглядит как непоследовательность. Встроенные роли почти не сужают инструменты: только coder-with-subagents включает делегирование, остальные видят весь обычный набор. Причина в том, что переключение роли не должно неожиданно ломать рабочий процесс. Человек переключился на qa за чеклистом, и внезапно пропавший bash был бы сюрпризом. Сужение это осознанный выбор для собственной роли: документационная роль без shell и без базы, инцидентная роль с мониторингом и без правок. Такие роли пишутся под конкретную задачу и ограничиваются под неё.
Чего роль не делает
Здесь честность важнее презентации, поэтому список.
Роль не превращает модель в сертифицированного безопасника, администратора баз данных или руководителя инцидента. Она меняет, что модель проверяет, и не меняет, что модель знает. Роль не даёт универсального прироста качества: исследования выше говорят об этом прямо, и на концептуальных вопросах роль может даже мешать. Роль не заменяет схемы инструментов, тексты ошибок, тесты, хуки и проверки прав. Это разные слои, и промпт не работает ни за один из них.
Список инструментов роли это не песочница операционной системы. Он ограничивает вызовы через цикл агента. Права на файловую систему, процессы и сеть определяются отдельно, и разрешённый инструмент делает ровно то, что позволяет ему система.
Смена роли посреди сессии сохраняет предыдущее рассуждение в контексте. Модель не забывает, что десять ходов назад думала как senior, когда становится qa. Поэтому для смены задачи честнее начать новую сессию.
И последнее, связанное с контекстом. Системный промпт с ролью пересобирается перед каждым запросом, чтобы роль всегда стояла в начале контекста, в позиции, которую модель видит хорошо. Это смягчает деградацию инструкций на длинном контексте и не отменяет её.
Что из этого следует
Роль это самая заметная снаружи часть моего агента и одновременно самая переоценённая, если понимать её как костюм. Данные говорят, что костюм не работает: он не добавляет знаний и ломается от лишних деталей.
Работает другое. Роль как процедура: что собирать, что проверять, когда остановиться. И роль как политика: какие инструменты существуют для этой процедуры. Первое меняет, что модель ищет в коде. Второе определяет, до чего она дотягивается. Одна модель, семь наборов правил и семь списков возможностей. Ровно столько разных взглядов на один и тот же репозиторий.