Розуміння штучних інтелектуальних агентів: виклик інструментів, MCP та цикл агента
Як взаємодіють виклик інструментів, MCP та цикл агента в реальній архітектурі AI-агентів, починаючи з розширеного LLM та ігноруючи модні терміни.
Джерела: Tool Calling vs MCP: How AI Agents Actually Use Tools
Коли люди починають досліджувати AI-агентів, одні й ті самі терміни постійно з’являються всюди:
Агенти. Інструменти. Виклик функцій. MCP. Контекст. Пам’ять.
На перший погляд це схоже на низку неспоріднених технологій.
Але якщо приділити достатньо часу вивченню того, як будуються справжні агентські системи, особливо шляхом аналізу технічних описів Anthropic щодо агентів та MCP, починає проявлятися значно простіша основна архітектура.
У цій статті розглядається ця архітектура з практичної точки зору, орієнтованої на розробників.
Що насправді робить AI-систему агентом?
Типовий додаток, що працює за допомогою LLM, можна зобразити так:
User
↓
LLM
↓
Response
Тут модель просто отримує вхідні дані та генерує вихідні.
Але багато реальних завдань неможливо вирішити лише шляхом генерації тексту.
Візьмемо це запитання як приклад:
«Перегляньте цей репозиторій GitHub на наявні відкриті проблеми, детально розгляньте ту, що є найважливішою, та описайте, що все ще потребує виправлення».
Щоб впоратися з чимось подібним, система мусить:
- Зрозуміти запит.
- Вирішити, яку інформацію їй потрібно.
- Вибрати відповідний інструмент.
- Запустити цей інструмент.
- Перевірити результат.
- Вирішити, що робити далі.
- Потенційно викликати інший інструмент.
- Сформувати кінцеву відповідь.
Саме тут і стає корисною концепція агентської системи.
Anthropic чітко розмежовує робочі потоки та агентів.
Робочий потік проходить за фіксованою послідовністю кроків:
LLM → Step 1 → Step 2 → Step 3 → Answer
Агент, з іншого боку, сам вирішує, які дії та інструменти використовувати:
┌──────────────┐
│ LLM │
└──────┬───────┘
│
choose action
↓
Tool
↓
Result
│
└──────────→ LLM
│
choose next action
Ключовою деталлю є не просто те, що LLM бере участь у якомусь етапі процесу.
Це те, що сам LLM має вплив на формування процесу.
Anthropic розглядає агентів як системи, у яких LLM активно керує власним робочим процесом та використанням інструментів, тоді як робочі процеси залежать від логіки оркестрації, визначеної заздалегідь розробником.
Розширений LLM
Особливо корисною ідеєю з матеріалів Anthropic є концепція розширеного LLM.
Замість того, щоб уявляти LLM просто як:
LLM → Text
ви можете уявляти його як:
┌─────────────┐
│ LLM │
└──────┬──────┘
│
┌────────────┼────────────┐
↓ ↓ ↓
Retrieval Tools Memory
За цією концепцією LLM набуває здатності виходити за межі своїх навчених параметрів та взаємодіяти з зовнішньою інформацією та можливостями.
Anthropic описує отримання інформації, доступ до інструментів та пам’ять як форми посилення, які перетворюють звичайний LLM на основу для створення більш здатних агентських систем.
Це важливо, тому що це прояснює, що сама модель не перетворюється магічним чином на повну програмну систему.
Саме додаток, який обгортає модель, надає ці додаткові можливості.
Що таке виклик інструменту?
Перш ніж переходити до MCP, корисно розглянути щось більш базове.
get_weather(city)
Потім користувач запитує:
"Яка погода в Коломбо?"
Замість того, щоб відповісти одразу, модель може відповісти з проханням викликати функцію:
{
"name": "get_weather",
"arguments": {
"city": "Colombo"
}
}
Саме навколишній додаток фактично виконує цю функцію.
Ця обробка може повернути щось на кшталт:
{
"temperature": 29,
"condition": "Partly cloudy"
}
Цей результат подається назад у вікно контексту моделі.
Звідти модель може створити відповідь на кшталт:
"Зараз у Коломбо 29°C та частково хмарно."
Критична деталь тут полягає у наступному:
LLM лише вирішує, що потрібно викликати інструмент. Саме додаток його фактично запускає.
Модель ніколи не встановлює прямого з’єднання з самим сервісом погоди.
Виклик інструментів — це не MCP
Це, мабуть, найважливіша відмінність, яку потрібно зрозуміти в усій цій галузі.
Виклик інструментів та MCP вирішують дві різні проблеми.
Виклик інструментів по суті стосується обміну між:
LLM
↓
Tool request
↓
Application
↓
Tool result
MCP, навпаки, — це протокол, створений для стандартизації способу підключення штучних інтелектуальних додатків до зовнішніх інструментів, джерел даних та контексту.
Anthropic оприлюднила MCP у листопаді 2024 року як відкритий стандарт, призначений для підключення штучних інтелектуальних асистентів до систем, де знаходяться фактичні дані та інструменти.
Згідно з власною документацією Anthropic, MCP стандартизує спосіб, яким додатки надають контекст ШІ-моделям, причому для порівняння вказується, що він функціонує як порт USB-C для штучних інтелектуальних додатків.
Підсумовуючи:
Tool Calling
↓
How an LLM requests an action
MCP
↓
How AI applications can standardize connections
to external tools and data
Іншими словами, ці дві ідеї доповнюють одна одну, а не конкурують.
Що насправді додає MCP
- GitHub
- PostgreSQL
- Google Drive
- Slack
- локальної файлової системи
- внутрішніх API компанії
Без спільного протоколу кожен із цих з’єднань може потребувати власної індивідуальної схеми підключення. Ви можете легко опинитися у ситуації, подібній до цієї:
AI Application
├── Custom GitHub integration
├── Custom Slack integration
├── Custom PostgreSQL integration
├── Custom filesystem integration
└── Custom internal API integration
MCP вирішує цю проблему, визначаючи стандартизований протокол, який знаходиться між додатком ШІ та будь-якими зовнішніми системами, що надають можливості. Концептуально це виглядає ось так:
AI Application
│
MCP Client(s)
│
┌───────────────┼────────────────┐
↓ ↓ ↓
MCP Server MCP Server MCP Server
GitHub Database Files
│ │ │
↓ ↓ ↓
GitHub API PostgreSQL Filesystem
Завдяки такій схемі додаток ШІ більше не потребує глибоких, індивідуальних знань про кожну систему бекенду. Натомість сервери MCP відкривають свої можливості через спільний протокольний шар.
Архітектура MCP
MCP побудований на основі моделі клієнт-хост-сервер. На високому рівні це виглядає ось так:
┌─────────────────────────────────────┐
│ HOST │
│ │
│ AI Application │
│ │
│ ┌──────────────────────────┐ │
│ │ MCP Client │ │
│ └────────────┬─────────────┘ │
└─────────────────┼───────────────────┘
│
│ MCP
↓
┌──────────────────┐
│ MCP Server │
│ │
│ Tools │
│ Resources │
│ Prompts │
└────────┬─────────┘
│
↓
External System
Ключові ролі в цій архітектурі описані нижче.
Хост
Хост — це ШИ міні-програма, яка відповідає за організацію всього взаємодії. Це може бути щось на кшталт:
- асистент з кодування на основі ШИ
- десктопний додаток на основі ШИ
- інструмент для розробників
- спеціально створений додаток-агент
MCP Client
MCP-клієнт знаходиться всередині хоста та відповідає за підтримку активного та функціонального з’єднання з сервером MCP.
MCP Server
MCP-сервер — це просто програма, яка надає можливості через протокол MCP. Вона може надавати функціонал, пов’язаний з такими речами, як:
GitHub
Databases
Files
Cloud services
Internal systems
Development environments
Важливо те, що сам MCP-сервер не повинен бути агентом чи містити жодних механізмів міркування на основі ШИ. Його завдання полягає лише у забезпеченні доступу до певних можливостей.
MCP — це більше, ніж просто інструменти
Однією з причин, які можуть спричинити плутанину, є припущення, що MCP — це лише „протокол виклику інструментів“. Насправді MCP визначає кілька окремих примітивів, окрім інструментів.
Інструменти
Це дії, які модель може виконувати, наприклад:
create_issue()
search_repository()
query_database()
send_message()
Ресурси
Ресурси — це фрагменти інформації, які додаток може отримати та передати моделі як контекст, наприклад:
file://project/README.md
database://schema
Запити
MCP також може надавати шаблони запитів, які можна повторно використовувати, як окремий примітив.
У документації MCP від Anthropic чітко розмежовано, хто контролює кожен з цих елементів: інструментами керує модель, ресурсами — додаток, а запитами — користувач. Саме цей рівневий контроль робить MCP чимось більшим, ніж просто складним механізмом виклику функцій.
Повний приклад
Розгляньмо такий запит:
«Покажіть мені відкриті проблеми у цьому репозиторії GitHub».
Спрощена версія цього процесу може виглядати так:
User
│
│ "Show me the open issues"
↓
AI Application
│
↓
LLM
│
│ decides a GitHub tool is needed
↓
Tool Call
│
↓
MCP Client
│
│ MCP
↓
GitHub MCP Server
│
↓
GitHub API
│
↓
Issue Data
│
↓
MCP Client
│
↓
LLM
│
↓
Final Answer
Зверніть увагу, скільки тут різних етапів. Модель визначає, яку інформацію їй потрібна. Додаток керує організацією та виконанням завдань. MCP забезпечує стандартизований канал для взаємодії з зовнішніми сервісами. Сам зовнішній сервіс виконує фактичну роботу. Це чотири окремі функції, а не один змішаний етап.
Яке місце займає Docker?
Часто сервери MCP постачаються у вигляді контейнерів Docker, наприклад:
AI Application
│
│ stdio
↓
Docker Container
│
↓
MCP Server
│
↓
External Service
Варто чітко зазначити, що сам Docker не є MCP. Docker — це лише зручний спосіб пакування та запуску сервера MCP. Цей самий сервер може так само легко працювати як звичайний локальний процес або бути розміщений віддалено як сервіс. Сам протокол є абсолютно незалежним від того, як ви вирішите його розгорнути.
STDIO проти Streamable HTTP
MCP функціонує через кілька механізмів передачі даних.
Коли інтеграція є локальною, клієнт MCP може запустити сервер MCP як окремий процес та взаємодіяти з ним через STDIO.
Концептуально:
AI Application
│
│ stdin/stdout
↓
MCP Server Process
У ситуаціях, коли сервер знаходиться віддалено, MCP використовує замість цього Streamable HTTP.
AI Application
│
│ HTTP
↓
Remote MCP Server
Завдяки цьому MCP ефективно працює незалежно від того, чи знаходиться інструментарій на комп’ютері розробника, чи працює як сервіс в іншому місці.
MCP проти REST API
Ще одна важлива відмінність — це те, як MCP порівнюється зі звичайним REST API.
Інтеракція з REST API виглядає так:
Application
│
│ HTTP request
↓
REST API
│
↓
Data
Інтеракція з MCP виглядає так:
AI Application
│
│ MCP
↓
MCP Server
│
↓
REST API / Database / Filesystem / Other system
Цікаво те, що сервер MCP може вільно використовувати REST API під капотом.
Отже, MCP призначений не для заміни REST.
Його краще розуміти як шар, придатний для ШІ, що розташовується над вже існуючими системами.
Чому MCP став цікавим
Масштаб проблеми інтеграції стає зрозумілим, якщо уявити кілька додатків ШІ, кожен з яких потребує взаємодії з кількома зовнішніми інструментами.
Без спільного протоколу ви отримуєте щось на кшталт цього:
AI App A ───── Custom ───── GitHub
AI App A ───── Custom ───── Slack
AI App A ───── Custom ───── Database
AI App B ───── Custom ───── GitHub
AI App B ───── Custom ───── Slack
AI App B ───── Custom ───── Database
Кожне нове поєднання додатку та інструменту може означати необхідність написання нового коду для інтеграції.
Спільний протокол повністю змінює цю картину:
MCP
│
┌────────────┼────────────┐
↓ ↓ ↓
GitHub Slack Database
MCP MCP MCP
Server Server Server
Саме тому Anthropic випустила MCP як відкритий стандарт, замість того щоб розглядати її як інструмент, створений лише для Claude.
Згодом Anthropic розширила MCP, щоб вона підтримувала віддалені сервери, та безпосередньо інтегрувала її підключення у свої API та продукти.
Але наявність більшої кількості інструментів не автоматично робить агента кращим
Саме тут подальша інженерна робота Anthropic стає справді цікавою.
Легко припустити:
Більше інструментів = більш здатний агент.
Однак це припущення погано підтверджується на практиці.
Дослідження Anthropic щодо проектування інструментів показують, що агенти можуть навіть поганіше виконувати завдання, коли їм надається занадто багато перекриваючих один одного або недбало спроектованих інструментів.
Добре спроєктований інструмент має мати одну чітку мету та надавати корисну інформацію, уникаючи зайвого об’єму в вікні контексту моделі.
Як приклад, замість того, щоб використовувати три окремі виклики, наприклад:
list_users()
list_transactions()
list_notes()
може бути ефективніше надати агенту одну об’єднану можливість, наприклад:
get_customer_context()
припускаючи, що це краще відповідає тому, що агент насправді намагається досягти.
Іншими словами, сам інтерфейс інструменту стає частиною середовища, в якому працює агент.
Інструменти — це інтерфейс для агента
Це спостереження вказує на ширшу ідею, яку варто підкреслити:
Інструменти мають будуватися з урахуванням агента, а не просто перепаковуватися з існуючого API.
Традиційний API може працювати ідеально, коли його викликає детерміністична програма.
Однак агент, який керується ШІ, функціонує за іншим набором обмежень.
Йому доводиться боротися з:
- обмеженим вікном контексту
- ймовірнісними результатами
- час від часу помилками у виборі правильного інструменту
- час від часу помилками у генерації правильних параметрів
- неоднозначністю у тому, що насправді запитується
Через це дуже важливо, як описаний інструмент.
Розгляньте, наскільки це нечітко:
search(id)
на відміну від того, наскільки це зрозуміліше:
search_github_issues(
repository,
query,
state
)
Щоб модель могла ефективно використовувати інструмент, їй потрібно знати:
- що насправді робить інструмент
- коли варто скористатися саме ним
- що означає кожен параметр вхідних даних
- яку форму має результат
- що інструмент не може зробити
Керівні принципи Anthropic щодо розробки інструментів наголошують на точному найменуванні, чітких описах, добре визначених параметрах, корисних результатах та постійній оцінці.
Контекст стає важливою частиною інженерії агентів
Anthropic нещодавно також підкреслив ідею контексту «тільки у потрібний момент».
Примітивний підхід до обробки контексту виглядає так:
Load everything
↓
Put everything into context
↓
Ask the LLM to reason
Цей підхід швидко стикається з проблемами масштабування.
Більш стабільний підхід виглядає так:
Small amount of initial context
↓
Agent identifies what it needs
↓
Tool retrieves relevant information
↓
Relevant information enters context
↓
Agent continues
Замість того, щоб заздалегідь завантажувати все, що може знадобитися моделі, агент отримує інформацію лише тоді, коли визначає, що вона справді необхідна.
Anthropic представив це як крок у напрямку обробки контексту «тільки у потрібний момент» для систем агентів.
Це безпосередньо пов’язано з MCP.
MCP забезпечує стандартизований шлях до зовнішніх можливостей, тоді як сам агент вирішує коли щось отримати та саме що отримати.
Цикл агента
Як тільки ви поєднаєте всі ці елементи, загальна архітектура починає здаватися набагато зрозумілішою.
Спрощена версія циклу агента виглядає так:
┌──────────────┐
│ User │
└──────┬───────┘
↓
┌──────────────┐
│ LLM │
└──────┬───────┘
↓
Need a tool?
/ \
No Yes
↓ ↓
Answer Tool Call
↓
Tool/MCP
↓
Tool Result
│
└─────────┐
↓
LLM
│
┌──────────┴──────────┐
↓ ↓
Continue Answer
Цей цикл знаходиться в центрі значної кількості сучасних агентських систем.
Anthropic описує його дуже просто: агент по суті — це LLM, який у межах циклу використовує інструменти, причому зворотний зв’язок від середовища впливає на те, що він робитиме далі.
Система, побудована навколо цього циклу, може стати досить складною, але основний механізм залишається таким простим.
А як щодо фреймворків?
Фреймворки на кшталт LangGraph можуть полегшити створення таких систем, надаючи чітку структуру для роботи.
Проте існує важлива застереження, про яку варто пам’ятати.
Рекомендація компанії Anthropic — розуміти те, що відбувається під час роботи фреймворку: первинні виклики ШІ, визначення інструментів, логіку оркестрації та результати виконання, а не сприймати фреймворк як „чорну скриньку“.
Фреймворк зазвичай розкриває щось на кшталт:
Agent
├── State
├── Nodes
├── Tools
├── Routing
└── Execution
Але під цією абстракцією справжня механіка все одно виглядає так:
LLM
↓
Messages
↓
Tool calls
↓
Tool execution
↓
Tool results
↓
LLM
Розуміння цього нижчого рівня дозволяє значно легше аналізувати сам фреймворк, оскільки ви можете бачити, що саме він автоматизує, а не просто покладатися на те, що він працює.
MCP не замінює фреймворки агентів
Варто чітко зрозуміти, що це різні рівні системи, а не конкуруючі варіанти.
Спрощена стек-структура може виглядати так:
┌─────────────────────────────┐
│ User Interface │
├─────────────────────────────┤
│ Agent / Workflow │
├─────────────────────────────┤
│ LLM / Model API │
├─────────────────────────────┤
│ Tool Calling │
├─────────────────────────────┤
│ MCP │
├─────────────────────────────┤
│ External Tools / Systems │
└─────────────────────────────┘
Фреймворк агентів зазвичай керує такими аспектами:
- станом
- потоком виконання
- маршрутизацією
- циклами
- повторними спробами
- виконанням інструментів
З іншого боку, MCP стандартизує спосіб підключення до зовнішніх можливостей.
Виклик інструментів надає моделі механізм для запиту на виконання певної дії.
Жоден з цих трьох елементів не є заміною для іншого.
Кілька поширених хибних уявлень
„MCP — це модель ШІ.“
Це неправда.
MCP — це протокол, і нічого більше.
Він не має здатності генерувати текст чи міркувати самостійно.
„MCP замінює виклик функцій.“
Це також неправда.
Насправді сервер MCP може надавати інструменти, а додаток на основі ШІ потім використовує ці інструменти через свій існуючий механізм їх використання.
"LLM безпосередньо викликає GitHub."
Зазвичай — ні.
Модель лише створює запит на використання інструменту.
Саме додаток та супутня інфраструктура інструментів виконують цю операцію.
"Кожному серверу MCP потрібен Docker."
Це неправда.
Docker — це лише один із можливих способів розгортання сервера.
MCP стосується комунікації та надання можливостей, а не способу контейнеризації.
"Сервер MCP — це агент ШІ."
Не обов’язково.
Сервер MCP може просто надавати звичайні, детерміновані операції, такі як:
search()
read()
create()
update()
delete()
"MCP корисний лише для GitHub."
Зовсім ні.
MCP був створений як універсальний протокол для під’єднання AI-застосунків до зовнішніх даних та можливостей. У початковому оголошенні компанії Anthropic вже зазначалося про інтеграцію з такими системами, як GitHub, Slack, Google Drive, базами даних та різними середовищами розробки.
Важливіший урок: інженерія агентів — це не лише інженерія запитів
Це, мабуть, найсуттєвіша зміна погляду, яка виникає при вивченні цього матеріалу.
Створення справді корисних агентських систем — це не просто питання:
Write a clever prompt
↓
Use a powerful model
↓
Get a smart agent
У цьому процесі задіяні кілька окремих інженерних рівнів:
Model
↓
Tool Selection
↓
Tool Definitions
↓
Tool Execution
↓
Context Management
↓
State / Memory
↓
Control / Guardrails
↓
Evaluation
Власні технічні матеріали Anthropic все більше наголошують на цьому ширшому, системному підході до того, що насправді потрібно для створення агента.
Як приклад, їхня нещодавня робота з оцінки агентів зосереджується на аналізі багатоетапної поведінки, використання інструментів, змін стану та адаптації з часом, а не на оцінці якості виключно за кінцевим блоком створеного тексту.
Це є суттєво іншим підходом до проектування додатків з штучним інтелектом.
Частина, яка мене найбільше цікавить
Перехід, який тут має значення, насправді не є:
Chatbot → Agent
Більш точно це виглядає так:
LLM
↓
LLM + Tools
↓
LLM + Tools + External Context
↓
LLM + Tools + Context + Control Loop
↓
Agentic System
MCP вписується в цей процес, надаючи додаткам з штучним інтелектом стандартизований спосіб отримання зовнішніх можливостей.
Модель забезпечує інтелект.
Додаток забезпечує керування.
Інструменти забезпечують дії.
Зовнішні системи забезпечують інформацію та можливості реального світу.
MCP забезпечує стандартизований зв’язковий шар, який поєднує додатки з штучним інтелектом з цими можливостями.
Моя поточна ментальна модель
Після вивчення механізму виклику інструментів, концепції MCP та більш широких матеріалів Anthropic про агентні системи, ось найпростіша архітектурна схема, яка ілюструє, як усі ці елементи поєднуються між собою:
USER
│
↓
┌─────────────┐
│ LLM │
│ │
│ Reasoning │
│ Decision │
└──────┬──────┘
│
Tool request
│
↓
┌─────────────────┐
│ Agent Runtime │
│ │
│ State │
│ Control Flow │
│ Tool Execution │
└────────┬────────┘
│
↓
MCP / Tools
│
┌────────────┼────────────┐
↓ ↓ ↓
GitHub Database Files
│ │ │
└────────────┼────────────┘
↓
Tool Results
│
↓
LLM
│
↓
USER
Сама модель — це не весь агент.
Так само як і окремий інструмент.
Так само як і MCP.
Те, що насправді є „агентом“, виникає завдяки системі, яка оточує модель — тій частині, що дозволяє їй міркувати, діяти, спостерігати за тим, що відбувається, та продовжувати працювати над досягненням мети.
Остаточний висновок
Якщо ви плануєте створювати AI-агентів, варто досконало опанувати чотири ключові концепції:
1. Виклик інструментів
Модель може попросити додаток виконати певний інструмент.
2. Цикли агента
Система може неодноразово аналізувати ситуацію, діяти відповідно до неї, спостерігати за результатом та продовжувати роботу з цього моменту.
3. MCP
Стандартизований протокол для під’єднання AI-застосунків до зовнішніх інструментів, ресурсів та контексту.
4. Інженерія інструментів
Якість ваших інструментів, їхні описи, параметри, контекст, який вони повертають, та ступінь їхньої оцінки можуть суттєво вплинути на ефективність роботи агента.
Мабуть, найціннішим уроком з інженерної практики Anthropic є наступний:
Не додавайте складності лише тому, що можете це зробити.
Почніть із найпростішої архітектури, здатної вирішити поставлену задачу. Впроваджуйте робочі процеси, додаткових агентів, більше інструментів, пам’ять, сервери MCP та інші компоненти лише тоді, коли вони приносять конкретну користь.
Метою ніколи не було створення найскладнішого можливого агента.
Метою є створення системи, яка надійно виконує завдання.