🔧 Що таке Skill?
У контексті AI-агентів, skill (також називається tool or function) це упакована, багаторазова можливість, яку LLM може викликати для взаємодії з зовнішнім світом поза вікном контексту. Навички долають розрив між розумінням мови та дією в реальному світі.
Кожна навичка має чотири компоненти:
- Name — унікальний ідентифікатор, який модель використовує для посилання на навичку (наприклад,
web_search) - Description — текст природною мовою, що пояснює, що робить навичка і коли її використовувати; LLM читає це, щоб вирішити, коли викликати навичку
- Схема вводу — структурований опис аргументів (JSON Schema); модель заповнює їх на основі завдання
- Implementation — власне код, який виконується: виклик API, запит до бази даних, shell-команда або будь-яка інша операція
Приклад: A get_weather навичка має опис «Fetches current weather for a city», приймає { "city": "string" } як вхідні дані і викликає weather API. LLM ніколи не бачить API-ключа або HTTP-виклику — вона просто отримує результат у вигляді тексту.
⚙️ Як працює виклик інструментів
Коли агент має доступ до навичок, LLM не викликає їх безпосередньо — вона requests виклик, генеруючи структурований вихід. Рантайм (ваш прикладний код) виконує фактичний виклик і повертає результат. Ось повний цикл:
- Реєстрація інструменту — Ваш код надсилає моделі список доступних навичок з їхніми описами та схемами
- Міркування моделі — LLM читає завдання та доступні інструменти, вирішує, який інструмент викликати і з якими аргументами
- Запит на виклик інструменту — Модель виводить структуроване повідомлення «tool call" (наприклад,
{ "tool": "web_search", "args": { "query": "current Gemini models" } }) - Execution — Ваш рантайм викликає фактичну функцію, API або сервіс
- Впровадження результатів (result injection) — Результат додається назад у контекст розмови
- Продовження міркувань — Модель читає результат і або викликає інший інструмент, або ставить уточнювальне питання, або генерує остаточну відповідь
Цей цикл може повторюватися багато разів в одному ході. Складне агентне завдання може викликати 10–20 інструментів підряд перед тим, як сформувати остаточну відповідь.
📊 Навички vs Плагіни vs MCP Servers
Термінологія швидко розвивалася. Ось як поняття історично співвідносяться:
| Era | Name | Як це працювало | Status |
|---|---|---|---|
| 2023 | ChatGPT Plugins | Розширення, які користувачі могли встановлювати з OpenAPI spec; ChatGPT викликав їх через HTTP | Застаріло (замінено GPTs + tools) |
| 2023 | OpenAI Function Calling | Визначення JSON Schema на рівні API; модель виводить структурований function call, ваш код виконує його | Активне — перейменовано в «tool use» |
| 2023– | Tool Use / Skills | Те саме, що function calling; Anthropic ввів термін «tool use», інші використовують «skills» або «functions» | Активна — поточний стандарт |
| 2024– | MCP Servers | Стандартизований протокол (Anthropic, Dec 2024) для упакування та розповсюдження серверів інструментів; будь-який MCP client може підключатися до будь-якого MCP server | Активна — зростаюча екосистема |
Ключова відмінність: Традиційне використання інструментів визначається вбудовано у код вашого застосунку. MCP servers — це автономні процеси, які експонують інструменти через стандартизований протокол — роблячи їх повторно придатними для різних AI-клієнтів (Claude Desktop, Cursor, VS Code, кастомні агенти). Читати далі: Що таке MCP.
🗂️ Категорії інструментів і рівні ризику
Не всі інструменти мають однаковий ризик. Групування за рівнем ризику допомагає визначити вашого агента простір дій і де додавати контрольні точки human-in-the-loop:
| Category | Examples | Risk | Recommendation |
|---|---|---|---|
| Read-only | web_search, read_file, get_weather, list_dir | Low | Дозволити автономно; логувати всі виклики |
| Write (local) | write_file, create_dir, edit_code | Medium | Обмежити роботу каталогу до пісочниці |
| Network / External | send_email, post_to_slack, call_api | Середньо–Високий | HITL-погодження для незворотних відправлень |
| OS / Shell | run_command, execute_script, install_package | High | Обмежити до контейнеризованого середовища; потрібен HITL |
| Destructive | delete_file, drop_table, revoke_access | Critical | Завжди вимагати явного підтвердження людиною |
🏗️ Анатомія хорошої навички
Найважливіше проектне рішення для навички — її description. LLM читає описи, щоб вирішити, який інструмент викликати — погано складений опис призводить до неправильного вибору інструмента, пропущених викликів або неоднозначних аргументів.
Що робить опис ефективним
- Будьте конкретні щодо того, коли її використовувати — «Use this tool when the user asks about real-time data or current events» краще за «Searches the web»
- Вкажіть, чого вона НЕ робить — «Does not return historical data older than 30 days»
- Опишіть формат виводу — «Returns a JSON array of search results with title, url, and snippet fields»
- Тримайте опис до 200 слів — описи довші ~200 токенів можуть перевантажувати увагу моделі, коли зареєстровано багато інструментів
Принципи проєктування схем
- Обов’язкові vs необов’язкові — Позначайте поля як required лише коли це дійсно необхідно; необов’язкові поля з значеннями за замовчуванням зменшують помилки моделі
- Використовуйте enum для обмежених значень —
"format": {"enum": ["json", "markdown", "text"]}запобігає галюцинаціям значень - Надавайте перевагу ідемпотентним інструментам — Інструменти, які можна безпечно повторювати (операції читання, пошуку), безпечніші, ніж одноразові дії (відправлення, видалення)
- Повертайте структуровані дані — JSON-відповіді легше для моделі, ніж неструктурований текст
💡 Приклади з реального світу
| Назва навички | Що вона робить | Ключові аргументи | Risk |
|---|---|---|---|
web_search | Запитати пошукову систему й повернути найкращі результати | query: string, num_results?: number | Low |
read_file | Прочитати файл з робочого каталогу | path: string, offset?: number, limit?: number | Low |
write_file | Створити або перезаписати файл | path: string, content: string | Medium |
run_tests | Запустити тестовий набір проекту та повернути результати | filter?: string | Medium |
browser_screenshot | Перейти на URL і повернути скріншот | url: string | Medium |
send_email | Відправити електронний лист одному або кільком одержувачам | to: string[], subject: string, body: string | Високий — завжди HITL |
run_shell | Виконати довільну shell-команду | command: string, cwd?: string | Високий — потрібна пісочниця |
✅ Кращі практики
Мінімальні права
Надавайте агенту лише ті інструменти, які потрібні для його конкретного завдання. Агент, що відповідає на FAQ, не потребує write_file or send_email. Чим менший простір дій, тим менший радіус ураження, якщо агента будуть маніпулювати. Див.: Надмірна автономія агента.
Аудитуйте всі виклики інструментів
Логуйте кожен виклик інструменту з його аргументами та результатом. Це дає змогу відлагоджувати, розподіляти витрати та виявляти аномальну поведінку (наприклад, агент, що читає ~/.ssh/ коли він мав доступ лише до каталогу проєкту). Платформи AgentOps, як-от LangSmith, спрощують це.
Human-in-the-loop для незворотних дій
Будь-яка дія, яку важко або неможливо скасувати — відправлення повідомлень, видалення даних, здійснення покупок — повинна вимагати явного підтвердження людиною перед виконанням. Вбудовуйте HITL-контрольні точки у час виконання агента, а не лише в підказку. Підказки можна перевизначити; код — ні.
Остерігайтеся отруєння інструментів (tool poisoning)
Якщо ви дозволяєте агентам динамічно встановлювати або виявляти MCP servers, зловмисний сервер може зареєструвати інструмент із описом, що містить приховані інструкції. Завжди переглядайте описи інструментів перед додаванням їх у реєстр агента. Див.: Tool Poisoning.
Пишіть чіткі повідомлення про помилки
Коли інструмент зазнає невдачі, повертайте структуровану помилку з достатнім контекстом, щоб модель могла відновитися або підняти ескалацію — а не сирий стек виключення. Приклад: { "error": "rate_limited", "retry_after": 5 }. Добре описана помилка дозволяє агенту повторити дію, використати запасний інструмент або ввічливо повідомити користувача.