လေ့ကျင့်ခန်း — Approval၊ Memory နဲ့ Stop Condition

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

ခဏလေး ဒီလိုပဲ စဉ်းစားကြည့်

ပထမ lesson ထက် တစ်ဆင့်တက်ပြီး၊ ဒီမှာတော့ risky action, secret handling, retry loop တွေကို တစ်ပြိုင်နက် ထည့်တွက်ခိုင်းပါမယ်။ Real project တစ်ခုမှာ tool ကို “ခေါ်လို့ရလား” ဆိုတာတင်မဟုတ်ဘဲ “ခေါ်သင့်လား၊ ဘယ်အချိန် လူကို ခေါ်ရမလဲ၊ ရှုံးရင် ဘယ်လောက်ထပ်ကြိုးစားမလဲ” ဆိုတာတွေကို တစ်ချိန်တည်း ဆုံးဖြတ်ရပါတယ်။ Task တစ်ခုချင်းစီက scenario တစ်ခုပေးထားပြီး၊ ကိုယ်တိုင် rule ရေးရမှာပါ — “ဟုတ်တယ်/မဟုတ်ဘူး” ဖြေတာထက် ဘာကြောင့်လို့ဆိုတဲ့ အကြောင်းပြချက်ကို ရေးပါ။ ဒီ round ပြီးရင် build-a-study-helper-agent lesson လို project တွေကို စိတ်ချစွာ ကိုင်တွယ်နိုင်ပါလိမ့်မယ်။

လေ့ကျင့်ခန်းများ

Task 1 (Approval): "Delete old notes" tool ခေါ်ဖို့ Agent က ဆုံးဖြတ်ထားတယ်ဆိုပါစို့ — preview မှာ ဘာအချက်အလက်တွေ ပြရမလဲ (ဖိုင်အရေအတွက်၊ sample list...) စာရင်းရေးပြီး, "Allow all" ခလုတ်ကို ဘာကြောင့် မထည့်သင့်လဲ ရှင်းပါ။ Task 2 (Memory): Study Helper Agent တစ်ခုက student ရဲ့ email address ကို memory ထဲသိမ်းချင်တယ်ဆိုရင် ဘာကို သိမ်းသင့်၊ ဘာကို log မှာ mask လုပ်သင့်ကြောင်း rule သုံးချက် ချမှတ်ပါ။ Task 3 (Plan-then-act + Stop): "Research topic X ကို အင်တာနက်ကနေ ရှာပြီး report ရေးပါ" ဆိုတဲ့ goal အတွက် အဆင့် ၄ ဆင့်ပါတဲ့ plan ကြမ်းရေးပြီး, retry ဘယ်နှစ်ကြိမ်ထိ ပြုလုပ်မလဲ၊ ဘယ် error အမျိုးအစားမှာ ချက်ချင်းရပ်ပြီး လူ့ဆီပို့မလဲ ဆုံးဖြတ်ပါ။ Task 4 (Debug): အောက်က code snippet မှာ retry loop ဟာ error တိုင်းကို အကန့်အသတ်မရှိ ထပ်ကြိုးစားနေတယ် — bug ကိုရှာပြီး fix ရေးပါ။

Risky tool call တိုင်းအတွက် preview + confirm step ကို ရေးဖော်ပြနိုင်ပြီလား
Memory ထဲသိမ်းသင့်တဲ့ data နဲ့ log မှာ mask လုပ်သင့်တဲ့ data ကို ခွဲနိုင်ပြီလား
Retry limit နဲ့ hard-stop condition ကို code ထဲမှာ ပြင်နိုင်ပြီလား

Code နမူနာ

javascript

// Task 4 — ဒီ retry loop ထဲက bug ကို ရှာပြီး ပြင်ပါ
async function callToolWithRetry(toolName, input) {
  while (true) {
    try {
      return await callTool(toolName, input);
    } catch (err) {
      console.log("Tool failed, retrying...", err.message);
      // BUG: retry count မရှိဘူး၊ error type ကိုလည်း မခွဲခြားထားဘူး
      // TODO 1: retry count လျှော့ပြီး ကန့်သတ် (ဥပမာ- max 3 ကြိမ်)
      // TODO 2: auth/permission error ဆို ချက်ချင်းရပ်ပြီး human ဆီ ပို့ပါ
      // TODO 3: retry တစ်ခါချင်းစီကြားမှာ backoff (delay) ထည့်ပါ
    }
  }
}

You should see

Approval preview စာရင်း၊ memory/log split rule၊ 4-step plan + retry/stop rule၊ ပြင်ပြီးသား retry loop code — ငါးမိနစ်အတွင်း draft ရေးထားနိုင်မယ်။

၅ မိနစ် စမ်းကြည့်

Task 3 ကို timer ၅ မိနစ်နဲ့ဖြေပြီး၊ retry limit ဘယ်နှစ်ကြိမ်ထားလဲ ကိုယ့်ကိုယ်ကို "ဘာကြောင့်" လို့ တစ်ခါပြန်မေးကြည့်ပါ — အဖြေက "feel လုပ်လို့" ဆိုရင် ပြန်ဆင်းပြီး cost/time trade-off နဲ့ ပြန်ချိန်ပါ။

သတိလေးတစ်ချက်

Task 4 ရဲ့ retry code ကို production မှာ တကယ်ထည့်မသုံးခင် rate limit နဲ့ cost ကို ထည့်တွက်ပါ — retry များလွန်းရင် API cost တက်တာနဲ့ တခြား service ကို overload ဖြစ်စေနိုင်ပါတယ်။