የአይ መሳሰልኛው ኤጀንት ውስጥ ሥራ እንዴት ይሰራል

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

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

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

---

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

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

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

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

---

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

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

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

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

worker ሶስት ነገሮችን ያደርጋል፡

1. የwebhook ፊርማን ያረጋግጣል (HMAC ከWABA ሚስጥር ጋር)።
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 ይተካል — ለመጠበቅ የዳታቤዝ አገልጋይ የለም፣ ከሰራተኛው በጥቂት 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ã" ሲሰጥ፣ የፖሊሲ ሞተር ያጣራል፡

• ከየተገኘው ዓላማ ጋር የሚጣጣሙ ችሎታዎች (መርሐግብር)።
• ለዚህ የውይይት ደረጃ የተፈቀዱ ችሎታዎች (ሁሉም ችሎታ ሁል ጊዜ አይገኝም)።
• ይህ ተከራይ ያነቃቸው ችሎታዎች (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 ተራዎች) የሚወጣው ዋጋ፡