Jinsi Wakala wa AI wa Mazungumzo Anavyofanya Kazi Ndani

Jinsi Wakala wa AI wa Mazungumzo Unavyofanya Kazi kwa Ndani (Muundo wa OpenClaw)

Jinsi wakala wa AI wa mazungumzo unavyofanya kazi kivitendo, zamu kwa zamu? Chapisho hili linafungua sanduku jeusi la OpenClaw: kuanzia wakati ujumbe wa mteja unafika kwenye WhatsApp hadi maandishi ambayo wakala anaandika kujibu. Itakuwa ya kitaalamu. Inafaa ikiwa unaamua muundo wa bidhaa, ikiwa utanunua suluhisho na unataka kutathmini kwa undani, au ikiwa unapenda kujua kinachoendelea nyuma ya mazungumzo.

TL;DR: kila zamu inapitia hatua 6 — ingest, tatua muktadha, chagua ujuzi, amua hatua inayofuata, tekeleza na vizuizi vya usalama, hifadhi kumbukumbu. Mzunguko wote unafanya kazi kwa <sekunde 2 kwenye edge ya Cloudflare, bila seva ya kudumu.

---

Kwa nini muundo unajali

Wakala wa mazungumzo ambao unaonekana kufanya kazi kwenye demo lakini unavunjika katika uzalishaji kwa kawaida una moja ya matatizo haya 4:

1. Ucheleweshaji mkubwa — mteja anasubiri sekunde 8 kwa jibu, mazungumzo yanakufa.
2. Maono yasiyodhibitiwa — wakala anabuni bei, ratiba, sera.
3. Muktadha uliopotea — mteja anarudi baada ya siku 2 na wakala "anasahau" kila kitu.
4. Gharama zisizodhibitiwa — kila mazungumzo marefu yanajaza prompt na unalipa utajiri kwa token.

Yote 4 ni chaguo za muundo, si vikwazo vya modeli. OpenClaw ilijengwa kuepuka yote 4 — na njia ya kuelewa ni kuangalia mzunguko wa zamu moja.

---

Mzunguko wa zamu moja (hatua 6)

Fikiria kwamba mteja ametuma ujumbe "quero marcar pra sábado de manhã". Nini kinatokea kati ya "received" na jibu la wakala?

Hatua ya 1 — Ingest (edge worker, <50ms)

Ujumbe wa WhatsApp unafika kupitia webhook ya Meta moja kwa moja kwenye Cloudflare Worker katika kituo cha uwepo (PoP) kilicho karibu zaidi kijiografia. Nchini Brazil, hii inamaanisha São Paulo au Rio, ucheleweshaji wa mtandao < 20ms.

Worker inafanya mambo matatu:

1. Inathibitisha saini ya webhook (HMAC dhidi ya siri ya WABA).
2. Inatambua tenant kwa nambari ya simu ya mpokeaji (multi-tenant kwa to_number).
3. Inasawazisha payload — sauti inakuwa unukuzi, picha inakuwa maelezo, eneo inakuwa {lat,lng}, maandishi yanabaki kama yalivyo.

Mwishoni mwa hatua ya 1 una kitu {tenant_id, conversation_id, user_message} kilicho tayari kwa hatua inayofuata.

Hatua ya 2 — Tatua muktadha (D1 + KV, ~80ms)

Wakala anahitaji vipande 3 vya muktadha kabla ya kuamua:

• Historia ya hivi karibuni ya mazungumzo (zamu N za mwisho zinazohusika).
• Kumbukumbu ya muda mrefu ya mteja (mapendeleo, historia ya ununuzi, maelezo).
• Hali ya wakala (persona, skills zilizowezeshwa, sheria).

Zote zinatoka kwenye D1 (SQLite iliyosambazwa ya Cloudflare). D1 inachukua nafasi ya Postgres/Mongo ya kawaida — hakuna seva ya hifadhidata ya kudumisha, ufikiaji wa ms chache kutoka kwa worker, multi-tenant kwa tenant_id.

Jambo muhimu: sisi hatupakii mazungumzo yote kwenye prompt. Memory Manager v2 ya OpenClaw (iliyoelezwa katika nyaraka zetu za ndani) inachagua tu zamu zinazohusika kwa zamu ya sasa (N za mwisho + N zenye umuhimu mkubwa wa kisemantiki). Hii inadumisha gharama ya token inayotabirika hata katika mazungumzo ya zamu 100+.

Hatua ya 3 — Uchaguzi wa skills (policy engine, ~20ms)

Kila wakala ana seti ya skills zinazopatikana — kazi ambazo anaweza kuziita. Mifano: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Kwa ujumbe "quero marcar pra sábado de manhã", policy engine inachuja:

• Skills zinazoendana na nia iliyogunduliwa (kupanga ratiba).
• Skills zinazoruhusiwa kwa awamu hii ya mazungumzo (si kila skill inapatikana wakati wote).
• Skills ambazo mpangaji huyu ameziwasha (calendar inaonekana tu ikiwa mpangaji ameunganisha).

Mwishowe una seti ndogo ya skills inayopitishwa kwa modeli — si zile 50 zinazowezekana, ni zile 4 tu zinazofaa hapa. Hii inapunguza sana uwezekano wa modeli kuita skill isiyofaa.

Hatua ya 4 — Uamuzi (LLM call, 400-1200ms)

Sasa modeli inaingia. OpenClaw inafanya wito mmoja kwa LLM ya mpakani (Anthropic Claude, OpenAI GPT, Google Gemini — inayoweza kusanidiwa kwa kila mpangaji) na:

• System prompt = persona ya wakala + sheria + skills zinazopatikana.
• History = zamu zilizochaguliwa katika hatua ya 2.
• User message = ujumbe wa zamu ya sasa.

Modeli inajibu moja ya mambo mawili:

• Jibu la mwisho (maandishi ya moja kwa moja kwa mteja).
• Tool call (ombi la kutekeleza skill maalum na vigezo).

Katika mfano "quero marcar pra sábado de manhã", modeli kwa kawaida inarudisha:

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

Hatua ya 5 — Utekelezaji na vizuizi vya usalama (inabadilika, ~100-500ms)

Skill haiendeshwi kwenye modeli. Inaendeshwa kwenye msimbo wetu, ambao:

1. Inathibitisha vigezo (date_range ina muundo sahihi? iko ndani ya sheria za tenant?).
2. Inakagua ruhusa (wakala huyu ana haki ya kuuliza kalenda hii?).
3. Inatekeleza wito (Google Calendar API katika kesi hii).
4. Inarudisha matokeo yaliyopangwa kwa modeli.

Kwa nini hii ni muhimu? Kwa sababu modeli haizushi matokeo kamwe. Ikiwa kalenda inarudisha [10h, 11h], ndivyo hasa inavyoenda kwenye wito unaofuata. Ikiwa skill inashindwa, modeli inajua imeshindwa. Hatari sifuri ya wakala "kuzua" kwamba kuna nafasi saa 9h wakati hakuna.

Kwa kesi zinazohusisha taarifa nyeti (bei, muda, jina la mteja), pipeline inalazimisha tool call — hairuhusu modeli kujibu kutoka kwa "maarifa" yake mwenyewe. Hii inaondoa aina ya maono ya uongo yanayojulikana zaidi kwa mawakala wa biashara.

Hatua ya 6 — Jibu na uhifadhi (~50ms)

Ikiwa na matokeo ya skill mkononi, modeli inafanya wito wa pili — sasa kuunda jibu la mwisho kwa mteja. Mfano:

"Nina Jumamosi saa 10h na 11h. Unapendelea ipi?"

Wakati huo huo, worker:

1. Inatuma ujumbe kurudi kupitia API ya WhatsApp.
2. Inahifadhi zamu kamili (user + assistant + tool calls + muda) katika D1.
3. Inasasisha kumbukumbu ya muda mrefu ikiwa zamu ilitoa ukweli mpya (mfano: "mteja anapendelea Jumamosi").
4. Inatoa tukio la ufuatiliaji (kipimo cha ucheleweshaji, gharama ya token, kiwango cha kupandisha).

Yote haya yanafanya kazi kwa wakati mmoja. Uhifadhi hauzuii utumaji wa ujumbe — mteja hasubiri D1.

---

Ulinzi dhidi ya maono ya uongo uko wapi

Wakala anayeona maono ya uongo katika uzalishaji hupoteza imani haraka. OpenClaw ina mistari 4 ya ulinzi:

1. Chanzo cha ukweli kinacholazimishwa. Data za ukweli (bei, ratiba, jina) daima zinatoka kwenye skill, kamwe kutoka kwa modeli peke yake.
2. Uthibitisho maradufu kwa data nyeti. Ratiba inathibitishwa na mteja kabla ya kuhifadhiwa. Malipo yanathibitishwa kabla ya kutoa ufikiaji.
3. Sheria hasi za wazi. Persona ya kila wakala inajumuisha "kamwe usizue X, Y, Z" — modeli inatii.
4. Kurudi kwa binadamu. Wakati hakuna skill inayoshughulikia swali, wakala anasema "niache nikague na timu" na anafungua tiketi — hapigi nadharia.

Katika ukaguzi tuliofanya katika miezi 6 iliyopita (mazungumzo halisi yaliyokaguliwa kwa mkono), kiwango cha maono ya uongo ya ukweli kilikuwa chini ya 0.3% ya zamu — na karibu kesi zote zilitokana na usanidi (tenant alisahau kuwezesha skill husika), si kosa la modeli.

---

Gharama kwa mazungumzo

Usanifu mzuri hauonekani hadi utakapoangalia ankara. Kwa kuwa kila zamu inafanya simu 1-2 za LLM + utafutaji katika D1, gharama ya kawaida kwa mazungumzo kamili (zamu 10-15) inakuwa: