ကိုယ်ပိုင် AI Agent တစ်ခု ကိုယ်တိုင်ဖန်တီးချင်ပါသလား၊ ဘယ်လိုကိရိယာတွေ ပြင်ဆင်သင့်လဲ။ Developer ကိရိယာလမ်းကြောင်း အပြည့်အစုံ

သောကြာနေ့ မွန်းလွဲပိုင်းတွင် သူငယ်ချင်းတစ်ဦးက သူ၏ Agent demo ဗီဒီယိုကို ပေးပို့လာသည်- အသုံးပြုသူက စာတစ်ကြောင်းရိုက်ထည့်လိုက်ရုံဖြင့် Agent ကိုယ်တိုင် အချက်အလက်ရှာဖွေပေးခြင်း၊ API သုံးခုကို ခေါ်ယူခြင်းနှင့် ရှင်းလင်းပြတ်သားသော အနှစ်ချုပ်တစ်ခုကို ပြန်လည်ဖြေကြားပေးခြင်းတို့ ဖြစ်သည်။ အလွန်ကောင်းမွန်သည်။ ကျွန်တော်က သူ့ကို "Production တင်ပြီးပြီလား" ဟု မေးလိုက်သည်။ သူက နှစ်စက္ကန့်တိတိ တိတ်ဆိတ်သွားပြီး "Production တင်ထားတဲ့ ဗားရှင်းက မနေ့က ဝယ်သူရဲ့ အော်ဒါနံပါတ်ကို ငွေပြန်အမ်းတဲ့ ပရိုဆက်ဆီထဲ အမှားအယွင်းနဲ့ ထည့်လိုက်မိတယ်။ ဘယ်အဆင့်မှာ မှားသွားမှန်း ကျွန်တော်တို့ မသိတော့ဘူး" ဟု ပြန်ပြောပြသည်။

၎င်းသည် ကိုယ်တိုင်တည်ဆောက်ထားသော Agent အဖွဲ့တိုင်း ကြုံတွေ့ရလေ့ရှိသည့် ပြဿနာပင်ဖြစ်သည်။ Demo ပြသခြင်းသည် လေဆန်ခရီးစဉ်တစ်ခုဖြစ်ပြီး Production ပတ်ဝန်းကျင်သည် ပင့်ကူအိမ်ကဲ့သို့ ရှုပ်ထွေးလှပေသည် - မည်သည့်ဆုံမှတ် (Node) တွင်မဆို အမှားအယွင်းရှိပါက တစ်ခုလုံးပြတ်တောက်သွားမည်ဖြစ်ပြီး၊ မည်သည့်နေရာတွင် ပြတ်တောက်သွားသည်ကို သင် မကြာခဏဆိုသလို သိရှိနိုင်မည် မဟုတ်ပေ။ ခြားနားချက်မှာ မော်ဒယ်က မည်မျှထက်မြက်သည်တွင် မဟုတ်ဘဲ သင့်နောက်ကွယ်ရှိ 工具鏈 (Toolchain) က လုံလောက်စွာ ပြည့်စုံမှုရှိမရှိပေါ်တွင် မူတည်နေသည်။

၂၀၂۶ ခုနှစ်သည် "ဖရိန်ဝิร์က တစ်ခု" မဟုတ်ဘဲ "တူးလ်ချိန်း (Toolchain)" ဖြစ်လာရသည့် အကြောင်းရင်း

၂၀၂၃ နှင့် ၂၀၂၄ ခုနှစ်များတွင် လူတိုင်းမေးမြန်းခဲ့ကြသည်မှာ "Agent ဖန်တီးရာတွင် မည်သည့် ဖရိန်ဝิร์က (Framework) ကို အသုံးပြုသင့်သနည်း" ဟူ၍ ဖြစ်သည်။ ၂၀၂۶ ခုနှစ်သို့ ရောက်ရှိလာသောအခါ ဤမေးခွန်းသည် မှားယွင်းနေပြီဖြစ်သည်။ ဖရိန်ဝิร์က ဆိုသည်မှာ အပေါ်ယံ အလွှာမျှသာ ဖြစ်သည်။ တကယ်တမ်း Production တင်နိုင်သော၊ 維運 (Maintenance) လုပ်နိုင်သော၊ ပြဿနာတက်က ခြေရာခံစစ်ဆေးနိုင်သော Agent တစ်ခု၏ နောက်ကွယ်တွင် တာဝန်ခွဲဝေမှု ရှင်းလင်းသော အလွှာများ (Stack) စုစည်းမှု ရှိနေရပါမည် - ၎င်းသည် Backend အင်ဂျင်နီယာတစ်ဦးတွင် Web framework တစ်ခုတည်းသာ မရှိဘဲ Database၊ Cache၊ Logging၊ Monitoring နှင့် CI/CD စသည်တို့ပါ ရှိနေရခြင်းနှင့် တူညီပေသည်။

Agent ၏ ထူးခြားချက်မှာ ၎င်းတွင် "မသေချာမရေရာမှု" ရှိနေခြင်းပင် ဖြစ်သည်။ တူညီသော Input ကို ပေးလျှင်ပင် မော်ဒယ်သည် မတူညီသော အဆင့်များကို ထုတ်ပေးနိုင်သည် - ကိရိယာ (Tool) များကို သုံးမည်လား၊ မည်သည့်ကိရိယာကို သုံးမည်လားဆိုသည်ကို ၎င်းဘာသာ ဆုံးဖြတ်မည် ဖြစ်သည်။ ဤမသေချာမရေရာမှုကြောင့် "ရေးပြီးရင် Run မယ်၊ ချို့ယွင်းရင် Stack trace ကြည့်မယ်" ဟူသော ရိုးရာ ဖွံ့ဖြိုးတိုးတက်မှု အလေ့အထမှာ လုံးဝ အလုပ်မဖြစ်တော့ပေ။ ထို့ကြောင့် "အဘယ်ကြောင့် ဤကဲ့သို့ လုပ်ဆောင်ရသနည်း"၊ "မှန်ကန်စွာ လုပ်ဆောင်ခဲ့ပါသလား"၊ "Production မှာ ဘာပြဿနာတွေ ထပ်တက်နေသနည်း" ဟူသော မေးခွန်းများကို ဖြေရှင်းရန် သီးသန့်ထုတ်လုပ်ထားသော တူးလ်အလွှာအသစ်များကို သင် လိုအပ်လာမည်ဖြစ်သည်။

အဓိကအချက်- တူးလ်ချိန်း (Toolchain) ကို အလွှာ ခြောက်လွှာအဖြစ် ခွဲခြမ်းခြင်း

ကျွန်တော်သည် ကိုယ်တိုင်တည်ဆောက်ထားသော Agent ၏ တူးလ်ချိန်းကို အထက်မှအောက်သို့ အလွှာ ခြောက်လွှာအဖြစ် ခွဲခြမ်းလေ့ရှိသည်-

• ဖရိန်ဝิร์က အလွှာ (Framework Layer): Agent ကို မည်သို့ သတ်မှတ်မည်၊ ကိရိယာများကို မည်သို့ ခေါ်ယူမည်၊ အဆင့်ပေါင်းများစွာ လုပ်ဆောင်သည့် လုပ်ငန်းစဉ်များကို မည်သို့ စီမံခန့်ခွဲမည်ကို ဆုံးဖြတ်ပေးသည်။
• ရှာဖွေရေး အလွှာ (Retrieval Layer / RAG): မော်ဒယ်၏ အတွင်းပိုင်း ဗဟုသုတများကို ကျက်မှတ်ထားရုံသာမကဘဲ သင်၏ သီးသန့် အချက်အလက်များကိုပါ Agent ဖတ်ရှုနိုင်စေရန် လုပ်ဆောင်ပေးသည်။
• လုပ်ဆောင်ရေး ဆန်းဘောက်စ် အလွှာ (Execution Sandbox Layer): Agent က ကုဒ်ရေးရန်နှင့် အမိန့်ပေးချက်များ လုပ်ဆောင်ရန် လိုအပ်သည့်အခါ ထိန်းချုပ်ကန့်သတ်ထားသော နေရာတစ်ခုကို ပေးအပ်သည်။
• စောင့်ကြည့်လေ့လာနိုင်မှု အလွှာ (Observability Layer): 推理 (Reasoning) အဆင့်တိုင်းနှင့် ကိရိယာခေါ်ယူမှုတိုင်းကို မှတ်တမ်းတင်ထားရှိပြီး ၎င်း၏ စဉ်းစားပုံစဉ်းစားနည်းများကို မြင်တွေ့နိုင်စေရန် လုပ်ဆောင်ပေးသည်။
• အကဲဖြတ်မှုနှင့် လုံခြုံရေး အလွှာ (Evaluation & Security Layer): Production မတင်မီ ပုံသေ စာမေးပွဲမေးခွန်းအစုံဖြင့် ၎င်း၏ စွမ်းဆောင်ရည်ကို တိုင်းတာပြီး Red-teaming ကိုပါ တစ်ပါတည်း လုပ်ဆောင်သည်။
• ဖြန့်ဝေရေး အလွှာ (Deployment Layer): ဤစနစ်စုစုပေါင်းကို တည်ငြိမ်စွာနှင့် ချဲ့ထွင်နိုင်စွမ်းရှိရှိဖြင့် Production သို့ တင်ပေးသည်။

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

တစ်လွှာချင်းစီ ခွဲခြမ်းစိတ်ဖြာခြင်း - အလွှာတစ်ခုချင်းစီက ဘာကို ဖြေရှင်းပေးသနည်း၊ မည်သည့်အခါမှ လိုအပ်သနည်း

ဖရိန်ဝิร์က အလွှာ: Pydantic AI နှင့် LangChain

ဖရိန်ဝิร์ကများသည် မော်ဒယ်၊ ကိရိယာများနှင့် လုပ်ငန်းစဉ်များကို မည်သို့ ချိတ်ဆက်ရမည်ဆိုသည်ကို ကူညီဆောင်ရွက်ပေးသည်။ Pydantic AI သည် လွန်ခဲ့သော နှစ်နှစ်အတွင်း Python အင်ဂျင်နီယာ အများအပြား ပြောင်းလဲအသုံးပြုလာကြသည့် ရွေးချယ်မှုတစ်ခု ဖြစ်သည်။ အဘယ်ကြောင့်ဆိုသော် ၎င်းသည် Output များကို Type schema ဖြင့် တင်းတင်းကျပ်ကျပ် ချိတ်ဆက်ပေးထားသောကြောင့် ဖြစ်သည် - Agent က မည်သည့်အရာကို ပြန်ပေးသည်ဖြစ်စေ သင်ရရှိသည်မှာ ကိုယ်တိုင် Parse လုပ်ရန် မလိုသော ဖွဲ့စည်းပုံပါရှိပြီး အတည်ပြုပြီးသား အရာဝတ္ထု (Object) တစ်ခု ဖြစ်သည်။ Backend பின்னခံရှိပြီး Type များကို ရေးသားရသည်ကို ကျွမ်းကျင်သူများအတွက် အသုံးပြုရ အလွန်အမင်း ချောမွေ့စေသည်။

LangChain ကမူ အခြားသော အစွန်းတစ်ဖက်တွင် ရှိနေသည် - ဂေဟစနစ် အကြီးမားဆုံးဖြစ်ပြီး ပေါင်းစပ်မှု အများဆုံးပါရှိကာ လိုအပ်သည့် မည်သည့်အရာကိုမဆို အသင့်သုံးနိုင်သည်ကို တွေ့ရမည်ဖြစ်သည်။ ပေးဆေရမည့် တန်ဖိုးမှာ Abstraction အလွှာ ထူထဲခြင်း၊ ဗားရှင်းအပြောင်းအလဲ မြန်ဆန်ခြင်းတို့ ဖြစ်ပြီး ပရောဂျက်ငယ်များတွင် အသုံးပြုပါက ငှက်သတ်ရန် သေနတ်ကြီးဖြင့် ပစ်သကဲ့သို့ ဖြစ်နေတတ်သည်။ ကျွန်ဟော့်၏ အကြံပြုချက်မှာ - လုပ်ငန်းစဉ် ရိုးရှင်းပြီး Output ကို ဖွဲ့စည်းပုံချရန် လိုအပ်ပါက Pydantic AI ကို အရင်စမ်းပါ; အသင့်သုံး ပေါင်းစပ်မှုများကို အများအပြား ချိတ်ဆက်ရန် လိုအပ်ပြီး အဖွဲ့သားများက LangChain ကို ကျွမ်းကျင်ပြီးသားဖြစ်မှသာ အသုံးပြုပါ။ "လူတိုင်း သုံးနေကြလို့" ဆိုသည့် အကြောင်းပြချက်ဖြင့် စဉ်းစားဆင်ခြင်စရာမလိုဘဲ မရွေးချယ်ပါနှင့်။

ရှာဖွေရေး အလွှာ: RAGFlow

Agent တွင် RAG ကို မချိတ်ဆက်ထားပါက မော်ဒယ်ကို လေ့ကျင့်ပေးစဉ်က မှတ်မိထားသည့် အရာများဖြင့်သာ ဖြေကြားနိုင်မည်ဖြစ်ပြီး၊ သင့်ကုမ္ပဏီ၏ အတွင်းပိုင်း စာရွက်စာတမ်းများနှင့် နောက်ဆုံးပေါ် ထצרကုန် သတ်မှတ်ချက်များနှင့် တွေ့ကြုံရသည့်အခါ လေလွင့်ကာ မှားယွင်းစွာ ဖြေကြားလာပါလိမ့်မည်။ RAGFlow ကမူ ဤချိန်းဆက်မှုထဲတွင် အထናဆုံး တန်ဖိုးဖြတ်ခံထားရသော အစိတ်အပိုင်းကို ဖြေရှင်းပေးသည် - ၎င်းမှာ စာရွက်စာတမ်း အပိုင်းပိုင်းခွဲခြင်း (Chunking)၊ ခွဲခြမ်းစိတ်ဖြာခြင်း၊ Vectorize လုပ်ခြင်းနှင့် ရှာဖွေခြင်းတို့ ဖြစ်သည်။ ၎င်းသည် PDF၊ ဇယားများနှင့် အပြင်အဆင် ရှုပ်ထွေးသော စာရွက်စာတမ်းများကို သာမန် RAG တူးလ်များထက် ပိုမိုနက်ရှိုင်းစွာ ကိုင်တွယ်ဖြေရှင်းပေးနိုင်ပြီး၊ ဤအချက်သည် စာချုပ် PDF များနှင့် သတ်မှတ်ချက်စာအုပ်များ ပုံစံအမျိုးမျိုးဖြင့် ပြည့်နှက်နေသော လုပ်ငန်းခွင်များတွင် အလွန်ပင် သိသာထင်ရှားလှပေသည်။ မည်သည့်အခါတွင် လိုအပ်သနည်း။ သင့် Agent က "ကုမ္ပဏီတွင်းမှသာ သိရှိနိုင်သော အရာများ" ကို ဖြေကြားရန် လိုအပ်သည့်အခါတိုင်း လိုအပ်ပါသည်။

လုပ်ဆောင်ရေး ဆန်းဘောက်စ် အလွှာ: Blaxel

သင့် Agent က "ကုဒ်ကိုယ်တိုင်ရေးပြီး Run" ဖို့ စတင်လာသည့်အခါ အန္တရာယ်က စတင်လာပါပြီ။ ၎င်းသည် အဆုံးမရှိသော Loop ထဲ ရောက်သွားနိုင်သည်၊ မဝင်သင့်သည့် ဖိုင်များကို ဝင်ဖတ်မိနိုင်သည်၊ သို့မဟုတ် ပြင်ပ အင်တာနက်ကို မတော်တဆ ခေါ်ယူမိနိုင်ပေသည်။ Blaxel ကဲ့သို့သော လုပ်ဆောင်ရေး ဆန်းဘောက်စ် (Sandbox) များသည် ဤကဲ့သို့ ထိန်းချုပ်မရသော လုပ်ဆောင်ချက်များကို Run ရန်အတွက် Agent အား သီးသန့်ခွဲထုတ်ထားသော ပတ်ဝန်းကျင်တစ်ခုကို ပေးစွမ်းပြီး ပြဿနာတက်လာပါကလည်း သင့်၏ ပင်မဆာဗာကို ထိခိုက်ပျက်စီးစေမည် မဟုတ်ပေ။ သင့် Agent သည် အချက်အလက်ရှာဖွေခြင်းနှင့် ပုံသေ API များကိုသာ ခေါ်ယူခြင်းဖြစ်ပါက ယာယီ မလိုအပ်သေးပါ။ သို့သော် ၎င်းက ကုဒ်များကို Dynamic ဖြင့် လုပ်ဆောင်ရန် လိုအပ်လာသည်နှင့်တပြိုင်နက် ဆန်းဘောက်စ်သည် ရွေးချယ်စရာမဟုတ်တော့ဘဲ မဖြစ်မနေ လိုအပ်လာပါပြီ။

စောင့်ကြည့်လေ့လာနိုင်မှု အလွှာ: AgentOps နှင့် Langfuse

ဤအရာသည် အစတွင် ဖော်ပြခဲ့သော ကျွန်ဟော့်၏ သူငယ်ချင်းတွင် အလိုအပ်ဆုံး ဖြစ်နေသည့် အလွှာပင် ဖြစ်သည်။ Agent က အဆင့်ပေါင်းများစွာ လုပ်ဆောင်ပြီးသွားသည့်အခါ အလယ်တွင် ဘာတွေခေါ်ယူခဲ့သလဲ၊ အဆင့်တစ်ခုချင်းစီအတွက် Token ဘယ်လောက်ကုန်ကျသလဲ၊ ဘယ်အဆင့်ကစပြီး လမ်းမှားသွားသလဲ စသည်တို့ကို မှတ်တမ်းတင်ပေးမည့် တူးလ်မရှိပါက သင် လုံးဝ မြင်တွေ့နိုင်မည် မဟုတ်ပါ။ AgentOps သည် Agent ၏ လုပ်ဆောင်မှု လမ်းကြောင်း (Execution trace) အပေါ် အဓိက အာရုံစိုက်သည် - အဆင့်တိုင်းနှင့် Tool call တတိုင်းကို ပြန်လည်ကြည့်ရှုနိုင်သော အချိန်မျဉ်း (Timeline) တစ်ခုအဖြစ် ချိတ်ဆက်ပေးပြီး အဆင့်ပေါင်းများစွာ လုပ်ငန်းစဉ်များကို Debug လုပ်သည့်အခါ အသက်ကယ်တင်ပေးနိုင်ပါသည်။ Langfuse ကမူ Production ပတ်ဝန်းကျင်ရှိ စကားပြောဆိုမှုတိုင်းနှင့် ကုန်ကျစရိတ်တိုင်းကို ရေရှည်မှတ်တမ်းတင်ကာ ခြေရာခံစစ်ဆေးရန်အတွက် ပိုမိုသင့်လျော်သည်။ ဤတူးလ် နှစ်ခု၏ တည်နေရာမှာ အနည်းငယ် ထပ်နေသော်လည်း အဓိကထားသည့် ပစ်မှတ်ချင်း မတူကြပေ။ ၎င်းတို့ကို မည်သို့ တွဲဖက်အသုံးပြုရမည်ကို အကဲဖြတ်မှုနှင့် လုံခြုံရေးဆိုင်ရာ အခြားဆောင်းပါးတစ်ပုဒ်တွင် အသေးစိတ် ဆွေးနွေးတင်ပြပေးပါမည်။

အကဲဖြတ်မှုနှင့် လုံခြုံရေး အလွှာ: Promptfoo

Agent တွင် အကြောက်ရဆုံးမှာ စနစ်ရပ်တန့်သွားခြင်း မဟုတ်ဘဲ "တိတ်တဆိတ် မှားယွင်းနေခြင်း" ပင် ဖြစ်သည် - ၎င်းက ကျိုးကြောင်းဆီလျော်ဟန်ရှိသော်လည်း အမှန်တကယ်တွင် မှားယွင်းနေသော အဖြေတစ်ခုကို ပြန်လည်ပေးလိုက်ခြင်းဖြစ်ပြီး မည်သူမျှ သတိမထားမိကြပေ။ Promptfoo သည် စမ်းသပ်မှု ဖြစ်ရပ်မှန်အစုံ (Test cases) ကို ပုံသေ သတ်မှတ်ထားနိုင်စေရန် လုပ်ဆောင်ပေးပြီး Prompt ကို ပြောင်းလဲလိုက်တိုင်း သို့မဟုတ် မော်ဒယ်ကို လဲလှယ်လိုက်တိုင်း ၎င်းကို Run ကြည့်ကာ အဖြေ၏ အရည်အသွေး ကျဆင်းသွားခြင်း ရှိမရှိကို ကိန်းဂဏန်းဖြင့် တိုင်းတာပေးနိုင်ပြီး၊ လမ်းကြောင်းလွှဲခံရနိုင်သည့် အားနည်းချက်များကို ရှာဖွေဖော်ထုတ်ရန် Red-teaming ကိုပါ တစ်ပါတည်း လုပ်ဆောင်ပေးသည်။ ဤအလွှာ၏ စိတ်ဓာတ်မှာ "ကောင်းလာပြီလို့ ထင်တယ်" ဆိုသည်ကို "နံပါတ်တွေက ပိုကောင်းလာပြီလို့ ပြောနေတယ်" ဆိုသည့် အနေအထားသို့ ပြောင်းလဲပေးခြင်းပင် ဖြစ်သည်။ ပြီးပြည့်စုံသော လုပ်ဆောင်ပုံကို ဆက်လက်ဖတ်ရှုလိုပါက 〈AI Agent အပေါ်သို့ မတင်မီ သင် မဖြစ်မနေ လုပ်ဆောင်ရမည့် အကဲဖြတ်မှုနှင့် လုံခြုံရေး စစ်ဆေးချက်များ〉 ကို ကြည့်ရှုနိုင်ပါသည်။

ဖြန့်ဝေရေး အလွှာ: Northflank

နောက်ဆုံးအဆင့်မှာ စနစ်စုစုပေါင်းကို Production သို့ တင်ခြင်းပင် ဖြစ်သည်။ Agent များကို ဖြန့်ဝေခြင်းသည် သာမန် Web service တစ်ခုထက် ပိုမိုရှုပ်ထွေးသည် - ၎င်းသည် အချိန်ကြာမြင့်စွာ လုပ်ဆောင်ရမည်၊ နောက်ခံ လုပ်ငန်းစဉ်များ (Background tasks) ကို Run ရမည်ဖြစ်ပြီး တစ်ခါတစ်ရံ ဆန်းဘောက်စ် ကွန်တိန်နာများကိုပါ စီမံခန့်ခွဲရပေမည်။ Northflank ကဲ့သို့သော ပလပ်ဖောင်းများသည် ကွန်တိန်နာပြုလုပ်ခြင်း (Containerization)၊ ချဲ့ထွင်ခြင်း (Scaling) နှင့် CI/CD တို့ကို ကူညီဆောင်ရွက်ပေးသဖြင့် Kubernetes ကို ကိုယ်တိုင် အစကနေ စတင်တည်ဆောက်ရန် မလိုအပ်တော့ပေ။ အဖွဲ့ငယ်များအတွက် ဤကဲ့သို့သော ပလပ်ဖောင်းများကို အသုံးပြုခြင်းဖြင့် DevOps ဝန်ထမ်းတစ်ဦး၏ လုပ်အားကို သက်သာစေနိုင်ပါသည်။

အဖွဲ့အမျိုးအစား သုံးမျိုး၊ လုပ်ဆောင်ပုံ အလွှာသုံးမျိုး

မြန်မာနိုင်ငံမှ တစ်ဦးချင်း Developer များ: အလွှာ ခြောက်လွှာစလုံးကို တစ်ပြိုင်နက်တည်း အပြည့်အစုံ ရရှိရန် မတွေးပါနှင့်။ ပထမဦးစွာ Pydantic AI ကို အသုံးပြု၍ မူလလုပ်ငန်းစဉ်ကို ဖန်တီးပါ, Promptfoo ကို ချိတ်ဆက်ကာ ပြင်ဆင်လေလေ ပိုဆိုးလာလေ မဖြစ်စေရန် အာမခံချက် ပေးထားပါ၊ ကျန်ရှိသော အလွှာများကိုမူ အမှန်တကယ် အခက်အခဲကြုံတွေ့လာမှသာ ဖြည့်စွက်ပါ။ တစ်ဦးတည်း ထိန်းသိမ်းနိုင်သော တူးလ်အရေအတွက်မှာ ကန့်သတ်ချက်ရှိသဖြင့် ထိန်းထိန်းသိမ်းသိမ်း လုပ်ဆောင်ပါ။

စတားတပ် (Startup) အဖွဲ့များ: စောင့်ကြည့်လေ့လာနိုင်မှုကို စောစီးစွာ စတင်လုပ်ဆောင်သင့်သည်။ AgentOps နှင့် Langfuse တို့ကို "နောက်မှ လုပ်တော့မယ်" ဟု ဆိုင်းငံ့ထားကြသော အဖွဲ့များစွာကို ကျွန်တော် တွေ့ဖူးပါသည် - ရလဒ်အနေဖြင့် ပြဿနာတက်လာသည့်အခါ တစ်ဖွဲ့လုံး Log ပင်လယ်ကြီးထဲတွင် သုံးရက်တိုင်တိုင် ရှာဖွေနေကြရသည်။ စောစီးစွာ ချိတ်ဆက်ခြင်းသည် အာမခံကြေး ပေးဆောင်ထားခြင်းနှင့် အတူတူပင် ဖြစ်သည်။ ဖြန့်ဝေရေး အလွှာအတွက် Northflank ကဲ့သို့သော Hosted