Built-in subagents и delegation model

1. Делегирование работы Claude

После того как subagent отделился от separate session, фонового режима и worktree-сессии, можно спокойно смотреть на первый рабочий режим без терминологического тумана — built-in delegation: Claude выносит узкое исследование в отдельный контекст и возвращает не «ещё одного мудреца», а короткую проверяемую сводку. Когда вы впервые видите, что Claude «передал задачу другому помощнику», это немного похоже на научную фантастику и немного — на повод насторожиться. На деле проще: делегирование экономит внимание и защищает сессию от мусора.

Представьте, что у вас в Commerce OS есть баг с очередностью refund-запросов. Если начать разбирать его «в лоб» в основной сессии — Claude прочитает контроллер, сервис, DTO, тесты, фронтенд-таблицу, конфиги, логи, старые обсуждения и пару файлов «на всякий случай». И у вас уже не чистый рабочий стол, а шкаф, открытый ногой.

Встроенный subagent решает эту проблему иначе. Claude как бы говорит себе: «Для этой подзадачи нужен не весь мой разговор, а аккуратный исследователь с отдельным окном контекста. Пусть соберёт факты и вернёт сводку». Grep-результаты, десятки файлов и мимолётные гипотезы в основную сессию не попадают — только результат.

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

2. Delegation model на практике

На словах всё это звучит красиво, но полезнее увидеть механику как рабочий цикл. Тогда вместо «внутри что-то непонятное» останется инженерная модель: что Claude сделал, что вернул и где остаётся ваше решение.

flowchart TD
    A[Вы формулируете задачу] --> B[Claude выбирает подходящего встроенного subagent]
    B --> C[Subagent работает в isolated context]
    C --> D[Собирает файлы, команды, находки, ограничения]
    D --> E[Возвращает короткую сводку в main session]
    E --> F[Вы проверяете evidence и решаете следующий шаг]

Если разложить это по шагам, получается очень понятная схема:

Самое ценное здесь — четвёртый шаг. Именно он превращает делегирование в инженерный инструмент. Финальная мысль без следов — не лучше гадания. Файлы, строки, тесты, команды и блок «что не проверено» — материал для проверки.

Вам не нужно запоминать конкретные внутренние реализации, служебные механизмы и прочую кухню. Важен паттерн: роль выбрана → контекст изолирован → промежуточный шум не попал в основную сессию → сводка вернулась как evidence. Как только он ясен, магия исчезает.

3. Типы встроенных subagents

На этом месте хочется спросить: «Хорошо, а как они называются?» Но именно здесь курс специально держит вас подальше от зубрёжки. Имена, количество и доступность встроенных subagents в конкретной версии Claude Code меняются. Важен не список названий, а типы поведения. Чаще всего встречаете три больших класса встроенных ролей:

Если говорить совсем простым языком, один встроенный помощник хорош в режиме «покажи, где это находится», другой — «собери материал для плана», третий — «разберись с узкой веткой и верни сухой остаток». Важна не вывеска, а поведение. «Найди, где формируется сортировка refund-запросов, и ничего пока не меняй» — read-only исследование. «Посмотри, какие файлы затронет исправление, какие тесты есть и где риск регрессии» — уже исследование для плана.

И ещё одна важная деталь. Даже увидев знакомое имя в интерфейсе, не стройте процесс на мысли «этот агент всегда делает X». Стройте на мысли «мне нужен изолированный исследователь для такой-то подзадачи». Продукт изменится — а привычка останется рабочей, и лекция не устареет раньше, чем закончится кофе.

4. Isolated context улучшает ответы

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

Вспомните, как вы сами ищете проблему в большом проекте: файл, второй, grep, тест, конфиг, ещё файл — половина оказывается ложным следом. Это нормально. Но если вся цепочка тащится в основной диалог, Claude потом помнит лишнее: старые гипотезы и несработавшие догадки.

Изолированный subagent работает как одноразовая исследовательская ветка. Читает двадцать файлов, возвращает четыре действительно полезные находки. Вместо лавины исходников вы получаете компактную карту, по которой уже можно идти осмысленно. Представьте такой запрос:

Исследуй, где в Commerce OS формируется список refund-запросов.
Ничего не меняй.
Верни:
1) ключевые файлы,
2) связанные тесты,
3) что осталось непроверенным.

Если такую задачу выполнять прямо в основной сессии с полным выводом всех поисков, вы быстро получите стену текста. А у встроенного subagent — короткая сводка. И вот тут важно не обижаться на краткость: вам не вывалили склад промежуточного мусора.

5. Returned summary как evidence

Это центральный навык сегодняшней лекции. Пока вы читаете returned summary как «умный ответ Claude», легко принять гипотезу за факт. Как только начинаете читать её как документ с доказательствами, всё встаёт на места. Сводка — не приговор, а папка с найденными следами.

Сильную и слабую сводку удобно различать по нескольким признакам:

Вот слабый вариант:

Похоже, проблема находится в support-модуле.
Сортировку нужно поменять и, вероятно, добавить тесты.

Звучит уверенно, пользы мало. Где support-модуль? Какой файл? Что именно проверено? Это не доказательства, а настроение.

А вот сильный:

Сводка исследования:
- support/refund/RefundInboxService.java:42 — список сортируется по createdAt ASC
- support/refund/RefundController.java:18 — endpoint /api/support/refunds/inbox вызывает service.listInbox(...)
- support/refund/RefundInboxServiceTest.java:55 — есть тест на порядок ASC
- Не проверено: влияет ли фронтенд-таблица dashboard/refunds/InboxTable.tsx
  на финальную видимую сортировку

Вот это уже рабочий материал. Открыть файл и проверить строку. Открыть тест и увидеть, что он покрывает. Заметить пробел: фронтенд не проверен. Если сводка слабая, не надо драматично разочаровываться в built-in subagents — надо просто дожать формат:

Покажи, на каких файлах и строках основан вывод.
Если что-то не проверено, перечисли это отдельно.
Не делай общих рекомендаций без evidence.

Это очень важный перелом в мышлении: ответ оценивают не по тону, а по следам. Красивый абзац — это приятно. Открываемый файл и проверяемая строка — полезно.

6. Сценарий Commerce OS: баг сортировки refund

Теперь давайте соберём всё вместе на коротком сценарии, близком к нашему сквозному проекту. Представим, что в Commerce OS менеджер поддержки жалуется: в inbox refund-заявки идут в неправильном порядке. Первая ошибка, которую вы легко совершите, — сразу попросить Claude «исправить сортировку»: модель может пойти править не тот слой, фронтенд вместо сервиса. Нужен не фикс, а сначала расследование с доказательствами:

Исследуй, где в проекте задаётся порядок refund-запросов в inbox.
Ничего не меняй.
Верни короткую сводку:
- ключевые файлы,
- связанные тесты,
- возможную точку изменения,
- что ещё не проверено.

Claude делегирует подзадачу исследовательскому subagent — тот возвращает, например:

Сводка:
- support/refund/RefundInboxService.java:42 — сортировка по createdAt ASC
- support/refund/RefundController.java:18 — endpoint передаёт запрос в service
- support/refund/RefundInboxServiceTest.java:55 — тест проверяет ASC, нет сценария newest-first
- dashboard/refunds/InboxTable.tsx — таблица отображает данные в полученном порядке, локальной сортировки не найдено
- Не проверено: влияет ли параметр сортировки из query string на backend

Что вы делаете дальше? Не пишете сразу «отлично, чини». Сначала проверьте следы. Откройте RefundInboxService.java, убедитесь, что сортировка ASC. Тест не покрывает нужный сценарий. Фронтенд, похоже, не виноват. Теперь у вас обоснованная следующая команда: исследовать query string или планировать точечное исправление сервиса и теста.

Заметьте, насколько чище стала работа: основная сессия не утонула в шуме, а сводка конкретна для решения. Вот в этом и есть реальная ценность delegation model.

7. Запрос сводки в удобном формате

Очень часто качество built-in subagent определяется не только самой ролью, но и тем, насколько аккуратно вы задали формат результата. Расплывчатый запрос почти гарантирует расплывчатую сводку. Назвали заранее файлы, тесты, открытые вопросы и границы непроверенного — шанс на полезный результат резко растёт. Для поиска файлов и точек входа работает шаблон:

Найди, где в проекте реализовано это поведение.
Ничего не меняй.
Верни:
1) ключевые файлы,
2) связанные функции или классы,
3) тесты,
4) что осталось непроверенным.

Если вам важно не засорять основную сессию и получить именно сжатый результат, полезно уточнять это прямо в формулировке:

Исследуй задачу в изолированном контексте.
В основной разговор верни только короткую проверяемую сводку.
Не перечисляй весь промежуточный поиск.

А если вам нужна сводка, пригодная для дальнейшего решения, а не «общие рекомендации», добавьте требование к evidence:

Для каждого вывода укажи файл и, если возможно, строку.
Если это гипотеза, пометь её отдельно.
Если что-то не проверено, вынеси в отдельный блок.

Обратите внимание, чего здесь нет. Ни «думай как senior», ни «включи максимальный интеллект», ни прочих заклинаний. Есть задача, граница и формат артефакта — инженерный подход, скучнее шаманства, но стабильнее.

И ещё один мягкий, но полезный совет: не просите слишком много за один раз. Требуете в одном запросе найти файлы, понять архитектуру, оценить риски, придумать фикс, написать тесты и сходить за хлебом — даже хороший subagent вернёт кашу. Делегирование работает на узких подзадачах.

8. Делегирование: когда оно оправдано

На фоне всех преимуществ легко начать делегировать вообще всё — вплоть до поиска одной строки в уже открытом файле. И здесь полезно вовремя притормозить. Built-in subagents — не обязательный ритуал, а инструмент. Задача маленькая, сессия не загрязнится — делегирование будет лишней прослойкой.

Допустим, вы уже знаете точный файл и хотите понять одну функцию на двадцать строк. Тут отдельный subagent только добавит движения — прочитаете сами. А когда задача расползается на слои, тесты, конфиги и точки входа, isolated investigation окупается.

Хороший ориентир звучит так: исследование может захламить основной разговор — делегируйте; нет — обойдётесь без него. Не превращайте built-in subagents в новый культ. Курс борется с двумя крайностями: «AI всё сделает сам» и «надо обязательно использовать самую продвинутую фичу, иначе я плохой инженер».

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

Когда вы начинаете смотреть на built-in subagents не как на маленьких оракулов, а как на аккуратных сборщиков доказательств, всё становится спокойнее. Claude делегирует не чтобы забрать управление, а чтобы вернуть короткую, чистую и проверяемую сводку. А решение снова за вами: открыть файлы, проверить следы, сузить задачу и только потом двигаться дальше.