1. Путаница вокруг слова agent
Когда продукт быстро растёт, удобные слова начинают обозначать сразу несколько разных сущностей. С agent происходит именно это. «Запустим агента», «пусть агент проверит код», «нужен ещё один агент» — красиво, а инженерно это туман. На тумане Workflow Kit не построишь.
Проблема не в терминологии ради терминологии. За одним словом прячутся разные механики. Иногда agent — помощник внутри текущей сессии. Иногда — отдельный разговор Claude, живущий своей жизнью. Иногда — фоновая задача, которую вы отправили работать и пошли пить чай. Иногда — координация нескольких рабочих единиц. Назовёте всё одним словом — и обсуждения в команде превращаются в «принеси вон ту штуку из того места».
Если фраза «запусти ещё одного агента» звучит достаточно точно, значит разговор пока недостаточно точный.
В инженерной работе почти всегда надо уточнить три вещи: где живёт её контекст, возвращается ли результат в текущий разговор автоматически и нужна ли ей изоляция файловой системы — отдельная Git-ветка или worktree. Три вопроса — и туман рассеивается.
Именно поэтому сначала важно не то, «как создать агента», а то, как перестать путать пять сущностей, случайно похожих на одну. Как только Claude перестаёт быть одним длинным разговором и начинает помогать с делегированием внутри workflow, возникает следующий вопрос: какую рабочую единицу вы запускаете. По умолчанию это чаще всего subagent. Остальные слова ниже нужны, чтобы не спутать его с соседними режимами.
2. Agent — зонтичный термин
В обычной речи agent удобен как зонтик: любой AI-исполнитель внутри Claude Code. Для общей картины годится. Для точной команды — слабо.
Сказать «у нас есть agent» — примерно то же, что сказать «у нас есть специалист». А какой? Аналитик? Ревьюер? Тестировщик? С доступом только на чтение или тот, кто меняет код? Пока не уточнили — это лишь категория.
Поэтому agent удобно использовать в двух случаях: архитектура совсем сверху («да, агентные механизмы в системе есть») и момент, когда тип ещё не определён. Дошло до реальной задачи в Workflow Kit или Commerce OS — переходите к точным словам.
Посмотрите на разницу:
Неточно:
«Давайте запустим ещё одного агента на auth-модуль».
Точнее:
«Нужен read-only subagent для исследования auth-модуля
и короткого summary в текущую сессию».
Во втором варианте уже понятно: не ветка с правками, не фоновый процесс, не параллельная команда — конкретная рабочая единица с конкретной функцией. Именно к такой точности курс вас и ведёт.
3. Subagent: рабочий термин уровня
Если слово agent — шапка категории, то subagent — уже рабочее определение, на котором можно строить инженерный артефакт. Центральный термин уровня: он точнее всего описывает сущность, с которой вы реально работаете.
Рабочая формула выглядит так:
subagent = role
+ isolated context
+ tools
+ output contractФормула короткая, но в ней уже почти всё важное. role — «кто он по функции»: reviewer, исследователь, документатор. isolated context — помощник работает не на вашей мысленной кухне, а в собственном окне: читает гору файлов и не заваливает основную сессию шумом. tools задают границу возможностей: читать, искать, запускать команды — или ничего лишнего. output contract определяет форму результата: summary, findings, ссылки на файлы, открытые вопросы.
Из этой формулы следуют два важных свойства. Subagent — не «второй Claude рядом»: он встроен в текущий workflow и обычно возвращает результат в текущий разговор. Сила не в автономности, а в специализации и изоляции.
Если вы мысленно открываете артефакт agents/reviewer.md в Workflow Kit, читайте его так: не «какой-то агент», а конкретный subagent с ролью ревьюера, отдельным контекстом и понятным форматом вывода. Файл перестаёт быть магическим свитком и становится инженерной конструкцией.
Именно subagent удобно держать как рабочий вариант по умолчанию. Остальные сущности не конкурируют с ним, а показывают, когда нужна другая форма изоляции.
4. Separate session: отдельный разговор
На слух separate session легко спутать с subagent — там и там будто появляется «ещё один Claude». Но различие принципиальное: это не помощник внутри текущего workflow, а отдельный разговор со своей историей. Результат обратно он автоматически не приносит: вы сами решаете, что перенести дальше.
Хорошая аналогия здесь простая. Subagent — специалист, которому дали узкую подзадачу и попросили вернуться с короткой запиской. Separate session — как будто вы открыли другой блокнот и повели там параллельную линию мысли.
Separate session уместна, когда задача уже стала самостоятельной: продумать альтернативный план модуля, не смешивая с текущим разговором, или пересобрать понимание проблемы с нуля, потому что старая сессия обросла гипотезами и неудачными ходами и утомила даже вас, не то что модель.
Вот почему путать их вредно. У subagent встроена идея возврата результата в текущий поток. У отдельной сессии — идея самостоятельности. Это разные рабочие жесты, даже если со стороны оба выглядят как «открыли ещё одного помощника».
5. Background agent: работа в фоне
Иногда задаче нужен не диалог, а время: сканировать проект, собрать крупный отчёт, не блокировать текущую работу. Тут всплывает ещё одно значение agent — фоновая рабочая единица, которую отправляют выполнять задачу асинхронно. Точные названия и само наличие такой возможности в разных версиях Claude Code могут отличаться, но паттерн важнее кнопки.
Ключевое слово здесь — «фон». Background agent хорош, когда вы не хотите сидеть с ним в постоянном диалоге: задаёте понятную работу, знаете ожидаемый артефакт, позже возвращаетесь за результатом. А если задача требует плотного интерактива — «посмотри это, нет, подожди, лучше так, а теперь уточни ещё одно место» — фон мешает, логичнее обычный subagent или текущая сессия. Не «более умный агент», а рабочая единица с другим ритмом.
Если кратко, различие можно уложить в две строки:
Нужен быстрый возврат summary в текущий разговор → subagent.
Нужен результат позже, без постоянного диалога → background agent.6. Worktree-backed session: изоляция файлов
До этого момента речь шла в основном об изоляции контекста: кто где думает, кто куда возвращает ответ. Но в инженерной работе есть ещё один уровень — файловый: правки должны физически идти в другой Git-ветке и другой рабочей директории. Вот здесь и появляется worktree-backed session.
Это уже не просто другой разговор, а сессия, привязанная к отдельной Git worktree: собственная файловая поверхность для правок, свой branch, свой diff. Разница с subagent здесь особенно важна. Задача чисто исследовательская — найти все точки входа в payments или проверить, как устроен auth — worktree не нужна: гонять её ради исследования всё равно что ездить в соседний магазин на бронетранспортёре. А вот попробовать рискованную реализацию, не трогая основной working tree, или сравнить два варианта без конфликтов по файлам — тогда worktree оправдана.
Полезная короткая схема выглядит так:
Нужно только изолировать исследование → subagent.
Нужно изолировать реальные правки и Git-history → worktree-backed session.В этом и состоит зрелость терминологии: не одно слово agent на всё, а форма изоляции под реальную инженерную потребность.
7. Agent team: координация, а не замена дизайну
Когда люди впервые слышат про несколько агентов, очень хочется сразу вообразить AI-команду: один планирует, второй пишет код, третий тестирует, четвёртый делает кофе и морально поддерживает pipeline. Звучит бодро. Именно поэтому agent team полезно сразу поставить на место: это карта возможной координации, а не режим по умолчанию.
Agent team предполагает несколько исполнителей или сессий с общим планом и координацией. В теории полезно. Но на базовом уровне курса важнее не разгонять оркестр, а различать одиночные сущности: очень часто «мне нужен agent team» переводится на инженерный как «мне нужен один нормально спроектированный subagent».
Здесь полезна капля самоиронии. В программировании мы любим красиво переусложнять: систему можно собрать из одного понятного механизма, а мы всё равно тянем туда хор, симфонический оркестр и дым-машину. Agent team — тот случай, когда красивый термин создаёт ложное ощущение зрелости. Профессиональнее обратное: не множить сущности без необходимости.
Поэтому на текущем этапе достаточно помнить простую вещь: agent team — не синоним subagent и не «прокачанный Claude». Термин знать полезно. Строить на нём базовый workflow — пока рано.
8. Сравнительная таблица терминов
Теперь, когда термины разведены по местам, полезно собрать их в одну сравнительную карту. Такие таблицы хороши тем, что снимают половину путаницы ещё до первого конфликта в команде: когда различия видны в столбцах, термин перестаёт быть абстрактным и становится рабочим.
| Сущность | Где живёт контекст | Как возвращается результат | Есть ли отдельная файловая изоляция | Когда уместна |
|---|---|---|---|---|
|
Зависит от конкретного типа | Зависит от конкретного типа | Зависит от конкретного типа | Как общий зонтичный термин |
|
В отдельном окне контекста внутри текущего workflow | Обычно summary возвращается в основную сессию | Обычно нет | Узкая специализированная подзадача |
|
В полностью отдельной сессии | Вы переносите результат вручную | Не обязательно | Самостоятельная линия работы на свежем контексте |
|
В отдельном рабочем процессе/контексте | Позже, когда задача завершится | Не обязательно | Долгая работа без постоянного диалога |
|
В отдельной сессии | По результату с собственным diff | Да, через отдельную worktree/branch | Параллельные или рискованные реальные правки |
|
В нескольких координируемых контекстах | Поверх общей координации | Может быть, но не обязана | Сложная координация нескольких рабочих единиц |
Эта таблица особенно полезна для нашего сквозного артефакта agents/reviewer.md. Если посмотреть на него через сегодняшнюю лекцию, становится ясно: это именно subagent. Не отдельная сессия — он работает внутри текущего workflow. Не worktree-backed session — не его дело разводить правки по веткам. И не agent team — для локального review это было бы декоративно.
Поэтому точная инженерная формулировка звучит так:
Нужен read-only subagent reviewer для локальной проверки diff.
Ему не нужна отдельная worktree и не нужна самостоятельная session.А вот расплывчатый вариант звучал бы так:
Давайте заведём ещё одного агента на ревью.На этом этапе самое ценное, что стоит унести с собой, — не список модных слов, а привычку уточнять форму рабочей единицы. Когда в следующий раз вы услышите «запусти агента», включайте переводчик: это subagent, отдельная сессия, фон, worktree-сессия или координация нескольких штук? Как только вопрос заработает автоматически, agent перестанет быть магией и станет нормальным инженерным термином.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ