Artikel
Hentikan Fan-out Tanpa Berfikir: Praktik Seni Bina Orkestrasi Empat Lapisan Claude Haiku 5.5
Claude Haiku 5.5 pantas dan murah, tetapi melemparkan semua tugasan secara selari kepadanya hanya akan memburukkan salah tafsir, berat sebelah penilaian, serta risiko Supply Chain. Artikel ini menghuraikan seni bina berlapis: pertimbangan Fable, orkestrasi Opus, pelaksanaan Sonnet dan Haiku, pengesahan CI, serta penerimaan Opus, berserta jenis tugasan yang benar-benar berbaloi untuk Fan-out.
· 7 minit bacaan
Claude Haiku 5.5 dilancarkan pada 7 Oktober 2026. Apabila prompt berada di bawah 100,000 tokens, harganya hanyalah satu per dua puluh daripada Sonnet 5.5, dan kependamannya (latency) juga paling pantas dalam generasi Claude semasa.
Dengan harga yang murah dan prestasi yang pantas, timbul dorongan kuat untuk melakukan ini: pecahkan semua tugasan coding, lontarkan secara selari kepada sekumpulan Haiku, dan tunggu ia selesai.
Untuk membina prototaip, pendekatan ini mungkin berkesan. Namun apabila dibawa ke persekitaran kejuruteraan produksi, anda akan pantas berdepan dengan tiga masalah:
- Model kecil tidak sesuai mengendalikan kekaburan (ambiguity). Kedudukan rasmi Haiku 5.5 adalah untuk beban kerja bervolum tinggi dan berkependaman rendah seperti klasifikasi, pengekstrakan, penghalaan (routing), dan subagent. Apabila sesuatu keperluan masih mempunyai kekaburan domain perniagaan serta menuntut konteks sistem secara menyeluruh, ia cenderung menghasilkan output yang kelihatan lengkap tetapi sebenarnya tersasar andaian.
- Membiarkan model memilih jawapan mengundang berat sebelah penilaian (evaluator bias). Apabila puluhan output diserahkan untuk dibaca oleh model besar, ia cenderung memilih versi yang "kelihatan cantik seni binanya", bukannya versi yang benar-benar tepat dari segi logik dan pelaksanaan.
- Kebenaran akses (permissions) bertambah mengikut bilangan Worker. Jika subagent yang berjalan selari dibenarkan memasang pakej atau mengubah konfigurasi secara automatik, membuka N Worker bermakna membuka N pintu masuk yang berpotensi membawa masuk pakej berniat jahat.
Oleh itu, saya beralih kepada orkestrasi berhierarki (Hierarchical Orchestration): setiap lapisan hanya melakukan perkara yang ia kuasai, dan keupayaan selari Haiku hanya dimanfaatkan di tempat yang benar-benar memerlukannya.
Kesimpulannya terlebih dahulu: Fable bertanggungjawab memikirkan perincian dengan teliti, Opus mengendalikan agihan dan penerimaan, Sonnet memikul pelaksanaan utama, manakala Haiku hanya melakukan tugasan mekanikal serta tugasan carian yang boleh disahkan secara automatik. Calon penyelesaian mesti melepasi CI terlebih dahulu sebelum diserahkan kepada model untuk dinilai.
Seni Bina Empat Lapisan: Pertimbangan, Orkestrasi, Pengesahan, Penerimaan#
Input Keperluan
│
▼
[Lapisan Pertimbangan] Fable: Keputusan seni bina, pemecahan tugasan, kriteria penerimaan
│
▼
[Lapisan Orkestrasi] Opus Main Session: Hanya mengagihkan, tidak memecah semula
├─► Laluan A: Kompleks tetapi sempadan jelas ──► Pelaksanaan Sonnet
├─► Laluan B: Tugasan mekanikal ──► Haiku tunggal
├─► Laluan C: Berasaskan carian, pelbagai kaedah penyelesaian ──► Pelbagai Haiku, masing-masing dengan Git Worktree tersendiri
│
▼
[Lapisan Pengesahan] Build, Type Check, Test, Benchmark (Laluan C hanya kekalkan 2–3 teratas)
│
▼
[Lapisan Penerimaan] Opus membuat penumpuan mengikut kriteria penerimaan
Jika gagal, lakukan eskalasi: Haiku baiki 2 kali masih gagal ➔ Sonnet ➔ Kembalikan kepada Opus
Kedudukan setiap model dalam lapisan ditentukan berdasarkan penetapan rasmi dan harganya. Berikut adalah angka daripada dokumentasi rasmi Anthropic pada 8 Oktober 2026, dengan unit harga dalam USD bagi setiap sejuta token:
| Model |
Kedudukan Rasmi |
Kependaman |
Harga Input / Output |
| Claude Fable 5.1 |
Penaakulan beraras tinggi dan kerja agentic berdurasi panjang |
Lebih perlahan |
$10 / $50 |
| Claude Opus 5.5 |
Kerja coding agentic dan kerja berasaskan pengetahuan berdurasi panjang |
Sederhana |
$4 / $20 |
| Claude Sonnet 5.5 |
Gabungan terbaik antara kelajuan dan keupayaan |
Pantas |
$2 / $10 |
| Claude Haiku 5.5 |
Klasifikasi, pengekstrakan, penghalaan, dan tugasan subagent bervolum tinggi serta berkependaman rendah |
Paling pantas |
Bermula $0.10 / $0.50 |
Harga Haiku 5.5 dibahagikan kepada dua peringkat: apabila prompt melebihi 100,000 tokens, harganya menjadi $0.50 / $2.50.
Lapisan Pertimbangan: Fable Mengendalikan Keputusan Seni Bina dan Kriteria Penerimaan#
Bukan semua keperluan memerlukan Fable. Ia merupakan lapisan paling mahal dan paling perlahan; saya hanya menggunakannya apabila terdapat kekaburan dalam keperluan, melibatkan integrasi rentas sistem, atau ketika perlu membuat keputusan seni bina teras.
Fable perlu menghasilkan tiga perkara:
- Reka bentuk penyelesaian
- Pemecahan tugasan
- Kriteria penerimaan (Acceptance Criteria) bagi setiap sub-tugasan yang boleh disahkan melalui ujian
Penaakulan dan pemecahan mesti diselesaikan oleh lapisan yang sama. Lapisan yang mampu melihat titik buta sistem dengan jelas sahajalah yang boleh membahagikan sub-tugasan dengan sempadan yang kemas; jika seni bina diserahkan kepada A dan pemecahan diserahkan kepada B, takrifan antara muka selalunya akan menjadi kabur.
Tugasan keselamatan siber adalah pengecualian. Generasi model Claude semasa dilengkapi dengan pengelas keselamatan (safety classifier). Apabila permintaan disekat, ia akan memulangkan stop_reason: "refusal", dan kerja keselamatan yang sah juga berisiko disekat secara silap. Pengelas Fable 5.1 merangkumi sebahagian besar kandungan keselamatan, dan dokumentasi rasmi menyatakan bahawa ia bukan direka khusus untuk domain keselamatan siber; sebaliknya, Opus 5.5 membenarkan pencarian kerentanan dalam kod sumber. Oleh itu, untuk keperluan seperti pembaikan kerentanan keselamatan, saya menyerahkan analisis peringkat awal terus kepada Opus.
Lapisan Orkestrasi: Opus Hanya Mengagihkan, Tidak Memecah Semula#
Opus bertindak sebagai Main Session, bertanggungjawab untuk penghalaan dan agihan tugas. Lapisan ini tidak akan merombak seni bina, mahupun melakukan pemecahan kali kedua.
- Laluan A, kompleks tetapi sempadan jelas: Tugasan yang logiknya kompleks tetapi sempadan antara mukanya telah ditakrifkan dengan jelas akan diserahkan kepada Sonnet. Ia merupakan tunjang utama pelaksanaan.
- Laluan B, tugasan mekanikal yang ringkas: Kod templat (Boilerplate), penamaan semula pemboleh ubah, penambahan ujian unit asas, penambahan dokumentasi, diserahkan kepada satu Haiku.
- Laluan C, tugasan berasaskan carian dan pengoptimuman: Penalaan prestasi, pelbagai gaya penulisan SQL atau Regex yang kompleks, penyelesaian isu Flaky Test — barulah Fan-out diaktifkan: hantar beberapa Haiku, masing-masing mencuba penyelesaian berbeza di dalam Git Worktree yang berasingan.
Tidak kira laluan mana yang diambil, output mesti masuk ke lapisan pengesahan.
Lapisan Pengesahan: Utamakan Mesin, Diikuti Model#
Amalan yang sangat lazim adalah mencampakkan semua kod yang dihasilkan secara selari kepada Opus atau Sonnet, kemudian memintanya melakukan semakan menggunakan prompt.
Masalahnya, apabila model membaca kod, ia mudah tertarik kepada jawapan yang tersusun rapi serta mempunyai pengisytiharan jenis data yang lengkap, namun itu tidak bermakna kod tersebut melepasi ujian kes pinggir (edge cases). Oleh itu, calon penyelesaian mesti melepasi tapisan mesin terlebih dahulu:
- Build dan Type Check: Boleh dikompilasi, jenis data betul
- Unit / Integration Tests: Ujian unit dan ujian integrasi lulus
- Benchmark / Profiling: Ukur prestasi dan penggunaan memori
Mana-mana yang gagal dalam ujian automatik akan disingkirkan serta-merta. Bagi calon penyelesaian Laluan C, Opus hanya akan meneliti 2–3 pilihan teratas yang lulus semakan dan mempunyai metrik terbaik, sekali gus menjimatkan context window dan token.
Lapisan Penerimaan: Opus Membuat Penumpuan, Lakukan Eskalasi Jika Gagal#
Akhir sekali, Opus akan menumpukan dan memuktamadkan hasil berdasarkan kriteria penerimaan yang ditakrifkan oleh lapisan pertimbangan. Jika Worker tersekat, lakukan eskalasi mengikut laluan eskalasi (Escalation Path):
- Jika Haiku gagal dan pembetulan automatik sebanyak 2 kali masih tidak lulus, hentikan percubaan semula.
- Alihkan tugas kepada Sonnet untuk mengambil alih pembaikan.
- Jika Sonnet juga tidak dapat melepasi penerimaan, ini biasanya menandakan wujud percanggahan dalam pemecahan tugasan atau andaian asas. Tugasan dikembalikan kepada Opus, dan Opus akan menentukan sama ada ia perlu dihantar semula kepada Fable untuk dipecahkan semula.
Tiga Peraturan Sebelum Dibawa ke Persekitaran Produksi#
Jangan Lakukan Fan-out Secara Membabi Buta#
Tugasan mudah tidak memerlukan banyak Worker, manakala tugasan dengan tahap kekaburan yang tinggi tidak mampu diselesaikan oleh model kecil. Hanya tugasan carian yang mempunyai "ruang penyelesaian yang luas" dan "boleh disahkan dengan pantas melalui ujian automatik" yang berbaloi untuk dijalankan secara selari menggunakan beberapa Haiku.
Asingkan Persekitaran, Kunci Lockfile#
Git Worktree mengasingkan perubahan kod supaya Worker yang berjalan selari tidak menimpa fail antara satu sama lain; ia tidak mengehadkan rangkaian, dan tidak menyekat skop capaian program. Untuk mencegah Supply Chain Attack, sandbox masih diperlukan, selain melarang Worker daripada memasang pakej yang belum disemak atau mengubah Lockfile sesuka hati. Memberikan kebenaran pemasangan secara bebas adalah sama seperti membiarkan Agent membawa masuk pakej dan skrip yang tidak diketahui puncanya ke dalam repositori kod.
Buat Penerimaan Berdasarkan Data Pengukuran, Bukan Ulasan Model#
Keputusan ujian, liputan kod (coverage), penggunaan memori, dan kependaman adalah asas yang boleh diulang dan dibandingkan. Ulasan teks daripada model boleh dijadikan rujukan, tetapi tidak boleh digunakan sebagai kayu ukur penerimaan kualiti kod.
Model Murah Mesti Digunakan di Tempat yang Betul#
Haiku 5.5 menjadikan operasi selari lebih murah, tetapi operasi selari itu sendiri tidak menjamin ketepatan hasil. Asingkan pertimbangan, pengagihan, pengesahan, dan penerimaan terlebih dahulu — barulah kelebihan murah dan pantas bertukar menjadi kekuatan sebenar.
Seni bina berlapis ini sebenarnya adalah Graph yang pernah saya bincangkan dalam AI Agent Sebenarnya Sebuah Pasukan Tangkas: siapa yang bermula dahulu, kepada siapa hasil diserahkan, dan kepada siapa masalah dieskalasikan apabila timbul isu.