Підагенти на практиці: ролі, бюджети, заборони та беззвучні помилки

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

Знання — це проблема навичок. Роль — це проблема підагента, і саме про це йдеться в цій статті.

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

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

Прогалина, яку заповнює підагент

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

Усе це не означає, що модель є слабкою. Їй бракує ролі. Людина, яка перевіряє безпеку, думає про інші речі, ніж інженер з безпеки, а той, хто шукає помилки, аналізує інші докази, ніж людина, яка вже тричі розбиралася саме з цією проблемою під час чергування. Інтелект вже є. Бракує лише правильного форматування інформації.

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

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

• Економіка контексту. Дослідження є складними: двадцять пошуків, десяток отриманих сторінок, з яких половина марна. Якщо це відбувається під час основної сесії, вона заповнюється непотрібними даними, які ви ніколи не хотіли читати. Роботу потрібно виконувати в іншому місці та потім отримувати результат у вигляді резюме. Саме тому існує агент веб-пошуку. Він не є розумнішим за основний процес, а його мета — просто виключити прочитане з вашого контексту.
• Розділення ролей. Під час роботи над дизайном ви хочете залишатися в межах дизайнерської дискусії. Відволікання для схвалення одинадцятої механічної зміни, яка є прямим наслідком вже прийнятого рішення, є марною тратою часу. Тож рішення залишаються у людини, а введення даних — у агента-виконавця. Здібності не мають значення для цього розділення; воно визначає, хто повинен думати про що.

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

Навички проти підагентів: знання проти дій

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

Підагент об’єднує те, як агент має діяти: що він оптимізує, що перевіряє спочатку, які компроміси він обирає за замовчуванням та у якій формі має надаватися відповідь. Він не навчає модель нічого нового. Він спрямовує вже наявний інтелект на виконання певної задачі.

Корисним тестом є уявлення про те, що ви телефонуєте спеціалісту-колезі. Якщо те, що він може запропонувати, — це переважно інформація, якої у вас немає (знання в конкретній галузі, контекст, практичний досвід), то вам потрібна навичка. Якщо ж він пропонує переважно спосіб підходу до проблеми — тобто що він спочатку розглядає, що для нього має велике значення, що він відмовляється схвалити без перевірки та що він повертає назад — тоді вам потрібен підагент.

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

Знання належать до навичок. Методологія належить до підагента.

Що таке підагент у Claude Code

Claude Code є основним інструментом тут, оскільки він використовується щодня. Інші інструменти розміщені у окремому розділі нижче, разом із їхніми особливостями.

Усередині Claude Code субагент насправді є не чим іншим, як Markdown-документом, який починається з короткого блоку YAML. Його можна зберігати у двох каталогах:

• ~/.claude/agents/ — це особиста бібліотека, доступна у кожному проекті на машині. Сприймайте її як сандбокс.
• .claude/agents/ усередині репозиторію є прив’язаним до цього проекту та переходить разом із репозиторієм після збереження змін.

Фронтматер короткий. Ось повний працездатний приклад:

---
name: migration-risk-reviewer
description: Reviews database migration plans and schema changes for rollback risk, lock contention, and data integrity problems. Use before running any migration against real data.
tools: Read, Grep, Glob
model: sonnet
---

You are a senior database engineer reviewing a migration for production risk.

## What you look at first

- Can this be rolled back without losing data?
- Does it hold locks on a busy table during deploy?
- Is the ordering safe for a multi-step change?
- Will existing data violate any new constraint?

## Output shape

Findings in order of severity:

1. Blockers — deploy will fail or data will be lost
2. High risk — real production risk, needs a mitigation
3. Medium risk — should fix, won't necessarily block
4. Notes — worth tracking

For each finding: what it is, why it matters, what to do about it.

Є кілька аспектів того, як Claude Code обробляє такий файл, які варто знати.

• Основна частина — це системний запит. Усе, що знаходиться під frontmatter, стає інструкціями для підагента під час його виконання. Це не документація, яку модель читає та потім діє згідно з нею. Модель читає цей текст та сприймає його як свою ідентичність.
• description має велике значення. Claude Code користується ним, щоб вирішити, коли автоматично передати завдання, тому пишіть його так, ніби це API, яке інші мають знайти з контексту. Фраза „Використовувати перед виконанням будь-якої міграції“ може бути включена, а фраза „Допомагає з роботою з БД“ — ні. Також необхідно включити негативну інформацію: обидва обговорювані тут агенти описують, для чого вони не призначені, адже система охоче передасть їм завдання, які їм не підходять.

tools — це список дозволених елементів. Якщо його пропустити, підагент успадковує все. Якщо ж обмежити його, рецензент фізично не зможе редагувати ваші файли, навіть якщо у нього з’являться ідеї. Для агента-рецензента це є перевагою, адже варіант «просто скажіть, що не так» не повинен змінювати речі за примхою.

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

У нього є власне вікно контексту. Люди недооцінюють це: підагент працює у окремому контексті та повертає короткий огляд, тож ваша основна сесія не заповнюється всім, що він прочитав. Саме через це також виникають проблеми, і у наступному розділі показано, як це відбувається.

Вам не потрібно вручну створювати файл. Опишіть роль Claude Code, і він створить файл у правильному місці. Команда /agents також керує ними.

Ви можете викликати підагента, попросивши про це, дозволивши Claude направити запит до нього на основі опису, або включивши його до більшого процесу, де він працює як делегований працівник. У кожному випадку поведінка залишається однаковою.

Слово „агент“ виконує занадто багато функцій

Цей термін використовується щодо чотирьох різних речей, і їхнє плутання спричиняє постійну плутанину. Розглянемо їх окремо:

• Підагент (файл у .claude/agents/ або файл .agent.md у середовищі Copilot) — це повторно використовуваний файл, який визначає спеціалізовану роль. Саме про це йдеться в статті.
• Режим агента або автономна робота — це перемикач функцій. Ви дозволяєте інструменту виконувати команди та редагувати файли без необхідності схвалення кожної рядка. Це налаштування дозволів та не має нічого спільного зі спеціалістами.
• Агент кодування на фоні чи в хмарі — це сервіс, який бере завдання, працює над ним непомітно та повертає гілку чи запит на з’єднання. Це також не є спеціалізованим файлом.
• Файл інструкцій на рівні репозиторію — це постійні рекомендації, правила, яких дотримується кожен агент у цьому кодовому базі. Уявіть собі його як посібник для співробітників, а не колегу, якого ви називаєте на ім’я.

Кожного разу, коли далі згадується „підагент“, це означає повторно використовуваного спеціаліста, створеного один раз та запускаються за потреби. Якщо чітко розуміти ці чотири поняття, це розв’яже приблизно половину плутанини.

Створення першого

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

Перші підагенти найчастіше зазнають невдач через нечітко визначену роль. „Допоміжний інструмент безпеки“ не є справжньою роллю, оскільки в ньому немає жодних вказівок щодо того, що саме потрібно оптимізувати чи спочатку перевіряти. Справжня роль є своєрідним поведінковим контрактом, який охоплює саме завдання, перші етапи його виконання та те, що ніколи не можна проігнорувати. Якщо завдання неможливо сформулювати одним реченням, воно занадто розпливчасте.

Конкретна версія чітко визначає, що має значення для моделі, а що їй слід ігнорувати. Ігнорування — це половина цінності. Рецензент, який надає однакову вагу опечатці та межам привілеїв, є просто машиною для усереднення.

Що входить до основної частини

Після визначення ролі корисна основна частина охоплює п’ять аспектів. У перший день не потрібні всі п’ять.

1. Що вона оптимізує. Єдине, що ця роль намагається досягти найбільш ретельно. Коли виникає компроміс, саме це вона намагається зберегти.
2. Що вона перевіряє спочатку. Сигнали найвищого пріоритету — це те, що будь-який справжній фахівець читає перед усім іншим.
3. Способи збою. Конкретні способи, якими цей тип роботи може піти не так. Справжня експертиза полягає саме тут, і більшість її аспектів стає зрозумілими лише шляхом спостереження за тим, як агент помиляється під час виконання реальних завдань.

Формат результату. Це має бути не просто „якісь відгуки“, а результати, впорядковані за ступенем серйозності, поетапний план чи ранжований список гіпотез. Прогнозований результат — це найбільша практична перевага порівняно зі звичайним запитом.

Що воно не повинно робити. Раніше цей розділ вважався необов’язковим, але тепер це не так. У найбільш використовуваному агенті це найдовша частина файлу, і кожен рядок у ньому стосується конкретної ситуації.

Почніть з опису ролі, перших перевірок та формату результату, а решту нехай доповнять помилки.

Приклад: мисливець на баги, який ігнорує останні зміни

Ось приклад, що виник через постійні проблеми. Щось ламається, помилку копіюють у Claude Code, і його першою реакцією є перегляд файлу, який останнім було змінено. Іноді це правильно. Але часто остання зміна не має до проблеми жодного відношення.

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

---
name: bug-investigator
description: Investigates a bug or failure starting from evidence, not from recent code changes. Produces ranked hypotheses with the next diagnostic step for each. Use for "why is this broken" before touching the source.
tools: Read, Grep, Glob, Bash
---

You are a senior engineer investigating a failure. Your job is to find the most
likely cause, rule out the alternatives, and say what to check next.

## Investigation order

1. Start from the symptom — what is actually failing, and how does it show up?
2. Get the error output and any logs from around the time it broke — ask the caller for them if they weren't provided.
3. Only then look at recent changes, and only if the evidence points there.
4. Read source last, once there's a symptom-to-cause hypothesis worth testing.

## Output shape

**Symptoms:** what's failing and how it manifests.
**Likely causes (ranked):** for each — the hypothesis, the evidence for it, the next diagnostic step.
**Ruled out:** what you checked and why it isn't the cause.
**Next steps:** in priority order.
**Open questions:** what you still can't confirm.

## Failure modes to avoid

- Don't assume the last change is the cause without evidence.
- Don't propose a fix before you can name the mechanism.

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

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

Протилежність очікуваному: підагент починає роботу з нуля

Усі представляють ізольоване вікно контексту як чисту перевагу. Але це має і негативні наслідки.

Речення потрапило до агента-реалізатора після того, як одна передача даних зламалася трьома різними способами. У ньому описується, що агент добре знає проект, але нічого не знає про планування, яке передувало завданню.

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

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

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

У цій конфігурації об’єктом передачі є файл TASKS.md у корені репозиторію, створений за допомогою навички планування. Активне завдання містить саме ці розділи та більше жодних:

• Мета. Що буде істинним після завершення роботи.
• Чому (посилання). Посилання на рішення, записане у PLAN.md, а не новий аргумент на його підтримку. Це посилання, а не проза.
• Стан виконання. Агент постійно оновлює цей розділ. Деталі нижче, адже саме він допомагає вам уникнути проблем.

Дизайн у вигляді пронумерованих етапів. Послідовна черга, де [ ] означає «не розпочато», [x] — «завершено», а [!] — «блоковано»; залежності вказуються безпосередньо, наприклад залежить від #2.

Файли. Місце, де відбувається робота.

Тести. Перевірки, які замінюють процес рецензування.

Поза межами сфери. Найцінніша частина всього документа.

Звіт про результати. Що має міститися у кінцевому повідомленні.

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

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

Стан виконання, оскільки сесії закінчуються

Одне правило допомогло вирішити більше реальних проблем, ніж будь-яка хитра техніка формулювання запитів. Кожного разу, коли агент зупиняється — чи то завершив роботу, чи зіткнувся з перешкодою, — він повинен фіксувати поточний стан справ: позначати статус кожного етапу та оновлювати запис про стан виконання, у якому вказується, що вже зроблено, що заблоковано та чому, що залишилося та де можна продовжити. Редагування TASKS.md з цією метою прямо входить до обов’язків, адже цей файл є точкою відновлення у разі збою сеансу.

Сеанси все ж таки збиваються. Ноутбук закривається, з’єднання втрачається, досягається ліміт використання, або ви набридаєте та натискаєте Ctrl-C на роботі, яка майже завершена. Коли це трапляється з підагентом, усе, що він знав, зникає. Якщо єдиний запис про прогрес зберігався лише в його пам’яті, тепер доводиться порівнювати свій репозиторій із власною пам’яттю, щоб здогадатися, наскільки він просунувся.

Тому агент фіксує прогрес на диску по мірі виконання роботи, безпосередньо у тому файлі, який був призначений для виконання завдання. Наступна сесія відкриває цей файл та продовжує роботу з місця, де було зроблено позначку. Вона додає кілька рядків до визначення агента та перетворює завершену сесію з категорії „втрачена робота“ на категорію „зупинена сесія“.

Супутнє правило стосується пропускної здатності, а не відновлення. Заблокований елемент не зупиняє чергу. Коли елемент недостатньо описаний або стикається з нерозв’язною залежністю, агент позначає його символом [!] разом із однорядковим поясненням та продовжує роботу з будь-якими іншими елементами, які від нього не залежать, зупиняючись лише тоді, коли більше немає можливості продовжити. Він ніколи не припускає формат проекту, а кожен заблокований елемент потрапляє до звіту для подальшого розгляду людиною.

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

Хто платить за який тип мислення

Тут поля model відіграють ключову роль, і економіка налаштувань залежить від нього.

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

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

Такий підхід також дозволяє отримати два різні ритми роботи від одного й того ж обладнання.

• З контролем темпу. Складіть два-три завдання, відправте агента на виконання та плануйте наступну партію, поки він працює. Жодна зі сторін не залишається без діла, чекаючи на іншу.
• Без постійного контролю. Сформуйте велику чергу завдань, потім відійдіть та поверніться до аналізу відмінностей, звіту чи запису про стан виконання, де вказано, яке завдання заблокувалося та чому.

Під усім цим знаходиться шар дозволів, який насправді контролює дії. У автоматизованого виконавця команди файлів та оболонки внесені до списку дозволених у налаштуваннях проекту, а все, що не входить до цього списку, зупиняється на перевірку. Те, що зазначено в інструкціях, — це політика; список дозволених — це бар’єр.

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

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

Без бюджету він витрачає все

Будь-який підагент із інструментами на кшталт пошуку, отримання даних чи оболонки буде продовжувати працювати, поки щось його не зупинить, а висновок „цього достатньо“ — це не той висновок, до якого модель може надійно дійти самостійно. Дослідницький агент без бюджету може витратити півдня на низку прихованих вкладок браузера та надати огляд, який могли б надати три перші результати пошуку.

Отже, агент для пошуку в Інтернеті починає свою роботу з суворих обмежень, які стоять вище за його методологію та все інше. Скрипти, які він завантажує під час роботи та які містять списки джерел та тактики запитів для кожного домену, розміщені у окремому розділі нижче.

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

Надайте можливість вибору рівня глибини замість фіксованого ліміту. Більшість часу будь-яке окреме налаштування є неправильним: занадто суворе для складного запиту чи занадто ліберальне для швидкого пошуку фактів. За наявності трьох визначених рівнів та зазначеного стандартного значення вибір режиму deep стає свідомим рішенням, а не випадковістю. Також чітко визначено порядок пріоритетів: спочатку діють значення, вказані користувачем, потім рівень, зазначений у запиті, далі налаштування проекту, і нарешті режим standard.

Бюджет спонукає до гри, оскільки модель розглядає його як ціль, тому необхідні положення, що обмежують це. Важливі положення передбачають отримання одного результату за кожною URL, ніколи не перечитувати вже прочитану сторінку, зупинятися як тільки на запитання користувача дано відповідь, а залишок бюджету розглядати не як квоту. Глибокий запуск, який завершується після шести пошуків, вважається успішним, а не марним.

Останнє речення було додано після того, як запуск відповів на запитання на четвертому пошуку, але продовжив роботу, оскільки цифра 20 була встановлена як кінцева мета. Потрібно вголос сказати, що завершення роботи раніше — це перемога.

Підрахуйте елементи, які щось коштують. Бюджет на отримання даних включає кожне завантаження з мережі — від стандартних запитів до кожної спроби отримання заблокованих сторінок та кожного HTTP-запиту в допоміжному скрипті; крім того, кожна спроба повторного запуску з кодом 429 у цьому скрипті також підраховується окремо. У ранній версії підраховувалися лише „запити на отримання даних“, і агент випадково пройшов крізь цю прогалину. Це не було обманом — він просто слідував некоректно написаному правилу.

Змусьте його повідомляти про витрати. Після кожної фази агент повідомляє рядок на кшталт [deep: 3/20 пошуків, 5/30 отримань даних]. Без цього неможливо відрізнити ретельну роботу від неконтрольованого процесу до самого кінця. Якщо бюджет закінчується, а питання залишаються без відповіді, агент зупиняється та чітко вказує, що саме залишилося невідомим, який URL найімовірніше дасть відповідь, а також що можливим є повторний запуск у більш глибокому рівні. Єдиним забороненим кроком є продовження роботи після досягнення ліміту без попередження, адже користувач сам обрав рівень, і перевитрати скасовують цей вибір.

Обмеження складають основу зрілого агента

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

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

Ще один приклад походить від розробника у репозиторії research-agent, де саме цей механізм є основною причиною, чому хтось буде дотримуватися правила. Він ніколи не повинен створювати файли у каталогах agents/ чи skills/, оскільки agents/ є частиною завантажуваного вмісту, а менеджер пакетів під час встановлення перетворює кожен файл типу .md, який знаходиться там, на окремого агента верхнього рівня. Випадковий файл у цих каталогах потрапить у кожен проект-користувач.

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

Ще кілька форм, які можуть набути ці обмеження з часом:

Забороніть категорію та перелічте конкретні випадки. Просте формулювання „заборонено автоматизацію браузера“ залишає на розсуд агента вирішення питання про те, чи підпадає панель попереднього перегляду під цю заборону. Перелік шести конкретних інструментів, які він не може використовувати, закриває можливість для того, щоб він знайшов спосіб обійти це обмеження.

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

Необхідно створити умови для вихідного варіанту, інакше все перетвориться на звичайну автомагістраль. Деякі сторінки справді неможливо отримати, тому існує ієрархія альтернативних способів для заблокованих URL. Вона активується лише тоді, коли звичайний шлях для цього URL зазнає невдачі. Вона не отримує додаткових можливостей для завантаження, перевіряє наявність встановленого інструменту без його встановлення та обмежує обсяг виводу, щоб витік даних сторінки не заповнив весь контекст. Після цього настає остаточна зупинка: якщо URL залишається недоступним після використання всіх доступних варіантів, все закінчено. Запишіть це та переходьте далі, без подальших спроб, без додаткових інструментів та без винахідливих рішень.

Поясніть детально, чому це виняток не є лазівкою. У файлі є короткий абзац, у якому пояснюється, що одноразове безвіконне отримання простого тексту не порушує заборони на використання браузера, оскільки ця заборона стосується керування браузером та залишення вікон, які потрібно закрити. Якщо цього не зазначити, здається, що виняток та заборона суперечать один одному, і модель, стикаючись із такою суперечністю, обирає тлумачення, яке дозволяє більше.

Вони зазнають невдач мовчки та впевнено

Два дослідження колись дали результати, які були не просто гарними, а й відмінними: чіткі висновки, справжні джерела, послідовний звіт. Обидва вказували Reddit як основне джерело. Проте жодне з них не отримало жодної інформації з Reddit.

Сталося так, що запит WebSearch із обмеженням site:reddit.com повернув десять чистих, правдоподібних результатів з інших доменів, серед яких форум спільноти ринку ремесел, сайт уряду про малі підприємства та сайт для обміну слайдами, без жодних проблем. Жодного коду 403, жодного порожнього набору даних, жодних попереджень. Фільтр доменів був мовчки проігнорований, і в результатах це не відображалося. Агент отримав акуратний список корисних сторінок з неправильних джерел та зробив те, що робить будь-який розсудливий працівник із таким списком: він скористався ними та повідомив про успіх.

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

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

Існує три способи вирішити цю проблему, і жоден з них не полягає у тому, щоб попросити агента бути обережнішим.

Пройдіть механічну перевірку. Жодних помилок не виявлено, тому агент не бачив причин для перевірки чого-небудь. Рішення полягає у одному реченні, яке не потребує оцінки: коли пошук обмежений певним доменом, а жоден з отриманих URL не належить до нього, слід вважати це нульом результатів, а не набором результатів. Це не вимагає додаткових інструментів, запитів чи дозволів, адже URL вже є. Фраза «Будьте підозрілими щодо своїх джерел» не дає агенту жодних дій, тоді як фраза «Перевірте ім’я хоста порівняно з тим, яке ви використовували для фільтрації» дає чіткі вказівки.

Розглядайте джерело походження як обов’язковий канал виведення даних із схемою. Саме тут форма виведення перестає бути просто набором заголовків розділів та починає поводитися як тип даних. Два масиви прив’язуються до своїх імен ключів.

• unreachable[] містить по одній запису для кожної стіни, причому ключі точно дорівнюють source, url та reason. Він охоплює як повні відмови у отриманні даних, так і безпроблемну заміну.
• sources[] містить по одній запису для кожного джерела, яке дійсно надало відповідь, причому ключі точно дорівнюють source, url та fields. Сторінки, які були відкриті, але не надали жодної інформації, не фіксуються. Джерело, яке надало відповідь щодо чотирьох полів, утворює одну запис із чотирма іменами, а не чотири окремі записи.

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

Кожна невдача несе з собою урок, який варто використати. У першій версії цього агента було вказано, що потрібно „записати це як недосяжне“ у чотирьох різних місцях, проте так і не було названо жодного поля, масиву чи поля виводу. Ця інструкція ні до чого не призвела. Агент мусив щось записувати, але не мав куди це покласти, тому він нічого не записав, і ніхто не скаржився. Кожного разу, коли ви пишете інструкцію для підагента, переконайтеся, що дія, яку вона описує, має місце призначення. „Звітність X“ без вказаного поля для X нічого не робить та сприймає це як нормальне.

Перевіряйте ззовні агента. Чи дотримується агент умов свого виводу, вирішується за допомогою скрипта, який запускається пізніше, а не за словами самого агента. Близько 180 рядків коду на Python перевіряють JSON на відповідність оголошеним полям, і це має більшу цінність, ніж будь-які наголоси в самій інструкції.

Та сама ідея знову зустрічається у інструкціях для реалізатора у випадку репозиторію без набору тестів. У інструкціях зазначено, що такого набору немає; у розділі «Тести» завдання перелічуються перевірки, які замінюють собою тести — кожну з них потрібно виконати та конкретно задокументувати результати. Якщо перевірка передбачає фразу «ця URL відповідає», це означає фактичне отримання її вмісту. URL, який не вдалося підтвердити, не потрапляє до файлу; про нього повідомляється як про непідтверджений разом із описом того, що сталося, адже читач, який довіриться посиланню, яке ніхто не перевіряв, витратить ресурси на отримання 404-ої сторінки, чого можна було б уникнути за допомогою звичайного пошуку, що робить неперевірену URL ще гіршим варіантом, ніж її повне відсутність.

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

Одне завдання на агента та звички, які розростають файл

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

Усі розширені версії виглядають однаково, і кожна з них колись була випущена. Є „рецензент усього“, який усереднює п’ять аспектів та не демонструє переваг у жодному з них. Є позначка „старший інженер“, за якою не стоїть жодної конкретної функціональності. Є агент, який переписує ваш CLAUDE.md, додаючи інформацію про вартість токенів замість опису поведінки, а також агент, який дублює певну навичку, поки обидві версії не почнуть сильно відрізнятися. Усі вони мають одну основну помилку: завдання, яке стало занадто складним для виконання.

Очевидне наступне запитання — що, після року такої ситуації, насправді залишається у використанні.

Два, які вижили

Більшість публікацій на цю тему пропонують схему організації типів агентів для створення. Насправді після року залишаються лише два агенти, і це все.

Одна заява, оскільки до неї застосовується власне правило статті: агент веб-пошуку починався як форк проєкту з відкритим кодом для глибоких досліджень. Скелет контракту результату, тобто розділи зі зведенням та список джерел, які завжди є обов’язковими, був взятий без суттєвих змін безпосередньо з вихідного коду. Контрольний рівень, який додається зверху та охоплює бюджети, заборони, схему походження та ієрархію ескалації, є оригінальним та становить половину загальної кількості рядків. Усе, що стосується аспектів, пов’язаних із «шрамами», у цій статті, стосується саме цієї половини.

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

Впроваджувач виконує повністю визначений чергу завдань, тоді як планування продовжується в іншому місці. Чотири проекти мають такого впроваджувача. Саме ці чотири проекти надали уроки щодо контрактів передачі обов’язків, стану виконання та економіки делегування.

Решта елементів, які знаходяться у папках агентів, надійшли разом із фреймворками, і вони функціонують як сховище „сміття“ з кращим брендуванням, ніж справжнє сховище. Спеціалісти, яких вважали необхідними (дослідник проблем з тестуванням, агент з опрацюванням PR, автор документації, агент для керування кодовою базою у проектах, які були покинуті) — усі вони здавалися розумними вибором, проте майже жоден з них не був створений. Ті, що залишилися, виявилися не тими, які здавалися корисними. Це ті випадки, коли одна й та сама конкретна проблема у роботі постійно повторювалась у неправильному контексті чи у неправильній особі.

Тоді пропустіть схему організації. Зверніть увагу на роботу, яку б хотіли виконати в іншому місці, та збережіть саме її.

Спочатку шаблон, потім спеціалізація

Схема, яка робить других, третіх та четвертих виконавців дешевшими, полягає у наступному: агент генерується зі шаблону, а потім адаптується там, де проект відрізняється.

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

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

Копія іншого проєкту отримала вказівку вивчати рішення з файлу PLAN.md, на які вказує завдання, перед тим, як почати програмування, а також поле для звіту про все, що потребує втручання Opus чи людини. Протокол залишається таким самим, але ризики відрізняються.

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

Направте агента до знань, а не вставляйте їх безпосередньо

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

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

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

Це зауваження про те, що список змінюється, поки запит залишається незмінним, є повним обґрунтуванням цього паттерну. Знання (які джерела відповідають на які типи запитань, як їх запитувати, що є заблокованим) змінюються щомісяця, тоді як метод залишається незмінним. Якщо вбудувати список джерел у структуру агента, кожне нове джерело змушуватиме вносити зміни до запиту, який інакше залишився б незмінним, і тоді агент буде впевнено маршрутизувати запит до модуля, який було видалено ще у березні.

Дві механіки виявилися важливішими, ніж очікувалося.

Кандидати у порядку, а не один шлях. Агент працює у проектах, налаштованих по-різному, на двох машинах під різними іменами користувачів, створеними різними інсталяторами. Тому інструкція перераховує місця розташування кандидатів у послідовності та пропонує використовувати перше з них, копії локальні до проекту перед копіями на рівні користувача. Якщо закодувати один шлях, все буде працювати лише на одній машині.

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

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

Де знаходяться файли: особисті, проєктні, запаковані

Існує три рівні, і саме на третьому проживають усі справжні агенти.

• Особисті (~/.claude/agents/) призначені для загальних спеціалістів, яких потрібно у кожному проєкті. Вважайте їх майстернею, де допускається ламати речі.
• Проєктні (.claude/agents/, комітовані) — це спеціалісти, які мають сенс лише в одному кодбазі, наприклад, реалізатор, який знає, що в цьому проєкті відсутні тести. Комітуйте їх, і вони будуть чекати на вас щоразу, коли ви повернетеся, навіть через чотири місяці після того, як проєкт вийшов з вашої пам’яті.
• Упаковані (встановлені менеджером пакетів та прив’язані до конкретного коміту) роблять агента залежністю. Це той рівень, про наявність якого ніхто не здогадується, поки той самий агент не опиниться у десятку репозиторіїв, а тринадцять копій не почнуть віддалятися одна від одної.

Третій рівень змінює кілька аспектів, і краще знати їх ще до того, як ви до нього дістанетеся.

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

Дізнайтеся, що робить ваш інсталятор з файлами. Цей пакет встановлюється через APM від Microsoft, який перетворює кожен файл формату .md, що знаходиться у каталозі agents/, на окремого агента верхнього рівня. Цей стандартний підхід є розумним, але все одно має негативні наслідки. Якщо розмістити там файл даних, кожен проект-споживач отримає фальшивого зареєстрованого агента. Якщо ж записати туди агента, специфічного для проекту, він встановиться у репозиторіях усіх користувачів. Саме тому модулі стратегій пошуку знаходяться у каталозі skills/, а не у каталозі agents/, де, здавалося б, їм місце: у agents/ вони втратять свою структуру під час встановлення та створять по п’ять фантомних агентів у кожному проекті-споживачі.

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

Проте варто проріджувати. Папка, наповнена перекриваючимися та напівзабутими агентами, створює лише шум замість корисних інструментів. Об’єднайте два агенти, які виконують однакові завдання. Видаліть той, який не працював місяцями, адже історія git збереже його, якщо видалення виявиться помилковим. Це також гарна порада щодо організації роботи, але її ігнорують через справжній „сміттєвий кошик“ вдома.

Та сама ідея в інших інструментах

Claude Code — не єдиний інструмент для цього. Якщо ви користуєтесь різними інструментами, ці ідеї можна застосувати навіть там, де формати файлів відрізняються.

GitHub Copilot та VS Code називають це спеціальними агентами, які зберігаються у вигляді файлів .agent.md, зазвичай у директорії .github/agents/, з можливістю створення особистої бібліотеки у каталозі користувача. У фронтматері є більше полів, ніж у Claude: окрім попередніх name, description та tools, тут є argument-hint, model, user-invocable, disable-model-invocation, а найкраще — handoffs. Готовий агент може мати кнопку, яка передає завдання іншому агенту з вже заповненим наступним запитом, тож планування, реалізація та перевірка відбуваються послідовно, не зливаючись у одного заплутаного агента. Це пастка, якщо читати старі приклади: колишнє поле infer перетворилося на два окремі поля — user-invocable та disable-model-invocation; згодом ця зміна здається логічною, але спочатку викликає плутанину.

Ще одне твердження, з яким ви можете зустрітися, полягає у тому, що VS Code виявляє файли .claude/agents/ та перекладає назви інструментів, тож один агент може обслуговувати обидва інструменти без додаткових витрат. Це частково правда, але може вводити в оману. Словники інструментів не збігаються, і запит, який забороняє використання інструментів за назвою, як це робить кожен зрілий агент, не залишається недоторканим під час автоматичного перекладу.

Натомість використовується один канонічний запит разом із невеликим нативним модулем для кожного інструменту. Усій частині агента з боку Copilot у пакеті вистачає одинадцяти рядків:

---
name: Web Research Writer
description: "Use for bounded web research that must read a local schema, search and fetch current sources, write one designated result file, and validate it with a local command."
tools: [read, search, web, edit, execute]
user-invocable: false
disable-model-invocation: false
---

Load the installed canonical research prompt from the first existing candidate:

1. `.github/agents/web-search-agent.agent.md`
2. `.claude/agents/web-search-agent.md`

Follow its search budgets, module routing, source standards, tool discipline, output, and validation rules. Ignore that file's incompatible `tools` frontmatter; this wrapper's Copilot-native tool categories govern this session.

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

У документі README проекту вказано одну проблему. Якщо спрямувати завантажувач на .github/agents/, канонічний запит реєструється як окремий агент, тому Copilot може показувати дублюючіся назви: шим „Web Research Writer“ та канонічний файл під ним. Виберіть одне місце розташування для кожного інструменту або залиште канонічний файл у .claude/agents/, де автоматичне виявлення Copilot його ігнорує.

Усе інше, включаючи Cursor та Windsurf, підпадає під одну категорію під назвами такими як правила, режими чи агенти. Деталі часто змінюються, тому краще направити вас до поточної документації кожного інструменту, ніж з упевненістю стверджувати щось, що змінилося минулого місяця. Основний принцип залишається незмінним: це повторно використовуваний файл, який визначає роль та активується навмисно. Якщо зрозуміти це один раз, то далі залишається лише знайти, де кожен інструмент знаходить свою папку.

Як насправді створюються якісні інструменти

Кожен з підагентів тут спочатку був занадто загальним. Існував „рецензент“, який переглядав усе, „планувальник“, який не мав думки щодо того, яким має бути план, та „дослідник“, який підходив до кожної проблеми так само, як і до попередньої. Це не невдача — це відправна точка.

Корисною частиною, тією, яка могла б допомогти рік тому, не є „ітерація“. Усі кажуть про ітерації. Саме з них складаються ітерації.

Перечитайте наведені вище файли агентів та зверніть увагу, де знаходяться слова. Один абзац — для ролі. Одна сторінка — з обмеженнями. Схема з вказаними назвами ключів. Механічне правило для виявлення. Числовий бюджет із положенням проти його обходу. Примітка про необхідність розкриття інформації про оплачені запити. Заборона, яка пояснює, що робить інсталятор із відхиленнями. Майже все це фіксує одну конкретну проблему, яка виникла в певний момент.

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

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

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

Подивіться на роботу, яку б хотіли побачити в іншому місці. Це підагент, який все ще чекає на своє використання. А останній раз, коли підагент вас підвів, це була рядок, який ще чекав на написання.

Пов’язана література

• Практичні нотатки: Покроковий посібник з розробки вашого особистого агента — Детальний огляд Практичних нотаток: Покроковий посібник з розробки вашого особистого агента: контракти, перевірки та блоки коду для команд, які використовують цю модель.
• Практичні нотатки: Qwen3.8–27B як новий вибраний агент для програмування з SGLang/vLLM та — Детальний огляд Практичних нотаток: Qwen3.8–27B як новий вибраний агент для програмування з SGLang/vLLM та: контракти, перевірки та блоки коду для команд, які використовують цю модель.

The Harness Is the Product: A Practical Guide to Harnesses in Agentic AI — Дізнайтеся, що таке кріплення агента та скільки у нього є елементів: від інструментів та контексту до правил та механізмів оцінки, а також про підагентів, способи збоїв та корисні фреймворки.