Ваш перший робочий процес агента починається з одного промпту та кількох інструментів. Він відповідає на запитання. Він перевіряє статус замовлення. Він працює, тож ви його випускаєте.
Потім продукт росте. Відділ продажів просить оновлювач CRM, який синхронізує нотатки зустрічей. Служба підтримки потребує робочого процесу повернення коштів, що зачіпає три внутрішні системи. Інженерний відділ додає дії в браузері для заповнення форм постачальників. Кожен запит здається незначним. Кожен отримує свій власний файл промпту, свою гілку в Slack, своє власне «швидке виправлення». Через шість місяців ваш агент перестає бути єдиною системою. Він перетворюється на розрізнену купу скопійованих промптів, прихованих бізнес-правил і рішень, прийнятих у старих чатах, які ніхто не може знайти. Це — «розростання промптів» (prompt sprawl). Через це ваш ШІ-продукт стає важко тестувати, важко перевіряти та неможливо впевнено відкотити до попередньої версії.
Вирішенням є реєстр навичок (skill registry) ШІ-агента.
Що насправді являє собою навичка (skill)
Навичка — це не просто промпт, збережений у папці. Це версіонований пакет, що піддається тестуванню, який визначає, що саме робить агент, які інструменти він може викликати та чого йому категорично заборонено робити. Думайте про це як про контракт між вашою командою та машиною. Коли агент завантажує навичку, він має чітко розуміти свої межі та те, як виглядає успішне виконання завдання.
Без такої структури кожен промпт перетворюється на крихітну, незадекларовану продуктивну систему. Він несе в собі приховані дозволи, вбудовані бізнес-правила та вплив на витрати, які ніхто не відстежував. Він віддаляється від реального продукту, тому що дорожня карта продукту рухається вперед, а промпт залишається на місці. Найгірше те, що його копіюють. Хтось робить форк для демо-версії або вставляє його в новий мікросервіс, і ось у вас уже є два джерела істини, що розходяться в темряві.
Чому самі лише промпти не працюють
Промпти виглядають як текст, тому команди ставляться до них як до конфігурації. Насправді вони ближчі до коду, ніж хтось готовий визнати. Продуктивний промпт зазвичай кодує логіку послідовності дій, форматування, обробки помилок та контролю доступу. Коли ця логіка існує лише у формі природної мови, виникає неоднозначність. Чи має агент дозвіл оновлювати CRM, чи промпт просто запропонував це зробити? Якщо API білінгу перестане працювати, чи знає промпт, як безпечно завершити роботу з помилкою, чи він просто галюцинує повідомлення про успіх?
Витрати — це ще один «тихий убивця». Промпт, який просить агента «думати крок за кроком і проводити ретельний пошук», може спалювати величезну кількість токенів під час кожного запуску. Коли такий промпт копіюють у високонавантажений потік підтримки, ваш щомісячний рахунок за інференс подвоюється, і ніхто не розуміє чому.
«Дрейф» (drift) стається тоді, коли бізнес змінюється, а текст — ні. Наприклад, ваша політика повернення коштів тепер потребує схвалення менеджера для сум понад певний поріг. Якщо це правило живе всередині промпту, а не на рівні політик, вам доведеться перевіряти кожне розгортання, щоб знайти копії, які потребують оновлення. Пропустите одну — і ваші агенти почнуть роздавати гроші, які не повинні.
Анатомія продуктивної навички
Якщо ви хочете уникнути цього хаосу, ставтеся до кожної навички як до програмного артефакту. Корисна продуктивна навичка включає більше, ніж просто текст. Їй потрібні:
- Назва та призначення. Не «prompt_v3_final», а «process_standard_refund» із чітким описом бізнес-цілі.
- Схема вхідних даних та необхідний контекст. Визначте точні поля, які очікує навичка. Чи потрібен їй ID користувача, історія розмови, ідентифікатор тенанта? Сувора типізація тут запобігає припущенням з боку агента.
- Дозволи на інструменти та межі безпеки. Чітко перелічіть інструменти, які може викликати навичка. Встановіть обмеження (guardrails) на повторні спроби, ліміти витрат і обмеження частоти запитів. Якщо навичка не повинна чіпати API видалення користувачів, вкажіть це в коді, а не лише в тексті.
- Критерії успіху та тестові випадки. Навичка не вважається «робочою» лише тому, що вона виконується. Визначте, що саме має містити результат. Для навички повернення коштів успіх може означати валідований запис транзакції, надіслане підтвердження електронною поштою та створений запис в аудиторському журналі.
- Історія версій та відповідальний. Хтось має відповідати за це. Журнал змін (changelog) має пояснювати, чому з'явилася версія v2.3 і що зламалося у v2.2.
Розділяйте рівні
Найбільша помилка команд — це намагання запхати все в один промпт. Вони змішують дружні вказівки, документацію інструментів, політику безпеки та обробку помилок у суцільну стіну тексту. Це неможливо підтримувати.
Розділіть їх:
- Інструкції (Instructions) — це настанови для агента. Вони пояснюють тон, формат і загальний підхід.
- Правила інструментів (Tool Rules) — повідомляють агенту, які інструменти існують і що вони роблять. Це ознайомлення, а не надання дозволу.
- Політика (Policy) — забезпечується кодом, а не надією. Якщо повернення коштів на суму понад $500 потребує перевірки іншою особою, ця перевірка має бути в функції валідації, яка запускається ще до виклику інструменту.
- Евалюації (Evals) — це тести, які доводять, що навичка все ще працює після будь-яких змін.
Наприклад, не пишіть: «Будь ласка, ніколи не розкривайте повний номер кредитної картки клієнта». Замість цього створіть форматульник даних, який приховує PAN-номери до того, як їх побачить агент. Політика має бути в коді, тому що з кодом неможливо домовитися за допомогою хитрого вводу користувача.
Припиніть спрямовувати продакшн на «latest»
Ніщо так не псує вечір п'ятниці, як тихе оновлення промпту. Якщо ваш продакшн-агент завжди підтягує «latest» версію навички, то кожен мердж у main — це потенційний інцидент у реальному часі. Вам потрібні аліаси, такі як dev, staging та prod. Просувайте відому, протестовану версію через ці етапи. Коли prod вказує на v2.1.4, ви можете спостерігати за її роботою, вимірювати її поведінку та спокійно спати. Якщо щось піде не так, ви просто переведете аліас назад. Ви не будете налагоджувати природну мову опівночі під тиском.
Ця дисципліна також змушує вашу команду думати про зворотну сумісність. Чи зможе v2.2 обробляти таку ж структуру вводу, як і v2.1? Якщо ні, то просування провалиться на етапі staging, і ви помітите це раніше за клієнта.
Безпека починається всередині пакета
Реєстр, повний неаудитованих промптів, — це вразливість, що чекає на свій час. Вам потрібно сканувати свої навички на ті ж ризики, які ви скануєте в коді.
Шукайте жорстко закодовані секрети або API-ключі, заховані в шаблонах промптів. Перевіряйте наявність зовнішніх вебхуків або команд оболонки (shell commands), які можуть викрадати дані. Стежте за спробами обійти системну політику, наприклад, промптами, що містять «ignore previous instructions» або просять агента розкрити власну конфігурацію. Це не просто теорія. Це поширені патерни атак типу prompt-injection, і вони небезпечні, оскільки часто приходять разом із скопійованим текстом, який ніхто не перевіряв.
Пропускайте свої пакети навичок через статичний аналіз. Якщо файл навички містить URL-адресу, якої немає в білому списку (allowlist), зупиняйте збірку. Якщо він посилається на інструмент, якого немає в затвердженому маніфесті, відхиляйте його.
Якщо ви не можете це протестувати, ви не можете цьому довіряти
Реєстр без евалюацій — це просто папка з промптами. Кожна навичка потребує набору тестів, які перевіряють основний сценарій (happy path), граничні випадки (edge cases) та режими відмови. Для навичок високого ризику вам потрібно більше, ніж просто функціональні тести. Вам потрібно перевіряти межі дозволів, щоб переконатися, що агент не може бачити дані іншого користувача. Вам потрібні перевірки поведінки відмови, щоб підтвердити, що він каже «ні», коли політика блокує дію. Вам потрібні тести на стійкість до prompt-injection, щоб переконатися, що зловмисні вводи не обходять захист на рівні коду.
Давайте тестам чіткі назви. Тест під назвою refund_skill_rejects_negative_amount точно каже наступному інженеру, яка саме поведінка захищена. Коли тест провалюється під час просування версії, ви маєте вагомі докази того, що кандидат на збірку є небезпечним.
Справжня мета — контроль
Повторне використання — це добре, але саме контроль забезпечує вашу зайнятість. Реєстр навичок дозволяє вашій команді з упевненістю заявити: ось затверджений робочий процес. Ось версія, що працює в продакшні. Ось інструменти, які вона може використовувати. Ось саме так ми здійснюємо відкат.
Така чіткість переводить вас від випуску хитрих демо-версій до експлуатації надійного програмного забезпечення. Демо-версії вражають стейкхолдерів на десять хвилин. Надійне ПЗ працює о третій годині ночі, елегантно обробляє винятки та не змінює поведінку лише тому, що хтось об'єднав pull request у вівторок після обіду.
Створюйте свій реєстр. Версіонуйте свої навички. Забезпечуйте дотримання політик у коді. Тестуйте так, ніби від цього залежить ваш режим сну. Ваше майбутнє «я» подякує вам.