Побудова MCP-агентів ШІ: архітектура, що масштабується

Якщо ви стежите за простором інструментів ШІ у 2024-2025, термін MCP зустрічається скрізь. Model Context Protocol — відкритий стандарт Anthropic для підключення моделей ШІ до інструментів, джерел даних та зовнішніх систем — тихо став хребтом серйозних агентних архітектур. Не через хайп, а тому що вирішує реальну потворну проблему: як дати агенту ШІ надійний, композиційний доступ до зовнішнього світу без написання окремого інтеграційного коду для кожного інструменту?

Це практичний посібник. Ми будуємо такі системи. Ось що реально працює.

Що таке MCP (і чим він не є)

MCP — це протокол, не фреймворк. Думайте про нього як про HTTP для комунікації ШІ-інструмент: він визначає, як хост (клієнт LLM на кшталт Claude Desktop або ваш власний застосунок) підключається до серверів, що надають можливості: інструменти, ресурси та промпти.

MCP-сервер — це легкий процес, що декларує свої можливості. MCP-клієнт (ваш агент) виявляє ці можливості та їх викликає. Протокол обробляє серіалізацію, транспорт та переговори щодо можливостей. Ви пишете бізнес-логіку.

Чим MCP не є: це не хмарний сервіс, не vendor lock-in і не магія. MCP-сервер — це код, який ви (або хтось зі спільноти) пишете та запускаєте. Протокол відкритий. Реалізації під вашим контролем.

Важливість цього полягає у стандартизації. До MCP кожна інтеграція ШІ була ad-hoc: власні визначення функцій, власні JSON-схеми, власна обробка помилок. З MCP ви пишете один сервер, і будь-який сумісний клієнт може його використати. Це суттєвий зсув.

Патерн оркестратора

Архітектурний патерн, що відкриває справжній масштаб — оркестратор: головний агент, що координує спеціалізовані суб-агенти, кожен з яких відповідає за обмежену домен.

Запит користувача
       │
       ▼
┌─────────────────┐
│   Оркестратор   │  ← Головний агент (Claude, GPT-4o тощо)
│     Агент       │    Вирішує, які суб-агенти викликати
└────────┬────────┘    Управляє станом розмови
         │
    ┌────┴─────┐
    │          │
    ▼          ▼
┌───────┐  ┌───────┐
│Search │  │ Data  │  ← Суб-агенти (спеціалізовані MCP-сервери)
│ Agent │  │ Agent │    Кожен відповідає за конкретну домен
└───────┘  └───────┘
    │          │
    ▼          ▼
 Web/API    База даних

Оркестратор не виконує роботу — він делегує. Це ключово. Коли ви вкладаєте все в одного агента, отримуєте переповнення контексту, непослідовну поведінку та кошмари налагодження. Коли ви розподіляєте відповідальності між спеціалізованими суб-агентами, підключеними через MCP, кожен компонент залишається сфокусованим та тестованим.

Патерн оркестратора також природно відповідає A2A-комунікації (agent-to-agent), де вихід одного агента стає входом іншого.

Використання інструментів: правильна абстракція

Інструменти MCP — це атомарна одиниця можливостей агента. Кожен інструмент має назву, опис (це читає LLM, вирішуючи коли використовувати) та вхідну схему. Сервер реалізує обробник; клієнт його викликає.

# Визначення інструменту MCP-сервера (спрощено)
@server.tool()
async def search_documents(
    query: str,
    top_k: int = 5,
    filters: dict | None = None
) -> list[dict]:
    """
    Шукати в базі знань документи, релевантні до запиту.
    Використовуйте коли потрібно знайти інформацію з внутрішніх джерел.
    Повертає відсортовані результати з вмістом та метаданими.
    """
    results = await vector_store.search(
        query=query,
        limit=top_k,
        filters=filters
    )
    return [{"content": r.content, "score": r.score, "source": r.source}
            for r in results]

Кілька речей, де легко помилитися.

Якість опису визначає точність вибору інструменту. LLM вибирає інструмент за описом. Якщо опис розмитий або перетинається з описом іншого інструменту, отримуєте непередбачувану поведінку. Пишіть описи як документацію для джуніора, що не знає вашої системи.

Вхідні схеми мають бути суворими. Використовуйте обов'язкові поля, enum де можливо, та чіткі описи полів. Чим більш обмежений вхід, тим надійніше агент викличе інструмент правильно.

Повертайте лише те, що потрібно агенту. Якщо інструмент повертає 2МБ JSON, а агент потребує три поля — ви спалюєте контекст та сповільнюєте інференцію. Фільтруйте на стороні сервера.

Ресурси та промпти

Інструменти — найбільш видима частина MCP, але ресурси та промпти не менш важливі.

Ресурси — джерела даних, які агент може читати: файли, рядки бази даних, відповіді API. Вони ідентифікуються URI і можуть бути перелічені, прочитані та підписані. В архітектурі оркестратора ресурси дозволяють суб-агентам надавати свій стан оркестратору без побудови власних API читання.

Промпти — повторно використовувані шаблони промптів, що сервери MCP можуть надавати. Це дозволяє централізувати логіку системних промптів у MCP-сервері, версіонувати її та подавати узгоджено в усіх агентах, що використовують ваш сервер.

Як Jeeves це реалізує

Наш внутрішній проект Jeeves — агент для бізнес-автоматизації, побудований для продакшну. Він слідує патерну оркестратора з чотирма спеціалізованими суб-агентами, кожен з яких працює як незалежний MCP-сервер:

• Research Agent: веб-пошук, вилучення контенту, резюмування
• Data Agent: запити до бази даних, генерація звітів, трансформація даних
• Calendar Agent: планування, координація зустрічей, нагадування
• Communication Agent: написання листів, повідомлення Slack, маршрутизація сповіщень

Оркестратор — головний агент на базі Claude, що підтримує контекст розмови та вирішує які суб-агенти викликати на основі наміру користувача.

# Потік рішень оркестратора (псевдокод)

повідомлення = "Підсумуй продажі за останній тиждень і заплануй оглядову зустріч"

# Оркестратор визначає потрібні суб-агенти
завдання = оркестратор.планувати(повідомлення)
# → [
#     Завдання(агент="data", дія="запит_продажі", params={"період": "минулий_тиждень"}),
#     Завдання(агент="calendar", дія="знайти_слот", params={"тривалість": 60}),
#     Завдання(агент="calendar", дія="створити_зустріч", params={"..."}),
# ]

# Виконати з вирішенням залежностей
результати = await оркестратор.виконати(завдання)

# Синтезувати та відповісти
відповідь = оркестратор.синтез(результати)

Ключове архітектурне рішення: кожен суб-агент незалежно розгортається. Коли Calendar Agent потребує оновлення, ми його перерозгортаємо без торкання оркестратора чи інших агентів.

Виробничі міркування

Управління станом — ваша проблема, не MCP. Протокол безстановий на виклик. Якщо ваш агент повинен підтримувати стан між викликами інструментів (а він буде), вам потрібне сховище стану. Ми використовуємо Redis для короткочасного стану сесії та PostgreSQL для постійного контексту.

Обробка помилок має бути явною. MCP-сервери можуть повертати помилки, але LLM повинен знати що з ними робити. Проектуйте відповіді помилок як структуровані об'єкти з кодом, повідомленням та необов'язковими вказівками повторної спроби.

Таймаути для всього. Виклики інструментів у продакшні зазнають невдачі. Мережі розпадаються. Зовнішні API лягають. Кожен обробник інструменту повинен мати явний таймаут та шлях graceful degradation.

Спостережуваність важливіша ніж ви думаєте. Логуйте кожен виклик інструменту зі входом, виходом, тривалістю та заявленим обґрунтуванням LLM. Коли щось піде не так — а воно піде — ось що ви налагоджуєте.

Чому MCP перемагає в довгостроковій перспективі

Чесна відповідь на питання "чому MCP замість власного function calling" — екосистема. З ростом прийняття MCP ви отримуєте:

• Сервери побудовані спільнотою, які можна додати до своєї архітектури (вже сотні на mcpservers.org)
• Інструменти, що працюють на всіх сумісних хостах — побудуй раз, запускай у Claude Desktop, своєму застосунку, CI-пайплайні
• Стандартизована безпека та переговори щодо можливостей, які в іншому разі довелося б будувати самим

Ми ще на початку. Протокол буде розвиватися. Але архітектурні принципи — розділення відповідальностей, декларативне виявлення можливостей, композиційна інтеграція інструментів — є надійними незалежно від того, як виглядає специфікація у версії 2.0.

Якщо ви будуєте агенти ШІ для виробничого використання, MCP вже не опціональний. Це розумний стандарт.

Ми будуємо агентні системи на базі MCP для B2B-клієнтів по всій Європі. Якщо ви оцінюєте цю архітектуру для свого бізнесу, зв'яжіться з нами.