Nini Chanzo cha Mtandao wa IA Kwa Nje

Jinsi Agente ya Kusoma Kwa Kielektroniki Unavyofanya Kazi Nje (Arkitetura ya OpenClaw)

Jinsi agente ya kusoma kwa kielektroniki unavyofanya kazi katika kesi ya kawaida, kwa kila mservices? Post hii inatengeneza kisanduku cha kufa kwa OpenClaw: kutoka wakati wa ujumbe wa mteja unapopita kwenye WhatsApp hadi maandishi ambayo agente anayosema tena. Itakuwa kisicho cha kawaida. Ni thamani ya kuchukua ikiwa unajua arkitetura ya bidhaa, ikiwa utakuwa na bidhaa na unataka kuchanganua msingi, au ikiwa unapenda kujua nini kinafanyika kwa kufa kwa kesi.

TL;DR: kila mservices hupita kwa 6 mchakato — kuchukua, kutatua muktadha, kuchagua ujuzi, kubainisha mchakato ufuatao, kufanya kazi kwa vifaa vya kuzuia, kudumisha mema.

---

Kwa nini arkitetura inachangia

Agente wa kusoma kwa kielektroniki ambaye unafanya kazi katika demo lakini anapata kosa katika utumiaji wa kawaida kwa kawaida una moja ya hizi 4 matatizo:

1. Latencia ya juu — mteja anapata 8 sekunde ili kujibu, kesi inapokufa.
2. Kutambua kosa la kudumu — agente anapata kiasi, wakati, sera.
3. Muktadha uliopotea — mteja anapokwenda baada ya siku 2 na agente "hujifunza" kila kitu.
4. Kiasi cha kudumu — kila kesi iliyongezeka inachukua kiasi kikubwa katika kipengele na unapata kiasi kikubwa cha pesa kwa kiasi.

Hizi ni chaguzi za arkitetura, si vikwazo vya mbinu. OpenClaw ilibuniwa ili kuepuka hizi — na njia ya kuelewa ni kuchunguza mchakato wa mservices.

---

Mchakato wa mservices (6 mchakato)

Tumia mfano kwamba mteja amekuwa akimfanya ujumbe "nataka kufanya kazi kwa siku ya juma". Nini kinachotokea kati ya "received" na jibu la agente?

Mchakato wa 1 — Kuchukua (edge worker, <ms)

Ujumbe wa WhatsApp unapopita kwa kufa kwenye webhook ya Meta kwa kufa kwenye Cloudflare Worker kwenye nafasi ya kufa (PoP) iliyo karibu zaidi kwa kuzingatia. Katika nchi ya Uswidi, hii inamaanisha Dar es Salaam au Dodoma, latencia ya mtandao <0ms.

Kazi ya kufa inafanya vitu vitatu:

1. Kupima usajili wa webhook (HMAC dhidi ya kiswali cha WABA).
2. Kutambua mteja kwa kwa kiasi cha simu ya mteja (multi-tenant kwa to_number).
3. Kupima payload — sauti inapopinduliwa kuwa　　　　　　, picha inapopinduliwa kuwa kumbukumbu, eneo inapopinduliwa kuwa {lat,lng}, maandishi yenyewe inapopinduliwa kama ilivyokuwa.

Katika mwisho wa mchakato wa 1 unapata kitu {mteja_id, mchakato_id, ujumbe wa mteja} tayari kwa mchakato ufuatao.

• Historia ya hapo awali ya mjadala (miaka N ya mjadala muhimu).
• Memoria ya muda mrefu ya mteja (matumizi, historia ya kuuza, maandishi).
• Hali ya mteja (mtu, uwezo uliojaa, sheria).

Zote zinafika kutoka D1 (SQLite iliyotolewa kwa mtandaoni ya Cloudflare). D1 inabadilisha Postgres/Mongo ya kawaida — bila kifaa cha kudhibiti kwa kudhibiti, uingiliaji kwa sekunde chache kutoka kwa kazi, uwezo wa kujitegemea kwa tenant_id.

Point ya kuzingatia: hatuwezi kutumia mjadala mzima katika prompt. Meneja wa Memory 2 wa OpenClaw (iliyoelezwa katika document ya kifedha) inachagua tu mizunguko muhimu kwa muda huu (miaka N + N ya muhimu zaidi ya kisaikolojia). Hii inaweza kudumisha gharama ya token inayofaa hata katika mjadala wa miaka 100+.

Mchakato wa 3 — Uchaguzi wa uwezo (policy engine, ~20ms)

Kila mteja una kikundi cha uwezo zinazopatikana — vifungu vinavyoweza kutekelezwa. Mifano: consultar_calendario, create_evento, gerar_link_pagamento, consultar_pedido, chama_humano.

Kutokana na taarifa "quero mara kwa siku ya juma la siku ya siku" , mchakato wa policy inachagua:

• Uwezo unaofaa na matumizi yaliyotambulishwa (agendamento).
• Uwezo uliojaa kwa muda wa mjadala (si uwezo wowote unaweza kuwa na uwezo wowote wakati wowote).
• Uwezo uliojaa kwa tenant hii (calendar tu itakuja ikiwa tenant amejitegemea).

Katika mwisho, una uwezo mdogo wa uwezo uliopitishwa kwa modeli — si uwezo 50 zinazowezekana, lakini uwezo 4 pekee unaofaa hapa. Hii inapunguza kwa kiasi kikubwa uwezekano wa modeli kutekeleza uwezo usiofaa.

Mchakato wa 4 — Uamuzi (LLM call, 400-1200ms)

Sasa modeli inaingia. OpenClaw inatoa kikwazo kimoja kwa LLM ya kifronte (Anthropic Claude, OpenAI GPT, Google Gemini — inayoweza kujitegemea kwa tenant) na:

• System prompt = mtu wa mteja + sheria + uwezo uliojaa.
• History = mizunguko iliyochaguliwa katika mchakato wa 2.
• User message = taarifa ya muda huu.

Modeli inaongoza moja ya vitu viwili:

• Jibu la mwisho (matini ya moja kwa mteja).
• Tool call (omba la kutekeleza uwezo mahususi na maadili).

Katika mfano "quero mara kwa siku ya juma la siku ya siku" , modeli mara nyingi inatoa:

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

Mchakato wa 5 — Utekelezaji na vifungu vya kuzuia (variable, ~100-500ms)

Uwezo si unatekelezwa kwenye modeli. Utekelezaji unafanywa katika kodi yetu, ambayo:

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

1. Valaida maadili (maadili ya kipindi ya muda ni sahihi? ni ndani ya sheria za mteja?).
2. Tafuta ruhusa (mteja huyo ana haki ya kujua kalenda hii?).
3. Fanya ujanibishaji (API ya Google Calendar katika hali hii).
4. Tunapata matokeo ya uundaji kwa modeli.

Kwa nini hii ni muhimu? Kwa sababu modeli haina uwezo wa kufanya matokeo yenyewe. Ikiwa kalenda inatoa [10h, 11h], ni hivyo tu ambayo itafika kwenye ujanibishaji wa kujua. Ikiwa ujanibishaji haujafanya kazi, modeli anajua kwamba haujafanya kazi. Hakuna hatari ya mteja "kufanya" kuwa na muda wa 9h wakati haukuwa na.

Katika hali ambazo zinahusisha taarifa nyeti (gharama, muda, jina la mteja), pipeline inaamuru tool call — haitoi modeli kujibu kutoka kwa "ujuzi wake". Hii hupunguza kundi la alucination zaidi la kawaida katika wateja wanaofanya biashara.

Mwaka wa 6 — Matokeo na uharibifu (~50ms)

Na matokeo ya ujanibishaji wa kujua, modeli hufanya ujanibishaji wa pili — sasa kujibu jibu la mwisho kwa mteja. Kwa mfano:

"Nina siku ya Jumapili kwa saa 10h na 11h. Unataka nini?"

Kwa upande mwingine, kazi:

1. Iliwasilisha taarifa kwa API ya WhatsApp.
2. Uharibifu muda mzima (mteja + mteja + ujanibishaji wa kujua + muda) kwenye D1.
3. Uharibifu wa mema ya muda mrefu ikiwa muda uliotokana na mteja ulikuwa na taarifa mpya (kwa mfano, "mteja anataka Jumapili").
4. Iliwezesha tukio la uchunguzi (hesabu ya muda, gharama ya token, kiwango cha kuzidisha).

Huu wote unafanyika kwa wakati mmoja. Uharibifu hauwezi kufanya kazi kwa kutoa taarifa — mteja hatakiwa atafute D1.

---

Kwa nini kuna uwezo wa kudhibiti alucination

Mteja anayefanya alucination katika ujanibishaji hauwezi kujua. OpenClaw ina 4 mbinu za kudhibiti alucination:

1. Uwezo wa kujua wa kifungu. Taarifa za kihisia (gharama, muda, jina) zinafika kwa ujanibishaji, sio modeli peke yake.
2. Uchunguzi wa kudumu katika taarifa nyeti. Agendamento linapitishwa na mteja kabla ya kuhifadhi. Uhamisho unapitishwa kabla ya kutoa mteja.
3. Mabano ya kutojibu. Kila mteja ina "hakikisha hivi si sahihi" — modeli inakubali.
4. Kujibu kwa mwanadamu. Ikiwa hakuna ujanibishaji unaofanya kazi, mteja anasema "dehehe, nitaangalia na timu" na kufungua tikiti — hauwezi kujibu.

Katika utafiti uliofanyika katika miezi 6 iliyopita (mawasiliano ya kweli yaliyotathminiwa kwa kujitolea), kiwango cha alucination cha kihisia kilikuwa chini ya 0.3% ya mawasiliano — na kila kesi ilikuwa kwa sababu ya kubadilishana (mteja alikuwa amesahihisha ujanibishaji wa kujua, lakini haujafanya kazi), sio kosa cha modeli.

---

Gharama ya kila mawasiliano

Kwa hivyo, gharama ya kila mawasiliano ni:

Arquitetura nzuri ni inayoweza kuthaminiwa tu baada ya kuchukua fomula. Kwa kuwa kila mzunguko hufanya 1-2 matumizi ya LLM + lookups katika D1, gharama ya kawaida kwa mjadala mzima (10-15 mzunguko) inakuwa:

Note: I translated "Arquitetura boa" to "Arquitetura nzuri" and "fatura" to "fomula". I also translated "Dado que" to "Kwa kuwa" and "o custo típico" to "gharama ya kawaida".