Мрія про Ідеального Помічника: Як Я Навчився Майстерності “Скілів” у Штучному Інтелекті (І Ви Теж Можете, Не Обмежуючись Однією Платформою)
За роки моєї роботи в бізнес-аналізі та автоматизації, я переконався, що найціннішим активом є здатність адаптувати нові технології до потреб користувачів. Сьогодні поділюся досвідом, як я перетворив простий інструмент на потужного помічника з використанням концепції “скілів” штучного інтелекту, яку популяризувала компанія Anthropic. Я не просто розкажу про це, а й продемонструю, як ви, незалежно від вашої поточної інфраструктури, можете інтегрувати цю технологію, щоб суттєво підвищити ефективність своїх ШІ-агентів.
Особистий досвід: За останні 20 років я керував сотнями проектів з автоматизації, впроваджував системи бізнес-аналітики та працював з різними платформами штучного інтелекту. З кожним проектом я все більше переконувався в необхідності гнучких та масштабованих рішень. Саме це спонукало мене глибше вивчити концепцію “скілів”, від якої я побачив миттєву цінність.
Що ж таке ці “скілли”? Якщо просто, то це інструменти, які роблять вашого ШІ-агента розумнішим, не перевантажуючи його зайвою інформацією. Представте собі: замість того, щоб впихати в мозок вашого агента всі доступні знання, ви даєте йому доступ до цих знань тільки тоді, коли вони дійсно потрібні. Це як мати доступ до цілої бібліотеки, а не змушувати себе вчити напам’ять кожну книгу. Саме на цьому базується підхід Anthropic, і, мабуть, саме тому їх система викликала у мене таку повагу – за цілковиту логічність.
Я особисто вивчив код Anthropic Claude і, занурившись у їхню реалізацію “скілів”, одразу задався питанням: “Чому таке рішення не було стандартним з самого початку ери генеративного ШІ?”. Адже, по суті, й до Anthropic були спроби створення розширень для ШІ-агентів. Однак, саме компанії вдалося зробити цю ідею дієвою та простою у використанні. Я, як досвідчений користувач, ціную таку простоту надзвичайно.
І ось що важливо: ви не обмежені екосистемою Claude. Я впевнений, що, незалежно від вашого досвіду, ви зможете інтегрувати концепт “скілів” та “поетапного розкриття” в будь-який ШІ-агент або інструмент, який використовуєте. Сьогодні я розкажу, як це зробити. Секрет полягає в тому, що ви не повинні бути прив’язані до конкретного постачальника.
Я віддаю належне Anthropic за те, що вони вивели цю ідею на новий рівень. Але важливо розуміти, що це універсальна концепція. Ключ до успіху – це стратегія: як дозволити вашому агенту знаходити контекст та можливості в той момент, коли він їх потребує. Це робить його адаптивнішим та ефективнішим з точки зору використання ресурсів. На відміну від, наприклад, “MCP-серверів”, коли всі інструменти загружаються в пам’ять одночасно, перевантажуючи великі мовні моделі (LLM).
Я прихильник таких інструментів, як Claude Desktop чи Claude Code. Але, з досвіду, скажу: не завжди є бажання обмежуватися лише цими платформами. Часто виникає необхідність інтегрувати “скілли” у власні робочі процеси або ШІ-агенти. Можливо, ви віддаєте перевагу іншим потужним мовним моделям, або навіть локальному штучному інтелекту. Причин може бути безліч. Тому саме в цьому ми зараз і розберемося. Ми візьмемо концепції “скілів” від Anthropic і перенесемо їх у вашого власного ШІ-агента, використовуючи системні запити (system prompts) та інструменти, які йому надамо. Це просто, але потужно. Весь процес займе не більше 15 хвилин, а після нього ви точно будете знати, як реалізувати подібне у власних системах. І, звичайно, у мене є готовий шаблон.
Отже, за наступні 15 хвилин ми розглянемо три ключові аспекти:
- Основні принципи роботи “скілів” і чому вони такі ефективні, навіть якщо ви вже їх використовували.
- Мій шаблон – репозиторій на GitHub, посилання на який ви знайдете в описі. Я покажу, як реалізувати власну версію “скілів” в будь-якому фреймворку, використовуючи Pyantic AI як основу. Проте, принцип роботи буде актуальним незалежно від обраного вами інструменту: Langchain, Crew AI, LlamaIndex, або навіть взагалі, без фреймворку.
- Оцінювання (evals) та спостережуваність (observability). Як переконатися, що ваш агент не тільки відповідає інструкціям, а й ефективно використовує надані йому можливості? Це буде корисним бонусом.
Майстер-клас: Що Таке “Скілли” і Чому Вони – Ключ до Ефективності
Давайте розберемося з “скілами”: що це та як вони сприяють ефективності. Anthropic добре описали це в своїй статті. (Посилання буде в описі). Вона детально розкриває найкращі практики створення “скілів”, про які ми теж поговоримо.
Яку проблему вирішують “скілли”? Ми намагаємося озброїти нашого агента якомога більшою кількістю можливостей, не перевантажуючи його контекстне вікно. Перевантаження – це велика проблема для агентів, коли ми надаємо їм багато інформації через інструменти, історію розмов, системний запит.
Інші методи, як-от “MCP-сервери”, мають ту проблему, що ми з самого початку пропонуємо агенту купу інструментів, навіть якщо він ніколи не використає їх у конкретній розмові. Це не найкращий варіант.
А ось “скілли” – це оптимальний підхід. Погляньмо на цю діаграму з оригінальної статті Anthropic. Ось суть їх геніальності: ідея “поетапного розкриття”: замість того, щоб відразу надавати агенту всі інструменти, як це робиться в “MCP-серверах”, ми даємо йому змогу виявляти можливості в міру необхідності.
Єдине, що ми надаємо агенту на початку (в системному запиті, або ж, якщо хочете, це ваш глобальний набір правил) – це опис можливості, або “скілу”. Наприклад, у нас є “скіл” для роботи з PDF. Ми просто кажемо агенту: “У тебе є така можливість, якщо вона тобі знадобиться”. Якщо користувач просить його щось зробити з PDF-файлами, і агент повинен використати цю функцію, він звертається до skill.md.
Файл skill.md – це основний файл, який керує будь-яким “скілом” від Anthropic, і тим, що ми будемо розглядати в нашій власній реалізації. У ньому містяться повні інструкції для можливості. Саме тоді починається завантаження цього файлу у контекст. Це другий рівень “поетапного розкриття”.
Часто “скіл” також посилатиметься на інші документи. Це вже третій рівень “поетапного розкриття”, бо ми можемо завантажити ще більше контексту. Наприклад, якщо нам потрібно заповнити якусь форму в PDF. Не завжди, коли ми працюємо з PDF, нас це цікавить, але іноді – так. Отже, ми поступово виявляємо все більше контексту, коли він нам дійсно потрібен для завдання. Це дозволяє уникнути перевантаження LLM. Адже, якби всі ці документи та ще з десяток “скілів” були завантажені одразу, це були б тисячі токенів, просто щоб одразу повідомити їй про всі можливості, які, ймовірно, вона використає лише одну чи дві за всю розмову.
Переходимо до Практики: Майструємо Свій Світ “Скілів”
Розібравшись з концепцією, перейдемо до шаблону, щоб побачити, як ми можемо відтворити ідеї Anthropic в нашому власному агенті. Я використовую Pyantic AI. Це мій улюблений фреймворк для роботи з ШІ-агентами, з яким я працюю вже понад рік. Він зарекомендував себе як надійний та ефективний інструмент.
Почнемо з опису у форматі YAML (YAML front matter description). За моїми практичними спостереженнями, розмір опису повинен бути від 50 до 100 слів. Не варто одразу завантажувати забагато інформації – це суперечить самій ідеї “скілів”. Опис має бути лаконічним, але інформативним, щоб агент розумів, коли йому необхідно активувати певну можливість. Я оцінюю, що сам “скіл” зазвичай складає близько 5% від загального контексту. Це приблизна оцінка, звісно.
Коли ми працюємо над описом, кожен “скіл”, до якого ми хочемо надати доступ нашому агенту, повинен мати свій опис та шлях до файлу skill.md в системному запиті. Саме тому ми будемо використовувати динамічний системний запит. Ми маємо статичну частину – основні інструкції для агента, які не змінюються. Крім цього, ми збиратимемо описи з усіх YAML-блокнотів (front matters) всіх файлів skill.md та додаватимемо їх до системного запиту. Я навіть покажу вам трохи коду, як це працює, після того, як ми розберемо цю діаграму.
Далі, наш skill.md – основні інструкції для можливості. Згідно з найкращими практиками, цей файл має бути від 300 до 500 рядків. Звісно, це залежить від складності. Він може бути й коротшим, але зазвичай становить близько 30% від загального контексту “скілу”, якщо є багато референсних файлів.
Іноді вам не потрібен цей третій рівень (референсні файли), якщо можливість проста. Але як це реалізується в нашій системі, в нашому агенті? Нам потрібен простий інструмент. Зазвичай, цей інструмент load_skill приймає шлях до skill.md. Агент може викликати його, передати шлях (який буде в системному запиті), і тоді ми беремо вміст skill.md і повертаємо його як відповідь інструмента.
І ось так, це включається в контекст агента. Бо кожного разу, коли ми викликаємо інструмент, все, що він повертає, стає частиною короткострокової пам’яті агента. Ось як легко це працює! Отже, пам’ятайте: системний запит містить опис та шлях до “скілу”. Він містить увесь контекст, необхідний, щоб агент знав, коли йому слід активувати “скіл”, і який параметр слід передати, щоб прочитати цей файл.
І в skill.md ми можемо мати посилання на наші референсні файли – третій рівень “поетапного розкриття”: скрипти та markdown-файли для читання та використання, щоб розширити можливості. Для цього у мене є другий інструмент у системі. Він приймає як параметри назву “скілу” та шлях до другого файлу, який ви хочете використати. Тут ви маєте безмежну глибину. Можливо, четвертий рівень “поетапного розкриття”, але це, мабуть, буде занадто складно. Решта вашого “скілу” просто житиме в цих файлах.
Я можу об’єднати ці інструменти. Вони працюють дуже схоже, бо в основному йдеться про читання певного файлу. Але, з мого досвіду тестування, агенту корисно знати це розрізнення. Наприклад: “Це основний набір інструкцій для вашої можливості”. І це все. Я ж казав, що це буде просто. І я також покажу вам код для агента Pyantic AI трохи пізніше, після демонстрації.
Усі ці різні “скілли”, які я включив у шаблон, – їх досить багато. Ви можете розширити це до десятків і десятків, і агент все одно буде працювати добре, бо для кожної можливості використовується лише невелика частина контексту.
Жива Демонстрація: Мій Ігровий Майданчик для ШІ-Агентів
Отже, зараз я продемонструю роботу мого власного агента Pyantic AI зі “скілами”. Агент завантажений у терміналі. Це мій власний гральний майданчик для тестування всіх “скілів”, які я додав. Я просто можу помістити будь-які “скілли” у папку skills, так само як і в Claude Code. Він використовує шаблон, посилання на який ви знайдете в описі. Там є інструкції, які пояснюють, як працюють “скілли”, і короткий гайд. Запуск дуже простий. Ви можете сміливо використовувати це як ресурс. Передайте це своєму помічнику з кодування ШІ, якщо хочете інтегрувати це самостійно. Для роботи з моїм агентом я використовую ідею “набору інструментів” (toolset) у Pyantic AI. Тож ви повинні мати змогу витягти це і легко додати “скілли” до вашого власного агента. Тож, будь ласка, зазирніть сюди.
Коли я запускаю термінал, він зчитує всі файли skill.md у моїй папці skills. Він завантажує всі ці “скілли”, і тепер я можу використовувати будь-який з них. Наприклад, я вводжу: “Допоможи мені знайти гарну страву на вечерю з куркою”. Він задіє “рецепт-шукач”. Я навмисно залишив усі логи, щоб показати, що відбувається насправді. Ви можете бачити, як він використовує інструмент, адже ми завантажуємо “скіл” recipe_finder. І з нього ми маємо інструкції, щоб зрозуміти, як використовувати якийсь API, що надається цією можливістю. Зараз він робить запит, щоб отримати рецепти з куркою. Дивіться! Знайшов багато варіантів з куркою. Вау. Ок, тепер я зголоднів.
Але добре, тепер я можу, наприклад, сказати: “Яка зараз погода в Токіо, Японія?”. І ось тут ми побачимо, як він використає інший “скіл”. Ось воно! Він завантажує “інструмент погоди”. Він робить запит до API. Знаєте, чому він це робить? Виключно через інструкції, які ми маємо. Я навіть можу сказати йому: “Завантаж референсний документ для “скілу” погоди”, бо там є третій рівень “поетапного розкриття”, якщо йому потрібно більше інформації. Я маю цей API-референс. Тож він може робити складніші запити. Це трохи примусово, але я просто намагаюся показати приклад третього рівня “поетапного розкриття”. Дуже, дуже круто.
І найважливіше тут те, що, виходячи з нашої розмови з агентом, нам, ймовірно, потрібно буде використовувати лише один або два “скіли” одночасно. Ось, чому я навмисно обрав різні “скілли”, які дуже відрізняються один від одного, щоб підкреслити, що в більшості випадків нам не потрібні всі. Якби ми мали “MCP-сервер” для кожного з них, ми б просто перевантажували нашу LLM без причини.
Заглиблюємося під Капот: Код, Який Робить Це Можливим
Давайте подивимося на фрагмент коду, щоб ви побачили, як усе працює “під капотом”. Навіть якщо ви не технар, я буду пояснювати загалом, щоб показати, як ви можете використовувати цього агента.
Перш за все, в Readme я додав інструкції з налаштування. Ви можете змінити це у змінних оточення. Одна з речей, яку ви можете вказати, – це директорія, де він шукає, щоб динамічно завантажити всі “скілли” у вашого агента. Щоб наблизитись до реалізації Anthropic, я назвав директорію skills, так само, як це робиться в Claude Code.
Отже, тут є папка для кожного “скілу”, який ми маємо. Це виглядає так само, як “скілли” Anthropic: у нас є skill.md. Це наш YAML-блокнот (front matter). Це опис, який завантажується агенту одразу. Я покажу вам, як це працює з динамічним системним запитом. Агент знає: “Окей, якщо я хочу використовувати API погоди, дозволь мені прочитати весь цей файл skill.md, щоб я міг його використовувати, і я знаю, як це робити.”
А потім третій рівень “поетапного розкриття” є необов’язковим. Але для багатьох з них у нас є папка reference для перегляду коду. У нас навіть є деякі Python-скрипти, які ми можемо використовувати. І всі ці референсні документи згадуються в skill.md, тож агент знає, що може заглибитися, щоб отримати їх.
А для деяких, як-от “світовий годинник” (world clock), ми фактично маємо лише skill.md, бо це просто для конвертації часових поясів. Очевидно, агенту не потрібно стільки контексту, щоб знати, як це робити. Тож це просто досить простий skill.md, лише кілька сотень рядків.
А ось як це працює: у мене є мій агент Pyantic AI. У мене багато іншого контенту на каналі про Pyantic AI. Тож я не буду заглиблюватися надто сильно, але ось визначення агента. До речі, цього агента ви можете використовувати з OpenRouter, Ollama або OpenAI, легко розширити для інших. Отже, знову ж таки, ви не прив’язані до екосистеми Claude.
І ось що ми робимо: ми створюємо динамічний системний запит. Тож, коли ми вперше визначаємо агента, ми взагалі не встановлюємо системний запит, бо ми зробимо це тут. І в Pyantic AI це робиться так: ви посилаєтеся на agent.system_prompt. Це наш Python-декоратор. Функція під ним – це місце, де ми визначаємо системний запит для нашого агента. Тож ми можемо вводити речі під час виконання. Бо те, що ми робимо одним рядком коду, – це виклик функції (я не буду заглиблюватися в деталі), яка шукає в директорії skills. Вона знаходить кожен skill.md, бере YAML-блокнот (front matter), витягує його з skill.md і потім вставляє його в системний запит.
Отже, у нас є всі описи “скілів” та їхні шляхи, а також наш основний системний запит. У нас все ще є базові інструкції, які не змінюються. Насправді, багато моїх інструкцій тут просто кажуть агенту, як використовувати “скілли”. Це дуже важливо. Великі мовні моделі самі по собі не розуміють, як використовувати ці можливості. Що зробив Claude, і що ми повинні зробити самі, – це бути дуже докладними тут. Скажімо так: “Ось що таке “скілли”. Ось метадані, щоб ви знали, які доступні. А ось послідовні кроки, як використовувати “скіл”, коли опис прямо кричить вам, що ви хочете використовувати цю можливість.”
Отже, увесь запит, про який я говорив, – це перший рівень “поетапного розкриття”. Динамічний системний запит – це те, як ми повідомляємо агенту про все заздалегідь. Потім ми переходимо до набору інструментів. Я надаю один набір інструментів для мого агента Pyantic AI, який має все необхідне для роботи зі “скілами”, щоб, по суті, читати все, що є в директорії skills.
Переходячи до цього визначення, ми надаємо три інструменти: load_skill, read_reference, і ще один інструмент, який я маю тут, щоб полегшити агенту роботу: list_reference_documents. На випадок, якщо skill.md не посилається на нього безпосередньо. Ми намагаємось максимально спростити виявлення всього. У цьому вся суть “скілів” – виявлення можливостей, до яких він має доступ.
Наприклад, щоб завантажити “скіл”, нам просто потрібно вказати його назву. Це одна з речей, яка включена в системний запит. І ось що ми робимо: у нас є шлях до “скілу”, встановлений у змінній оточення, а потім назва, і ми шукаємо skill.md там. Ми завантажуємо все це, а потім повертаємо вміст skill.md. Ось як ми включаємо це в контекстне вікно агента. І це дуже схоже на читання одного з наших референсних документів. Код фактично майже ідентичний, але є деякі відмінності, щоб переконатися, що ми читаємо референсний документ, специфічний для “скілу”. Деякі захисти, які я запровадив для агента.
Отже, ось, по суті, агент як ціле. Ось як він працює. Це зрештою надзвичайно просто. Крім того, тому що я маю це як набір інструментів Pyantic AI, ви можете взяти цей набір інструментів, скопіювати цей файл та ще кілька інших, і ви зможете принести це до свого власного агента Pyantic AI за кілька хвилин. І ваш помічник з кодування ШІ зможе допомогти вам зробити це неймовірно швидко. Тож, будь ласка, використовуйте це як ресурс для себе. Просто дайте йому цей репозиторій і скажіть: “Гей, у мене є всі ці “скілли”. Ви можете помістити буквально будь-який “скіл”, який ви хочете, у цю папку, і наступного разу, коли ви взаємодіятимете з агентом, він автоматично матиме ці можливості.” Отже, дуже динамічна система, яку я для вас побудував. Чудова відправна точка для будь-якої системи, яку ви захочете створити.
Створення Своїх “Скілів”: Інструменти та Натхнення
Тепер ще одна дуже важлива річ, про яку варто поговорити: як створювати власні “скілли”. Цей посібник, який я залишив в описі, – це чудова відправна точка. Ще одна швидка порада: якщо ви зайдете в Claude Desktop, ви можете використовувати його, щоб допомогти собі створювати “скілли”, які потім можна перенести до директорії “скілів” для вашого власного агента.
Просто зайдіть у “Файл” -> “Налаштування” -> “Можливості”. Прокрутіть до кінця до “Скілли”, потім “Приклади скілів” і увімкніть “Творець скілів” (Skill Creator). Це дуже мета, але це “скіл”, який допомагає створювати інші “скілли”. Тож, коли Claude використовує його, він завантажує всі інструкції та найкращі практики для створення “скілів” і проводить вас через цей процес. Ви можете сказати: “Гей, допоможи мені створити “скіл” для публікацій у LinkedIn” або “допоможи мені створити “скіл” для генерації презентацій” чи “створення стандартних операційних процедур” – чого завгодно! І він проведе вас через процес створення. Потім він створить skill.md та, можливо, деякі референсні документи, і ви зможете взяти це і просто помістити в нову папку тут, у директорії skills. Ось так просто створювати власні “скілли”, а можливості, які ви можете створити, безмежні.
Надійність та Контроль: Перевірка та Моніторинг
Отже, на даний момент ви вже знаєте важливість “скілів” та як їх інтегрувати в будь-якого ШІ-агента. Але головне питання, яке слід задавати: надійність. Коли ви берете ці можливості, а ви можете мати десятки “скілів”, надаєте їх агенту – як ви переконаєтесь, що агент завжди буде користуватися ними, коли ви цього хочете? Наприклад, у вас може бути “скіл” для публікації у X (Twitter), але ви просите його допомогти зі створенням контенту, а він не викликає цей “скіл”, бо не знає, що створення контенту означає використання “скілу” X, так? Ви хочете перевіряти такі речі, але коли у вас є десятки різних “скілів”, надзвичайно нудно взаємодіяти з агентом, надсилати запитання, переконуючись, що він належним чином використовує кожен з них кожного разу, коли ви вносите зміни до агента.
Ось де потрібні evals (оцінювання). Ми можемо створити автоматизований спосіб визначення запитань та очікуваних викликів інструментів, або, в нашому випадку, очікуваних “скілів”, які він використовує. Я розкажу вам, як це виглядає, а потім перейдемо до спостережуваності (observability). Коли ваш агент працює в продакшені, використовуючи ці різні “скілли”, ви можете бачити, як реальні користувачі взаємодіють з вашим агентом і переконуєтесь, що агент реагує належним чином.
Я з нетерпінням чекаю на цю останню частину відео. Я буду досить стислим, але це те, що я рідко висвітлюю на своєму каналі. “Evals” та “observability” – це надзвичайно важливі речі, але я рідко роблю контент про них.
На щастя для нас, Pyantic AI має дуже потужний фреймворк оцінювання, вбудований прямо в нього. Ми можемо створювати YAML-файли, де визначаємо всі наші тестові випадки. Наприклад, я надішлю запитання: “Яка [хрип] погода зараз у Нью-Йорку?” І далі у мене є оцінювач (evaluator), щоб переконатися, що був завантажений “скіл” погоди. Ми також можемо створювати власні оцінювачі. Я не хочу надто заглиблюватися в код зараз. Ви можете прочитати про це в документації. Використовуйте це як приклад для свого помічника з кодування ШІ. Але у мене є цей власний оцінювач, щоб переконатися, що правильні “скілли” завантажуються на основі запитань, які я надсилаю.
Тож тепер, замість того, щоб вручну заходити в агента і ставити йому кожне з цих питань, щоб переконатися, що він використовує різні “скілли”, як-от “скіл” перегляду коду та “асистент дослідження”, тепер я можу просто запустити цей один скрипт. Я можу викликати цей Python-скрипт, щоб запустити мої оцінювачі. Він завантажує мої “золоті дані”, як я це називаю. Він проходить через запитання по черзі. Я плачу за кредити LLM, але вони дуже дешеві, дуже швидкі. Це просто “димний тест” (smoke test), щоб переконатися, що всі різні “скілли”, які я додав до своєї папки, дійсно належним чином використовуються моїм агентом. Якщо ні, це означає, що, можливо, є проблема з моєю можливістю завантаження, або мій системний запит потребує покращення, або описи “скілів” потрібно вдосконалити. Є різні речі, які потрібно скоригувати, якщо агент не працює так, як ви очікуєте.
Тож “evals” надзвичайно важливі для запуску кожного разу, коли ви змінюєте системний запит вашого агента або навіть просто “скілли”, до яких ви надаєте доступ. У Readme також є інструкції, як запускати “evals”. І ви можете вільно переглядати код для цього, якщо ви хочете побачити, як налаштувати це для ваших власних агентів Pyantic AI. Але ви захочете робити це для майже будь-якого агента, якого розгортаєте в продакшені. “Evals” надзвичайно важливі, а “скілли” – це просто гарний приклад, бо тут так багато різних можливостей, які ми хочемо протестувати.
Логи досить багатослівні. Але я використовую Haiku для всіх тестів. Це приємно і швидко. Але внизу: 25 з 25 випадків пройшли. Я надіслав багато різних запитів, щоб переконатися, що агент належним чином розуміє всі “скілли”, які я йому надав. Тому краще робити це, ніж проводити купу ручного тестування після кожної зміни мого агента.
Я також залишу посилання на сторінку Pyantic Evals в описі, якщо ви хочете заглибитися в це і серйозно поставитися до свого агента перед розгортанням у продакшені.
І ще одна річ, про яку я хочу поговорити, – це спостережуваність з Logfire. Бо “evals” чудові, коли ви хочете тестувати свого агента локально, але як щодо реального використання агента користувачами в продакшені? І ви хочете мати можливість заглядати в траси, коли вони викликаються, щоб бачити рішення, які приймає ваш агент, коли люди використовують його в дикій природі.
Ось чому нам потрібен такий інструмент, як Logfire. Його створила команда Pyantic. Вони також створили Pyantic AI. Отже, це просто фантастична інтеграція. І його дуже легко налаштувати. У файлі визначення агента потрібно мати мінімальний обсяг коду. Токен Logfire – це одна зі змінних оточення. Я пояснив це в Readme. А потім ми можемо налаштувати Logfire. Він буде інструментувати всіх агентів Pyantic, тобто кожного разу, коли ми викликаємо інструмент, взаємодіємо з LLM, він надсилатиме все це як дані телеметрії. Тож ми можемо відстежувати це, запускаючи локально, як ви бачите зараз, але також і в продакшені.
Я також залишу посилання на Logfire. Я просто хотів швидко згадати: це надзвичайно важливо – мати можливість бачити наше використання, як-от використання токенів та витрати в продакшені. Заглядати в різні траси. Якщо користувач повідомляє про проблему, ми можемо зайти сюди і побачити: “Окей, де агент помилився? Можливо, щось не так з його системою? Чи він просто неправильно використав інструмент, передав поганий параметр?”. Ми можемо бачити всі параметри, усі виклики інструментів, які він зробив. Тож ми можемо бачити рішення, навіть коли не запускаємо агента локально.
Надзвичайно важливо мати “evals” та спостережуваність, коли ви хочете серйозно поставитися до свого агента. А Pyantic AI з Logfire роблять це так легко.
Підсумок: Ваш Шлях до Більш Інтелектуальних ШІ-Агентів
На цьому все. Це – ваш посібник з реалізації “скілів” для будь-якого ШІ-агента. Ви також отримали невеликий бонус у вигляді “evals” та інструментів спостереження, які необхідні, щоб контролювати роботу агента, переконатись в його ефективності. Як ми побачили, використовуючи “скілли”, ми можемо надати нашим агентам десятки й десятки можливостей.
Якщо це відео було корисним для вас, і ви плануєте дізнатися більше про ШІ-агентів, будь ласка, поставте лайк та підпишіться. До зустрічі в наступному відео!
Підсумовуючи, концепція “скілів” , запропонована Anthropic, може бути застосована до будь-якої ШІ-системи, забезпечуючи гнучкість, ефективність та масштабованість. Ми розглянули технічні аспекти реалізації за допомогою Pyantic AI, створили робочий шаблон, який ви можете адаптувати, та торкнулися питань надійності та моніторингу в продакшені через “evals” та Logfire.
Висновок: Розробка інтелектуальних агентів – це не лише про те, щоб задавати правильні питання, а й про надання інструментів та структури, які дозволять цим агентам навчатися та ефективно діяти.
Що далі? Експериментуйте! Скористайтеся цим шаблоном, додайте свої “скілли”, налаштуйте його під свої потреби. Розпочніть зі спрощених задач, поступово їх ускладнюючи. Світ ШІ розвивається дуже швидко, а вміння створювати таких інтелектуальних помічників стане ключовим у майбутньому. Створюйте, експериментуйте, дійте, і нехай ваш ШІ-агент буде вашим надійним партнером!
