Mga Artikulo
Huwag Basta Mag-Fan-out: Praktikal na 4-Layer Orchestration Architecture Gamit ang Claude Haiku 5.5
Mabilis at mura ang Claude Haiku 5.5, pero kapag basta na lang ipinasa rito nang parallel ang lahat ng task, mapapalaki lang ang maling hatol, evaluation bias, at mga peligro sa Supply Chain. Ipinapaliwanag dito ang layered architecture ng pagpapasya gamit ang Fable, orchestration gamit ang Opus, implementation gamit ang Sonnet at Haiku, CI verification, at acceptance gamit ang Opus—pati na rin kung kailan lang talaga dapat mag-Fan-out.
· 8 minutong basa
Inilabas ang Claude Haiku 5.5 noong Oktubre 7, 2026. Kapag ang prompt ay nasa loob ng 100,000 tokens, ang presyo nito ay sangkadalawampu (1/20) lang ng Sonnet 5.5, at ang latency nito ang pinakamabilis sa kasalukuyang henerasyon ng Claude.
Dahil mura at mabilis, nakakatuksong gawin ito: paghiwa-hiwalayin ang lahat ng coding task, ipasa nang parallel sa isang grupo ng Haiku, at hintaying matapos.
Kapag nagpo-prototype, baka umubra ito. Pero kapag dinala na sa production engineering environment, mabilis kang tatama sa tatlong problema:
- Hindi angkop ang maliliit na model para sa ambiguity. Ang opisyal na positioning ng Haiku 5.5 ay para sa high-volume at low-latency workloads gaya ng classification, extraction, routing, at subagent tasks. Kapag may business ambiguity pa ang requirements at kailangan ang konteksto ng buong sistema, madali itong makapagbigay ng output na mukhang kumpleto pero mali pala ang hinulaang direksyon.
- May evaluation bias kapag pinapili mo ng sagot ang model. Kapag nagpabasa ka ng dose-dosenang outputs sa isang malaking model, madalas nitong piliin ang bersyong "mukhang maganda ang architecture" kaysa sa bersyong talagang tama ang logic at execution.
- Lumalawak ang permissions kasabay ng dami ng Worker. Kung papayagan ang mga parallel subagent na awtomatikong mag-install ng packages o magbago ng configuration, bawat dagdag na N na Worker ay dagdag na N na posibleng entry point para sa mga malisyosong package.
Kaya lumipat ako sa Hierarchical Orchestration: bawat layer ay gumagawa lang ng kung saan ito magaling, at ang parallel capability ng Haiku ay ginagamit lang kung kailan talaga kailangan.
Diretsuhin na natin ang konklusyon: Fable ang bahala sa malalim na pag-iisip, Opus ang nagtatalaga at nag-a-accept, Sonnet ang humahawak ng pangunahing implementation, at Haiku naman para sa mechanical tasks at search-type tasks na kayang i-verify nang awtomatiko. Kailangang dumaan muna sa CI ang candidate solutions bago ipakita sa model.
4-Layer Architecture: Pagpapasya, Orchestration, Verification, Acceptance#
Input ng Requirements
│
▼
[Judgment Layer] Fable: Mga desisyon sa architecture, task breakdown, acceptance criteria
│
▼
[Orchestration Layer] Opus Main Session: Nagtatalaga lang, hindi na muling naghihimay
├─► Path A: Komplekado pero malinaw ang boundaries ──► Sonnet implementation
├─► Path B: Mechanical tasks ──► Isang Haiku
├─► Path C: Search-type, maraming solusyon ──► Maraming Haiku, bawat isa may sariling Git Worktree
│
▼
[Verification Layer] Build, Type Check, Test, Benchmark (Sa Path C, top 2–3 lang ang ititira)
│
▼
[Acceptance Layer] Opus nagko-converge batay sa acceptance criteria
Kapag pumalya, mag-escalate: Haiku nag-retry nang 2 beses at bagsak pa rin ➔ Sonnet ➔ Ibalik sa Opus
Ang paglalagay sa bawat model sa partikular na layer ay nakabatay sa opisyal na positioning at presyo ng mga ito. Narito ang mga numero mula sa opisyal na dokumentasyon ng Anthropic noong Oktubre 8, 2026, kung saan ang presyo ay nasa US Dollars kada milyong tokens:
| Model |
Opisyal na Positioning |
Latency |
Presyo ng Input / Output |
| Claude Fable 5.1 |
High-difficulty reasoning at matagalang agentic workloads |
Mas mabagal |
$10 / $50 |
| Claude Opus 5.5 |
Matagalang agentic coding at knowledge work |
Katamtaman |
$4 / $20 |
| Claude Sonnet 5.5 |
Pinakamahusay na kombinasyon ng bilis at kakayahan |
Mabilis |
$2 / $10 |
| Claude Haiku 5.5 |
High-volume, low-latency classification, extraction, routing, at subagent tasks |
Pinakamabilis |
Magsisimula sa $0.10 / $0.50 |
May dalawang tier ang presyo ng Haiku 5.5: kapag lumampas sa 100,000 tokens ang prompt, nagiging $0.50 / $2.50 ito.
Judgment Layer: Fable ang Bahala sa mga Desisyon sa Architecture at Acceptance Criteria#
Hindi lahat ng requirement ay nangangailangan ng Fable. Ito ang pinakamahal at pinakamabagal na layer, kaya ginagamit ko lang ito kapag may ambiguity ang requirements, may kinalaman sa cross-system integration, o kailangang gumawa ng mga kritikal na desisyon sa architecture.
Tatlong bagay ang kailangang i-deliver ng Fable:
- Disenyo ng solusyon
- Paghimay ng mga gawain (task breakdown)
- Acceptance Criteria para sa bawat subtask na kayang i-verify gamit ang tests
Dapat magmula sa iisang layer ang reasoning at ang paghihimay. Ang layer na kayang makakita nang malinaw sa mga blind spot ng sistema ang siya ring makakapaghati ng malilinis ang boundary na subtasks; kapag ipinaubaya mo ang architecture kay A at ang breakdown kay B, kadalasang lumalabo ang mga interface definition.
Pambihirang exception dito ang security tasks. May safety classifiers ang kasalukuyang henerasyon ng Claude models; kapag naharang ang request, nagbabalik ito ng stop_reason: "refusal", kaya maging ang lehitimong security work ay posibleng ma-false positive. Sinasaklaw ng classifier ng Fable 5.1 ang karamihan sa security content, at ayon sa opisyal na paliwanag ay hindi ito idinisenyo para sa larangan ng cybersecurity; pinapayagan naman ng Opus 5.5 ang paghahanap ng vulnerabilities sa source code. Kaya para sa mga gawaing tulad ng pag-aayos ng security vulnerabilities, diretso kong ipinauubaya sa Opus ang paunang pagsusuri.
Orchestration Layer: Opus Nagtatalaga Lang, Hindi Na Muling Naghihimay#
Ang Opus ang nagsisilbing Main Session na namamahala sa routing at task assignment. Hindi na binabago ng layer na ito ang architecture, at hindi na rin ito naghihimay sa pangalawang pagkakataon.
- Path A, Komplekado pero malinaw ang boundaries: Para sa mga gawaing masalimuot ang logic pero malinaw na ang interface boundaries, ibigay ito kay Sonnet. Ito ang pangunahing workhorse para sa implementation.
- Path B, Simpleng mechanical tasks: Para sa Boilerplate code, pag-rename ng variables, pagdagdag ng simpleng unit tests, o pag-update ng documentation, isang Haiku lang ang humahawak nito.
- Path C, Search-type at optimization tasks: Para sa performance tuning, iba't ibang approaches sa komplikadong SQL o Regex, at pag-troubleshoot ng Flaky Test, dito lang magpapatakbo ng Fan-out: magtalaga ng maraming Haiku, kung saan bawat isa ay susubok ng magkakaibang solusyon sa loob ng sarili nitong hiwalay na Git Worktree.
Kahit aling path ang tahakin, kailangang dumaan ang output sa verification layer.
Verification Layer: Makina Muna Bago ang Model#
Karaniwang praktis ang basta na lang ipasa ang lahat ng parallel-generated code kay Opus o Sonnet at hingan ito ng code review gamit ang prompt.
Ang problema, kapag nagbabasa ng code ang mga model, madali silang maakit sa mga sagot na maayos ang pagkaka-format at kumpleto ang type annotations—pero hindi ibig sabihin noon ay pumasa na ito sa boundary conditions. Kaya dapat munang dumaan sa makina ang mga candidate solution:
- Build at Type Check: Nagko-compile nang maayos at tama ang types
- Unit / Integration Tests: Pumapasa sa unit tests at integration tests
- Benchmark / Profiling: Sinusukat ang performance at memory usage
Diretsong tinatanggal ang mga hindi pumapasa sa automated tests. Para sa candidate solutions sa Path C, tinitingnan lang ng Opus ang top 2–3 na pumasa sa checks at may pinakamagagandang metrics, na nakakatipid din sa context window at token.
Acceptance Layer: Opus Nagko-converge, Nag-eescalate Kapag Pumalya#
Sa huli, kinokolekta at kino-converge ng Opus ang mga resulta batay sa acceptance criteria na itinakda ng judgment layer. Kapag na-stuck ang isang Worker, susundin nito ang Escalation Path:
- Kapag pumalya ang Haiku, awtomatiko itong susubok mag-fix nang 2 beses; kung hindi pa rin pumasa, titigil na ang retry.
- Si Sonnet naman ang sasalong mag-ayos.
- Kung hindi pa rin makapasa si Sonnet sa acceptance, kadalasang senyales ito na may kontradiksyon sa task breakdown o sa underlying assumptions. Ibabalik ang task kay Opus, at si Opus ang magpapasya kung kailangang ibalik kay Fable para himayin muli.
Tatlong Panuntunan Bago Dalhin sa Production#
Huwag basta-basta mag-Fan-out#
Hindi kailangan ng simpleng tasks ang maraming Worker, at hindi rin kayang lutasin ng maliliit na model ang tasks na may mataas na ambiguity. Ang search-type tasks lang na may "malawak na solution space" at "mabilis ma-verify gamit ang automated tests" ang may saysay na patakbuhin nang parallel gamit ang maraming Haiku.
Ihiwalay ang environment, i-lock ang Lockfile#
Ang inihihiwalay lang ng Git Worktree ay ang mga pagbabago sa code para hindi magpatong-patong o mag-overwrite ang parallel Workers sa mga file; hindi nito nililimitahan ang access sa network o ang naaabot ng mismong program. Para maprotektahan laban sa Supply Chain Attack, kailangan pa rin ng sandbox, at ipagbawal sa Workers ang awtomatikong pag-install ng unvetted packages o pagbago sa Lockfile. Ang basta na lang pagbibigay ng install permissions ay katumbas ng pagpapahintulot sa Agent na magpasok ng mga hindi mapagkakatiwalaang packages at scripts sa codebase.
Gumamit ng metrics para sa acceptance, hindi komento ng model#
Ang test results, coverage, memory footprint, at latency ang mga batayang puwedeng maulit (reproducible) at maikumpara. Pwedeng gawing sanggunian ang text reviews ng model, pero hindi ito dapat gamiting batayan sa acceptance para sa kalidad ng code.
Gamitin ang murang model sa tamang paraan#
Dahil sa Haiku 5.5, naging mura ang parallel execution, pero hindi garantiya ang parallelism para maging tama ang resulta. Ihiwalay muna ang pagpapasya, orchestration, verification, at acceptance—doon lang magiging totoong bentahe ang pagiging mura at mabilis.
Ang layered setup na ito ay ang mismong Graph na tinukoy ko sa Ang AI Agent ay Isa Talagang Agile Team: sino ang unang gagawa, kanino ipapasa pagkatapos, at kanino iaakyat kapag nagkaaberya.