vyvchy
    Теми розділу

    14 · AI для QA

    Сабагенти й оркестрація

    Зміст

    Актуально станом на липень 2026. Інструменти цього класу змінюються швидко — деталі звіряй з офіційною документацією.

    Одна велика задача — «пройдися всім e2e-набором, познач флакі-тести (flaky) за патернами падінь і запропонуй фікс кожному» — теоретично під силу одному . На практиці він захлинається: у контекст лягають десятки , простирадла логів, тупикові гіпотези, і за кілька десятків кроків модель уже гірше памʼятає, з чого почала, а рахунок за токени тихо росте. Замість одного агента, що тоне у власному контексті, роботу ділять: провідний агент роздає шматки , кожен працює у своєму чистому вікні й повертає лише вичавку.

    Для QA це не екзотика, а спосіб масштабувати рутину — аудит набору тестів, широкий пошук по кодовій базі, розбір пачки падінь — без того, щоб один агент задихнувся. Уміння пояснити, навіщо взагалі сабагенти і чому вони коштують кратно дорожче, відрізняє «чув про модне» від «розумію механіку». Ця глава — канонічний розбір; оглядово патерн уже згадувався у главі Агенти й agentic loop.

    (context window) скінченне, і що більше в ньому накопичується, то дорожче й гірше працює модель: кожен крок агента перевідсилає всю історію, а на довгому контексті модель ще й гірше тримає деталі (механіку розібрано у главі Токени, контекст і вартість). Один агент на великій задачі неминуче засмічує собі контекст: туди лягають проміжні викиди інструментів, які більше не знадобляться, і покинуті гіпотези, від яких модель уже відмовилась. Це прямо бʼє по якості й по рахунку.

    Ділення розвʼязує три різні проблеми — і плутати їх не варто:

    • Ізоляція контексту. Сабагент робить брудну роботу (пошук, читання купи файлів, перебір варіантів) у своєму вікні, а провідному агенту повертає лише підсумок. Головний контекст лишається чистим. Це — головна причина, а не паралелізм.
    • Паралелізм. Незалежні підзадачі виконуються одночасно, тож wall-clock (реальний час до результату) коротшає.
    • Спеціалізація. Кожен сабагент має власний і власний, обмежений набір інструментів: окремий «дослідник», окремий «рецензент», окремий «кодер».

    Ключова думка: навіть на одній машині, без жодного паралелізму, сабагенти виправдані — бо тримають головний контекст чистим. Паралелізм — приємний бонус, а не суть.

    Анатомія сабагента: контекст, задача, звіт

    Сабагент (subagent) — це окремий екземпляр моделі зі своїм контекстним вікном, власним системним , власним набором дозволених інструментів і власними дозволами. Він не бачить історію провідного агента й не ділить із ним памʼять. Уся взаємодія зводиться до трьох речей:

    • Контекст — те, з чим сабагент стартує: його системний промпт (роль та інструкції), доступні йому інструменти й порожня, свіжа історія. Нічого з того, що вже накопичив оркестратор, сюди автоматично не потрапляє.
    • Задача — конкретне доручення, яке передає оркестратор. Оскільки сабагент не бачить розмови вище, задача має бути самодостатньою: шляхи до файлів, потрібні факти, критерій готовності — усе в тексті доручення.
    • Звіт — єдине фінальне повідомлення, яке сабагент віддає назад. Уся його проміжна робота (десятки кроків, простирадла виводу) лишається в його контексті й не перетинає межу — назад іде тільки вичавка.

    У Claude Code це оформлено буквально так. Сабагент — це Markdown-файл із YAML-фронтматером у .claude/agents/ (для проєкту) або ~/.claude/agents/ (для всіх ваших проєктів):

    ---
name: flaky-hunter
description: Аналізує падіння e2e-тестів і позначає флакі за патернами. Використовувати при розборі червоного прогону.
tools: Read, Grep, Glob, Bash
model: sonnet
---

Ти — аналітик стабільності тестів. Для кожного падіння визнач,
чи це флакі, за патерном (таймаут / гонка / дані), і поверни короткий звіт.

    Тіло файлу — це системний промпт сабагента; tools обмежує його інструментарій; model дозволяє посадити дешевшу роботу на дешевшу модель. Поле description — не декор: саме за ним провідний агент вирішує, коли делегувати задачу цьому сабагенту, тож опис має чітко казати «для чого я і коли мене кликати».

    Передача контексту: вузький канал

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

    Звідси два практичні наслідки, на яких сиплються найчастіше:

    1. Задача має бути самодостатньою. Сабагент осліп до контексту оркестратора. Доручення «полагодь ці тести» без переліку файлів і симптомів приречене: сабагент або вигадає деталі, або зробить не те. Добрий бриф — це, по суті, добре написаний баг-репорт, відданий інженеру, якого не було в кімнаті.
    2. Звіт має бути повним. Якщо сабагент знайшов точний шлях до зламаного , але не вписав його у звіт, — оркестратор цього вже не дістане: транскрипт сабагента зник. Межа лоссі (з втратами, lossy), тож інтерфейс звіту треба проєктувати, а не сподіватися, що «і так зрозуміло».

    Схематично видно, чому проміжна робота не засмічує головний контекст:

    Сабагент (свій контекст)ОркестраторСабагент (свій контекст)Оркестраторкрок 1... крок 2... крок Nлягає лише в контекст сабагентау головний контекстповертається тільки звітЗадача (самодостатній бриф)Звіт (лише підсумок)Сабагент (свій контекст)ОркестраторСабагент (свій контекст)Оркестраторкрок 1... крок 2... крок Nлягає лише в контекст сабагентау головний контекстповертається тільки звітЗадача (самодостатній бриф)Звіт (лише підсумок)

    Оркестрація

    Оркестратор (orchestrator) — це провідний агент, чия робота не «зробити самому», а розбити, роздати, звести:

    • Розбити мету на підзадачі, які можна виконати незалежно.
    • Роздати кожну сабагенту з самодостатнім брифом (і, за потреби, під потрібну спеціалізацію).
    • Зібрати звіти.
    • Звести їх у фінальний результат: узгодити суперечності й вирішити, чи потрібен ще раунд роботи.

    Сам оркестратор — теж агент у циклі (agentic loop): тільки його «дії» — це не запуски тестів, а виклики сабагентів, а «спостереження» — їхні звіти. Тому він теж може зациклитись чи згубити мету, і ті самі запобіжники (ліміт кроків, умови зупинки) тут потрібні. Канонічний патерн — (orchestrator-workers): провідний агент динамічно вирішує, на скільки й яких підзадач бити, а не працює за жорстко прописаним планом.

    Ні

    Так

    Мета

    Розбити на підзадачі

    Роздати сабагентам

    Зібрати звіти

    Достатньо?

    Звести результат

    Ні

    Так

    Мета

    Розбити на підзадачі

    Роздати сабагентам

    Зібрати звіти

    Достатньо?

    Звести результат

    Оркестратор тримає загальну картину й план; сабагенти тримають деталі. Це і є поділ праці: одному вікну — стратегія, іншим — брудна тактика.

    Паралельний запуск

    Коли підзадачі незалежні, оркестратор може запустити сабагентів одночасно й дочекатися всіх звітів. Виграш — у реальному часі: три пошуки по різних частинах кодової бази, зроблені паралельно, завершаться приблизно за час найдовшого з них, а не їхньої суми.

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

    • добре паралеляться read-heavy віяльні задачі: пошук, аудит, збір інформації — вони нічого не змінюють, тож не заважають одне одному;
    • погано паралеляться write-heavy звʼязані задачі, де кроки залежать від результатів сусіда: тут послідовність дешевша й безпечніша.

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

    Headless-режим у CI

    Інтерактивний агент у терміналі розрахований на людину поруч, яка підтверджує дії. У CI людини немає — і тут вмикається headless-режим (безголовий, неінтерактивний). У Claude Code це -p (або --print): агент отримує промпт, робить роботу, друкує результат і завершується.

    claude -p "Проаналізуй лог падіння і познач ймовірну причину" \
  --allowedTools "Read,Bash" --output-format json

    Кілька речей, критичних саме для CI:

    • . --output-format json віддає результат машиночитним (є ще text і stream-json), тож наступний крок може його розпарсити. У JSON-відповіді повертається й вартість запуску — зручно стежити за витратами.
    • Дозволи без людини. Головний запобіжник агента — human-in-the-loop () — у headless зникає: підтверджувати нема кому. Тому інструменти доводиться дозволяти наперед (--allowedTools) і тримати список вузьким. Для закритих CI-прогонів є суворі режими дозволів, що забороняють усе, крім явно дозволеного.
    • без нагляду. Скрипт може запустити агента, який сам роздасть роботу сабагентам, — і все це відпрацює без людини. Саме тому в CI особливо важить безпека: незворотні дії (видалення даних, , git push) без гейта — це та сама каскадна біда з глави про агентів, тільки тепер без нагляду. Тримайте прогон у , давайте read-only там, де можна, і обмежуйте інструментарій (докладніше — у главі про безпеку й приватність при роботі з AI).

    Типові QA-сценарії headless: падінь у нічному прогоні, генерація тесту з тікета, лінтер-рецензент на дифі PR. Базовий й дозволи розібрано у главах Claude Code: базовий воркфлоу для QA і Памʼять, скіли та слеш-команди.

    Ціна оркестрації

    Мультиагентність — не безкоштовна. Платити доводиться за кількома статтями:

    • Токени, і багато. Кожен сабагент — це окреме вікно з власним системним промптом і власною наростаючою історією; кожен крок кожного агента перевідсилає свою історію. За оцінкою Anthropic, їхня багатоагентна дослідницька система спалювала приблизно у 15 разів більше токенів, ніж звичайна чат-взаємодія. Сам вузький канал теж коштує: бриф униз і звіт угору — це додаткові токени понад корисну роботу.
    • Складніший дебаг. Коли результат поганий, причина може бути в поганому розбитті оркестратора, у роботі конкретного сабагента або у зведенні звітів. Недетермінізм (глава про те, як працюють LLM) множиться на кількість агентів — відтворити фейл важче.
    • Координаційний оверхед. Погане розбиття знецінює всю роботу сабагентів: якщо оркестратор дав нечіткі брифи, звіти будуть неякісні, і зводити нема чого.

    Звідси висновок, спільний із главою про агентів: спершу найпростіше рішення. Один агент дешевший і передбачуваніший; сабагенти виправдані лише тоді, коли задача справді ділиться на незалежні шматки і виграє від ізоляції контексту (широкий пошук, аудит, дослідження). Для тісно звʼязаної послідовної роботи один агент упорається дешевше.

    Типові помилки

    Виглядає як економія контексту, а насправді роздутий рахунок. Дрібну задачу розбили на сабагентів — і кожен наново завантажив системний промпт, описи інструментів, свій контекст. На малому обсязі накладні витрати зʼїдають будь-яку вигоду; сабагенти окупаються лише на масштабі.

    Виглядає як паралелізм, а насправді гонка. Кілька сабагентів одночасно правлять ті самі файли або сидять на тих самих тестових даних — конфлікти й недетермінований результат, як у неізольованих паралельних тестів. Паралелити можна лише незалежне.

    Виглядає як передана задача, а насправді сабагент осліп. Бриф написали так, ніби сабагент бачить розмову оркестратора. Він не бачить — і або вигадує деталі, або повертає не те. Лікується самодостатнім дорученням.

    Виглядає як звіт, а насправді половина загублена. Сабагент зробив роботу, але у звіт не вписав ключову знахідку (той самий шлях до файлу). Оркестратор її вже не дістане — транскрипт сабагента зник. Проєктуйте звіт як повний артефакт.

    Виглядає як автономний CI-ран, а насправді знятий запобіжник. Headless прибирає human-in-the-loop; сабагент із правами на запис чи деплой і без нагляду — це незворотні дії без гейта. У CI інструменти мусять бути обмежені туго.

    Підсумок

    • Сабагент = окремий екземпляр моделі зі своїм свіжим контекстом. Назад до оркестратора повертається лише звіт, а не транскрипт роботи.
    • Головна причина ділити — ізоляція контексту, а не паралелізм: сабагент тримає брудну роботу у своєму вікні, головний контекст лишається чистим.
    • Канал між оркестратором і сабагентом вузький і лоссі. Задача вниз має бути самодостатньою, звіт угору — повним; що не передав — того нема.
    • Паралелити можна лише незалежне. Спільний змінюваний стан (ті самі файли, ті самі дані) = гонка, точно як у паралельних автотестів.
    • Оркестрація коштує кратно дорожче (близько 15x токенів у Anthropic) і важче дебажиться. Спершу — найпростіше рішення; сабагенти виправдані лише на великих задачах, що діляться.
    • Headless знімає human-in-the-loop — у CI обмежуйте інструменти туго й гейтьте незворотні дії.

    Можливі питання

    • «Навіщо взагалі сабагенти, чому не один агент?» — інтервʼюер слухає, чи назвете ізоляцію контексту, а не лише «щоб швидше». Сильна відповідь: один агент на великій задачі засмічує собі контекст, сабагент робить брудну роботу у своєму вікні й повертає вичавку.
    • «Як оркестратор передає роботу сабагенту і що отримує назад?» — очікують «самодостатній бриф униз, звіт угору; транскрипт сабагента назад не перетинає». Бонус — що межа лоссі, тож бриф і звіт треба проєктувати.
    • «Коли мультиагентність — overkill?» — червоний прапорець, якщо кандидат тулить сабагентів усюди. Сильний назве ціну (кратно більше токенів, складніший дебаг) і «спершу найпростіше»: для звʼязаної послідовної роботи один агент дешевший.
    • «Що небезпечного в запуску агента headless у CI?» — чекають: зникає human-in-the-loop, тож інструменти треба обмежити наперед, а незворотні дії — гейтити або тримати в пісочниці.

    Джерела

    Навіщо ділити роботу

    • Claude Code Docs — Create custom subagents — у переліку вигід джерела збереження контексту стоїть першим, а паралелізму в ньому немає взагалі: саме це й робить ізоляцію головною причиною.
    • Claude Code Docs — Best practices for Claude Code — контекст названий фундаментальним обмеженням, а сабагенти — одним із найпотужніших доступних інструментів проти нього.
    • Claude Platform Docs — Context windows — механіка під цим: попередні ходи зберігаються повністю, тож кожен крок перевідсилає всю історію, а з ростом вікна деградує пригадування.
    • Anthropic Engineering — How we built our multi-agent research system — компресія як суть, а не побічний ефект: сабагенти згущують найважливіші токени для провідного агента.

    Анатомія сабагента: контекст, задача, звіт

    • Claude Code Docs — Create custom subagents — сабагент робить роботу у власному контексті й повертає лише підсумок; файл — Markdown із YAML-фронтматером, обовʼязкові name і description, є tools, model і maxTurns, а тіло стає системним промптом.
    • Anthropic Engineering — How we built our multi-agent research system — чотири обовʼязкові частини брифа: мета, формат виводу, вказівка щодо інструментів і джерел, чіткі межі задачі.

    Передача контексту: вузький канал

    • Claude Code Docs — Create custom subagents — сабагент стартує зі свіжого ізольованого вікна й не бачить історії розмови, викликаних і прочитаних файлів; делегувальне повідомлення складає провідний агент.
    • Anthropic Engineering — How we built our multi-agent research system — без детального брифа агенти дублюють роботу або лишають прогалини; втрату на межі обходять виводом у файлову систему й легкими посиланнями нагору.
    • Claude Code Docs — Run Claude Code programmatically (headless) — підтвердження лоссі-межі з боку потоку: за замовчуванням назовні виходять лише блоки tool_use і tool_result сабагента, а не його транскрипт.

    Оркестрація

    • Anthropic Engineering — Building Effective Agents — сам патерн: центральна модель динамічно розбиває задачі, делегує їх і синтезує результати, причому підзадачі не задані наперед; там же — умови зупинки як частина дизайну.
    • ISTQB CT-GenAI Syllabus v1.1 — вендор-нейтральне означення оркестрації як координованої роботи кількох агентів і шкала автономності (автономні проти напівавтономних).
    • Claude Code Docs — Overview — продуктове втілення того самого: провідний агент координує роботу, призначає підзадачі й зводить результати.

    Паралельний запуск

    • Anthropic Engineering — How we built our multi-agent research system — виміряний виграш (провідний агент піднімає 3–5 сабагентів паралельно) і межа: домени зі спільним контекстом і багатьма залежностями паралеляться погано.
    • Claude Code Docs — Create custom subagents — продуктовий запобіжник проти гонки за файли: isolation: worktree, тобто окрема копія репозиторію на сабагента.
    • Claude Code Docs — Common workflows — той самий прийом для паралельних сесій: окремі git-worktree, щоб правки не стикалися.

    Headless-режим у CI

    • Claude Code Docs — Run Claude Code programmatically (headless) — прапорець -p, три формати виводу, total_cost_usd у JSON-відповіді, --allowedTools і режим dontAsk для замкнених CI-прогонів.
    • Claude Code Docs — Best practices for Claude Code — це штатний спосіб інтегрувати агента в CI-пайплайни й pre-commit-хуки; там же — пісочниця з ізоляцією на рівні ОС.
    • OWASP — LLM06:2025 Excessive Agency — чому в CI ставки вищі: без нагляду під контролем лишаються тільки функціональність і дозволи, а надмірна автономія тут максимальна за побудовою.

    Ціна оркестрації

    • Anthropic Engineering — How we built our multi-agent research system — джерело чисел і межі: агент витрачає ≈4× токенів проти чату, мультиагентна система ≈15×, і виправдана вона лише там, де цінність задачі покриває приріст; там же — синхронне виконання як вузьке місце.
    • Claude Platform Docs — Context windows — звідки береться нелінійність: вхідна фаза кожного ходу містить усю попередню історію, а попередні ходи зберігаються повністю.
    • Anthropic Engineering — Building Effective Agents — та сама ціна в загальному вигляді: автономність означає вищі витрати й потенціал накопичення помилок.

    Пояснення

    «Поясни» працює з власним API-ключем Anthropic: запит іде з вашого браузера прямо до Anthropic.

    Свій API-ключ (BYOK)

    Вставте власний ключ Anthropic — пояснення працюватиме на реальній моделі. Ключ зберігається лише у вашому браузері (localStorage), нікуди не надсилається, крім api.anthropic.com, і не логується.

    Знайшли помилку?