የ AI መስተጋብራዊ ወኪል ውስጥ እንዴት ይሰራል

የውይይት AI ወኪል ከውስጥ እንዴት እንደሚሰራ (የOpenClaw አርክቴክቸር)

የውይይት AI ወኪል እንዴት እንደሚሰራ በተግባር፣ ተራ በተራ? ይህ ጽሁፍ የOpenClaw ጥቁር ሳጥንን ይከፍታል፡ የደንበኛው መልእክት በWhatsApp ላይ ከደረሰበት ጊዜ ጀምሮ ወኪሉ ወደ ኋላ እስከሚጽፈው ጽሑፍ ድረስ። ቴክኒካል ይሆናል። የምርት አርክቴክቸር ከወሰኑ፣ መፍትሄ ለመግዛት ሲሄዱ እና ጥልቀቱን መገምገም ከፈለጉ፣ ወይም ከውይይቱ በስተጀርባ ምን እየተከሰተ እንደሆነ ማወቅ ከፈለጉ ጠቃሚ ነው።

TL;DR: እያንዳንዱ ተራ በ6 ደረጃዎች ያልፋል — ingest፣ ሁኔታን መፍታት፣ ክህሎቶችን መምረጥ፣ ቀጣዩን እርምጃ መወሰን፣ በጥበቃ-ሀዲዶች መፈጸም፣ ማህደረ ትውስታን ማስቀመጥ። ሁሉም ዑደት ቋሚ አገልጋይ ሳይኖር በCloudflare edge ላይ በ<2 ሰከንድ ውስጥ ይሰራል።

---

አርክቴክቸር ለምን አስፈላጊ ነው

በማሳያ ላይ የሚሰራ የሚመስል ግን በምርት ላይ የሚሰበር የውይይት ወኪል በአጠቃላይ ከእነዚህ 4 ችግሮች አንዱ አለው፡

1. ከፍተኛ መዘግየት — ደንበኛ ለምላሽ 8 ሰከንድ ይጠብቃል፣ ውይይቱ ይሞታል።
2. ያልተቆጣጠረ ቅዠት — ወኪሉ ዋጋ፣ ሰዓት፣ ፖሊሲ ይፈጥራል።
3. የጠፋ ሁኔታ — ደንበኛ ከ2 ቀናት በኋላ ይመለሳል እና ወኪሉ ሁሉንም "ይረሳል"።
4. ያልተቆጣጠረ ወጪ — እያንዳንዱ ረጅም ውይይት ፕሮምፕቱን ይሞላል እና በቶከን ላይ ሀብት ይከፍላሉ።

4ቱም የአርክቴክቸር ምርጫዎች ናቸው፣ የሞዴል ገደቦች አይደሉም። OpenClaw 4ቱንም ለማስወገድ ተገንብቷል — እና ለመረዳት መንገዱ የአንድ ተራ ዑደት መመልከት ነው።

---

የአንድ ተራ ዑደት (6 ደረጃዎች)

ደንበኛው አሁን "ለቅዳሜ ጠዋት መያዝ እፈልጋለሁ" የሚለውን መልእክት እንደላከ አስብ። በ"received" እና በወኪሉ ምላሽ መካከል ምን ይከሰታል?

ደረጃ 1 — Ingest (edge worker, <50ms)

የWhatsApp መልእክት በMeta webhook በኩል በጂኦግራፊያዊ ሁኔታ በጣም ወደ ቅርብ Cloudflare Worker በመገኛ ነጥብ (PoP) ላይ ይደርሳል። በብራዚል፣ ይህ ሳኦ ፓውሎ ወይም ሪዮ ማለት ነው፣ የአውታረ መረብ መዘግየት < 20ms።

ሰራተኛው ሶስት ነገሮችን ያደርጋል፡

1. የwebhook ፊርማን ያረጋግጣል (HMAC ከWABA ሚስጥር ጋር)።
2. ተከራዩን ይለያል በተቀባዩ ስልክ ቁጥር (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 ይተካል — ለመጠበቅ የውሂብ ጎታ አገልጋይ የለም፣ ከሰራተኛው በጥቂት ms ውስጥ መዳረሻ፣ በtenant_id ባለብዙ-ተከራይ።

ቁልፍ ነጥብ፡ እኛ ሙሉውን ውይይት አንጭንም በፕሮምፕቱ ውስጥ። የ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 ያጣራል፡

• ከየተገኘው ዓላማ ጋር ተኳሃኝ የሆኑ ክህሎቶች (መርሐግብር)።
• ለዚህ የውይይት ደረጃ የተፈቀዱ ክህሎቶች (ሁሉም ክህሎት ሁል ጊዜ አይገኝም)።
• ይህ ተከራይ ያነቃቸው ክህሎቶች (calendar የሚታይ ተከራዩ ካዋሃደ ብቻ ነው)።

በመጨረሻ ለሞዴሉ የሚተላለፍ ትንሽ የክህሎቶች ንዑስ ስብስብ ያገኛሉ — የሚቻሉት 50 ሳይሆን እዚህ ትርጉም ያላቸው 4 ብቻ። ይህ ሞዴሉ የተሳሳተ ክህሎት የመጥራት እድልን በከፍተኛ ሁኔታ ይቀንሳል።

ደረጃ 4 — ውሳኔ (LLM call, 400-1200ms)

አሁን ሞዴሉ ይገባል። OpenClaw ወደ ድንበር LLM (Anthropic Claude፣ OpenAI GPT፣ Google Gemini — በተከራይ ሊዋቀር የሚችል) አንድ ጥሪ ያደርጋል፡

• 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 — በጥበቃ-ሀዲዶች አፈጻጸም (ተለዋዋጭ፣ ~100-500ms)

ክህሎቱ አይሰራም በሞዴሉ ውስጥ። በእኛ ኮድ ውስጥ ይሰራል፣ እሱም፡

1. መለኪያዎችን ያረጋግጣል (date_range ትክክለኛ ቅርጸት አለው? በተከራይ ደንቦች ውስጥ ነው?).
2. ፈቃድ ይፈትሻል (ይህ ወኪል ይህንን የቀን መቁጠሪያ የመጠየቅ መብት አለው?).
3. ጥሪውን ያከናውናል (በዚህ ጉዳይ ላይ Google Calendar API).
4. የተዋቀረ ውጤት ይመልሳል ለሞዴሉ።

ይህ ለምን አስፈላጊ ነው? ምክንያቱም ሞዴሉ ውጤቱን በፍፁም አያመነጭም። የቀን መቁጠሪያው [10h, 11h] ቢመልስ፣ ለሚቀጥለው ጥሪ የሚሄደው በትክክል ያ ነው። ክህሎቱ ካልተሳካ፣ ሞዴሉ ያልተሳካ መሆኑን ያውቃል። ወኪሉ በ9ሰ "ሰዓት አለ" ብሎ "የመፍጠር" ዜሮ አደጋ።

ሚስጥራዊ መረጃን የሚያካትቱ ጉዳዮች (ዋጋ፣ ጊዜ፣ የደንበኛ ስም) ለሚመለከቱ፣ ፓይፕላይኑ tool call ያስገድዳል — ሊሞዴሉ ከራሱ "እውቀት" መልስ እንዲሰጥ አይፈቅድም። ይህ በንግድ ወኪሎች ውስጥ በጣም የተለመደውን የማስመሰል ክፍል ያስወግዳል።

ደረጃ 6 — ምላሽ እና ዘላቂነት (~50ms)

የክህሎት ውጤቱ በእጅ ሲኖር፣ ሞዴሉ ሁለተኛውን ጥሪ ያደርጋል — አሁን ለደንበኛው የመጨረሻ ምላሽ ለመስጠት። ምሳሌ:

"ቅዳሜ በ10ሰ እና 11ሰ አለኝ። የትኛውን ይመርጣሉ?"

በተመሳሳይ ጊዜ፣ ሰራተኛው:

1. መልእክቱን ይልካል በWhatsApp API በኩል።
2. ሙሉውን ተራ ያስቀምጣል (user + assistant + tool calls + ቆይታ) በD1 ውስጥ።
3. የረጅም ጊዜ ማስታወሻውን ያዘምናል ተራው አዲስ እውነታ ካመነጨ (ምሳሌ: "ደንበኛ ቅዳሜን ይመርጣል")።
4. የመመልከት ክስተት ያወጣል (የመዘግየት መለኪያ፣ የቶከን ወጪ፣ የማስፋፊያ መጠን)።

ይህ ሁሉ በትይዩ ይሰራል። ዘላቂነቱ መልእክቱን መላክ አያግድም — ደንበኛው D1ን አይጠብቅም።

---

ከማስመሰል ጥበቃው የት ነው

በምርት ላይ የሚያስመስል ወኪል በፍጥነት እምነት ያጣል። OpenClaw 4 የመከላከያ መስመሮች አሉት:

1. የተገደደ የእውነታ ምንጭ። እውነታዊ መረጃዎች (ዋጋ፣ ሰዓት፣ ስም) ሁልጊዜ ከክህሎት ይመጣሉ፣ ከሞዴሉ ብቻ በፍፁም አይደለም።
2. በሚስጥራዊ መረጃ ላይ ድርብ ማረጋገጫ። ቀጠሮ ከመያዝ በፊት ከደንበኛው ጋር ይረጋገጣል። ክፍያ መዳረሻ ከመስጠት በፊት ይረጋገጣል።
3. ግልጽ አሉታዊ ደንቦች። የእያንዳንዱ ወኪል ስብዕና "X, Y, Z በፍፁም አትፍጠር" ያካትታል — ሞዴሉ ይታዘዛል።
4. ለሰው ተተኪ። ምንም ክህሎት ጥያቄውን በማይሸፍንበት ጊዜ፣ ወኪሉ "ከቡድኑ ጋር እፈትሻለሁ" ይላል እና ቲኬት ይከፍታል — አይገምትም።

ባለፉት 6 ወራት ባደረግናቸው ኦዲቶች (እውነተኛ ውይይቶች በእጅ ተገምግመዋል)፣ የእውነታ ማስመሰል መጠን ከ0.3% ተራዎች በታች ቆይቷል — እና ሁሉም ጉዳዮች በconfig ምክንያት ነበሩ (ተከራይ ተዛማጅ ክህሎትን ማንቃት ረስቷል)፣ የሞዴል ስህተት አይደለም።

---

በውይይት ወጪ

ጥሩ አርክቴክቸር እስከ ሂሳቡን እስከምታይ ድረስ የማይታይ ነው። እያንዳንዱ ተራ 1-2 የLLM ጥሪዎች + በD1 ውስጥ ፍለጋዎችን ስለሚያደርግ፣ በአንድ ሙሉ ውይይት (10-15 ተራዎች) የሚወጣው ዋጋ፡