Як працює розмовний AI-агент зсередини

Як працює розмовний ІІ-агент зсередини (Архітектура OpenClaw)

Як працює розмовний ІІ-агент на практиці, крок за кроком? Цей пост відкриває чорну скриньку OpenClaw: від моменту, коли повідомлення клієнта надходить у WhatsApp, до тексту, який агент пише у відповідь. Буде технічно. Варто прочитати, якщо ви приймаєте рішення щодо архітектури продукту, якщо збираєтесь купити рішення і хочете оцінити його глибину, або якщо вам цікаво знати, що відбувається за лаштунками розмови.

TL;DR: кожен крок проходить через 6 етапів — ingest, визначення контексту, вибір навичок, прийняття рішення про наступну дію, виконання з guard-rails, збереження пам'яті. Весь цикл виконується за <2 секунди на edge Cloudflare, без виділеного сервера.

---

Чому архітектура має значення

Розмовний агент, який начебто працює на демо, але ламається в продакшені, зазвичай має одну з цих 4 проблем:

1. Висока затримка — клієнт чекає 8 секунд на відповідь, розмова вмирає.
2. Неконтрольована галюцинація — агент вигадує ціну, розклад, політику.
3. Втрачений контекст — клієнт повертається через 2 дні, а агент "забуває" все.
4. Неконтрольовані витрати — кожна довга розмова заповнює промпт, і ви платите цілий статок за токени.

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

---

Цикл одного кроку (6 етапів)

Уявіть, що клієнт щойно надіслав повідомлення "quero marcar pra sábado de manhã". Що відбувається між "received" і відповіддю агента?

Етап 1 — Ingest (edge worker, <50ms)

Повідомлення з WhatsApp надходить через webhook Meta безпосередньо в Cloudflare Worker у найближчій географічно точці присутності (PoP). У Бразилії це означає Сан-Паулу або Ріо, мережева затримка < 20ms.

Worker виконує три речі:

1. Перевіряє підпис вебхука (HMAC проти секрету WABA).
2. Ідентифікує тенанта за номером телефону отримувача (multi-tenant за to_number).
3. Нормалізує payload — аудіо перетворюється на транскрипцію, зображення на опис, локація на {lat,lng}, текст залишається як є.

Наприкінці етапу 1 ви маєте об'єкт {tenant_id, conversation_id, user_message}, готовий до наступного кроку.

Етап 2 — Визначення контексту (D1 + KV, ~80ms)

Агенту потрібні 3 частини контексту перед прийняттям рішення:

• Нещодавня історія розмови (останні N релевантних кроків).
• Довгострокова пам'ять клієнта (вподобання, історія покупок, нотатки).
• Стан агента (персона, увімкнені skills, правила).

Усе це надходить із D1 (розподілений SQLite від Cloudflare). D1 замінює традиційний Postgres/Mongo — жодного сервера бази даних для підтримки, доступ за кілька мс із worker, мультитенантність за tenant_id.

Ключовий момент: ми не завантажуємо всю розмову в промпт. Memory Manager v2 від OpenClaw (описаний у нашій внутрішній документації) обирає лише релевантні кроки для поточного ходу (останні N + N із високою семантичною релевантністю). Це дозволяє зберігати передбачувану вартість токенів навіть у розмовах із 100+ кроків.

Етап 3 — Вибір skills (policy engine, ~20мс)

Кожен агент має набір доступних skills — функцій, які він може викликати. Приклади: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Для повідомлення "quero marcar pra sábado de manhã" policy engine фільтрує:

• Skills, сумісні з виявленим наміром (планування).
• Skills, дозволені для цієї фази розмови (не всі skills доступні весь час).
• Skills, які цей tenant увімкнув (calendar з'являється лише якщо tenant інтегрував його).

У результаті ви маєте невеликий підмножину skills, що передається моделі — не всі 50 можливих, а лише 4, які мають сенс у цьому контексті. Це різко знижує ймовірність того, що модель викличе неправильний skill.

Етап 4 — Рішення (LLM call, 400-1200мс)

Тепер вступає модель. OpenClaw робить один виклик до frontier LLM (Anthropic Claude, OpenAI GPT, Google Gemini — налаштовується для кожного tenant) з:

• System prompt = персона агента + правила + доступні skills.
• History = кроки, обрані на етапі 2.
• User message = повідомлення поточного ходу.

Модель відповідає одним із двох варіантів:

• Фінальна відповідь (текст безпосередньо клієнту).
• Tool call (запит на виконання конкретного skill із параметрами).

У прикладі "quero marcar pra sábado de manhã" модель зазвичай повертає:

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

Етап 5 — Виконання з guard-rails (змінна, ~100-500мс)

Skill не виконується в моделі. Він виконується в нашому коді, який:

1. Валідує параметри (date_range має правильний формат? відповідає правилам tenant?).
2. Перевіряє дозвіл (цей агент має право запитувати цей календар?).
3. Виконує виклик (Google Calendar API у цьому випадку).
4. Повертає структурований результат моделі.

Чому це важливо? Тому що модель ніколи не вигадує результат. Якщо календар повертає [10h, 11h], саме це й потрапляє до наступного виклику. Якщо skill завершується з помилкою, модель знає, що сталася помилка. Нуль ризику того, що агент "вигадає", що є вільний час о 9-й, коли його немає.

Для випадків, що стосуються чутливої інформації (ціна, термін, ім'я клієнта), pipeline примусово використовує tool call — не дозволяє моделі відповідати з власних "знань". Це усуває клас галюцинацій, найпоширеніший у комерційних агентів.

Етап 6 — Відповідь і збереження (~50ms)

Маючи результат skill, модель робить другий виклик — тепер для формування фінальної відповіді клієнту. Наприклад:

"Маю суботу о 10-й і 11-й. Який варіант обираєте?"

Паралельно worker:

1. Надсилає повідомлення назад через API WhatsApp.
2. Зберігає повний хід (user + assistant + tool calls + тривалість) у D1.
3. Оновлює довготривалу пам'ять, якщо хід створив новий факт (наприклад: "клієнт надає перевагу суботі").
4. Генерує подію спостережуваності (метрика латентності, вартість токенів, рівень ескалації).

Все це працює паралельно. Збереження не блокує надсилання повідомлення — клієнт не чекає на D1.

---

Де знаходиться захист від галюцинацій

Агент, який галюцинує у продакшені, швидко втрачає довіру. OpenClaw має 4 лінії захисту:

1. Примусове джерело істини. Фактичні дані (ціна, час, ім'я) завжди надходять від skill, ніколи від моделі самостійно.
2. Подвійна перевірка чутливих даних. Запис підтверджується з клієнтом перед збереженням. Оплата підтверджується перед наданням доступу.
3. Явні негативні правила. Персона кожного агента включає "ніколи не вигадуй X, Y, Z" — модель підкоряється.
4. Фолбек на людину. Коли жоден skill не покриває запитання, агент каже "дозвольте я уточню з командою" і створює тікет — не вгадує.

В аудитах, які ми провели за останні 6 місяців (реальні розмови, переглянуті вручну), рівень фактичних галюцинацій залишився нижче 0,3% ходів — і майже всі випадки були через конфігурацію (tenant забув увімкнути відповідний skill), а не через помилку моделі.

---

Вартість за розмову

Гарна архітектура невидима, доки ви не подивитесь на рахунок. Враховуючи, що кожен крок робить 1-2 виклики LLM + запити до D1, типова вартість за повну розмову (10-15 кроків) становить: