Как Функционира Агент на ИА Конверсационал по Дентур

Как Функционира Един Agente на IA за Конверсация върху (Архитектура OpenClaw)

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

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

---

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

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

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

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

---

Цикълът на повороти (6 етапа)

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

Етап 1 — Ингест (edge worker, <ms)

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

Работникът прави три неща:

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

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

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

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

1. Контекст на разговора — кой е клиентът, какво е съобщението му.
2. Контекст на тенианта — какво е тенианта, какво е състоянието му.
3. Контекст на агента — какво е състоянието на агента, какво е състоянието му.

Агентът трябва да има тези части от контекст, за да реши следващото действие.

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

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

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

Стадиум 3 – Избор на умения (политика на движението, ~20ms)

Кажди агент има набор от умения, които могат да бъдат извикани. Примери: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Дадена съобщението "quero marcar pra sábado de manhã", политиката на движението филтрира:

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

На края от това имате малък набор от умения, които се предават на модела – не 50 възможности, а само 4, които са подходящи тук. Това drasticно намалява шансите модела да извика грешно умение.

Стадиум 4 – Решение (звън на LLM, 400-1200ms)

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

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

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

• Финално съобщение (текст директно към клиента).
• Умиеливи извиквания (предложение за извикване на конкретно умение с параметри).

В примера "quero marcar pra sábado de manhã", модела обикновено отговаря:

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

Стадиум 5 – Изпълнение с гарири (променлива, ~100-500ms)

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

...

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

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

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

Стадий 6 — Отговор и съхранение (~50ms)

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

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

Паралелно, работникът:

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

Всичко това се изпълнява паралелно. Съхранението не блокира изпращането на информацията — клиентът не чака D1.

---

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

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

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

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

---

Стоимостта на обръщението

Translated markdown (bg-BG) ends here.

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

(предполага се, че има съдържание в markdown, което трябва да бъде преведено)