Життєвий цикл і оцінювання subagentʼа

1. Subagent супроводжують як код, а не як налаштування

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

Упродовж усього курсу я тягну одну й ту саму думку: Claude прискорює інженерну роботу, але відповідальність залишається за розробником. Із subagentʼами вона стає ще важливішою. Будь-який агент — інженерний артефакт: файл, конфігурація, інструкція та обмеження. Він живе в репозиторії, змінюється, проходить review і застаріває. І якщо ним користується команда, ви маєте відповідати на приземлені питання. Чи відтворювана поведінка? Чи розуміємо межі? Чи бачимо, коли стало гірше? Чи відкотимо невдалу зміну?

Тут корисно запам’ятати одне суворе, але чесне правило: якщо агент не працює краще, ніж хороший prompt у свіжій сесії, він команді не потрібен. Витрачаєте на лікування tester-агента більше, ніж на ручний запит із task spec, — перед вами не актив, а дорога іграшка.

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

2. Ознаки справді корисного агента

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

Нижче наведена зручна таблиця, за якою можна оцінювати будь-якого subagentʼа, але особливо добре вона лягає на agents/tester.md і agents/reviewer.md із Workflow Kit.

Ці критерії корисні саме разом. Агент може бути бездоганним за scope, але findings настільки слабкі, що користі немає. Або навпаки: знаходить цікаве й плодить стільки хибних спрацьовувань, що йому перестають довіряти. Підсумок один — роль командного інструмента він не тягне.

Для новачка тут особливо важливий критерій 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 — повторюваний тип збою, який можна розпізнати й полагодити. Ось карта найчастіших.

Тепер розберімо це людською мовою. Вигадані знахідки — це коли reviewer пише «можливо, тут race condition», але не дає ні посилання на код, ні trace, ні тесту. Це не знахідка, а гіпотеза, так її і треба маркувати. Змішує з фактами — винен слабкий output contract.

Агент із надмірними правами виглядає ще веселіше. Ви запускали tester-а, щоб він запропонував тести, а він чомусь править production-файл, «щоб тести проходили». Виглядає як ініціатива, а це конфігураційна аварія. Зайвих можливостей «про всяк випадок» не роздають: в інженерії це «до першого неприємного сюрпризу».

Застарілі інструкції підкрадаються тихіше. Припустімо, в Commerce OS оновили CLAUDE.md, scripts і conventions, а agents/tester.md усе ще посилається на старий патерн — і агент виглядає дурнішим, ніж є: живе у вчорашньому дні. Agent file — це версія артефакту, а не напис на камені.

Засмічення памʼяті особливо підступне там, де агенту дали занадто багато довготривалої пам’яті або погано відокремили 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 -> запит на розбиття
- оновлено команди запуску тестів під поточний 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

Опитування

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

Недоступний

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

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

Відкрити