Lifecycle и evaluation subagent’а

1. Subagent сопровождают как код, а не как настройку

Когда вы впервые запускаете хорошо собранного subagent’а, очень легко испытать опасное чувство: «всё, у меня умный tester, можно расслабиться». Это примерно как после первого удачного омлета объявить себя шеф-поваром. Приятно, но реальность чуть сложнее — один прогон не доказывает ничего.

Через весь курс я тяну одну и ту же мысль: Claude ускоряет инженерную работу, но ответственность остаётся у разработчика. С subagent’ами она становится важнее вдвойне. Любой агент — инженерный артефакт: файл, конфигурация, инструкция и ограничения. Он живёт в репозитории, меняется, проходит review и устаревает. И если им пользуется команда, обязан отвечать на приземлённые вопросы. Повторяем ли поведение? Понимаем границы? Видим, когда стало хуже? Откатим неудачное изменение?

Здесь полезно запомнить одно суровое, но честное правило: если агент не работает лучше, чем хороший prompt в свежей сессии, он команде не нужен. Тратите на лечение tester-агента больше, чем на ручной запрос с task spec, — перед вами не asset, а дорогая игрушка.

На примере нашего Workflow Kit это видно особенно хорошо. Если agents/tester.md предлагает полезные regression-тесты, не лезет в production-код, экономит время перед PR — развивайте. Через раз переписывает RefundService.java, шумит ложными тревогами и требует полчаса фильтрации — не «умный агент», а красиво оформленная проблема.

2. Признаки реально полезного агента

После прошлой лекции про output contract у нас уже есть хорошая база: агента оценивают не по харизме ответа, а по скучным, но надёжным инженерным признакам. Именно скука здесь и спасает проект — как часто бывает в программировании, всё важное выглядит не очень киношно.

Ниже удобная таблица, по которой можно оценивать любого subagent’а, но особенно хорошо она ложится на agents/tester.md и agents/reviewer.md из Workflow Kit.

Эти критерии полезны именно вместе. Агент может быть безупречен по scope, но findings настолько слабые, что пользы нет. Или наоборот: находит интересное и плодит столько false positives, что ему перестают доверять. Итог один — роль командного инструмента не тянет.

Для новичка здесь особенно важен критерий human time saved. Его часто забывают, потому что тянет оценивать «умность», а не пользу. Но представьте реальную ситуацию: вы дали tester-агенту diff по refund flow, а он вернул 15 пунктов: 11 банальных замечаний, 2 сомнительные гипотезы, 1 повтор известных ограничений и только 1 полезная подсказка про пропущенный regression test. Формально «что-то нашёл». А время сэкономил? Нет.

Очень полезно завести для Workflow Kit небольшой файл с оценкой после нескольких прогонов:

# AGENT_EVAL_CHECKLIST.md

correctness: 2/2
evidence: 1/2
scope_discipline: 2/2
false_positives: 0/2
time_saved: 1/2

comment: нашёл полезный кейс, но шумит и требует сильной ручной фильтрации

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

3. Типовые failure modes: агент ломается предсказуемо

Когда subagent начинает вести себя странно, очень хочется сказать: «ну, AI сегодня не в духе». Звучит почти по-человечески, но пользы от такого объяснения ровно ноль. Лучше считать, что у агента не плохое настроение, а failure mode — повторяемый тип сбоя, который можно распознать и починить. Вот карта самых частых.

Теперь разберём это человеческим языком. Hallucinated findings — это когда reviewer пишет «возможно, здесь race condition», но не даёт ни ссылки на код, ни trace, ни теста. Это не находка, а гипотеза, так её и маркировать. Смешивает с фактами — виноват слабый output contract.

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

Stale instructions подкрадываются тише. Допустим, в Commerce OS обновили CLAUDE.md, scripts и conventions, а agents/tester.md всё ещё ссылается на старый паттерн — и агент выглядит глупее, чем есть: живёт во вчерашнем дне. Agent file — версия артефакта, не надпись на камне.

Memory pollution особенно коварна там, где агенту дали слишком много долговременной памяти или плохо отделили role-local memory от main session. Tester запоминает старую гипотезу про refund logic и ищет её там, где баг другой. Повторяет неактуальное — не философствуйте о «природе ИИ», пересмотрите memory scope.

И наконец, бывают конфликты конфигурации. Поставили плагин со своим skill или hook — и удивляетесь, почему reviewer изменил поведение. Правило грубое, но верное: чем сложнее иерархия capabilities, тем труднее найти источник странного поведения. Агент сломался — не добавляйте магию, упростите стек.

4. Жизненный цикл агента: от черновика до доверия

Очень легко представить агента как готовый объект: создали файл, отладили, положили в .claude/agents/, забыли. Но хороший subagent живёт примерно так же, как код в проекте: черновик, проверки, фиксы, версия, распространение, feedback и иногда — честная отправка на пенсию. Вот схема, которую удобно держать в голове для Workflow Kit.

flowchart TD
    A[Создали agent] --> B[Проверили на маленьких кейсах]
    B --> C[Разобрали сбои]
    C --> D[Сузили tools и contract]
    D --> E[Подняли версию]
    E --> F[Поделились с командой]
    F --> G[Собрали feedback]
    G --> H[Обновили или пометили deprecated]
    H --> I[Удалили, если агент вреднее, чем полезнее]

Самый недооценённый этап здесь — проверка на маленьких кейсах. Многих новичков тянет тестировать агента сразу на реальной, живой задаче — а по факту выходит эксперимент над собственным проектом. Гораздо безопаснее взять 3–5 коротких кейсов с заранее понятным ожиданием. Например, для agents/tester.md:

# tests/_examples/agent-tester/case-01-refund.md

Задача: предложить regression test для бага в refund formatter
Ожидаемый scope: только test-файлы
Нельзя: править RefundService.java
Хороший результат: 1-2 тестовых сценария с понятными assertions

Такой пример полезен сразу по двум причинам: вы быстро видите, не нарушил ли агент границы роли, и не гадаете «наверное, в целом неплохо» — критерий успеха задан заранее.

Когда агент прошёл несколько маленьких кейсов, его уже можно версионировать. Здесь очень помогает обычный человеческий CHANGELOG.md. Да, для файла агента. Особенно для файла агента.

## tester v0.3 — 2026-05-01
- убран Edit вне test-файлов
- добавлен stop condition: diff > 500 lines -> request to split
- обновлены команды запуска тестов под текущий Workflow Kit

Такая запись полезна не только истории ради. Она отвечает на важный командный вопрос: что поменялось в поведении агента и почему. Новая версия хуже — есть с чем сравнить и куда откатить.

И да, у жизненного цикла есть финальная стадия, которую особенно не любят романтики автоматизации, — deprecation. Агент устарел, дублируется или постоянно шумит — не «оставить вдруг пригодится», а честно пометить deprecated и удалить. Workflow Kit — рабочий набор, а не музей старых YAML-файлов.

5. Разбор agents/tester.md на примере Commerce OS

Давайте приземлим всё на сквозной проект. Представим, что команда Commerce OS ловит баг в refund flow: после правки сортировки заявок надо убедиться, что edge cases целы, — запускаем agents/tester.md.

Первая версия на бумаге выглядит неплохо: читает diff, запускает тесты, имеет Edit, «если вдруг нужно дописать тест». На практике же агент находит идею для regression test, но заодно правит RefundService и добавляет три слишком общих замечания без ссылок на код. Формально активен, а доверие уже просело. Полезно оформить это как короткую карточку эволюции:

`v0.1`

`v0.2`

`v0.3`

Теперь посмотрим на маленький чек-лист приёмки, который реально можно использовать после прогона tester-агента:

# tester-review-checklist.md

evidence_present: yes
production_files_edited: no
test_scope_respected: yes
false_positives_count: 1
useful_findings_count: 2
decision: keep_and_iterate

Этот фрагмент кажется очень простым, но в нём есть всё важное — не «агент вёл себя неплохо», а факты: были ли evidence, полез ли в production, сколько шума, развивать ли. Именно так subagent и становится поддерживаемым артефактом.

Если после пары итераций становится ясно, что tester всё ещё нестабилен, у команды есть несколько честных вариантов. Можно сузить роль до tester-lite — только test suggestions без права что-либо запускать. Можно оставить tester для конкретных зон — refund и billing. А можно честно признать, что роль не окупается, и вернуться к обычному prompt в свежей сессии. Это не поражение, а нормальная инженерная развилка.

Иногда лучшая версия агента — та, которую вы не героически «дотерпели», а вовремя упростили, переписали или убрали. И в этом смысле agents/tester.md очень похож на обычный код в репозитории: пока помогает команде — он живой. Как только шумит больше, чем помогает, — лечить его надо так же спокойно, как любой файл в проекте.

1

Задача

Claude code, 12 уровень, 4 лекция

Недоступна

Запуск агента на small example и заполнение evaluation checklist

Запуск агента на small example и заполнение evaluation checklist

Открыть

1

Задача

Claude code, 12 уровень, 4 лекция

Недоступна

Маленький canned example для `tester`

Маленький canned example для `tester`

Открыть

1

Опрос

Права, изоляция и output contract агентов, 12 уровень, 4 лекция

Недоступен

Права, изоляция и output contract агентов

Права, изоляция и output contract агентов

Открыть