Как функционирует агент ИА конверсационный внутри

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

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

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

---

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

Агент конверсационный, который кажется работать в демонстрации, но ломается в производстве, обычно имеет одно из этих 4 проблем:

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

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

---

Цикл одного хода (6 этапов)

Представьте, что клиент только что отправил сообщение "я хочу записаться на субботу утром". Что происходит между "получено" и ответом агента?

Этап 1 — Ингест (рабочий edge, <мс)

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

Рабочий делает три вещи:

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

В конце этапа 1 у вас есть объект {tenant_id, conversation_id, user_message} готов к следующему шагу.

Этап 2 — Решает контекст (D1 + KV, ~80мс)

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

1. Контекст беседы — история беседы, включая предыдущие сообщения и действия.
2. Контекст пользователя — информация о пользователе, включая профиль и настройки.
3. Контекст навыков — информация о навыках, включая их настройки и конфигурацию.

Агент использует эти части контекста, чтобы решить, что делать дальше.

Этап 3 — Выбирает навыки (D1 + KV, ~80мс)

Агент выбирает навыки, которые необходимо использовать для решения проблемы или ответа на вопрос. Это может включать в себя выбор навыков, которые были настроены для конкретной беседы или пользователя.

Этап 4 — Решает следующую действие (D1 + KV, ~80мс)

Агент решает, что делать дальше, основываясь на контексте беседы, пользователя и навыков. Это может включать в себя решение, что ответить на вопрос или как решить проблему.

Этап 5 — Выполняет с ограничениями (D1 + KV, ~80мс)

Агент выполняет решение, которое было принято на предыдущем этапе. Это может включать в себя ответ на вопрос или решение проблемы.

Этап 6 — Сохраняет память (D1 + KV, ~80мс)

Агент сохраняет контекст беседы, пользователя и навыков, чтобы использовать их в будущем. Это позволяет агенту помнить о предыдущих беседах и использовать эту информацию для улучшения ответов и решений.

Всё цикл работает в <секунды на краю Cloudflare, без фиксированного сервера.

• История последних событий (последние N важных событий).
• Долгосрочная память клиента (предпочтения, история покупок, заметки).
• Состояние агента (личность, активные навыки, правила).

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

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

Этап 3 — Выбор навыков (политика движка, ~20мс)

Каждый агент имеет набор навыков, доступных функций, которые он может вызвать. Примеры: consultar_calendario, создать_событие, сгенерировать_ссылку_оплаты, consultar_pedido, позвонить_человеку.

Данная строка "я хочу отметить на субботу утром", политика движка фильтрует:

• Навыки, совместимые с детектированной целью (запланировать).
• Навыки, разрешенные для этапа текущей беседы (не все навыки доступны в любое время).
• Навыки, разрешенные для этого клиента (календарь появляется только если клиент интегрировал его).

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

Этап 4 — Решение (вызов LLM, 400-1200мс)

Теперь модель включена. OpenClaw делает единственный вызов к переднему LLM (Anthropic Claude, OpenAI GPT, Google Gemini — конфигурируемый клиентом) с:

• Системный prompt = личность агента + правила + доступные навыки.
• История = выбранные события в этапе 2.
• Сообщение пользователя = сообщение текущего тура.

Модель возвращает одну из двух вещей:

• Окончательный ответ (текст напрямую для клиента).
• Tool call (запрос на выполнение конкретного навыка с параметрами).

В примере "я хочу отметить на субботу утром", модель обычно возвращает:

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

Этап 5 — Выполнение с ограничениями (различная, ~100-500мс)

Навык не выполняется в модели. Он выполняется в нашем коде, который:

...

1. Проверка параметров (формат date_range правильный? находится ли он в рамках правил тенианта?).
2. Проверка разрешения (у этого агента есть ли право на доступ к этому календарю?).
3. Выполнение вызова (API Google Calendar в этом случае).
4. Возвращение структурированного результата в модель.

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

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

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

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

"У меня есть воскресенье в 10 часов и 11 часов. Какой предпочитаете вы?"

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

1. Отправляет сообщение обратно через API WhatsApp.
2. Сохраняет полный цикл (пользователь + ассистент + вызовы инструментов + продолжительность) в D1.
3. Обновляет долгосрочную память если цикл создал новую информацию (например, "клиент предпочитает воскресенье").
4. Выдает событие наблюдаемости (метрика задержки, стоимость токена, скорость масштабирования).

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

---

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

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

1. Источник истины принудительно. Фактическая информация (цена, время, имя) всегда приходит из навыка, а не из модели в одиночку.
2. Двойная проверка в конфиденциальной информации. Расписание подтверждается с клиентом перед сохранением. Оплата подтверждается перед освобождением доступа.
3. Эксплицитные отрицательные правила. Персона каждого агента включает в себя "никогда не выдумывайте X, Y, Z" — модель следит.
4. Fallback на человека. Когда ни один навык не покрывает вопрос, агент говорит "дайте мне проверить с командой" и открывает тикет — не бросает.

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

ХОРОШАЯ АРХИТЕКТУРА НЕВОЗМОЖНА ДО ТОГО, ПОКА ВЫ НЕ ПОСМОТРЕТЕ СЧЕТ. ПРИНЯТОЕ ВАРИАНТЕ, КАЖДЫЙ ТУРН ПОДНИМАЕТ 1-2 ЗАПРОСЫ К LLM + поиски в D1, СТОИМОСТЬ ОБЫЧНОЙ ПОВЕСТКИ (10-15 ТУРН) ОТНОСИТСЯ К:

(примечание: перевод выполнен в соответствии с указанными правилами)