Как работает разговорный ИИ-агент изнутри

Как устроен разговорный ИИ-агент изнутри (Архитектура OpenClaw)

Как работает разговорный ИИ-агент на практике, ход за ходом? Этот пост открывает чёрный ящик OpenClaw: от момента, когда сообщение клиента приходит в WhatsApp, до текста, который агент пишет в ответ. Будет технично. Стоит прочитать, если вы принимаете решения по архитектуре продукта, если собираетесь покупать решение и хотите оценить его глубину, или если вам просто интересно, что происходит за кулисами разговора.

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

---

Почему архитектура важна

Разговорный агент, который вроде бы работает на демо, но ломается в продакшене, обычно имеет одну из этих 4 проблем:

1. Высокая задержка — клиент ждёт ответа 8 секунд, разговор умирает.
2. Неконтролируемые галлюцинации — агент выдумывает цену, расписание, политику.
3. Потеря контекста — клиент возвращается через 2 дня, а агент «забыл» всё.
4. Неконтролируемые расходы — каждый длинный разговор раздувает промпт, и вы платите целое состояние за токены.

Все 4 — это выбор архитектуры, а не ограничения модели. OpenClaw был построен так, чтобы избежать всех 4 — и путь к пониманию лежит через рассмотрение цикла одного хода.

---

Цикл одного хода (6 стадий)

Представьте, что клиент только что отправил сообщение "quero marcar pra sábado de manhã". Что происходит между «received» и ответом агента?

Стадия 1 — Приём (edge worker, <50ms)

Сообщение из WhatsApp приходит через вебхук Meta напрямую в Cloudflare Worker на ближайшей географически точке присутствия (PoP). В Бразилии это означает Сан-Паулу или Рио, сетевая задержка < 20ms.

Worker выполняет три действия:

1. Проверяет подпись вебхука (HMAC по секрету WABA).
2. Определяет тенанта по номеру телефона получателя (мультитенантность по to_number).
3. Нормализует полезную нагрузку — аудио превращается в транскрипцию, изображение — в описание, геолокация — в {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 имеет правильный формат? соответствует правилам тенанта?).
2. Проверяет разрешения (этот агент имеет право запрашивать этот календарь?).
3. Выполняет вызов (Google Calendar API в данном случае).
4. Возвращает структурированный результат модели.

Почему это важно? Потому что модель никогда не фабрикует результат. Если календарь вернул [10h, 11h], именно это и попадёт в следующий вызов. Если скилл завершился с ошибкой, модель знает, что произошёл сбой. Нулевой риск того, что агент «выдумает», будто есть свободное время в 9 утра, когда его нет.

Для случаев, связанных с чувствительной информацией (цена, сроки, имя клиента), пайплайн принудительно использует tool call — не позволяет модели отвечать из собственных «знаний». Это устраняет самый распространённый класс галлюцинаций в коммерческих агентах.

Этап 6 — Ответ и персистентность (~50ms)

Имея результат скилла на руках, модель делает второй вызов — теперь для формирования финального ответа клиенту. Пример:

"Tenho sábado às 10h e 11h. Qual prefere?"

Параллельно воркер:

1. Отправляет сообщение обратно через API WhatsApp.
2. Сохраняет полный ход диалога (user + assistant + tool calls + длительность) в D1.
3. Обновляет долгосрочную память, если в ходе диалога появился новый факт (например: «клиент предпочитает субботу»).
4. Генерирует событие наблюдаемости (метрика латентности, стоимость токенов, коэффициент эскалации).

Всё это выполняется параллельно. Персистентность не блокирует отправку сообщения — клиент не ждёт D1.

---

Где находится защита от галлюцинаций

Агент, который галлюцинирует в продакшене, быстро теряет доверие. В OpenClaw есть 4 линии защиты:

1. Принудительный источник истины. Фактические данные (цена, время, имя) всегда берутся из скилла, никогда из модели самостоятельно.
2. Двойная проверка чувствительных данных. Запись на приём подтверждается с клиентом перед сохранением. Оплата подтверждается перед предоставлением доступа.
3. Явные негативные правила. Персона каждого агента включает «никогда не выдумывай X, Y, Z» — модель подчиняется.
4. Фоллбэк на человека. Когда ни один скилл не покрывает вопрос, агент говорит "deixa eu checar com o time" и создаёт тикет — не угадывает.

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

---

Стоимость одного разговора

Хорошая архитектура невидима, пока вы не посмотрите на счёт. Учитывая, что каждый ход делает 1-2 вызова LLM + запросы к D1, типичная стоимость за полный разговор (10-15 ходов) составляет: