Как Работи Конверсационен AI Агент Отвътре

Как Работи Разговорен AI Агент Отвътре (Архитектура OpenClaw)

Как работи разговорен AI агент на практика, ход по ход? Тази публикация отваря черната кутия на OpenClaw: от момента, в който съобщението на клиента пристигне в WhatsApp, до текста, който агентът изпраща обратно. Ще бъде техническо. Струва си, ако вземате решения за продуктова архитектура, ако ще купувате решение и искате да оцените дълбочината, или ако обичате да знаете какво се случва зад разговора.

TL;DR: всеки ход преминава през 6 етапа — прием, разрешаване на контекст, избор на умения, решаване на следващо действие, изпълнение с предпазни мерки, запазване на памет. Целият цикъл се изпълнява за <2 секунди на ръба на Cloudflare, без фиксиран сървър.

---

Защо архитектурата е важна

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

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

И четирите са архитектурни избори, не ограничения на модела. OpenClaw е построен, за да избегне и четирите — и пътят за разбиране е да се погледне цикълът на един ход.

---

Цикълът на един ход (6 етапа)

Представете си, че клиентът току-що е изпратил съобщението "искам да запиша за събота сутринта". Какво се случва между "получено" и отговора на агента?

Етап 1 — Прием (edge worker, <50ms)

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

Worker-ът прави три неща:

1. Валидира подписа на webhook (HMAC срещу тайна на WABA).
2. Идентифицира tenant-а по телефонния номер на получателя (multi-tenant по to_number).
3. Нормализира payload-а — аудио става транскрипция, изображение става описание, местоположение става {lat,lng}, текст остава както е.

В края на етап 1 имате обект {tenant_id, conversation_id, user_message} готов за следващата стъпка.

Етап 2 — Разрешаване на контекст (D1 + KV, ~80ms)

Агентът се нуждае от 3 части контекст, преди да реши:

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

Всички идват от D1 (разпределен SQLite на Cloudflare). D1 замества традиционните Postgres/Mongo — без сървър за база данни за поддръжка, достъп за няколко ms от worker, multi-tenant чрез tenant_id.

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

Етап 3 — Избор на умения (policy engine, ~20ms)

Всеки агент има набор от налични умения — функции, които може да извиква. Примери: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

При съобщение "quero marcar pra sábado de manhã", policy engine филтрира:

• Умения, съвместими с открито намерение (планиране).
• Умения, разрешени за тази фаза на разговора (не всяко умение е налично по всяко време).
• Умения, които този tenant е активирал (calendar се появява само ако tenant е интегрирал).

В края имате малък подмножество от умения, предадени на модела — не всичките 50 възможни, само 4-те, които имат смисъл тук. Това драстично намалява шанса модела да извика грешно умение.

Етап 4 — Решение (LLM call, 400-1200ms)

Сега влиза моделът. OpenClaw прави едно извикване към frontier LLM (Anthropic Claude, OpenAI GPT, Google Gemini — конфигурируем по tenant) с:

• System prompt = персона на агента + правила + налични умения.
• History = избрани обмени в етап 2.
• User message = съобщение от текущия обмен.

Моделът отговаря с едно от две неща:

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

В примера "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-500ms)

Умението не се изпълнява в модела. То се изпълнява в наш код, който:

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

Защо това е важно? Защото моделът никога не фабрикува резултата. Ако календарът върне [10h, 11h], точно това отива към следващото извикване. Ако skill-ът се провали, моделът знае, че се е провалил. Нулев риск агентът да "измисли", че има час в 9h, когато няма.

За случаи, които включват чувствителна информация (цена, срок, име на клиент), pipeline-ът налага tool call — не позволява на модела да отговори от собственото си "знание". Това елиминира класа халюцинации, най-често срещан при търговски агенти.

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

С резултата от skill-а в ръце, моделът прави второто извикване — сега за формиране на финалния отговор към клиента. Напр.:

"Имам събота в 10h и 11h. Кой предпочитате?"

Паралелно worker-ът:

1. Изпраща съобщението обратно чрез API на WhatsApp.
2. Персистира пълния ход (user + assistant + tool calls + продължителност) в D1.
3. Актуализира дългосрочната памет, ако ходът е произвел нов факт (напр.: "клиентът предпочита събота").
4. Емитира събитие за наблюдаемост (метрика за латентност, разход на токени, процент на ескалация).

Всичко това работи паралелно. Персистентността не блокира изпращането на съобщението — клиентът не чака D1.

---

Къде е защитата срещу халюцинация

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

1. Принудителен source-of-truth. Фактически данни (цена, час, име) винаги идват от skill, никога само от модела.
2. Двойна проверка при чувствителни данни. Насрочването се потвърждава с клиента преди персистиране. Плащането се потвърждава преди освобождаване на достъп.
3. Изрични отрицателни правила. Персоната на всеки агент включва "никога не измисляй X, Y, Z" — моделът се подчинява.
4. Fallback към човек. Когато нито един skill не покрива въпроса, агентът казва "нека проверя с екипа" и отваря тикет — не гадае.

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

---

Разходът на разговор

Добрата архитектура е невидима, докато не погледнете фактурата. Предвид че всеки ход прави 1-2 извиквания на LLM + заявки в D1, типичната цена за пълен разговор (10-15 хода) е: