Local AI Agents နှင့် Tool Calling

နားလည်ထားရမယ့် အချက်

LLM တစ်ခုတည်းက function တစ်ခုပါ — text ဝင်၊ text ထွက်၊ ဒီကြောင့် ကမ္ဘာမှာ ဘာမှ မပြောင်းလဲပါဘူး။ Agent တစ်ခုက LLM တူတူကို ထပ်ဆောင်း piece လေးခုနဲ့ wrap လုပ်ပါတယ်

• Memory — step တွေတစ်လျှောက် ဆောင်ထားတဲ့ state
• Tools — file ဖတ်တာ ဒါမှမဟုတ် API ခေါ်တာလို model က invoke လုပ်နိုင်တဲ့ function
• Planning — goal တစ်ခုကို step တွေအဖြစ် ခွဲတာ
• Execution — ဒီ step တွေကို တကယ် run ပြီး ရလဒ်ကို ပြန်ပို့တာ

LLM ကိုယ်တိုင်ကတော့ မပြောင်းလဲပါဘူး — ပြောင်းလဲသွားတာက ၎င်းရဲ့ text output က real side effect တွေ ဖြစ်စေနိုင်တာပါ။

Model က ၎င်းကိုယ်ပိုင် (တခါတရံ မှားနိုင်၊ တခါတရံ manipulate ခံရနိုင်တဲ့) reasoning ပေါ်မူတည်ပြီး tool ဘယ်ခေါ်မလဲ ဆုံးဖြတ်လို့ safety ဟာ model ရဲ့ judgment ထဲမှာ မဟုတ်ဘဲ ၎င်းပတ်ဝန်းကျင်ရှိ execution layer ထဲမှာ ရှိရမှာပါ။

• Least-privilege access — task တစ်ခုအတွက် လိုအပ်တဲ့ tool တိကျတိကျပဲ ခွင့်ပြု၊ ကျယ်ပြန့်တာ မလုပ်ဘူး
• Sandboxed workspace — agent မထွက်နိုင်တဲ့ directory ဒါမှမဟုတ် container
• Default အနေနဲ့ read-only tool၊ write/delete access ကို opt-in ဖြစ်စေခြင်း
• Open-ended shell အစား ခွင့်ပြုထားတဲ့ tool explicit allowlist
• Execute မလုပ်ခင် tool argument validation
• Call တိုင်းရဲ့ audit logging
• Timeout နှင့် network restriction

File ဒါမှမဟုတ် system access ကန့်သတ်ချက်မရှိတဲ့ agent တစ်ခုဟာ ပိုစွမ်းရည်ရှိတဲ့ assistant တစ်ခု မဟုတ်ပါဘူး — standing risk တစ်ခုပါ။

Agent

LLM တစ်ခုကို memory, tools, planning, execution layer တို့နှင့် ပေါင်းစပ်ထားတာပါ၊ text response တစ်ခုတည်း ထုတ်ပေးရုံမက real side effect ရှိတဲ့ multi-step task တွေကို လုပ်ဆောင်နိုင်ပါတယ်။

Tool Calling

LLM တစ်ခုက function အတိအကျတစ်ခုကို argument အတိအကျတွေနဲ့ run ဖို့ structured request တစ်ခု ထုတ်ပေးတဲ့ mechanism ပါ၊ ပတ်ဝန်းကျင် program က execute လုပ်ပြီး result ကို conversation ထဲ ပြန်ထည့်ပေးပါတယ်။

THE TOOL-CALLING LOOP
---------------------
THE TOOL-CALLING LOOP
------------------------

  user request
       |
       v
     LLM  -----------------------------+
       |  decides a tool is needed     |
       v                               |
  tool call (name + arguments)         |
       |                               |
       v                               |
  [ CONFIRMATION GATE ]  <-- required for destructive tools
       |  (blocked until user confirms)
       v
  tool executes (outside the model)
       |
       v
  result returned to LLM  -------------+
       |
       v
  LLM responds to user (or calls another tool)

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

အောက်က code ဥပမာက real agent framework တိုင်းက တစ်နည်းနည်းနဲ့ implement လုပ်ထားတဲ့ pattern ရဲ့ minimal version တစ်ခုပါ — execute မလုပ်ခင်၊ execute လုပ်ပြီးမှ မဟုတ်ဘဲ request လုပ်ထားတဲ့ tool call ကို run ခွင့်ပြုမလား ဆုံးဖြတ်ပေးတဲ့ lookup table တစ်ခုပါ။

ပထမ၊ default-deny — allowlist ထဲ လုံးဝမပါတဲ့ tool name တစ်ခုက safe ဖြစ်မဖြစ် system က မှန်းဆကြည့်မယ့်အစား တိုက်ရိုက် reject ခံရပါတယ် — ဥပမာထဲက `send_email` က ဘယ်လို argument ပါလာပါစေ grant ခံရဖူးခြင်း မရှိလို့ fail ဖြစ်ပါတယ်။

ဒုတိယ၊ သီးခြား destructive flag တစ်ခု — state ကို ပြောင်း/ဖျက်တဲ့ tool တွေ (ဒီမှာ `delete_file` နဲ့ `run_shell_command`) က allowlist ထဲပါတာအပြင် explicit `confirmed=True` ထပ်လိုအပ်ပါတယ်၊ read access နဲ့ write/delete access ကို bar တစ်ခုတည်း ဘယ်တော့မှ မမျှဝေသင့်ဘူးဆိုတဲ့ idea ကို model လုပ်ပြထားတာပါ။

Real implementation တစ်ခုက agent လုပ်တဲ့ tool call တိုင်းမလုပ်ခင် ဒါကို check ရမှာပါ၊ ဆုံးဖြတ်ချက်ကို ဘယ်လိုပဲဖြစ်ဖြစ် log ချရမှာပါ၊ `confirmed=True` ကို human (ဒါမှမဟုတ် human ကိုယ်တိုင် explicit သတ်မှတ်ထားတဲ့ policy) ပဲ ပေးနိုင်တာလို့ သဘောထားရမှာပါ။

• Agent တစ်ခုဆိုတာ LLM plus memory, tools, planning, execution ပါ — model ကတော့ text ကိုပဲ ထုတ်ပေးဆဲပါ၊ ကမ္ဘာပေါ်တကယ် လုပ်ဆောင်ပေးတာက ပတ်ဝန်းကျင် program ပါ။
• Tool-calling loop က model ပြင်ပ code ကို အမြဲ ဖြတ်ကျော်သွားပါတယ် — LLM က call တစ်ခု ပြင်ဆင်တင်ပြ၊ program က execute လုပ်၊ result ကို ပြန်ပို့ပေး — model က filesystem ဒါမှမဟုတ် network ကို တိုက်ရိုက် ဘယ်တော့မှ မထိပါဘူး။
• Safety ဟာ execution layer (allowlist, least privilege, confirmation gate, sandboxing, audit log) ထဲမှာ ရှိရမှာပါ၊ model ကိုယ်တိုင်ရဲ့ safe/unsafe reasoning က မှားနိုင်ဒါမှမဟုတ် manipulate ခံနိုင်လို့ပါ။

အတူတူ စမ်းရေးကြည့်မယ်

ALLOWED_TOOLS = {
    "read_file": {"destructive": False},
    "list_directory": {"destructive": False},
    "web_search": {"destructive": False},
    "delete_file": {"destructive": True},
    "run_shell_command": {"destructive": True},
}


def check_permission(tool_name, allowed_tools, confirmed=False):
    if tool_name not in allowed_tools:
        return False, "not in allowlist"
    if allowed_tools[tool_name]["destructive"] and not confirmed:
        return False, "destructive tool requires confirmed=True"
    return True, "permitted"


calls = [
    ("read_file", False),
    ("send_email", False),       # not in allowlist at all
    ("delete_file", False),      # destructive, no confirmation
    ("delete_file", True),       # destructive, confirmed
]

for tool_name, confirmed in calls:
    ok, reason = check_permission(tool_name, ALLOWED_TOOLS, confirmed=confirmed)
    print(f"tool={tool_name!r} confirmed={confirmed} -> allowed={ok} ({reason})")

Example call လေးခုကို check_permission ထဲ run လိုက်ရာ -

tool='read_file' confirmed=False -> allowed=True (permitted)
tool='send_email' confirmed=False -> allowed=False (not in allowlist)
tool='delete_file' confirmed=False -> allowed=False (destructive tool requires confirmed=True)
tool='delete_file' confirmed=True -> allowed=True (permitted)

read_file က allowlist ထဲပါပြီး destructive မဟုတ်လို့ ချက်ချင်း allow ခံရပါတယ်။ send_email က allowlist ထဲ လုံးဝမပါလို့ deny ခံရတာပါ — ၎င်းရဲ့ destructive flag ကို check တောင် မလုပ်ပါဘူး။ delete_file က confirmation မပါဘဲ deny ခံရပြီး confirmation ပါလာရင် allow ခံရပါတယ်၊ layer နှစ်ခု check (allowlist membership, ပြီးရင် destructive tool အတွက် သီးခြား confirmation requirement) design အတိုင်း အလုပ်လုပ်နေတာကို ပြသပါတယ်။

Anthropic — Tool Use Overview — Local AI / Local LLM