Сұхбатты AI Агентінің Ішкі Жұмысы Қалай Жүзеге Асады

Сөйлесу ИИ агентінің ішкі жұмыс істеу принципі (OpenClaw архитектурасы)

Сөйлесу ИИ агенті іс жүзінде қалай жұмыс істейді, әр кезеңде? Бұл пост OpenClaw-тың қара жәшігін ашады: клиенттің хабарламасы WhatsApp-қа келген сәттен бастап агент жазатын мәтінге дейін. Бұл техникалық болады. Егер сіз өнім архитектурасын шешсеңіз, шешімді сатып алып, терең бағалағыңыз келсе немесе әңгіменің артында не болып жатқанын білгіңіз келсе, бұл пайдалы болады.

Қысқаша: әр кезең 6 сатыдан өтеді — қабылдау, контекстті шешу, дағдыларды таңдау, келесі әрекетті шешу, қауіпсіздік шектеулерімен орындау, жадты сақтау. Бүкіл цикл Cloudflare-дің edge желісінде <2 секундта, тұрақты серверсіз жұмыс істейді.

---

Архитектура неліктен маңызды

Демода жұмыс істейтін сияқты көрінетін, бірақ өндірісте бұзылатын сөйлесу агенті әдетте осы 4 мәселенің біреуіне ие:

1. Жоғары кідіріс — клиент жауап үшін 8 секунд күтеді, әңгіме өледі.
2. Бақыланбайтын галлюцинация — агент бағаны, уақытты, саясатты ойдан шығарады.
3. Жоғалған контекст — клиент 2 күннен кейін қайтып келеді және агент бәрін "ұмытады".
4. Бақыланбайтын шығын — әр ұзақ әңгіме промптты толтырады және сіз токен үшін көп ақша төлейсіз.

Бұл төртеуі де модельдің шектеулері емес, архитектуралық таңдаулар. OpenClaw осы төртеуінен аулақ болу үшін құрылды — және түсінудің жолы бір кезеңнің циклін қарау.

---

Бір кезеңнің циклі (6 сатыдан)

Клиент жаңа ғана "сенбіге таңертең жазылғым келеді" хабарламасын жіберді делік. "Received" мен агенттің жауабы арасында не болады?

1-сатыдан — Қабылдау (edge worker, <50ms)

WhatsApp хабарламасы Meta-дан webhook арқылы географиялық жақын Cloudflare Worker нүктесіне (PoP) тікелей келеді. Бразилияда бұл Сан-Паулу немесе Рио дегенді білдіреді, желі кідірісі < 20ms.

Worker үш нәрсе жасайды:

1. Webhook қолтаңбасын тексереді (WABA құпиясына қарсы HMAC).
2. Қабылдаушының телефон нөмірі бойынша tenant-ті анықтайды (multi-tenant to_number бойынша).
3. Payload-ты нормалдайды — аудио транскрипцияға айналады, сурет сипаттамаға айналады, орын {lat,lng} болады, мәтін өзгеріссіз қалады.

1-сатының соңында сізде келесі қадамға дайын {tenant_id, conversation_id, user_message} объектісі бар.

2-сатыдан — Контекстті шешу (D1 + KV, ~80ms)

Агент шешім қабылдамас бұрын 3 контекст бөлігі қажет:

• Әңгіменің соңғы тарихы (соңғы N маңызды кезектер).
• Клиенттің ұзақ мерзімді жады (қалаулар, сатып алу тарихы, жазбалар).
• Агент күйі (персона, қосылған дағдылар, ережелер).

Барлығы D1 (Cloudflare-дің таратылған SQLite) арқылы келеді. D1 дәстүрлі Postgres/Mongo-ны алмастырады — қызмет көрсететін дерекқор сервері жоқ, worker-ден бірнеше мс ішінде қол жеткізу, tenant_id бойынша multi-tenant.

Негізгі нүкте: біз әңгіменің толық нұсқасын prompt-қа жүктемейміз. OpenClaw-дың Memory Manager v2 (біздің ішкі құжаттамада сипатталған) ағымдағы кезекке тек қатысты кезектерді таңдайды (соңғы 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 шекаралық 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 сәтсіз болса, модель оның сәтсіз болғанын біледі. Агенттің 9 сағатта уақыт бар деп "ойдан шығаруы" қаупі нөлге тең.

Құпия ақпаратты қамтитын жағдайларда (баға, мерзім, клиент аты), pipeline tool call мәжбүрлейді — модельдің өз "білімінен" жауап беруіне жол бермейді. Бұл коммерциялық агенттердегі ең кең таралған галлюцинация класын жояды.

6-кезең — Жауап және сақтау (~50ms)

Skill нәтижесі қолында болғанда, модель екінші шақыруды жасайды — енді клиентке соңғы жауапты қалыптастыру үшін. Мысалы:

"Сенбіде сағат 10 пен 11-де бос. Қайсысын қалайсыз?"

Параллель түрде worker:

1. Жібереді хабарламаны WhatsApp API арқылы қайта.
2. Сақтайды толық кезекті (user + assistant + tool calls + ұзақтығы) D1-де.
3. Ұзақ мерзімді жадыны жаңартады егер кезек жаңа факт шығарса (мысалы: "клиент сенбіні қалайды").
4. Бақыланатын оқиғаны шығарады (кідіріс метрикасы, токен құны, эскалация жылдамдығы).

Мұның бәрі параллель жұмыс істейді. Сақтау хабарлама жіберуді блоктамайды — клиент D1-ді күтпейді.

---

Галлюцинацияға қарсы қорғаныс қайда

Өндірісте галлюцинация жасайтын агент сенімді тез жоғалтады. OpenClaw-та 4 қорғаныс желісі бар:

1. Мәжбүрлі ақиқат көзі. Фактілік деректер (баға, уақыт, ат) әрқашан skill-ден келеді, ешқашан жалғыз модельден емес.
2. Құпия деректерді қос тексеру. Кездесу клиентпен сақтаудан бұрын расталады. Төлем қолжетімділікті беруден бұрын расталады.
3. Айқын теріс ережелер. Әрбір агенттің персонасында "ешқашан X, Y, Z ойдан шығарма" бар — модель бағынады.
4. Адамға Fallback. Ешбір skill сұрақты қамтымаған кезде, агент "командамен тексеріп көрейін" дейді және тикет ашады — болжамдамайды.

Соңғы 6 айда жасаған аудиттерімізде (нақты әңгімелер қолмен қайта қаралды), фактілік галлюцинация жылдамдығы кезектердің 0,3%-дан төмен болды — және барлық жағдайлардың көпшілігі конфигурация себебінен болды (tenant тиісті skill-ді қосуды ұмытты), модель қатесінен емес.

---

Әңгіме бойынша құн

Жақсы архитектура шот-фактураны қарағанша көрінбейді. Әрбір кезек 1-2 LLM шақыруын + D1-дегі іздеулерді жасайтынын ескерсек, толық әңгіме үшін (10-15 кезек) әдеттегі құн: