Оксамит, але з перчинкою: Як зробити вашого ШІ-помічника розумнішим та не переплачувати за це
Мій друг-розробник якось поділився: “Ліло, сил вже немає. Пишу код, а мій помічник… ніби й розуміє, що я хочу, але щось не те. Наче наштовхується на невидиму перепону, і я постійно мушу розтлумачувати йому, що робити. Це як намагатися навчити кота приносити капці – цікаво, але результат… поки не дуже.”
Ця історія наштовхнула мене на актуальну для багатьох думку: ми навчилися давати ШІ-помічникам доступ до інструментів, даних, фактично – до всього, що робить їх корисними. Але чи правильно ми це робимо? Чи не перевантажуємо їх, ніби намагаючись зробити з кота дворецького?
Останній рік протокол MCP (Meta-Command Protocol) став золотою серединою для такого підключення. Завдяки йому наші агенти, ШІ-помічники, отримали доступ до безмежних знань та інструментів. Але, як це часто буває, чим популярнішою стає технологія, тим помітнішими стають її недоліки. Один з них, як виявили навіть самі Anthropіc, творці цього протоколу, – “токенова ненажерливість” та “забування контексту”. Звучить як із науково-фантастичного фільму, чи не так?
Тож, розберемося, як ці проблеми впливають на наших помічників та чи можна зробити їх розумнішими, не перегріваючи процесор. Пройдемося від проблеми з прикладами до запропонованого рішення, яке мене вразило. І, як ви вже здогадалися, в кінці торкнемося питання: чи означає це кінець епохи MCP?
Коли ваш ШІ-помічник захлинається від знань: Проблема MCP
Уявіть, що ви вперше на базарі, і замість запитання про помідори вам викладають все: фрукти, овочі, рибу, парфуми, які, можливо, вам ніколи не знадобляться. Це про протокол MCP.
Суть проблеми в тому, що кожне визначення інструменту, кожна команда агенту – це “токени” (гроші). І чим більше інструментів підключаємо, тим більше їх “з’їдається”, ще до того, як ви поставите перше питання. Це як запам’ятовувати ціни на все, що є на базарі, перш ніж вирішити, що купувати.
Варто знати: Контекстне вікно – це, грубо кажучи, “оперативна пам’ять” вашого ШІ. Чим воно більше, тим більше інформації може тримати в голові одночасно. Але ці “гігабайти” пам’яті не безмежні, а кожен токен – як маленька крихта, яка заповнює це вікно.
Покажу вам дещо, що особисто мене налякало. Уявіть п’ять MCP-серверів для допомоги з кодом. Я ними користувалася, але ніколи не використовувала їх разом в одній сесії з помічником. Чому? Бо кожен “з’їдає” тисячі токенів лише для опису своїх можливостей. Це відбувається ще до першого повідомлення!
Звісно, сучасні великі мовні моделі (LLM) можуть обробляти й більше токенів. Але те, що модель може вмістити їх, не означає, що вона справляється з цим “граціозно”. Якщо спробувати “завалити” помічника купою інструментів, він може просто “впасти” – і ви відчуєте себе у 2022 році, коли GPT 3.5 ледве справлявся з парою інструментів. Це справді може бути плачевно.
І я вам це доведу.
Коли 97 000 токенів – це новий “Привіт!”
Для експерименту я зайшла у свій улюблений інструмент для написання коду, підключила ті самі сервери, що й завжди, та використала команду /context, щоб побачити, скільки токенів “з’їдає” кожна з моїх можливостей.
І… вражаюче! Купа інструментів, але лише MCP-інструменти “з’їли” 97 000 токенів! Це майже половина (48%) контекстного вікна для Claude Sonnet 4.5. Навіть якщо у вас LLM, яка вміщує мільйон чи два мільйони токенів, це все одно багато! Ніби замість склянки води вам приносять океан – ви захлинетесь.
Що робити? Де рішення?
Коли я це побачила, виникло питання: “І що тепер? Невже я не можу використовувати всі ці можливості одночасно?”
Виявляється, рішення є, одночасно просте та геніальне: давати можливості лише тоді, коли вони СПРАВДІ потрібні. Мова про “виявлення в реальному часі” – інструменти завантажуються лише тоді, коли ви хочете їх використовувати. Або навіть “створення можливостей на льоту”. Це те, що Anthropіc називає “виконанням коду”.
Коли агент сам пише інструкції: Архітектура майбутнього
Більшість MCP-серверів – це просто обгортки для API. Мої, наприклад, як у відкритому проєкті Archon, працюють саме так. Є API-ендпойнти для роботи з вашими знаннями, проєктами, завданнями. В коді MCP-сервера небагато: набір інструкцій для агента: “Ось функції, які ти можеш викликати, щоб взаємодіяти з нашим API”.
Уявіть: що, якби ми дозволили агенту самому писати код для взаємодії з цими API-ендпоінтами Archon, замість використання MCP-сервера як посередника, який завантажує десятки інструментів одразу?
Це не тільки зекономить токени, а й зробить систему гнучкішою. Агент сам вирішуватиме, як взаємодіяти з API. Він не буде змушений використовувати “обов’язкові” інструменти. І найцікавіше: агент зможе зберігати згенерований код і використовувати його повторно.
Спочатку ШІ-агент генеруватиме скрипти “на вимогу”, а потім, можливо, й інструкції, як ними користуватися. Це дуже схоже на “Claude skills”, про які поговоримо далі. Коли агент захоче скористатися можливостями, він завантажить набір інструкцій плюс контекст коду та виконає його. І це станеться лише тоді, коли це потрібно!
Замість завантаження всіх MCP-серверів одразу, у вас буде папка, яку агент може шукати в реальному часі. Натрапив на щось, пов’язане з Google Drive? Чудово! Тоді завантажуємо код, що дозволяє отримати документ. І все це – залежно від запиту!
Claude Skills: Коли майстерність стає доступною
Здавалося б, дати агенту можливість виконувати та використовувати код – чудово. Але як це реалізувати? Одна з переваг MCP – простота підключення нових можливостей.
Тут на сцену виходять “Claude Skills” від Anthropic. Це втілення рішення проблеми MCP. Вони дозволяють нам і нашим ШІ-агентам генерувати скрипти для взаємодії з API, створювати інструкції до них, писати код “на льоту”. Це виконання коду у чистому вигляді!
Що найбільше вражає: опис кожного “скіла” – лише кілька речень. Замість тисяч токенів, що визначають інструменти в MCP, інформація коротка та змістовна. Коли агент використовує “скіл”, завантажується повний набір інструкцій та код. Він навіть не повинен завантажувати весь код – може описати, які функції доступні та як їх викликати.
Це неймовірно ефективно з точки зору токенів – лише 2-3% від використання MCP на початку розмови!
P.S. Якщо вам цікаво дізнатися більше про Claude Skills, дайте знати в коментарях – я готова присвятити їм окреме відео!
Archon Skill: Моя перевірка на міцність
Взяла MCP-сервер для свого проєкту Archon і трансформувала його в “скіл”. Це просто фантастика! Тепер помічник може взаємодіяти з Archon API, генеруючи власний код. Набагато ефективніше та гнучкіше.
Тепер я можу підключати десятки таких “скілів” одночасно, не хвилюючись про вичерпання контексту. Замість 90 000 токенів на старті, ми говоримо про кілька сотень! Я вже продемонструвала це в спільноті Dynamus, і ви можете спробувати.
Чи це кінець епохи MCP?
Найімовірніше, ні. Ось чому:
MCP – це про “що бачиш, те й отримуєш”. Коли я створюю MCP-сервер, я чітко визначаю інструменти. Це дає більше контролю та передбачуваності.
Виконання коду, хоч і гнучке й ефективне, пов’язане з ризиками та складністю. Потрібно думати про безпеку, пісочницю для коду. Тут справжній компроміс між контролем і гнучкістю.
З одного боку (MCP):
- Більше контролю: Визначаю, як агент використовує інструменти, адже він не пише довільний код.
- Управління обліковими даними: Легше налаштовувати та керувати змінними середовища.
- Менший ризик пропустити можливості: Все надається одразу, немає потреби в пошуку, що може зменшити ризик пропуску чогось.
З іншого боку (Гнучкість – “скіли” та виконання коду):
- Велика гнучкість: Можна мати десятки можливостей, не перевантажуючи контекст.
- Ефективність: Завантаження інструкцій та коду відбувається лише за потреби.
- Широкі можливості: Агент може самостійно створювати робочі процеси, комбінуючи різні API-виклики.
Думаю, гнучкість перемагатиме контроль все більше й більше. LLM стають потужнішими, ми довіряємо їм виконання коду та пошук можливостей. ШІ-агенти створені для автономності, а ми лише робимо їх більш автономними, збільшуючи гнучкість.
Що далі?
Ми розібрали проблему “токенової ненажерливості” та “забування контексту” в MCP. Побачили, як Claude Skills та виконання коду пропонують більш ефективне та гнучке рішення. MCP не зникає, але майбутнє – за новими, “розумнішими” підходами.
Якщо ви, як і я, захоплені світом ШІ-агентів та майбутнім програмування, поставте лайк цій статті та підписуйтесь на мій блог. Давайте разом досліджувати ці захопливі можливості!
Підсумовуючи, сучасні ШІ-агенти стають потужнішими, і методи їх підключення до інструментів мають еволюціонувати. MCP – важливий крок, але “скіли” та виконання коду пропонують шлях до більш ефективних, гнучких та потужних ШІ-помічників. Не бійтеся експериментувати, використовуйте нові підходи, і нехай ваші цифрові помічники стають тільки кращими!
