> For the complete documentation index, see [llms.txt](https://channyeintun.gitbook.io/blogs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://channyeintun.gitbook.io/blogs/ai/the-anatomy-of-an-agent-harness.md).

# The Anatomy of an Agent Harness

Stateless LLM မှသည် စွမ်းဆောင်ရည်မြင့် Agent တစ်ခုဆီသို့ ပြောင်းလဲတည်ဆောက်ခြင်း

သင်ဟာ Chatbot တစ်ခု တည်ဆောက်ပြီး ReAct loop လေးနဲ့ Tool တချို့ ချိတ်ဆက်ဖူးပါလိမ့်မယ်။ Demo ပြတဲ့အချိန်မှာတော့ အဆင်ပြေနေပေမဲ့ Production-grade တစ်ခုကို တကယ်တမ်း တည်ဆောက်လိုက်တဲ့အခါ "ဘီးပြုတ်" ထွက်သွားတတ်ပါတယ် - Model က လွန်ခဲ့တဲ့ သုံးဆင့်လောက်က အလုပ်ကို မေ့သွားတာ၊ Tool call တွေက ဘာသံမှမထွက်ဘဲ Error တက်နေတာနဲ့ Context window က အသုံးမကျတဲ့ အချက်အလက်တွေနဲ့ ပြည့်သွားတာမျိုးတွေ ကြုံရပါလိမ့်မယ်။

ပြဿနာက Model ကြောင့် မဟုတ်ပါဘူး။ Model ကို ဝန်းရံထားတဲ့ Infrastructure (အခြေခံအဆောက်အအုံ) ကြောင့်ပါ။ LangChain ဟာ သူတို့ LLM ရဲ့ Infrastructure (တူညီတဲ့ Model၊ တူညီတဲ့ Weights) ကိုပဲ ပြောင်းလဲလိုက်တာနဲ့ TerminalBench 2.0 မှာ အဆင့် ၃၀ ပြင်ပကနေ အဆင့် ၅ ထိ ခုန်တက်သွားပါတယ်။ အဲ့ဒီ Infrastructure ကို အခုအခါမှာ "Agent Harness" လို့ အမည်တပ်ခေါ်ဆိုလာကြပါတယ်။

၁။ Agent Harness ဆိုတာ ဘာလဲ?

၂၀၂၆ ခုနှစ် အစောပိုင်းမှာ ဒီစကားလုံးဟာ တရားဝင် Formalized ဖြစ်လာပါတယ်။ Harness ဆိုတာ LLM တစ်ခုကို အသုံးဝင်အောင် ဝန်းရံပေးထားတဲ့ Software Infrastructure တစ်ခုလုံး (Orchestration loop, Tools, Memory, Context management, State persistence, Error handling နဲ့ Guardrails) ကို ဆိုလိုတာပါ။

LangChain က Vivek Trivedy ရဲ့ Canonical Formula တစ်ခုရှိပါတယ် - "If you're not the model, you're the harness" (သင်ဟာ Model မဟုတ်ဘူးဆိုရင်၊ သင်ဟာ Harness ပဲ)။

Beren Millidge ရဲ့ ၂၀၂၃ ခုနှစ် essay ဖြစ်တဲ့ "Scaffolded LLMs as Natural Language Computers" မှာ ဒီလို နှိုင်းယှဉ်ပြထားပါတယ်။ Raw LLM တစ်ခုဟာ RAM မရှိ၊ Disk မရှိ၊ I/O မရှိတဲ့ CPU တစ်လုံးနဲ့ တူပါတယ်။ Context window က RAM (မြန်ပေမဲ့ ကန့်သတ်ချက်ရှိ) ဖြစ်ပြီး၊ External databases တွေက Disk (ကြီးမားပေမဲ့ နှေးကွေး) ဖြစ်ပါတယ်။ Tool integrations တွေကတော့ Device drivers တွေပေါ့။ ဒါဆိုရင် Harness ဆိုတာ အဲ့ဒီ အစိတ်အပိုင်းအားလုံးကို မောင်းနှင်ပေးတဲ့ Operating System (OS) ပါပဲ။

၂။ Engineering အဆင့် ၃ ဆင့်

Model တစ်ခုကို ဝန်းရံထားတဲ့ Engineering အလွှာ ၃ ခု ရှိပါတယ် -

1. Prompt Engineering: Model ဆီကို ပေးပို့မယ့် Instructions (ညွှန်ကြားချက်) တွေကို စနစ်တကျ ဖန်တီးတာ။
2. Context Engineering: Model က ဘာတွေကို မြင်ရမလဲ၊ ဘယ်အချိန်မှာ မြင်ရမလဲဆိုတာကို စီမံတာ။
3. Harness Engineering: အပေါ်က နှစ်ခုလုံးအပြင် Tool orchestration, State persistence, Error recovery, Verification loops, Safety enforcement နဲ့ Lifecycle management စတဲ့ System တစ်ခုလုံးကို တည်ဆောက်တာ။

<br>

၃။ Production Harness တစ်ခုရဲ့ အစိတ်အပိုင်း ၁၂ ခု

၁။ The Orchestration Loop (နှလုံးခုန်သံ): ဒါဟာ Thought-Action-Observation (TAO) cycle ကို မောင်းနှင်ပေးတဲ့ စက်ဝန်းပါ။ အလုပ်တစ်ခုကို အဆုံးမသတ်မချင်း Prompt ကို စုစည်းမယ်၊ LLM ကို ခေါ်မယ်၊ Output ကို Parse လုပ်မယ်၊ Tool call တွေရှိရင် Run မယ်၊ ရလဒ်ကို ပြန်ကျွေးမယ်။

၂။ Tools (လက်များ): ဒါဟာ Agent ရဲ့ လက်တွေပါ။ File operations, Search, Web access စတဲ့ capability တွေကို Schema အနေနဲ့ Model ဆီ ပို့ပေးပြီး Harness က အဲ့ဒီ Tool တွေကို လက်တွေ့ Execute လုပ်ပေးရပါတယ်။

၃။ Memory (မှတ်ဉာဏ်): Tier ၃ ဆင့်နဲ့ သွားလေ့ရှိပါတယ်။ Lightweight index (\~150 characters အမြဲ loaded ဖြစ်နေတာ)၊ Detailed topic files (လိုမှ ဆွဲထုတ်တာ) နဲ့ Raw transcripts (Search လုပ်မှသာ ကြည့်တာ) ဆိုပြီး စီမံကြပါတယ်။

၄။ Context Management (အချက်အလက် စီမံမှု): ဒါက Agent တွေ ကျရှုံးတတ်တဲ့ နေရာပါ။ "Lost in the Middle" ပြဿနာကို ဖြေရှင်းဖို့ Harness က အချက်အလက်တွေကို ချုံ့တာ (Compaction)၊ မလိုအပ်တဲ့ Observation တွေကို ဖုံးကွယ်တာ (Masking) နဲ့ Just-in-time retrieval တွေကို လုပ်ပေးရပါတယ်။

၅။ Prompt Construction: System prompt, Tool definitions, Memory နဲ့ Conversation history တွေကို Priority stack အလိုက် စနစ်တကျ စီစဉ်ပြီး Model မြင်ရမယ့် စာသားကို အဆင့်ဆင့် တည်ဆောက်ပေးတာပါ။

၆။ Output Parsing: Model ဆီက ပြန်လာတဲ့ Structured tool\_calls တွေကို Harness က နားလည်အောင် ဖတ်ပြီး လမ်းကြောင်းပေးရပါတယ်။

၇။ State Management: အလုပ်တစ်ခု လုပ်နေတုန်း ကြားဖြတ် ရပ်သွားရင်တောင် နောက်မှ ပြန်စလို့ရအောင် (Check-pointing) လုပ်ပေးတာပါ။ ဒါကြောင့် "Time-travel debugging" တွေ လုပ်လို့ရတာ ဖြစ်ပါတယ်။

၈။ Error Handling: Harness က Transient error, LLM-recoverable error, User-fixable error နဲ့ Unexpected error ဆိုပြီး ခွဲခြားကိုင်တွယ်ရပါတယ်။

၉။ Guardrails and Safety: Agent က မလုပ်သင့်တာတွေ မလုပ်မိအောင် တားဆီးပေးတဲ့ "Tripwire" စနစ်တွေ ပါဝင်ပါတယ်။

၁၁။ Verification Loops (စစ်ဆေးရေး): Agent လုပ်လိုက်တဲ့ အလုပ်ကို Tests, Linters တွေနဲ့ ပြန်စစ်တာ ဒါမှမဟုတ် "LLM-as-judge" နဲ့ ပြန်စစ်ခိုင်းတာမျိုး ဖြစ်ပါတယ်။ ဒါက Quality ကို ၂ ဆကနေ ၃ ဆအထိ တိုးတက်စေပါတယ်။

၁၁။ Subagent Orchestration: အလုပ်တွေကို Fork လုပ်တာ၊ Teammate အနေနဲ့ ခိုင်းတာ ဒါမှမဟုတ် Handoff ပေးတာတွေကို စီမံပါတယ်။

၁၂။ Termination Logic: အလုပ်ဘယ်အချိန်မှာ ပြီးမလဲဆိုတာကို သတ်မှတ်ပေးတာပါ။

<br>

၄။ The Loop in Motion: Step-by-Step Walkthrough

Cycle တစ်ခုမှာ Harness က အောက်ပါအတိုင်း အလုပ်လုပ်ပါတယ် -

* Step 1 (Prompt Assembly): Prompt အားလုံးကို စုစည်းမယ်။ အရေးကြီးတဲ့ Context ကို အစနဲ့ အဆုံးမှာ ထားပါတယ်။
* Step 2 (LLM Inference): Prompt ကို Model ဆီ ပို့ပြီး Output ရယူပါတယ်။
* Step 3 (Output Classification): Tool call ပါသလား? Text သက်သက်လား? ဆိုတာ ခွဲခြားပါတယ်။
* Step 4 (Tool Execution): Sandbox ထဲမှာ Tool တွေကို Run ပါတယ်။
* Step 5 (Result Packaging): Tool ရလဒ်ကို LLM နားလည်မယ့် format ပြောင်းပါတယ်။
* Step 6 (Context Update): Conversation history ထဲ ထည့်ပြီး လိုအပ်ရင် Compaction လုပ်ပါတယ်။
* Step 7 (Loop): Step 1 ကို ပြန်သွားပါတယ်။

<br>

၅။ Seven Decisions That Define Every Harness

Harness တစ်ခုကို ဒီဇိုင်းဆွဲတော့မယ်ဆိုရင် အောက်ပါ ဆုံးဖြတ်ချက် ၇ ခုကို မဖြစ်မနေ ချမှတ်ရပါတယ် -

1. Single-agent vs. Multi-agent: Tool တွေ ၁၀ ခုထက် မကျော်မချင်း Single Agent ကိုပဲ Maximize လုပ်ဖို့ OpenAI နဲ့ Anthropic က အကြံပြုပါတယ်။
2. ReAct vs. Plan-and-execute: ReAct က ပိုပြောင်းလွယ်ပြင်လွယ် ရှိပေမဲ့ Plan-and-execute က ၃.၆ ဆ ပိုမြန်ပါတယ်။
3. Context window management strategy: Summarization, Masking, ဒါမှမဟုတ် Sub-agent delegation စတဲ့ နည်းလမ်းတွေကို ရွေးချယ်ရပါတယ်။
4. Verification loop design: Deterministic ဖြစ်တဲ့ Tests တွေ သုံးမလား၊ Semantic ဖြစ်တဲ့ LLM-as-judge သုံးမလား?
5. Permission and safety architecture: အလိုအလျောက် ခွင့်ပြုမလား (Permissive)၊ ဒါမှမဟုတ် တစ်ခုချင်းစီ စစ်မလား (Restrictive)?
6. Tool scoping strategy: လက်ရှိ အဆင့်အတွက် လုံးဝ လိုအပ်မယ့် Minimum tool set ကိုပဲ ပြထားဖို့ ဖြစ်ပါတယ်။
7. Harness thickness: Logic တွေဟာ Harness (Code) ထဲမှာ ပိုရှိမလား၊ Model ထဲမှာ ပိုရှိမလားဆိုတာပါ။

<br>

၆။ နိဂုံး- Harness သည်သာလျှင် Product ဖြစ်သည်

Model တူညီနေရင်တောင် Harness ကောင်းတဲ့ Product ကသာ အပြတ်အသတ် အနိုင်ရမှာပါ။ Harness ဆိုတာ "ငြမ်း" (Scaffolding) လိုပါပဲ။ အဆောက်အဦး (Model performance) ဆောက်ဖို့ လိုအပ်ပေမဲ့ အဆောက်အဦး ပြီးသွားရင် (Model တွေ ပိုတော်လာရင်) ငြမ်းတွေကို ဖယ်ရှားပစ်လို့ ရပါတယ်။ ဒါပေမဲ့ Model က ဘယ်လောက်ပဲ တော်နေပါစေ၊ Context စီမံဖို့နဲ့ Tool run ဖို့ Harness ကတော့ အမြဲလိုအပ်နေမှာပါ။

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