Чи справді померла епоха “старих” ШІ-агентів? Розбір, коли обирати SDK, а коли – фреймворк (З Мого Досвіду)
Привіт, друзі! Ліла Харт на зв’язку, з досвідом у сфері бізнес-аналізу, автоматизації та штучного інтелекту вже понад двадцять років. Останнім часом я все частіше замислююсь над одним питанням: чи не стали ми, ентузіасти технологій, заручниками трендів? Здається, ми так захопилися новітніми рішеннями, що забули про перевірені інструменти, які ще вчора були вершиною прогресу. Минулого року змагалися, хто витонченіше змайструє ШІ-агента на Langchain чи Pydantic AI – шукати файли, читати скриньку електронної пошти, та й взагалі, творити цифрові дива. А що зараз? YouTube та LinkedIn рясніють рекламою AI coding assistants (асистентів для написання коду). Про старі добрі фреймворки згадують хіба що як про історичний артефакт.
Я, відверто кажучи, теж потрапила під вплив цього потоку. У розмовах та статтях я захоплювалися створенням локальних ШІ-агентів за допомогою Pydantic AI, N8N, OpenAI Agents SDK. Це було захопливо – і масштабно. Але потім мій блог, як і багато інших, швидко переорієнтувався на AI coding assistants, що цілком логічно. Адже сьогодні це найактуальніше. І найцікавіше, що ці нові помічники мають власні SDK, які дозволяють будувати нових агентів, спираючись на їхню потужність.
У цій ситуації формується головний дискурс: “Нам більше не потрібні складні фреймворки, бо все можна зробити з SDK”. І, мушу визнати, для деяких задач це справді так. Але чи означає це, що старий підхід варто повністю відкинути? Зовсім ні. Тут є безліч нюансів, і вони, повірте мені, дуже важливі.
Давайте зануримося у цей світ разом. Розберемося, коли справді потрібно звертатися до “готових рішень” від SDK, а коли – потрібно повернутися до перевірених фреймворків. Ми також поговоримо про важливі еволюційні зміни: як тепер дивляться на поняття “скілів” (skills) та різні способи реалізації RAG. Моя мета – зробити ваш вибір максимально обґрунтованим і зрозумілим. Готові? Тоді починаємо!
1. Як ми будували ШІ-агентів “за старим рецептом” (Спойлер: це все ще актуально!)
Чи пам’ятаєте, як це було? Я пам’ятаю, адже це був мій основний інструментарій. Рік-два тому, якщо ви хотіли створити справді ефективного ШІ-агента, шлях був один – вибір потужного фреймворку. Їх було багато, і кожен міг стати вашим надійним помічником. Спочатку їхня кількість навіть трохи лякала, але зрештою, ви обирали той, з яким вам було найкомфортніше працювати, або той, який використовувала ваша команда. З власного досвіду, згадую, як кілька разів переходила з одного фреймворка на інший, поки не знайшла той, що максимально відповідає моїм потребам та рівню команди.
Типовий “рецепт” виглядав так:
- Вибір фреймворку: Pydantic AI, Langchain, N8N, LlamaIndex – обираємо свого героя.
- Визначення “інструментів”: Це були всі можливості вашого агента – пошук файлів, доступ до пошти, взаємодія з іншими сервісами. Все, що робило агента “розумним”.
- RAG (Retrieval-Augmented Generation): Третій, але обов’язковий крок. Тут ви визначали стратегію подрібнення (chunking), ембеддингів (embedding) та пошуку (retrieval) для того, щоб ваш агент міг “читати” вашу базу даних знань.
- Запуск “циклу агента”: Керування станом, пам’яттю, короткостроковою пам’яттю, зберігання розмов. Це мало на меті, щоб агент вас розумів і “пам’ятав”.
Наведу приклад, який є класикою жанру, адже сама не раз його використовувала. Уявіть собі найпершого RAG-агента. Так, ці ідеї нікуди не зникли, але саме так ми тоді бачили майже кожного агента.
Ви починали з визначення агента за допомогою фреймворку, наприклад, Pydantic AI. Потім задавали модель, системний промпт, і, звісно, інструменти. А оскільки RAG був майже у всіх, ви детально прописували його стратегію: подрібнення, ембеддинги, пайплайн імпорту даних.
“`python
Псевдокод для розуміння
from pydantic_ai import Agent, tool
class KnowledgeBaseSearchTool:
def init(self):
# Тут вся логіка для RAG:
# 1. Завантаження документів
# 2. Подрібнення на чанки
# 3. Створення ембеддингів
# 4. Налаштування векторної бази даних (наприклад, Neon)
pass
@tool def search(self, query: str) -> str: """Searches the knowledge base for relevant information.""" # Логіка пошуку в базі return "Результати пошуку..." agent = Agent(
model=”gpt-4o”,
tools=[KnowledgeBaseSearchTool()],
system_prompt=”You are a helpful AI assistant. Use the available tools to answer questions.”
)
“`
Все зберігалося у вашій базі даних. Наприклад, я досі із задоволенням використовую Neon для PostgreSQL – це сервер без зайвої метушні, з миттєвим розгалуженням баз даних, автоскейлінгом і можливістю згортання до нуля. Там ви керували документами, фрагментами, повідомленнями, сесіями. Словом, вся інфраструктура агента була у ваших руках.
Цікаво знати: Цей підхід вимагав багато “клею” – коду, який з’єднував всі компоненти. Іноді це здавалося надмірним. Наприклад, у великих проєктах розробка та підтримка цього “клею” займала до 60% часу команди, оскільки постійно виникали проблеми зі стикуванням різних бібліотек та сервісів. Тому, перехід на наступний етап розвитку агентів видавався цілком обґрунтованим.
2. Нова хвиля: “Батарейки в комплекті” від SDK – легко, але чи завжди?
І ось, на сцену виходять нові гравці – SDK з вже інтегрованими рішеннями. Тобто ви будуєте некодингових агентів на основі вже готових, потужних кодингових помічників. Яскраві приклади – Claude Agent SDK, CodeX SDK.
У чому їхня краса? Основа – в готових рішеннях. Це дозволяє пришвидшити процес та знизити вартість розробки.
- Готові інструменти та промпти: Вам не потрібно вигадувати все з нуля. Багато що вже вбудовано. Це серйозно скорочує час розробки.
- Автоматизація керування історією: Ваш агент вже “пам’ятає” розмови, вам не потрібно налаштовувати власну базу даних для цього.
- Стартовий майданчик: Це чудова відправна точка, яка одразу дає вам чудові можливості. Це особливо актуально для новачків.
Подивіться, наскільки це просто! Уявіть, що весь ваш ШІ-агент тепер може вміститися в одному файлі. Замість того, щоб будувати агента з нуля, ви просто викликаєте команду, де задаєте опції, включаючи ті інструменти, які вже вбудовані в SDK. Моя особиста практика показала, що це зменшує час на розробку прототипу з тижнів до днів.
“`typescript
// Псевдокод для Claude Agent SDK
import { Agent, Tool } from “@anthropic/sdk”;
// Визначення власних інструментів (MCP Servers)
const myCustomTool = new Tool(“MyCustomTool”, “Performs a custom task.”);
// Визначення скілів (наприклад, генерація презентацій)
const presentationSkill = { name: “generate_presentation”, description: “Generates a PowerPoint presentation.” };
const agent = new Agent({
model: “claude-3-opus-20240229”,
tools: [myCustomTool],
skills: [presentationSkill],
systemPrompt: “You are a helpful AI assistant that can leverage tools and skills.”,
// … інші налаштування
});
“`
Тут з’являються нові поняття: скіли (skills) та MC P servers. Це сучасні способи додавати можливості. Замість того, щоб жорстко прописувати інструменти безпосередньо в агента, ви можете створити їх як окремі MC P сервери. Це робить їх значно більш універсальними. Так само зі скілами: ви можете надати агенту можливість, наприклад, генерувати презентації.
Що дивно – для багатьох задач, які раніше вимагали б складного RAG, тепер вистачає можливостей пошуку файлів, які вже вбудовані в SDK. З’являються “хуки” (hooks), гнучкі дозволи, можливість задати власний системний промпт. Майже все, що було раніше, але ще й більше!
І навіть якщо вам все ще потрібен RAG, ви можете реалізувати його через скіли чи MC P сервери. Це виглядає потужно, правда? SDK спрощують нам життя, дозволяючи будувати на основі вже потужних інструментів. Я сама була вражена, наскільки просто можна вирішити деякі задачі з цими інструментами. І цьому є причина, чому стільки уваги приділяється цим кодинговим агентам.
Лайфхак: Саме Claude Agent SDK я використовую для свого “другого мозку” – системи Heartbeat, натхненної OpenClaw. Вона обробляє інтеграції, створює спогади, проводить щоденні рефлексії. Хочете дізнатися більше? Я проводжу 4-годинний майстер-клас у спільноті Dynamis, де я детально розповідаю, як це зробити. Це може заощадити вам години роботи щотижня!
3. Але чи все так безхмарно? Обмеження “батарейок”
Проте, навіть у найсолодшій бочці меду є ложка дьогтю. SDK with “батарейками” мають свої суттєві обмеження. І саме вони змушують нас знову згадувати про старі добрі фреймворки.
Три головні обмеження SDK:
- Швидкість: SDK відчутно повільніші за те, що ви можете побудувати самостійно за допомогою фреймворків. Чому? Багато причин. Коли все вже вбудовано – інструменти, скіли, промпти – це додає “ваги” системі. Зручність має свою ціну. Ця “важкість” робить агент більш “токен-важким”. Я помітила, що в деяких проєктах ця різниця у швидкості може бути критичною.
- Детермінованість: SDK менш передбачувані. Багато процесів керуються автоматично, тож ви не завжди маєте повний контроль над тим, як працює ваш агент. У фреймворках ви будуєте майже з нуля, керуючи кожним аспектом, включаючи історію розмов. Це критично для продакшн-агентів, де потрібна максимальна прозорість. Неконтрольованість може призвести до неочікуваних результатів.
- Вартість: Це, мабуть, найприкріше обмеження. SDK часто використовують вашу підписку (наприклад, Anthropic чи OpenAI). І це чудово, коли ви використовуєте агента особисто. Але коли ваш агент призначений для багатьох користувачів, використання вашої підписки може вважатися порушенням умов сервісу – тоді доводиться переходити на API ключ, а це може коштувати цілий статок.
Не робіть того, що я колись робила… Намагалася запустити бета-версію agent SDK для тисячі користувачів. Результат? Рахунок за API перевищив усі мої найсміливіші очікування. Я швидко зрозуміла, що для масштабних проєктів це непрактично.
Саме тому для продакшн-рішень, де швидкість, вартість і максимальна гнучкість є пріоритетом, фреймворки, як Pydantic AI, залишаються поза конкуренцією. Вони дають змогу досягти відгуку менше ніж за секунду та контролювати абсолютно все.
4. Як приручити “диких” скілів у фреймворках (І навіщо це нам)
Може здатися, що фреймворки відстають у розвитку, особливо коли йдеться про сучасні можливості, як-от скіли. Але це не так. Проблема радше в тому, що ці можливості тільки-но починають інтегруватися в старі інструменти.
Я покажу вам, як це працює на прикладі Pydantic AI. Я створила агента, який підтримує скіли.
“`python
Псевдокод для Pydantic AI з підтримкою скілів
from pydantic_ai import Agent, tool
from pathlib import Path
class SkillLoaderTool:
def init(self, skills_path: Path):
self.skills_path = skills_path
@tool def load_skill(self, skill_name: str) -> str: """Loads a skill from the skills directory.""" try: skill_file = self.skills_path / f"{skill_name}.md" return skill_file.read_text() except FileNotFoundError: return "Skill not found." Приклад файлу ‘weather.md’
# Weather Skill
## Description
This skill provides the current weather information for a given city.
## How to use
To get the weather, call this skill with the city name.
## API Call Example
GET /weather?city=New York
skills_directory = Path(“./skills”)
agent = Agent(
model=”gpt-4o”,
tools=[SkillLoaderTool(skills_path=skills_directory)],
system_prompt=”You are a helpful AI assistant. You can load and use skills to fulfill requests.”
# … можливо, динамічне завантаження промпту зі скілами
)
“`
Отже, у нас є каталог skills з файлами, що описують можливості. Наш агент може динамічно завантажувати ці файли, надаючи агенту інструкції, як їх використовувати.
Приклад взаємодії:
Ви вводите: “Яка погода в Нью-Йорку?”
Агент: (Викликає SkillLoaderTool, завантажує weather.md, аналізує інструкції та робить API-запит) “Зараз в Нью-Йорку +20 degreesC, сонячно.”
Це спрацьовує настільки швидко, що може зайняти менше 10 секунд! На мою думку, це дуже добрий результат, і він показує потенціал фреймворків. Для порівняння, SDK-версія могла б зайняти вдвічі більше часу через свою “важкість”.
Лайфхак: Навіть для створення цього Pydantic AI-агента я використовувала AI coding assistance. Це демонструє, як нові інструменти допомагають нам працювати зі старими.
5. Дерево рішень: SDK чи фреймворк? Не заблукайте!
Отже, коли ж обирати SDK, а коли – фреймворк? Я розробила просту, але ефективну схему, яка базується на двох ключових питаннях:
- Хто буде користуватися вашим агентом?
- Тільки ви: Якщо агент потрібен лише для ваших особистих потреб, і невелика затримка у відповіді не критична, сміливо обирайте SDK (Claude Agent SDK, CodeX SDK). Це значно спростить інфраструктурні питання.
- Багато користувачів / Продакшн: Якщо агент розгортається для широкої аудиторії, працює на продакшн-платформі, йому потрібна швидкість та масштабованість – ваш вибір фреймворк (Pydantic AI, LangGraph).
- Наскільки важливі для вас швидкість і масштабованість?
- Не критично: SDK – ваш вибір.
- Дуже важливо: Фреймворк – ваш вибір.
І ще один нюанс: ви завжди можете почати з SDK, щоб швидко протестувати ідею чи інструмент, а потім, коли проєкт зростатиме, перенести його на фреймворк. Це гнучкий підхід, який я часто практикую.
6. Еволюція RAG: Де Він Зараз і Чи Справді “Помер”?
Залишилося торкнутися теми RAG, яка, здається, так сильно змінилася. Багато хто тепер говорить: “RAG мертвий!” Давайте розберемося.
Минулого року (2024) RAG був стандартом. Майже кожен агент використовував семантичний пошук для доступу до зовнішньої інформації. Але у 2024 році почалися сумніви. Особливо, коли кодингові агенти почали активно використовувати пошук по файлах (наприклад, grep). Llama Index навіть проводив дослідження, яке показало, що для менших обсягів даних файловий пошук може бути ефективнішим і швидшим за RAG.
Але чи означає це кінець RAG? Ні.
- Для великих баз знань: Семантичний пошук залишається точнішим і значно дешевшим.
- Гібридний RAG: Сьогодні популярними стають підходи, де агент може використовувати як семантичний пошук, так і
grepчи пошук за ключовими словами. - Graph RAG: Особливо актуальний для величезних кодових баз або проектів з багатьма взаємопов’язаними документами.
Для більшості агентів RAG все ще необхідний для доступу до важливих знань. Файловий пошук – це чудовий старт, але для складніших завдань він не завжди достатній. Навіть у моєму другому мозку, побудованому на Claude Agent SDK, я поєдную вбудовані можливості з власним RAG-рішенням, натхненним OpenClaw.
Висновок: Кожен інструмент має своє місце
Отже, друзі, підсумовуючи, головне – підібрати правильний інструмент для вашої задачі.
- SDK (“Батарейки в комплекті”): Ідеальні для особистого використання, швидкого прототипування, коли інфраструктурні питання вас не надто турбують. Вони надають готову функціональність, яка значно прискорює старт. Це як мати швидкий автомобіль для щоденних поїздок.
- Фреймворки (Pydantic AI, LangChain): Незамінні для продакшн-систем, де потрібні максимальна швидкість, масштабованість, контроль над кожним аспектом роботи агента та економія коштів. Це як будувати професійну гоночну машину, ви налаштовуєте кожен гвинтик для досягнення цілі.
Епоха “старих” ШІ-агентів не минула. Вона просто еволюціонувала. Тепер ми маємо більше інструментів, ніж будь-коли, і це чудово! Використовуйте їх з розумом, експериментуйте, і найголовніше – будуйте те, що справді приносить цінність.
Якщо ця стаття була для вас корисною, та ви хочете більше дізнатися про створення агентів та агентне кодування, поставте лайк та підпишіться на канал. Вас чекає ще багато цікавого!
До нових зустрічей!
Ваша Ліла Харт.
