S02E02 (Part 1): Orchestrator — Bandingkan Dulu Sebelum Pilih
Sambungan dari S02E00 (Pilot) — kita "teaser" konsep Tier 3 (orchestration) di situ. Sekarang jom kita mula benar-benar teroka, bermula dengan pilihan yang ada di pasaran.
😄 Nota: Episod ni lebih kepada perbandingan dan penjelasan konsep — setup teknikal penuh menanti di Part 2.
📑 Kandungan (Table of Content)
- Pembukaan
- Bahagian 1: Jadual Perbandingan 6 Framework Orchestration
- Bahagian 2: Post-Mortem — Kenapa Percubaan Pertama Saya Gagal
- Bahagian 3: Kenapa Saya Pilih BMad-Method
- Bahagian 4: Konsep Penting — "Agent = Persona, Bukan Semestinya Model Berasingan"
- Penutup
Pembukaan
Rata-rata content creator teknologi suka tunjuk hasil mengagumkan dari sistem "orchestration" — berbilang AI agent bekerja serentak, hasil app siap dalam masa singkat. Tapi selalunya, tool sebenar di sebalik tabir jarang didedahkan secara terperinci. Ada pelbagai sebab munasabah untuk ni — mungkin setup terlalu personal untuk kes penggunaan spesifik mereka, mungkin sukar dipaparkan menarik dalam video pendek, atau sekadar belum masanya untuk kongsi.
Daripada cuba teka apa yang orang lain guna, jom kita bandingkan sendiri pilihan yang memang wujud dan percuma di pasaran — supaya awak boleh buat penilaian sendiri.
BAHAGIAN 1: Jadual Perbandingan 6 Framework Orchestration
| Framework | Paradigma | Pros | Cons | Sesuai Untuk |
|---|---|---|---|---|
| CrewAI | Kod Python | Popular, dokumentasi banyak, konsep role-based mudah faham | Perlukan kemahiran Python, boleh jadi kompleks untuk skop besar, sensitif pada kualiti model (pengalaman peribadi saya!) | Developer selesa dengan Python |
| AutoGen (Microsoft) | Kod Python | Dibangun Microsoft, kuat untuk pattern perbualan kompleks antara agent | Learning curve lebih curam, lebih "penyelidikan" dari "praktikal harian" | Kes penggunaan advanced, penyelidikan AI |
| LangGraph | Kod (graph-based state machine) | Kawalan sangat terperinci ke atas flow, sesuai production-grade | Paling kompleks dari senarai ni, perlukan pemahaman konsep graph/state | Developer berpengalaman, sistem kritikal |
| n8n | Visual/GUI (node-based) | Tiada perlu coding, drag-and-drop, sangat visual | Kurang fleksibel untuk logik AI kompleks, lebih untuk automation/integration am | Automate workflow, bukan khusus AI orchestration |
| Flowise | Visual/GUI (drag-drop) | Fokus LLM/RAG, senang nampak "flow" data | Sama macam n8n — GUI-first, kurang sesuai untuk headless/TUI/server | Prototaip cepat, demo visual |
| BMad-Method | Markdown-native | Tool-agnostic (jalan dalam Claude Code/Cursor/OpenCode/Aider), sesuai TUI/headless, tiada perlu Python, expansion pack pelbagai domain | Perlukan disiplin ikut struktur (planning-first), komuniti lebih kecil dari CrewAI | Kerja headless/server, pengguna tak selesa coding Python |
💡 Tips & Trick: Perhatikan paksi utama perbezaan — kod (CrewAI/AutoGen/LangGraph) vs visual GUI (n8n/Flowise) vs markdown (BMad). Pilihan awak patut ikut selesa awak — kalau awak dah biasa terminal/TUI (macam siri kita), markdown-native lebih natural. Kalau awak lebih suka "nampak" flow secara visual, GUI tool lebih sesuai.
🆘 Jika Tersekat (Bahagian 1)
Saya keliru nak pilih framework orchestration. Keperluan saya: [nyatakan
— contoh "nak headless di server" atau "nak visual GUI"]. Tolong
cadangkan mana sesuai.
BAHAGIAN 2: Post-Mortem — Kenapa Percubaan Pertama Saya Gagal
Sebelum teruskan, jom kongsi pengalaman jujur — percubaan pertama saya dengan orchestration (guna CrewAI) gagal. Setup: 4 "brain" AI berbeza, 8 agent, cuba bina "Sistem Klinik Standalone Patuh KKM" — hasil mengecewakan, agent "architect" cuma hasilkan beberapa fail MD yang tak detail, agent lain gagal teruskan kerja dengan baik.
Diagnosis Sebenar (Bukan Salah Tool Semata)
- Skop terlalu besar untuk percubaan pertama — "sistem klinik lengkap" terlalu ambisius untuk baseline test
- Model local terlalu lemah untuk peranan "coordinator/manager" — peranan ni perlukan reasoning sangat konsisten, model kecil (7-14B) struggle
- Context tak "passed" dengan baik antara agent — output satu agent tak sampai dengan jelas ke agent seterusnya
😄 Kegagalan ni sebenarnya "bayaran" pembelajaran yang berbaloi — tanpa cuba dan gagal, saya takkan tahu sebab sebenar apa yang perlu diperbaiki untuk percubaan seterusnya.
🆘 Jika Tersekat (Bahagian 2)
Saya pernah cuba [nama framework] untuk orchestration tapi gagal.
Gejala: [terangkan apa berlaku]. Tolong bantu diagnosa punca yang
mungkin.
BAHAGIAN 3: Kenapa Saya Pilih BMad-Method
Selepas bandingkan semua 6 pilihan (Bahagian 1), ini sebab terperinci saya condong ke BMad-Method untuk siri ni:
- Tool-agnostic sepenuhnya — jalan dalam OpenCode (yang kita dah setup S02E01), tak perlu belajar TUI/tool baharu
- Markdown-native — agent ialah fail
.md, senang baca, senang edit sendiri kalau nak sesuaikan - Sesuai headless/server — tiada keperluan GUI, sempurna untuk aibox kita
- Tiada perlu Python — awak tak perlu belajar bahasa pengaturcaraan baharu untuk guna framework ni (walaupun projek akhir yang dihasilkan mungkin dalam Python/JS/dll)
- Expansion pack pelbagai domain — bukan cuma software engineering, ada pek khusus untuk pelbagai bidang lain
- Istilah "Orchestrator" — konsep jelas dinamakan dalam framework ni sendiri, memudahkan pemahaman peranan setiap "watak" AI
- Percuma & Open Source — sejajar falsafah keseluruhan siri ni
🎮 Cheat Code: Kalau satu sebab je nak diingat kenapa BMad —
"Ia jalan atas tool yang KITA DAH ADA (OpenCode), bukan perlukan ekosistem baharu."
🆘 Jika Tersekat (Bahagian 3)
Saya dah baca sebab pemilihan BMad-Method, tapi keperluan saya lain
sikit: [terangkan]. Tolong nilai adakah BMad tetap sesuai atau
framework lain lebih baik untuk saya.
BAHAGIAN 4: Konsep Penting — "Agent = Persona, Bukan Semestinya Model Berasingan"
Ini salah faham yang perlu dibetulkan sebelum kita masuk setup (Part 2) — ramai (termasuk saya sebelum ni) anggap "5 agent" bermakna "5 model AI berasingan" yang perlu load-guna-offload bergilir-gilir.
Realiti sebenar: Dalam kebanyakan framework macam BMad-Method, "agent" ialah persona/arahan (fail markdown yang describe peranan, tanggungjawab, gaya kerja) — BUKAN semestinya model AI fizikal berasingan.
Dua Pendekatan Berbeza
Pendekatan A (yang ramai risau/bayangkan): Model berbeza untuk setiap agent → perlukan load-offload berulang, berat untuk VRAM terhad
Load Model-27B (Architect) → guna → offload → Load Model-14B (Developer) → guna → offload...
Pendekatan B (yang sebenarnya kita akan guna): SATU model kuat, kekal loaded, tukar cuma system prompt/persona ikut "topeng" agent semasa
Load Model-27B SEKALI → jadi "Architect" (persona A) → jadi "Developer" (persona B) →
jadi "QA" (persona C) → ... [model SAMA kekal dalam VRAM sepanjang]
Pendekatan B elak sepenuhnya isu load-offload berulang yang membebankan aibox dengan VRAM terhad (16GB) — satu model kuat cukup untuk "berlakon" pelbagai peranan.
😄 Ini macam satu pelakon serba boleh berbanding kru penuh — sama ada Meryl Streep main watak berbeza dalam filem berbeza (satu "model", banyak "peranan"), berbanding perlu tukar pelakon setiap kali watak berubah. Lebih cekap, lebih murah untuk "produksi" kita.
🆘 Jika Tersekat (Bahagian 4)
Saya masih keliru macam mana "agent" berfungsi tanpa perlu model
berasingan. Tolong terangkan dengan contoh lebih mudah.
Penutup
Sekarang awak faham landskap penuh pilihan orchestration (6 framework, pros/cons masing-masing), sebab BMad-Method dipilih untuk siri ni, dan konsep kritikal yang akan buat setup kita berjaya (insyaAllah) di mana percubaan pertama saya gagal — "satu otak, banyak topeng", bukan "banyak otak, banyak beban VRAM".
Part 2 seterusnya — kita install dan setup BMad-Method sepenuhnya di AI Box, 100% local, sampai berjaya sesi pertama.
Artikel ini sebahagian dari Season 2, siri "Vibe Coding". Perbandingan framework berdasarkan dokumentasi rasmi dan pengalaman praktikal penulis.
Comments