Субагент - это отдельная роль со своим окном контекста, которая возвращает основному агенту результат, а не сырой поток работы. Встроенных ролей три: исследователь для широкого поиска, оболочка для проверок командами и браузер для работы со страницей. Смысл механизма в изоляции: шумная часть работы идёт в стороне, а в основной разговор попадает уже сводка. Разница между сводкой и потоком не косметическая: чтение тридцати файлов стоит основному агенту всего их объёма, а вывод из этого чтения занимает несколько строк.
Наивная альтернатива - делать всё в одном контексте. На маленькой задаче это удобно, на большой начинает мешать: результаты поиска, вывод команд и промежуточные гипотезы вытесняют то, ради чего разговор затевался. Субагент решает ровно эту проблему - он не ускоряет модель, а сохраняет вам контекст, который стоит дороже пары секунд ожидания. Плата за изоляцию тоже есть: роль не видит вашего разговора, и всё, что ей нужно знать, приходится изложить в задаче явно.
Есть выбор между двумя режимами исполнения, и он важен. Роль в основном потоке блокирует агента до своего результата - это правильно, когда без результата следующий шаг не определён. Фоновая роль позволяет основному агенту работать дальше - это правильно для длинной проверки, результат которой понадобится позже. Ошибка в выборе стоит времени в обе стороны: блокирующая роль на долгом поиске превращает работу в ожидание, а фоновая там, где ответ нужен немедленно, заставляет основного агента строить догадки и потом их переделывать.
Собственные роли задаются файлами в стандартных каталогах и описываются коротким заголовком: имя, описание, модель, признак только для чтения и признак фоновой работы. Полезно один раз увидеть такое определение целиком. Ниже - аудитор миграций: только чтение, инструкция вернуть находки по серьёзности с точными ссылками на файлы и явный запрет менять файлы. Признак только для чтения здесь несёт основную нагрузку: роль, которая физически не может писать, не сломает ничего, даже если ошибётся. Описание работает не меньше: по нему основной агент решает, звать ли роль вообще, поэтому его пишут как условие применения, а не как титул.
Граница между ролью и навыком проходит по назначению. Роль нужна, когда работа выигрывает от отдельного контекста или параллельности. Навык нужен, когда одну роль надо научить воспроизводимой процедуре. Их часто путают, и получается либо роль без процедуры, которая каждый раз делает по-своему, либо процедура без изоляции, которая засоряет основной разговор. Рабочая комбинация обычная: роль задаёт границы и права, навык внутри неё задаёт порядок шагов.
Как это выглядит на реальной задаче. Поле в записи иногда оказывается пустым, и непонятно, что его обнуляет. Основной агент держит план и гипотезы, а поиск всех мест, где это поле пишется, уходит в роль только для чтения с точным контрактом: вернуть список путей вызова и условие, при котором значение перезаписывается. Обратно приходит таблица на десяток строк вместо сотен строк поисковой выдачи, и разговор продолжается с того места, где остановился. Основной агент при этом ни разу не открывает файлы, которые к делу не относятся.
Качество делегирования определяется контрактом, а не выбором роли. Опишите вход, разрешённые действия, формат результата и условие остановки. Задача вида разберись с бэкендом задачей не является: у неё нет ни границ, ни признака выполнения, поэтому роль сама решает, когда остановиться, и решает обычно раньше, чем нужно. Формулировка только для чтения, найди всех, кто пишет в это поле, и верни таблицу путь вызова - инвариант проверяема: результат либо в заданном формате, либо нет, и это видно, не читая весь транскрипт.
У делегирования есть граница применимости. Оно проигрывает там, где задача требует плотного диалога: роль не может переспросить вас по ходу, а её единственный выход - итоговая сводка. Проигрывает и на мелочи: постановка задачи и разбор ответа стоят дороже самой работы. Признак, по которому в реальной работе понимают, что делегирование не удалось, простой - основной агент после сводки лезет в те же файлы сам. Значит, формат результата не был задан и сводка не даёт оснований для следующего шага.
Инженерный вывод про количество ролей простой: их заводят под функцию, а не под название. Отдельная роль оправдана изоляцией контекста, суженными правами, другой моделью или другой стоимостью. Если единственное отличие в имени, это лишняя сущность, которую придётся поддерживать и править при каждом изменении процесса. И отдельно стоит помнить про ограничения платформы: программный интерфейс облачных агентов допускает не больше двадцати собственных ролей на запуск, а имена должны быть уникальны и не совпадать со встроенными.
Типичные провалы предсказуемы. Дать роли право писать там, где хватило бы чтения. Отправить в фоновую роль работу, результат которой нужен немедленно. Поставить задачу без контракта и получить сводку, которую нельзя проверить. И плодить роли ради названий вместо одной хорошо описанной.
---
name: migration-auditor
description: Ищет риски потери данных и отката в миграциях базы.
model: inherit
readonly: true
is_background: false
---
Изучи указанную миграцию и её вызывающих.
Верни находки по серьёзности с точными ссылками на файлы.
Файлы не меняй.