Коли у штучного інтелектуального агента є 1 000 інструментів MCP: вибір, контекст та навички
Підключення агентів до багатьох серверів MCP спричиняє надмірну кількість інструментів, перевантажений контекст та погані вибори. Чому відкриття можливостей, навички та шлюзи можуть бути важливішими за прямий доступ.
Більше інструментів для AI-агента здається суцільною перевагою, принаймні доки їх кількість не досягне 1 000. У цей момент питання змінюється: воно вже не звучить як «Чи може агент це зробити?», а стає «Чи може агент знайти правильний інструмент та правильно ним скористатися?» Саме тут MCP стає цікавим.
MCP полегшує використання інструментів
Однією з основних переваг протоколу Model Context Protocol є те, що функціональність надходить до агентів через один спільний інтерфейс. Продукт типу SaaS може публікувати функції create_customer, get_customer, update_customer, create_invoice, refund_payment та search_orders. Інший сервер MCP може обробляти дані з GitHub, ще один — з Slack, а четвертий — з внутрішньої бази даних. Кожен з них працює добре окремо. Проблеми починаються тоді, коли один агент підключається до багатьох серверів, і їхня кількість швидко зростає. Десять інструментів — це нічого, сто вже починають створювати труднощі, а тисяча — це зовсім інша проблема.
Експлозія інструментів
Поставте себе на місце агента, у якого є 1 000 інструментів. Вам доведеться з’ясувати, що робить кожен з них, які вони пов’язані між собою, які використовувати, які параметри вони приймають, які мають запускатися першими та чи виконують кілька інструментів однакову функцію. Технічно агент може дістатися до всього, але доступ — це не те саме, що зручність використання. Більше інструментів означає більше можливостей та більше варіантів вибору, а більше варіантів може ускладнити вибір.
Заповнення контексту
Кожен інструмент потребує опису. Для одного інструменту це може бути назва:
create_invoice
та коротке визначення:
Creates an invoice for a customer.Parameters:
- customer_id
- amount
- currency
- due_date
Помножте це на 1 000. Навіть невеликі описи разом створюють велику кількість контексту, тож токени витрачаються лише на те, щоб повідомити моделі, що вона може робити, причому більшість цих інструментів не мають жодного відношення до конкретного завдання. Якщо користувач запитує про статус замовлення, немає жодних причин, чому агент має опрацьовувати 500 інструментів для обліку, GitHub, CRM та розгортання.
Справжня складність — це вибір правильного інструменту
Припустимо, агент бачить наступне:
get_customer
get_customer_details
lookup_customer
search_customer
find_customer
Усі вони звучать однаково. Який з них слід використати? А тепер уявіть це у сотнях інструментів. Модель може чудово викликати інструменти. Складно те, що потрібно вибрати один із величезного набору інструментів. Це наче дати розробнику 10 000 функцій та побажати йому удачі. Це можливо, але не приємно.
Більше інструментів — більше помилок
Вибір часто не є бінарним, адже кілька інструментів можуть підійти:
search_orders
get_order
list_orders
find_order_by_customer
Агент може обрати дійсний інструмент та використовувати його неефективно, викликати кілька інструментів там, де достатньо одного, або викликати їх у неправильному порядку. Весь процес починається з наявності інструментів, потім йде їх вибір, після цього — послідовність виконання, і нарешті — виконання самого завдання. MCP переважно допомагає з першим етапом. Решта залежить від агента та архітектури, яка його оточує.
Чи повинні агенти мати менше інструментів?
Не обов’язково. Мета не в тому, щоб обмежити можливості агента. Йдеться про те, щоб уникнути ситуації, коли йому доводиться розуміти все одночасно. Людина, яка вирішує проблему з оплатою, не відкриває кожен внутрішній інструмент та не читає документацію — вона використовує лише ті інструменти, які стосуються оплати. Агенти могли б працювати так само. Модель завантаження всього та подальшого вибору може бути замінена на модель відкриття, вибору, завантаження та виконання, що є більш цікавим підходом до проектування.
Де вписуються навички
Навички пов’язані між собою безпосередньо. Одна навичка може надати контекст для виконання певного типу завдання. Наприклад, навичка обробки рахунків клієнтів може підказати агенту знайти клієнта, перевірити підписку, переглянути непогашені рахунки, визначити правильні дії щодо оплати, у разі потреби отримати схвалення та потім використати відповідний інструмент.
Агент більше не мусить обмірковувати кожен інструмент у системі. Він отримує менший, більш релевантний набір інструментів для виконання завдання. Замість цього:
Agent
↓
1,000 tools
Потік може бути таким:
Agent
↓
Relevant Skill
↓
Relevant tools
↓
MCP
↓
API / System
Навички не замінюють MCP, оскільки вони вирішують різні проблеми. MCP з’єднує агента з можливостями, а навички можуть навчити його їх використовувати. Ідея використання навичок замість MCP все ще є експериментальною та розвивається, тому краще розглядати її як перспективний напрямок, а не як усталену архітектуру.
Гейтвеї також можуть бути важливими
Ще одним напрямком є гейтвей MCP. Замість того, щоб безпосередньо під’єднувати агента до десятків серверів MCP, між ними встановлюється гейтвей:
Agent
↓
MCP Gateway
↓
MCP Servers
↓
APIs / Systems
Гейтвей може виконувати функції автентифікації, маршрутизації, контролю доступу, забезпечення прозорості, пошуку інструментів та керування багатьма серверами. Його цінність зростає у міру збільшення масштабів впроваджень MCP.
Справжня проблема — нерелевантність
Проблема не в самій кількості інструментів у 1 000 штук. Проблема у тому, що це 1 000 нерелевантних інструментів. Якщо для виконання завдання справді потрібні тисяча інструментів, нехай так і буде. Але якщо потрібно лише дванадцять, а агент змушений обробляти тисячу інструментів, щоб їх знайти, це зайва складність. Принцип: агентам не потрібен доступ до всього, лише до того, що є важливим у цей момент.
Це, ймовірно, стане ключовою проблемою в архітектурі MCP, оскільки агенти підключатимуться до все більшої кількості систем. MCP вирішив перше питання — як надати агентам стандартизований доступ до інструментів. Наступне питання — як розумно керувати всіма цими інструментами, і це видається значно складнішим. Надати агентам інструменти стало просто. А от надати їм правильні інструменти у правильний час — ось завдання, яке попереду.
Пов’язана література
- Як MCP змінює спосіб підключення AI-агентів до бізнес-програмного забезпечення — Як протокол Model Context Protocol під’єднує агенти до CRM, ERP та внутрішніх API, що потрібно захищати та як бізнесу варто починати з малого.