မစဉ်းစားဘဲ Fan-out မလုပ်ပါနဲ့- လက်တွေ့အသုံးချ Claude Haiku 5.5 အလွှာလေးလွှာ ခွဲဝေမှု Architecture

Claude Haiku 5.5 က မြန်ပြီး ဈေးသက်သာပေမဲ့ task အားလုံးကို parallel ပေးလိုက်ရင် အမှားများတာ၊ evaluation bias ဖြစ်တာနဲ့ Supply Chain အန္တရာယ်တွေကို ပိုဆိုးစေပါတယ်။ ဒီဆောင်းပါးမှာ Fable ဆုံးဖြတ်၊ Opus ခွဲဝေ၊ Sonnet နဲ့ Haiku အကောင်အထည်ဖော်၊ CI စစ်ဆေး၊ Opus လက်ခံစစ်ဆေးတဲ့ layered architecture နဲ့ ဘယ်လို task မျိုးကိုမှ Fan-out လုပ်သင့်လဲဆိုတာ အသေးစိတ်ရှင်းပြထားပါတယ်။

2026/10/08 · 2 မိနစ် ဖတ်ရန်

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

Claude Haiku 5.5 ကို ၂၀၂၆ ခုနှစ် အောက်တိုဘာလ ၇ ရက်မှာ စတင်မိတ်ဆက်ခဲ့ပါတယ်။ prompt က 100,000 tokens အတွင်းမှာဆိုရင် သူ့ရဲ့ဈေးနှုန်းဟာ Sonnet 5.5 ရဲ့ အပုံနှစ်ဆယ်ပုံ တစ်ပုံပဲ ရှိပြီး latency ကလည်း လက်ရှိ ဒီ Claude မျိုးဆက်ထဲမှာ အမြန်ဆုံး ဖြစ်ပါတယ်။

ဈေးလည်းသက်သာ၊ မြန်လည်းမြန်တော့ လူတွေက coding task အားလုံးကို ခွဲထုတ်ပြီး Haiku အုပ်စုဆီ parallel လွှဲပေးလိုက်ရင် ပြီးရောလို့ စဉ်းစားမိတတ်ကြပါတယ်။

Prototype လုပ်တုန်းကတော့ အဆင်ပြေနိုင်ပေမဲ့ တကယ့် production engineering environment ထဲ ထည့်လိုက်တဲ့အခါ ပြဿနာ ၃ ခုနဲ့ ချက်ချင်း ရင်ဆိုင်ရပါလိမ့်မယ်-

Model သေးသေးလေးတွေက မရေရာတဲ့ အခြေအနေ (ambiguity) တွေကို မကိုင်တွယ်နိုင်ပါဘူး။ Haiku 5.5 ရဲ့ official positioning က classification၊ extraction၊ routing နဲ့ subagent လိုမျိုး volume များပြီး low latency လိုအပ်တဲ့ အလုပ်တွေအတွက် ဖြစ်ပါတယ်။ Business ambiguity တွေရှိနေသေးပြီး system တစ်ခုလုံးရဲ့ context လိုအပ်တဲ့အခါ ကြည့်ရတာ ပြည့်စုံသယောင်နဲ့ တကယ်တော့ လမ်းကြောင်းလွဲမှန်းထားတဲ့ ရလဒ်တွေကို ပေးတတ်ပါတယ်။
Model ကို အဖြေရွေးခိုင်းရင် evaluation bias ဖြစ်တတ်ပါတယ်။ Output အများကြီးကို model ကြီးဆီ ပေးဖတ်ခိုင်းရင် logic နဲ့ execution အမှန်တကယ် မှန်တာထက် “ကြည့်ရတာ architecture သပ်ရပ်တဲ့” version မျိုးကို ပိုရွေးချယ်တတ်ပါတယ်။
Worker အရေအတွက် များလာတာနဲ့အမျှ permission တွေလည်း ပိုကျယ်ပြန့်လာပါတယ်။ Parallel subagent တွေကို package တွေ install လုပ်ခွင့် ဒါမှမဟုတ် config တွေ ပြင်ခွင့်ပေးထားရင် Worker N ခု ဖွင့်လိုက်တာနဲ့ malicious package တွေ ဝင်လာနိုင်တဲ့ entry point N ခု တိုးလာပါလိမ့်မယ်။

ဒါကြောင့် ကျွန်တော်က အလွှာလိုက် ခွဲဝေညှိနှိုင်းမှု (Hierarchical Orchestration) ကို ပြောင်းသုံးထားပါတယ်- အလွှာတိုင်းက ကိုယ်ကျွမ်းကျင်တာကိုပဲ လုပ်ပြီး Haiku ရဲ့ parallel စွမ်းရည်ကို တကယ်လိုအပ်တဲ့ နေရာမှာပဲ သုံးပါတယ်။

အနှစ်ချုပ်ကို အရင်ပြောရရင်- Fable က သေချာစဉ်းစားဆုံးဖြတ်တယ်၊ Opus က တာဝန်ခွဲဝေပြီး စိစစ်လက်ခံတယ်၊ Sonnet က အဓိက အကောင်အထည်ဖော်တယ်၊ Haiku ကတော့ ထပ်တလဲလဲလုပ်ရတဲ့ ပုံသေ task တွေနဲ့ အလိုအလျောက် စစ်ဆေးနိုင်တဲ့ search task တွေကိုပဲ လုပ်ပါတယ်။ အဖြေတွေကို အရင်ဆုံး CI စစ်ပြီးမှ model ဆီ လွှဲပေးပါတယ်။

အလွှာလေးလွှာ Architecture- ဆုံးဖြတ်ခြင်း၊ ခွဲဝေခြင်း၊ စစ်ဆေးခြင်း၊ လက်ခံခြင်း

လိုအပ်ချက် ထည့်သွင်းခြင်း
  │
  ▼
[ဆုံးဖြတ်လွှာ] Fable- Architecture ဆုံးဖြတ်ချက်၊ Task ခွဲထုတ်ခြင်း၊ လက်ခံစံနှုန်းများ
  │
  ▼
[ခွဲဝေလွှာ] Opus Main Session- တာဝန်ခွဲဝေခြင်းသာ လုပ်၊ ထပ်မံမခွဲထုတ်တော့ပါ
  ├─► လမ်းကြောင်း A- ရှုပ်ထွေးသော်လည်း boundary ရှင်းလင်း ──► Sonnet အကောင်အထည်ဖော်
  ├─► လမ်းကြောင်း B- ထပ်တလဲလဲ ပုံသေ task ──► Haiku တစ်ခုတည်း
  ├─► လမ်းကြောင်း C- ရှာဖွေစူးစမ်းရသော နည်းလမ်းစုံ ──► သီးခြား Git Worktree နှင့် Haiku အများအပြား
  │
  ▼
[စစ်ဆေးလွှာ] Build, Type Check, Test, Benchmark (လမ်းကြောင်း C အတွက် ထိပ်တန်း ၂–၃ ခုသာ ထားရှိ)
  │
  ▼
[လက်ခံလွှာ] Opus က လက်ခံစံနှုန်းများနှင့်အညီ အတည်ပြု
          မအောင်မြင်ပါက အထက်သို့လွှဲ- Haiku ၂ ကြိမ်ပြင်ဆင်သော်လည်း မအောင်မြင်ပါက ➔ Sonnet ➔ Opus သို့ ပြန်ပို့

Model တစ်ခုချင်းစီကို ဘယ်အလွှာမှာ ထားမလဲဆိုတာ official positioning နဲ့ ဈေးနှုန်းပေါ် မူတည်ပြီး သတ်မှတ်ထားတာ ဖြစ်ပါတယ်။ အောက်ပါဇယားကတော့ ၂၀၂၆ ခုနှစ် အောက်တိုဘာလ ၈ ရက်ထုတ် Anthropic official documentation ထဲက ကိန်းဂဏန်းတွေဖြစ်ပြီး ဈေးနှုန်းယူနစ်က ဒေါ်လာ / 1M tokens ဖြစ်ပါတယ်-

Model	Official Positioning	Latency	Input / Output ဈေးနှုန်း
Claude Fable 5.1	အဆင့်မြင့် reasoning နှင့် ကြာရှည်လုပ်ဆောင်ရသော agentic အလုပ်များ	နှေးသည်	$10 / $50
Claude Opus 5.5	ကြာရှည်လုပ်ဆောင်ရသော agentic coding နှင့် knowledge work	အသင့်အတင့်	$4 / $20
Claude Sonnet 5.5	Speed နှင့် capability မျှတမှုအကောင်းဆုံး	မြန်သည်	$2 / $10
Claude Haiku 5.5	Volume များ၊ latency နည်းသော classification, extraction, routing နှင့် subagent task များ	အမြန်ဆုံး	$0.10 / $0.50 မှစတင်

Haiku 5.5 ရဲ့ ဈေးနှုန်းက အပိုင်း ၂ ပိုင်း ခွဲထားပါတယ်- prompt က 100,000 tokens ကျော်သွားရင် $0.50 / $2.50 ဖြစ်သွားပါတယ်။

ဆုံးဖြတ်လွှာ- Fable က Architecture ဆုံးဖြတ်ချက်များနှင့် လက်ခံစံနှုန်းများကို တာဝန်ယူသည်

Task တိုင်းမှာ Fable ကို သုံးဖို့ မလိုပါဘူး။ သူက အဈေးအကြီးဆုံးနဲ့ အနှေးဆုံး အလွှာဖြစ်လို့ ambiguity ရှိတဲ့အခါ၊ cross-system integration ပါဝင်တဲ့အခါ ဒါမှမဟုတ် core architectural decision တွေ ချမှတ်ရမယ့်အခါမှသာ ကျွန်တော် သုံးပါတယ်။

Fable က အောက်ပါအချက် ၃ ချက်ကို ထုတ်ပေးရပါမယ်-

Solution design
Task breakdown
Subtask တစ်ခုချင်းစီအတွက် test တွေနဲ့ စစ်ဆေးနိုင်မယ့် Acceptance Criteria

Reasoning နဲ့ breakdown ကို အလွှာတစ်ခုတည်းက ပြီးပြတ်အောင် လုပ်ရပါမယ်။ System ရဲ့ blind spot တွေကို သေချာနားလည်တဲ့ အလွှာကသာ boundary ရှင်းလင်းတဲ့ subtask တွေကို ခွဲထုတ်နိုင်မှာဖြစ်ပြီး architecture ကို A ဆီပေး၊ breakdown ကို B ဆီပေး လုပ်လိုက်ရင် interface definition တွေ ဝေဝါးသွားတတ်ပါတယ်။

Security task တွေကတော့ ချွင်းချက်ပါ။ လက်ရှိ Claude မျိုးဆက် model တွေမှာ safety classifier ပါဝင်ပြီး request တွေ အပိတ်ခံရတဲ့အခါ stop_reason: "refusal" ပြန်ပို့တတ်တာကြောင့် တရားဝင် security work တွေတောင်မှ မှားယွင်းပိတ်ပင်ခံရနိုင်ပါတယ်။ Fable 5.1 ရဲ့ classifier က security content အများစုကို လွှမ်းခြုံထားပြီး official documentation အရ security domain အတွက် ရည်ရွယ်မထားဘူးလို့ ဆိုပါတယ်၊ Opus 5.5 ကတော့ source code ထဲမှာ vulnerability ရှာဖွေတာကို ခွင့်ပြုပါတယ်။ ဒါကြောင့် security vulnerability တွေ ဖြေရှင်းရတဲ့အခါ ရှေ့ပိုင်း analysis ကို ကျွန်တော် Opus ဆီ တိုက်ရိုက် ပေးလိုက်ပါတယ်။

ခွဲဝေလွှာ- Opus သည် တာဝန်ခွဲဝေရုံသာလုပ်ပြီး ထပ်မံမခွဲထုတ်ပါ

Opus က Main Session ဖြစ်ပြီး routing နဲ့ task dispatch လုပ်တာကို တာဝန်ယူပါတယ်။ ဒီအလွှာက architecture ကို ပြန်လှန်တာ ဒါမှမဟုတ် ဒုတိယအကြိမ် ထပ်မံခွဲထုတ်တာမျိုး မလုပ်ပါဘူး။

လမ်းကြောင်း A၊ ရှုပ်ထွေးသော်လည်း boundary ရှင်းလင်းခြင်း- Logic ရှုပ်ထွေးပေမဲ့ interface boundary သေချာသတ်မှတ်ပြီးသား task တွေကို Sonnet ဆီ ပေးပါတယ်။ သူက implementation အဓိကလုပ်သူ ဖြစ်ပါတယ်။
လမ်းကြောင်း B၊ သာမန်ထပ်တလဲလဲလုပ်ရသော task များ- Boilerplate code၊ variable rename လုပ်တာ၊ ရိုးရှင်းတဲ့ unit test ဖြည့်တာ၊ documentation ဖြည့်တာတွေကိုတော့ Haiku တစ်ခုတည်းကို ကိုင်တွယ်ခိုင်းပါတယ်။
လမ်းကြောင်း C၊ ရှာဖွေစူးစမ်းရသော အကောင်းဆုံးဖြစ်အောင် ပြင်ဆင်သည့် task များ- Performance tuning၊ ရှုပ်ထွေးတဲ့ SQL ဒါမှမဟုတ် Regex တွေကို နည်းလမ်းအမျိုးမျိုးနဲ့ ရေးသားတာ၊ Flaky Test တွေကို debug လုပ်တာတွေမှာမှ Fan-out ကို စတင်အသုံးပြုပါတယ်- သီးခြား Git Worktree တွေထဲမှာ မတူညီတဲ့ solution တွေကို စမ်းသပ်ဖို့ Haiku အများအပြားကို လွှတ်ပေးပါတယ်။

ဘယ်လမ်းကြောင်းကိုပဲ သွားသွား output တွေကတော့ စစ်ဆေးလွှာဆီ ရောက်ရပါမယ်။

စစ်ဆေးလွှာ- စက်က အရင်စစ်၊ Model က နောက်မှစစ်

အတွေ့များတဲ့ နည်းလမ်းတစ်ခုကတော့ parallel ထွက်လာတဲ့ code အားလုံးကို Opus ဒါမှမဟုတ် Sonnet ဆီ ပေးပြီး prompt နဲ့ စစ်ဆေးခိုင်းတာ ဖြစ်ပါတယ်။

ပြဿနာက model က code ကို ဖတ်တဲ့အခါ format သပ်ရပ်ပြီး type declaration ပြည့်စုံတဲ့ အဖြေတွေဘက်ကို သဘောကျလွယ်ပေမဲ့ အဲဒါက edge case test တွေကို အောင်မြင်တယ်လို့ မဆိုလိုပါဘူး။ ဒါကြောင့် အဖြေတွေကို စက်နဲ့ အရင်ဆုံး စစ်ဆေးရပါမယ်-

Build နှင့် Type Check- compile လုပ်လို့ရရမယ်၊ type မှန်ရမယ်
Unit / Integration Tests- unit test တွေနဲ့ integration test တွေ အောင်မြင်ရမယ်
Benchmark / Profiling- performance နဲ့ memory ကို တိုင်းတာစစ်ဆေးရမယ်

Automated test တွေ မအောင်မြင်တာတွေကို တိုက်ရိုက် ပယ်ထုတ်ပါတယ်။ လမ်းကြောင်း C ရဲ့ အဖြေတွေထဲကမှ check အောင်မြင်ပြီး metrics အကောင်းဆုံးဖြစ်တဲ့ ထိပ်တန်း ၂–၃ ခုကိုပဲ Opus က ကြည့်တော့ context window နဲ့ token တွေကိုလည်း သက်သာစေပါတယ်။

လက်ခံလွှာ- Opus က အတည်ပြုပြီး မအောင်မြင်ပါက အထက်သို့ လွှဲတင်သည်

နောက်ဆုံးမှာတော့ ဆုံးဖြတ်လွှာက သတ်မှတ်ထားတဲ့ Acceptance Criteria နဲ့အညီ Opus က ရလဒ်တွေကို စိစစ်အတည်ပြုပါတယ်။ Worker တစ်ခု အဆင်မပြေဖြစ်တဲ့အခါ အောက်ပါ Escalation Path အတိုင်း အဆင့်ဆင့် လွှဲတင်သွားပါတယ်-

Haiku မအောင်မြင်လို့ အလိုအလျောက် ၂ ကြိမ် ပြင်ဆင်ပြီးတဲ့အထိ မအောင်သေးရင် retry လုပ်တာကို ရပ်လိုက်ပါတယ်။
Sonnet က ဝင်ရောက်ပြင်ဆင်ပေးပါတယ်။
Sonnet တောင်မှ စစ်ဆေးမှုကို မကျော်ဖြတ်နိုင်ဘူးဆိုရင် task breakdown ဒါမှမဟုတ် assumption တွေမှာ ပဋိပက္ခဖြစ်နေတာ များပါတယ်။ Task ကို Opus ဆီ ပြန်ပို့ပြီး အသစ်ပြန်ခွဲထုတ်ဖို့ Fable ဆီ ပို့သင့်မသင့် Opus က ဆုံးဖြတ်ပါတယ်။

Production မတိုင်မီ လိုက်နာရမည့် စည်းမျဉ်း ၃ ချက်

မျက်စိစုံမှိတ် Fan-out မလုပ်ပါနဲ့

ရိုးရှင်းတဲ့ task တွေအတွက် Worker အများကြီး မလိုသလို အရမ်းမရေရာတဲ့ task တွေကိုလည်း model သေးသေးလေးတွေက မဖြေရှင်းနိုင်ပါဘူး။ “Solution space ကြီးမားပြီး” “automated test တွေနဲ့ အမြန်စစ်ဆေးနိုင်တဲ့” search task တွေမှာမှ Haiku အများအပြားကို parallel run သင့်ပါတယ်။

Environment ကို ခွဲထုတ်ပြီး Lockfile ကို ပိတ်ထားပါ

Git Worktree က code change တွေကို သီးခြားခွဲထုတ်ပေးတာကြောင့် parallel Worker တွေ အချင်းချင်း file တွေ မထပ်သွားစေပါဘူး။ ဒါပေမဲ့ သူက network ဒါမှမဟုတ် program ဝင်ရောက်သုံးစွဲနိုင်တဲ့ scope ကို ကန့်သတ်မထားပါဘူး။ Supply Chain Attack ကို ကာကွယ်ဖို့ sandbox လိုအပ်ပြီး Worker တွေ သဘောအလျောက် unreviewed package တွေ install လုပ်တာ ဒါမှမဟုတ် Lockfile ပြင်ဆင်တာတွေကို တားမြစ်ရပါမယ်။ Install လုပ်ခွင့်ကို ကြိုက်သလို ဖွင့်ပေးထားတာဟာ အတည်မပြုနိုင်တဲ့ package တွေနဲ့ script တွေကို Agent က codebase ထဲ ယူလာခွင့် ပေးလိုက်တာနဲ့ အတူတူပါပဲ။

Model ရဲ့ သုံးသပ်ချက်ထက် တိုင်းတာရရှိတဲ့ data တွေနဲ့ လက်ခံစစ်ဆေးပါ

Test result တွေ၊ coverage၊ memory usage နဲ့ latency တွေကသာ ပြန်လည်စမ်းသပ်နိုင်ပြီး နှိုင်းယှဉ်နိုင်တဲ့ အခြေခံအချက်တွေ ဖြစ်ပါတယ်။ Model ရဲ့ စာသားသုံးသပ်ချက်ကို အကိုးအကားအဖြစ် ယူနိုင်ပေမဲ့ code quality ကို လက်ခံအတည်ပြုဖို့တော့ အသုံးမပြုသင့်ပါဘူး။

ဈေးသက်သာတဲ့ Model ကို နေရာမှန်မှာ သုံးပါ

Haiku 5.5 က parallel လုပ်တာကို ဈေးသက်သာစေပေမဲ့ parallel ဖြစ်ရုံနဲ့ ရလဒ်တွေ မှန်ကန်သွားမှာ မဟုတ်ပါဘူး။ ဆုံးဖြတ်ခြင်း၊ ခွဲဝေခြင်း၊ စစ်ဆေးခြင်းနဲ့ လက်ခံခြင်းတွေကို သေချာခွဲထုတ်လိုက်မှသာ သက်သာတာနဲ့ မြန်တာက တကယ့် အားသာချက် ဖြစ်လာမှာပါ။

ဒီ layered structure ဟာ ကျွန်တော် AI Agent ဆိုတာ အမှန်တော့ Agile Team တစ်ခုပါပဲ ထဲမှာ ပြောခဲ့တဲ့ Graph နဲ့ အတူတူပါပဲ- ဘယ်သူ အရင်လုပ်မလဲ၊ ပြီးရင် ဘယ်သူ့ဆီ လွှဲမလဲ၊ ပြဿနာတက်ရင် ဘယ်သူ့ဆီ တင်ပြမလဲ ဆိုတာပါပဲ။

ဤဆောင်းပါး၏ အစ

2026/10/08 14:06 [Claude] ကုန်ကျစရိတ်နည်းပြီး လုံခြုံရေးမြင့်မားသော Agent Ar…