LLM မှသည် agent များဆီသို့

ChatGPT တို့ Gemini တို့လို chat service တွေအတွက် နောက်ကွယ်မှာ အလုပ်လုပ်ပေးနေတာက LLM model တွေဖြစ်တယ်။ LLM ဆိုတာ အလွယ်နားလည်အောင် ပြောရရင် စာကြောင်းတကြောင်းကို ဆက်ရေးသွားပေးနိုင်တဲ့ machine learning မော်ဒယ်တွေကို ခေါ်တယ်။ လူသားတွေ အသက်ရှင်သန်ဖို့ ဘာဓာတ်ငွေ့ကို ရှူရသလဲဆိုရင် အောက်စီဂျင် ရှူရပါတယ်လို့ ဆက်ရေးပေးနိုင်တယ်။ programmer တယောက်က ငါ့ကို ဒီ feature လေးရေးပေးစမ်းပါဆိုရင်လည်း သူဆက်ပြီး generate လုပ်သွားပေးနိုင်တယ်ပေါ့။ ဒါကြောင့်လည်း LLM က Generative AI အုပ်စုထဲ ပါတာပဲ။ အဲဒီမှာမှ ငါဆိုတာ ပြောနေတဲ့သူ၊ မင်းဆိုတာ LLM ကိုရည်ညွှန်းမှန်း သိနိုင်တယ်ဆိုတာက အဲသလို train ထားလို့ဖြစ်တယ်။ ဘာလို့လဲဆိုတော့ အဲသလို နှစ်ယောက် အ​ပြန်အလှန် chat နေတယ်ဆိုတဲ့ပုံစံက ChatGPT ဆိုတဲ့ service ကပေးထားတဲ့ အပေါ်ယံအလွှာသက်သက်ပဲဖြစ်ပြီး LLM အတွက်က အရာအားလုံးက အလွှာတခုတည်းအနေနဲ့ပဲ ရှိတာမို့​လို့ပါ။

LLM တွေရဲ့ အသုံးဝင်ပုံကိုပြောရင် ဆုံးမှာမဟုတ်ပါဘူး။ ဒါပေမယ့် ဒီ LLM တွေမှာလည်း ကန့်သတ်ချက်တွေရှိပါတယ်။ LLM model တွေဖြစ်တဲ့ Claude Opus 3.5, DeepSeek V4 စတဲ့ model တွေက static weight တွေ bias တွေနဲ့တည်ဆောက်ထားတဲ့ ဖိုင်သက်သက်ပဲဖြစ်တယ်။ hardware level မှာ tensor ဝင် tensor ထွက်ဆိုတဲ့ စနစ်ဖြစ်တဲ့အတွက် LLM တွေက သူတို့ကို train ထားသလောက်ပဲ generate လုပ်နိုင်စွမ်းရှိပါတယ်။

ဥပမာ LLM ကိုကျွန်တော်က ငါနောက်အပတ် Paris သွားမယ်၊ ရာသီဥတု အနေအထားကြည့်ပြီး ပလန်ဆွဲပေးစမ်းကွာဆိုရင် သူမလုပ်နိုင်ပါဘူး။ ဘာလို့လဲဆိုတော့ နောက်အပတ် နေပူမလား မိုးရွာမလား သူမှမသိတာကိုး။ ဒါပေမယ့် ကျွန်တော်က ရော့ ငါ့ဆီမှာ realtime weather ကြည့်လို့ရမယ့် weather API ရှိတယ်ဆိုပြီး အဲဒီ Weather API ရဲ့ OpenAPI schema ဖြစ်ဖြစ်၊ protobuf definition ဖြစ်ဖြစ် ပေးလိုက်ရင် run ရမယ့် curl command ကိုသူပြန်ပေးနိုင်လိမ့်မယ်။ ကိုယ်က terminal တခုဖွင့်၊ အဲဒီ command ကို run ပြီး ရလာတဲ့ ရလဒ်ကို ပြန်ပေးလိုက်ရင် LLM ကလာမယ့်အပတ်အတွက် ရာသီဥတုကို သိသွားပါပြီ။

ဒါပေမယ့် သူက စားသောက်ဆိုင်တွေ၊ ဟိုတယ်တွေတော့ book နိုင်ဦးမှာ မဟုတ်သေးပါဘူး။ ခုနက ပြောခဲ့သလိုပဲ LLM ဆိုတာ model weight တွေပါတဲ့ ဖိုင်တခုသက်သက်ပဲဆိုတာကိုး။ ဒီတော့ ကျွန်တော်တို့က ငါ့မှာ Booking API လည်းရှိတယ်။ ရော့ ဒါက သူ့ရဲ့ API schema တွေဆို​ပြီး ပေးလိုက်ရင် LLM ကခုနကလိုပဲ ခေါ်ရမယ့် command တွေထပ် generate လုပ်ပေးနိုင်လိမ့်မယ်။ ကျွန်တော်က အဲဒီ command ကိုသွား run လို့ error တက်သွားတယ်ဆိုပါတော့။ LLM ကို error လိုက်ကြီး ပြန် paste ထည့်ပြီး မှားနေတဲ့ command ကိုပြင်ခိုင်းလို့ရပါတယ်။ အဆုံးသတ်မှာ နောက်အပတ်အတွက် Paris သွားလည်ဖို့ အဆင်သင့်ဖြစ်သွားပါပြီ။

ဒီ process ကြီးတခုလုံးကို ကြည့်မယ်ဆိုရင် LLM တလှည့် လူတလှည့်နဲ့ အတော်လေး efficient မဖြစ်တာကို တွေ့ရလိမ့်မယ်။ ဒီတော့ ကျွန်တော်တို့ middle program တခုရေးထားဖို့ လိုအပ်လာတယ်။ အဲဒီ program ရဲ့အဓိက တာဝန်က bash sub process တွေ spawn နိုင်ဖို့ပဲ။ LLM က command တခု run ခိုင်းတိုင်း အဲဒီ program က shell process တခု fork ပြီး command ကို run မယ်။ exit status နဲ့တကွ output တွေကို LLM ဆီပြန်ပေးမယ်ပေါ့။ ဘယ်ဟာက run ရမယ့် shell command လဲဆိုတာ သိရဖို့ LLM နဲ့ program ကြားမှာ contract တခုလည်း ရှိဖို့လိုလာမယ်။ ဥပမာ

{
  "command": "curl -X POST my-booking-site.com/api/bookings"
}

ဆိုတာမျိုးပေါ့။ ဒါက MCP ရဲ့အခြေခံ အိုင်ဒီယာပါပဲ။ ဒါပေမယ့် ဒီမှာ ပြဿနာလေးတွေရှိပါတယ်။

နံပါတ်တစ်ကတော့ context window management ပါ။ အလွယ်ပြောရရင် context window ဆိုတာ LLM ကဖတ်ပြီး နောက်ထပ်စာလုံးတွေ ဆက် generate နိုင်တဲ့ အတိုင်းအတာ အကန့်အသတ်လို့ မှတ်လို့ရတယ်။ ဒီပမာဏကို LLM ရဲ့ architecture ကအဓိက အဆုံးအဖြတ်ပေးတယ်။ ပြောရရင် unlimited စားနိုင်သလောက် အကုန်စား ဘူဖေးစနစ် မဟုတ်ဘူးဆိုပါတော့။ ဒီတော့ LLM-powered app တခုကောင်းကောင်း အလုပ်လုပ်နိုင်ဖို့ဆိုရင် context window ထဲဘာတွေထည့်ထားမလဲ၊ ဘာတွေကို လှဲထုတ်သွားမလဲဆိုတဲ့ ဗျူဟာက အရေးကြီးပါတယ်။ ဗျူဟာလို့ဆိုတဲ့နေရာမှာ RAG, chunk-based semantic retrieval, system resource စသဖြင့် မျိုးစုံရှိပါတယ်။ ဒါပေမယ့် structure တထေရာတည်း မရှိတဲ့ API format တွေကို parse ဖို့ format ဖို့ဆိုတာ ဘယ်လိုမှ လွယ်ကူလှတဲ့ကိစ္စ မဟုတ်ပါဘူး။ ဒီအတွက် lightweight ဖြစ်တဲ့ first-class interface တခုလိုအပ်လာတယ်။

နံပါတ်နှစ်က LLM friendly မဖြစ်ခြင်းပါ။ အရင်ကရှိထားတဲ့ API schema format တွေက semantic search ကိုဦးစားပေးပြီး ရေးထားတဲ့ spec တွေမဟုတ်ပါဘူး။ M2M static validation လုပ်ဖို့နဲ့ လူသား developer တွေဖတ်ပြီး ဟိုဖက်ဒီဖက် (client နဲ့ server) interface တွေဆောက်နိုင်ဖို့ အသားပေး ရေးထားတာတွေဖြစ်လို့ LLM အတွက်ဆိုရင် တကယ်လိုအပ်တာထက် ပွထနေတယ်။ နံပါတ်တစ်အချက်က context window နဲ့ဆက်စပ်လိုက်ရင် LLM တွေအတွက် ​semantic search ကိုအဓိကထားပြီး တိုတိုနဲ့ ကျစ်ကျစ်လျစ်လျစ်ရှိတဲ့ specification တခုရှိဖို့ လိုအပ်လာတယ်။

နံပါတ်သုံးက implementation burden ပါ။ ဒီအချက်က ပြောစရာအများကြီး ရှိပေမယ့် မြင်သာထင်သာရှိတာတခုကို ရွေးပြောပါ့မယ်။ ရှေ့မှာတုန်းက middle program က LLM ကဆန္ဒရှိတဲ့ command တွေကို run ပေးဖို့အတွက် ရှိနေရတယ်လို့ ပြောခဲ့တယ်။ ဒါပေမယ့် LLM က schema အတွက်လိုအပ်တဲ့ argument type နဲ့ bound တွေကို တကယ်ပေးနေရဲ့လား ကျွန်တော်တို့စစ်ဖို့လိုတယ်။ ဒီအတွက် middle program ကနာမည်ကြီး schema format တွေအကုန်လုံးနဲ့ အလုပ်လုပ်နိုင်အောင် တည်ဆောက်ထားရလိမ့်မယ်။ ဆိုလိုချင်တာက implementation burden က provider ဆီမှာမရှိပဲ runtime layer မှာဖြစ်သွားတဲ့အတွက် vendor တွေက တယောက်တမျိုးစီ လုပ်ကြပြီး ဒီအချက်က ရေရှည်မှာ LLM powered application တွေရဲ့ ecosystem မှာ portability ကို အကြီးကြီး ထိခိုက်ပါလိမ့်မယ်။ အလားတူပဲ authentication, idempotency စတဲ့ခေါင်းစဥ်တွေက ဒီအချက်ထဲမှာ ပါတယ်။

နံပါတ်လေးက safety နဲ့ policy enforcement ပါ။ LLM ကိုအချို့ command တွေ API တွေကို လူခွင့်ပြုချက်မပါပဲ ပေးသုံးချင်တယ်။ တချို့ command တွေကိုတော့ လူက ခွင့်ပြုမှရမယ်။ OpenAPI, gRPC, Apache Thrift စတဲ့ schema တွေမှာ data classification နဲ့ sensitivity စသဖြင့်တွေက vendor အပေါ်မူတည်ပြီး သတ်မှတ်ပုံကွဲပြားကြတဲ့အတွက် automatic approval တို့ HITL (human in the loop) တို့တွေကို middle program ကအပြည့်အဝ support ဖို့မဖြစ်နိုင်သလောက်ပါပဲ။

ဒီပြဿနာတွေကို ချုံကြည့်ရင် အဖြေက ၂ မျိုးပဲရှိပါတယ်။ API တွေ တပြေးညီတည်း ဖြစ်မနေမှုကို middle program တွေကပဲ တတ်နိုင်သလောက် လိုက်ဖြည့်မလား။ ဒါမှမဟုတ် uniform API specification အသစ်တခုသတ်မှတ်တာဖြစ်ဖြစ်၊ ရှိပြီးသား format တခုခုကို extend လုပ်ပြီးတော့ပဲဖြစ်ဖြစ် implementation burden ကို provider တွေဆီ တွန်းပို့မလား။ ပထမ option ကိုရွေးရင်တော့ runtime ကကြာလေ bloat ဖြစ်လေဆိုတဲ့ အခြေအနေကို ရောက်လာပါမယ်။ 2026 မှာဒီစာကို ဖတ်နေတယ်ဆိုရင်တော့ industry ကဘယ်လမ်းကို ရွေးခဲ့လဲဆိုတာ သိလောက်ပါပြီ။ ဒီလိုနဲ့ MCP spec ဖြစ်လာခဲ့ပါတယ်။

ဒီနေရာမှာလည်း ရှိပြီးသား format တခုခုကို extend လုပ်မယ့်အစား MCP ဆိုပြီး သီးခြား protocol ဖြစ်လာအောင် တွန်းပို့ခဲ့တဲ့အထဲမှာ client-server communication ပုံစံအပေါ် မြင်တဲ့ပုံချင်း မတူတော့တာကလည်း တခုအပါအဝင်ဖြစ်တယ်။ သာမန် web application အတွက် server (ဥပမာ object storage backend, SMS API စသဖြင့်) တွေက ကိုယ့် application ရဲ့ ပင်တိုင် feature တွေနဲ့ couple ဖြစ်လွန်းနေတယ်။ ဒါပေမယ့် တခြား niche ဖြစ်တဲ့ LLM application တွေကို တင် run မယ့် container/runtime အဖြစ်ရည်ရွယ်ပြီး တည်ဆောက်ထားတဲ့ middle program တွေအတွက်ကတော့ server တွေဆိုတာ runtime မှာ ဖြုတ်/တပ်လို့ရရမယ့် resource တွေထက် မပိုပါဘူး။ ဒါကြောင့် လက်ရှိ API format တွေမှာမရှိသေးတဲ့ LLM specific construct တွေကို လိုအပ်လာပြီး ဒီအတွက် အဖြေက specification အသစ်သွားဖို့ဆိုတာကလွဲပြီး တခြား အဖြေမရှိတော့ပါဘူး။

MCP ကြောင့် VSCode, Claude Code CLI စတဲ့ runtime orchestration platform တွေက niche agent တွေ (ဥပမာ developer တွေကို code ကူရေးပေးနိုင်တဲ့ GitHub Copilot, Claude Code စတဲ့ coding agent တွေ) ကို ကောင်းကောင်းကြီး support ပေးနိုင်တဲ့ middle program တွေဖြစ်လာခဲ့တယ်။ တဖက်မှာလည်း MCP ကြောင့် LLM တွေရဲ့ training time ကန့်သတ်ချက်တွေကို ကျော်ဖြတ်နိုင်ရုံမကပဲ mutating action တွေကိုပါ လုပ်လာနိုင်ခဲ့တယ်။ agent provider တွေအနေနဲ့လည်း သူတို့ရဲ့ harness pipeline ကိုဘယ် server နဲ့မှ tight coupling လုပ်စရာမလိုပဲ တည်ဆောက်လာနိုင်ခဲ့တယ်။

ဒါကတော့ MCP ပဲဖြစ်ပါတယ်။