Роман Поляшенко
Ми будуємо AI-агентів для компаній, і щоразу на старті чую одну й ту саму плутанину: MCP, RAG, «агенти», LangGraph, оркестратор — їх кидають у купу й думають, що це конкуренти або синоніми. Це не так. Це три різні шари, і саме разом вони дають співробітника, а не балакучу демку.
ChatGPT у вкладці браузера — це не AI-співробітник. Він не знає вашого бізнесу й нічого в ньому не може зробити. Справжній агент = думає + знає вашу компанію + діє у ваших системах. Нижче — як це збирається технічно, з прикладами коду, і де тут граблі.
Три шари: памʼять, руки, голова
Простий спосіб не плутатись: уявіть співробітника. Йому потрібна памʼять (знати ваш бізнес), руки (робити дії в системах) і голова (вирішувати, що робити). Кожен шар закриває рівно одну з цих потреб.
RAG — це памʼять
RAG (retrieval-augmented generation) «заземлює» відповіді моделі на ваших конкретних, актуальних даних: регламентах, каталозі, базі знань, історії клієнта. Механіка проста: ваші документи ріжуться на шматки (chunks), кожен перетворюється на вектор (embedding) і кладеться у векторну базу. На запит дістаємо кілька найрелевантніших шматків і підкладаємо їх у контекст моделі.
1. документи → чанки → embeddings → векторна база (один раз + оновлення)
2. запит користувача → embedding → top-k схожих чанків
3. чанки + запит → LLM → відповідь, заземлена на ВАШИХ данихЧому не просто «дотренувати модель на наших даних»? Бо fine-tuning дорогий, повільний, і його треба повторювати щоразу, коли змінився прайс чи регламент. RAG оновлюється миттєво: змінили документ — переіндексували, і агент уже відповідає по-новому. Fine-tuning вчить стилю, RAG дає факти.
MCP — це руки
MCP (Model Context Protocol) — відкритий стандарт від Anthropic, через який агент читає й пише у зовнішні системи за єдиним протоколом клієнт-сервер. Замість того щоб під кожну інтеграцію писати власний «клей», ви піднімаєте MCP-сервер (свій або готовий), який віддає набір інструментів (tools) і ресурсів. Будь-який агент, що говорить мовою MCP, одразу вміє ними користуватись.
# MCP-сервер оголошує інструмент — агенту не треба знати про вашу CRM напряму
@server.tool()
def get_order(order_id: str):
"Повертає статус, товари й суму замовлення з CRM."
return crm.fetch_order(order_id)Цінність — у розвʼязуванні: один MCP-сервер обслуговує багато агентів, а один агент через MCP-клієнт дотягується до багатьох систем (CRM, ERP, платіжка, магазин, пошта). Це різниця між «зоопарком саморобних інтеграцій» і однією шиною, де додати нову систему = підняти ще один сервер.
Оркестратор — це голова
Оркестратор (агентський фреймворк, на практиці часто LangGraph) — шар, що автономно планує: декомпозує задачу, обирає інструмент, виконує дію, дивиться на результат і вирішує наступний крок. Це не «один запит — одна відповідь», а цикл «думка → дія → спостереження», який крутиться, поки задача не закрита.
while not задача_виконана:
крок = llm.вирішити(стан, доступні_інструменти) # голова
if крок.потребує_даних: результат = rag.retrieve(...) # памʼять
if крок.потребує_дії: результат = mcp.call(крок.tool) # руки
if крок.критична_дія: чекати_підтвердження_людини() # HITL
стан = оновити(стан, результат)Саме тут живуть гілки, повтори при помилці й human-in-the-loop: оркестратор може поставити виконання «на паузу» й дочекатися кнопки від людини, перш ніж робити незворотну дію.
Як це працює разом: повернення товару
Клієнт просить оформити повернення на 4 200 грн. Слід виконання:
Оркестратор: декомпозує → [знайти замовлення, перевірити політику,
оформити, повернути кошти, оновити CRM]
MCP get_order("#1487") → "доставлено", 1 товар, 4 200 грн
RAG retrieve("політика повернень") → "14 днів, без слідів використання"
Оркестратор: умови виконано, але сума велика → HITL
Slack: "Повернення #1487 на 4 200 грн відповідає політиці. Підтвердити?"
[✓ Підтвердити] [✗ Відхилити]
Людина: ✓
MCP create_return("#1487") + refund(4200) + update_deal("#1487","Повернення")
Slack: "Готово: повернення оформлено, кошти повернуто, угоду оновлено."Жоден шар окремо цього не зробив би: RAG без MCP лише перекаже політику, MCP без оркестратора чекає, поки ним хтось покерує, а «гола» LLM упевнено вигадає і політику, і номер замовлення, і факт рефанду.
Архітектура: як шари зʼєднані
Зверху — Slack як інтерфейс. Повідомлення з каналу йде в оркестратор. Оркестратор тримає стан діалогу й на кожному кроці тягнеться або в RAG-ретривер (памʼять), або через MCP-клієнт до MCP-серверів (руки), які вже стукають у реальні API ваших систем. Критичні дії повертаються в Slack кнопкою підтвердження. Усе — з логуванням кожного кроку.
Slack ── оркестратор (LangGraph)
├── RAG-ретривер ── векторна база (ваші документи)
├── MCP-клієнт ── MCP-сервери ── CRM / ERP / платіжка / магазин
└── HITL ── кнопка підтвердження назад у SlackДе команда з ним говорить: Slack
Агенту потрібен один інтерфейс, де з ним працює вся команда. Ми беремо Slack: агент заходить у воркспейс як учасник, до нього звертаються згадкою або slash-командою, а канали стають контекстом — окремий під продажі, під підтримку, під фокус-групу. Те саме повідомлення в #продажі й #фінанси має різний дозволений набір дій.
Безпека тут не опція, а частина архітектури:
- Права й скоупи — хто з команди що може просити і які дії дозволені в якому каналі.
- SSO й автентифікація — агент діє від імені компанії, а не «когось»; дії прив'язані до реального користувача.
- Human-in-the-loop — критичні дії (рефанд, масова розсилка, видалення) агент кидає на підтвердження кнопкою.
- Окремі ролі/агенти під відділи — щоб менеджер продажів не міг через чат залізти у фінанси.
- Аудит — кожен виклик інструмента й кожне підтвердження логуються: хто, що, коли.
Граблі, на які ми наступали
- RAG на брудних даних. Якщо в базі знань суперечливі або застарілі документи — агент упевнено цитуватиме сміття. Памʼять треба чистити.
- Дати агенту все й одразу. Без скоупів перший же «винахідливий» запит дотягнеться туди, куди не треба. Менше прав — спокійніший сон.
- Критичні дії без HITL. Незворотні дії (гроші, розсилки, видалення) — лише через підтвердження людини, поки немає довіри до метрик.
- Оркестратор без логів. Якщо не видно ланцюжка «думка→дія», ви не зможете ні відлагодити, ні довести, що саме сталося.
З чого почати
Не намагайтеся збудувати «універсального співробітника» одразу. Беріть один сценарій (повернення або «де моє замовлення»), вмикайте ескалацію на людину з першого дня, налагоджуєте памʼять (RAG) і 2–3 MCP-інструменти. Працює — розширюєте набір дій; ні — чесно згортаєте. Архітектура (RAG + MCP + оркестратор) лишається та сама, росте лише кількість інструментів.
Чому це важливо вже зараз
Через рік питання буде не «чи є у вас сайт і CRM», а «чи є у вас агент, що в них працює — і де команда з ним говорить». RAG, MCP і оркестратор — це не три модні слова, а три відповіді на питання «памʼять, руки, голова».
Коротшу версію цієї статті також опубліковано на DOU: dou.ua/forums/topic/60070.
