မက်ဆေ့ချ်များ¶

ဤစာမျက်နှာသည် OpenClaw က အဝင်မက်ဆေ့ချ်များ၊ ဆက်ရှင်များ၊ တန်းစီခြင်း၊ စီးဆင်းပို့ဆောင်မှု နှင့် အကြောင်းရင်းမြင်သာမှုတို့ကို မည်သို့ ကိုင်တွယ်သည်ကို ပေါင်းစည်းရှင်းလင်းထားသည်။

မက်ဆေ့ချ် စီးဆင်းမှု (အဆင့်မြင့် အကျဉ်းချုပ်)¶

Inbound message
  -> routing/bindings -> session key
  -> queue (if a run is active)
  -> agent run (streaming + tools)
  -> outbound replies (channel limits + chunking)

အဓိက ခလုတ်များကို ဖွဲ့စည်းပြင်ဆင်မှုတွင် တွေ့နိုင်သည်-

• ပရီးဖစ်များ၊ တန်းစီခြင်း နှင့် အုပ်စု အပြုအမူများအတွက် messages.*။
• ဘလောက်အလိုက် စီးဆင်းပို့ဆောင်မှု နှင့် ချန့်ခွဲခြင်း မူလတန်ဖိုးများအတွက် agents.defaults.*။
• ချန်နယ်အလိုက် override များ (channels.whatsapp.*, channels.telegram.*, စသည်) ကို caps နှင့် streaming toggle များအတွက် အသုံးပြုနိုင်သည်။

အပြည့်အစုံ စနစ်ဖွဲ့စည်းပုံအတွက် Configuration ကို ကြည့်ပါ။

အဝင် မက်ဆေ့ချ် ထပ်တူဖယ်ရှားခြင်း (Inbound dedupe)¶

ချန်နယ်များသည် reconnect ပြန်လုပ်ပြီးနောက် တူညီသော မက်ဆေ့ချ်ကို ထပ်မံပို့နိုင်သည်။ OpenClaw သည် ထိန်းသိမ်းထားသည်။ short-lived cache keyed by channel/account/peer/session/message id so duplicate deliveries do not trigger another agent run.

အဝင် မက်ဆေ့ချ် တုန့်ပြန်နှေးကွေးပေါင်းစည်းခြင်း (Inbound debouncing)¶

ပေးပို့သူတစ်ဦးတည်းမှ ဆက်တိုက် အမြန်ပို့လာသော မက်ဆေ့ချ်များကို တစ်ခုတည်းသော အရာအဖြစ် စုပေါင်းနိုင်သည်။ agent turn via messages.inbound. Debouncing is scoped per channel + conversation and uses the most recent message for reply threading/IDs.

ဖွဲ့စည်းပြင်ဆင်မှု (ကမ္ဘာလုံးဆိုင်ရာ မူလတန်ဖိုး + ချန်နယ်အလိုက် အစားထိုးများ):

{
  messages: {
    inbound: {
      debounceMs: 2000,
      byChannel: {
        whatsapp: 5000,
        slack: 1500,
        discord: 1500,
      },
    },
  },
}

မှတ်ချက်များ-

• Debounce သည် စာသားသာ မက်ဆေ့ချ်များအတွက်သာ သက်ရောက်သည်; မီဒီယာ/အတူတွဲဖိုင်များသည် ချက်ချင်း လွှတ်ထုတ်သည်။
• ထိန်းချုပ်မှု အမိန့်များသည် Debouncing ကို ကျော်လွှားပြီး တစ်ခုချင်းစီ သီးသန့် ရှိနေစေသည်။

ဆက်ရှင်များ နှင့် ကိရိယာများ¶

ဆက်ရှင်များကို client များမဟုတ်ဘဲ Gateway က ပိုင်ဆိုင်သည်။

• တိုက်ရိုက် စကားပြောများသည် အေးဂျင့် အဓိက ဆက်ရှင် ကီးသို့ ပေါင်းစည်းသည်။
• အုပ်စုများ/ချန်နယ်များတွင် ကိုယ်ပိုင် ဆက်ရှင် ကီးများ ရှိသည်။
• ဆက်ရှင် သိုလှောင်ရာ နှင့် စာတမ်းမှတ်တမ်းများသည် Gateway ဟို့စ် ပေါ်တွင် ရှိသည်။

ကိရိယာများ/ချန်နယ်များ အများအပြားသည် session တစ်ခုတည်းသို့ ချိတ်ဆက်နိုင်သော်လည်း history ကို အပြည့်အဝ မရရှိနိုင်ပါ။ synced back to every client. Recommendation: use one primary device for long conversations to avoid divergent context. The Control UI and TUI always show the gateway-backed session transcript, so they are the source of truth.

အသေးစိတ်: Session management။

အဝင် ဘော်ဒီများ နှင့် သမိုင်းအကြောင်းအရာ¶

OpenClaw သည် prompt body နှင့် command body ကို ခွဲခြားထားသည်-

• Body- agent သို့ ပို့သော prompt စာသား။ ၎င်းတွင် ချန်နယ် envelope များနှင့် ပါဝင်နိုင်သည်။ ရွေးချယ်နိုင်သော history wrapper များ။
• CommandBody: လမ်းညွှန်ချက်/အမိန့် ခွဲခြမ်းစိတ်ဖြာရန် အသုံးပြုသော အသုံးပြုသူ၏ မူရင်း စာသား။
• RawBody: CommandBody အတွက် အဟောင်း alias (ကိုက်ညီမှုအတွက် ထားရှိထားသည်)။

ချန်နယ်တစ်ခုက သမိုင်းကို ပံ့ပိုးပါက မျှဝေထားသော အဖုံးတစ်ခုကို အသုံးပြုသည်-

• [Chat messages since your last reply - for context]
• [Current message - respond to this]

တိုက်ရိုက်မဟုတ်သော chat များ (group/channel/room များ) အတွက် လက်ရှိ မက်ဆေ့ချ် body ကို အောက်ပါအတိုင်း prefix ထည့်ပေးသည်။ sender label (same style used for history entries). This keeps real-time and queued/history messages consistent in the agent prompt.

သမိုင်း ဘဖာများသည် စောင့်ဆိုင်းနေသည့် အချက်များသာ ပါဝင်သည်- အလုပ်မလုပ်စေခဲ့သော အုပ်စု မက်ဆေ့ချ်များ (ဥပမာ၊ mention-gated မက်ဆေ့ချ်များ) ကို ထည့်သွင်းပြီး ဆက်ရှင် စာတမ်းမှတ်တမ်းထဲတွင် ရှိပြီးသား မက်ဆေ့ချ်များကို မပါဝင် စေပါ။

Directive ဖယ်ရှားခြင်းသည် လက်ရှိ မက်ဆေ့ချ် အပိုင်းအတွက်သာ သက်ဆိုင်ပြီး history ကို မထိခိုက်စေပါ။ remains intact. Channels that wrap history should set CommandBody (or RawBody) to the original message text and keep Body as the combined prompt. History buffers are configurable via messages.groupChat.historyLimit (global default) and per-channel overrides like channels.slack.historyLimit or channels.telegram.accounts.<id>.historyLimit (set 0 to disable).

တန်းစီခြင်း နှင့် နောက်ဆက်တွဲများ¶

အလုပ်လုပ်နေသော run တစ်ခု ရှိပြီးသားဖြစ်ပါက အဝင် မက်ဆေ့ချ်များကို တန်းစီနိုင်ပြီး လက်ရှိ run သို့ ဦးတည်စေနိုင်သကဲ့သို့ နောက်တစ်လှည့် အတွက် စုဆောင်းထားနိုင်ပါသည်။

• messages.queue (နှင့် messages.queue.byChannel) ဖြင့် ဖွဲ့စည်းပါ။
• မုဒ်များ: interrupt, steer, followup, collect, နှင့် backlog မျိုးကွဲများ။

အသေးစိတ်: Queueing။

စီးဆင်းပို့ဆောင်မှု၊ ချန့်ခွဲခြင်း နှင့် အစုလိုက်ပို့ခြင်း¶

Block streaming သည် model မှ စာသား block များ ထုတ်လုပ်သလို partial reply များကို ပို့ပေးသည်။ Chunking respects channel text limits and avoids splitting fenced code.

အဓိက သတ်မှတ်ချက်များ-

• agents.defaults.blockStreamingDefault (on|off, မူလအနေဖြင့် ပိတ်)
• agents.defaults.blockStreamingBreak (text_end|message_end)
• agents.defaults.blockStreamingChunk (minChars|maxChars|breakPreference)
• agents.defaults.blockStreamingCoalesce (အလုပ်မရှိချိန် အခြေပြု အစုလိုက်ပို့ခြင်း)
• agents.defaults.humanDelay (လူသားဆန်သည့် ဘလောက်ပြန်ကြားချက်များကြား ခဏနား)
• ချန်နယ် အစားထိုးများ: *.blockStreaming နှင့် *.blockStreamingCoalesce (Telegram မဟုတ်သော ချန်နယ်များတွင် အထူး *.blockStreaming: true ကို လိုအပ်သည်)

အသေးစိတ်: Streaming + chunking။

အကြောင်းရင်း မြင်သာမှု နှင့် တိုကင်များ¶

OpenClaw သည် မော်ဒယ် အကြောင်းရင်းကို ဖော်ပြနိုင်သလို ဖုံးကွယ်နိုင်ပါသည်-

• /reasoning on|off|stream သည် မြင်သာမှုကို ထိန်းချုပ်သည်။
• မော်ဒယ်က ထုတ်လုပ်ပါက အကြောင်းရင်း အကြောင်းအရာသည် တိုကင် အသုံးပြုမှုထဲတွင် ထည့်တွက်ထားဆဲ ဖြစ်သည်။
• Telegram သည် draft bubble ထဲသို့ အကြောင်းရင်း စီးဆင်းမှုကို ထောက်ပံ့သည်။

အသေးစိတ်: Thinking + reasoning directives နှင့် Token use။

ပရီးဖစ်များ၊ ချည်တွဲခြင်း နှင့် ပြန်ကြားချက်များ¶

အထွက် မက်ဆေ့ချ် ပုံစံချခြင်းကို messages တွင် အလယ်တန်း စီမံထားသည်-

• messages.responsePrefix, channels.<channel>.responsePrefix, and channels.<channel>.accounts.<id>.responsePrefix (outbound prefix cascade), plus channels.whatsapp.messagePrefix (WhatsApp inbound prefix)
• replyToMode နှင့် ချန်နယ်အလိုက် မူလတန်ဖိုးများဖြင့် ပြန်ကြားချက် ချည်တွဲခြင်း

အသေးစိတ်: Configuration နှင့် ချန်နယ် စာရွက်များ။