Multi-Agent Swarm di Terminal: Membagi Tugas Planning, Coding, dan Review ke 3 Agen Terpisah

Ada satu ilusi yang sering menjebak developer saat pertama kali mengintegrasikan Large Language Model (LLM) ke dalam alur kerja rekayasa perangkat lunak: asumsi bahwa satu model serba-bisa sanggup menyelesaikan seluruh siklus hidup software engineering dalam satu tarikan napas.

Kita menaruh stack trace eror sepanjang 80 baris ke dalam satu prompt, lalu meminta model tersebut untuk menganalisis akar masalah, menulis perbaikan kode, memperbarui unit test, dan sekaligus memastikan tidak ada regresi performa. Hasilnya hampir selalu sama: kode yang tampak meyakinkan di permukaan, tetapi rapuh saat menyentuh edge case, atau lebih buruk lagi, halusinasi logika yang tersembunyi rapi di balik sintaksis yang bersih.

Masalah ini bukan terletak pada kecerdasan model, melainkan pada distribusi beban kognitif.

Dalam dunia nyata, kita tidak pernah meminta seorang arsitek bangunan untuk mengaduk semen, memasang bata, lalu memeriksa kepatuhan standar keselamatan kerjanya sendiri dalam waktu bersamaan. Kita memisahkan peran tersebut karena objektivitas dan kedalaman fokus membutuhkan batas konteks (context boundary) yang tegas.

Prinsip yang sama berlaku mutlak pada rekayasa kecerdasan artifisial. Ketika kita memecah satu tugas besar ke dalam kawanan agen (agent swarm) di terminal—di mana masing-masing agen memiliki satu fungsi spesifik, model yang dioptimasi untuk tugas tersebut, dan ruang memori yang terisolasi—efektivitas debugging dan pembuatan patch meningkat secara eksponensial.

Mari kita bedah cara membangun orkestrasi terminal multi-agen minimalis namun tangguh menggunakan filosofi Unix: do one thing and do it well, dengan menghubungkan tiga agen terpisah melalui antarmuka baris perintah (CLI).

Anatomi Kerusakan: Mengapa Agen Monolitik Kerap Gagal

Saat sebuah LLM dipaksa menjalankan peran ganda dalam satu konteks sesi percakapan, terjadi fenomena yang disebut attention dilution (pelebaran atensi). Model harus membagi bobot probabilitas tokennya antara memahami logika bisnis tingkat tinggi (planning), mengingat detail sintaksis bahasa (coding), dan bersikap skeptis terhadap hasil kerjanya sendiri (reviewing).

Secara psikologis—jika kita boleh meminjam istilah tersebut untuk LLM—sebuah model memiliki bias konfirmasi yang kuat terhadap token yang baru saja ia hasilkan. Jika Model A menulis sebuah fungsi rekursif yang rawan stack overflow, meminta Model A yang sama untuk mereviu fungsi tersebut dalam prompt lanjutan sering kali menghasilkan jawaban: "Kode sudah optimal dan aman."

Pendekatan Monolitik(Rawan Halusinasi & Bias):
[Input Bug] ───> [ LLM Tunggal: Planner + Coder + Reviewer ] ───> [Output Kode Rapuh]

Pendekatan Swarm Terisolasi(Unix Philosophy):
[Input Bug] ───> [ Agen 1: Planner ]
                        │ (Spesifikasi Teknis & Root Cause)
                        ▼
                 [ Agen 2: Coder ]
                        │ (Diff Patch & Unit Test)
                        ▼
                 [ Agen 3: Reviewer/Tester ] ───> [Pass / Feedback Loop]

Solusinya adalah memutus rantai bias ini dengan membagi tanggung jawab ke dalam tiga entitas otonom:

1. Agen 1 (The Triage & Planner): Bertanggung jawab membedah stack trace, membaca struktur repositori, dan menghasilkan diagnosis akar masalah beserta spesifikasi perbaikan tanpa menulis kode implementasi final.
2. Agen 2 (The Craftsman / Coder): Bertanggung jawab murni mengonversi spesifikasi dari Agen 1 menjadi perubahan kode (git diff) yang presisi dan minim side-effect.
3. Agen 3 (The Skeptic / Sanity Reviewer): Bertanggung jawab mengevaluasi patch, menjalankan mock test, mencari celah keamanan atau regresi logika, dan memutuskan apakah kode layak di-merger atau harus dikembalikan ke Agen 2 dengan catatan revisi.

Matriks Perbandingan: Tiga Paradigma Otomasi Koding

Sebelum masuk ke implementasi skrip, mari kita bandingkan tiga pendekatan orkestrasi kode berbasis AI yang umum digunakan saat ini:

Menyiapkan Infrastruktur: Satu Pintu untuk Beragam Model

Tantangan teknis terbesar dalam membangun swarm multi-agen adalah fragmentasi API. Agen Planner mungkin bekerja paling optimal menggunakan model penalaran murni seperti DeepSeek-R1 atau Claude 3.5 Sonnet. Agen Coder membutuhkan model dengan pemahaman sintaksis tajam seperti Claude 3.5 Sonnet atau Qwen 2.5 Coder. Sementara Agen Reviewer membutuhkan model yang cepat dan tajam dalam analisis statis seperti GPT-4o.

Mengelola tiga SDK berbeda, tiga kartu kredit terpisah, dan tiga format rate limit yang tidak seragam adalah mimpi buruk pemeliharaan skrip terminal.

Di sinilah peran agregator cerdas menjadi krusial. Melalui ekosistem AiStudio.id API Gateway, kita dapat mengakses berbagai foundation model tier tertinggi (mulai dari OpenAI, Anthropic, DeepSeek, hingga Meta Llama) menggunakan satu API Key tunggal dengan format protokol yang kompatibel secara standar dengan SDK OpenAI.

Ini menyederhanakan kode orkestrasi kita secara drastis: satu klien HTTP, satu tagihan saldo berbasis Rupiah, dan fleksibilitas penuh untuk menukar model pada tiap agen hanya dengan mengubah string parameter model.

Langkah Praktis: Membangun Terminal Swarm 3 Agen

Mari kita bangun skrip orkestrasi terminal independen bernama swarm.py. Skrip ini akan menerima laporan bug atau deskripsi fitur, lalu mengalirkannya melalui tiga agen dengan batasan kontrak data yang ketat.

1. Struktur Lingkungan Kerja

Pastikan Python 3.10+ terpasang, lalu instal dependensi minimal yang kita butuhkan:

pip install openai rich pydantic

Buat file konfigurasi lingkungan .env atau set variabel lingkungan terminal Anda:

export AISTUDIO_API_KEY="sk-aistudio-xxxxxx-token-anda"
export AISTUDIO_BASE_URL="https://api.aistudio.id/v1"

2. Implementasi Kode Orkestrator (swarm.py)

Berikut skrip lengkap berbobot produksi yang mengorkestrasi alur Planner -> Coder -> Reviewer dengan umpan balik otomatis (loop feedback jika review gagal):

#!/usr/bin/env python3
import os
import sys
import json
from typing import Dict, Any
from openai import OpenAI
from rich.console import Console
from rich.panel import Panel
from rich.syntax import Syntax
from rich.markdown import Markdown

console = Console()

# Inisialisasi Klien via AiStudio.id API Gateway
client = OpenAI(
    api_key=os.getenv("AISTUDIO_API_KEY"),
    base_url=os.getenv("AISTUDIO_BASE_URL", "https://api.aistudio.id/v1")
)

# Konfigurasi Model per Agen (Disesuaikan dengan keunggulan masing-masing)
MODEL_PLANNER = "deepseek-r1"         # Kuat dalam reasoning logis & diagnosa
MODEL_CODER   = "claude-3-5-sonnet"   # Presisi tinggi dalam sintaks & refactoring
MODEL_REVIEW  = "gpt-4o"              # Objektif, cepat, tajam dalam analisis edge case

def call_agent(model: str, system_prompt: str, user_prompt: str) -> str:
    """Helper standar untuk mengeksekusi inferensi agen."""
    try:
        response = client.chat.completions.create(
            model=model,
            messages=[
                {"role": "system", "content": system_prompt},
                {"role": "user", "content": user_prompt}
            ],
            temperature=0.2, # Rendah untuk determinisme & konsistensi logika
        )
        return response.choices[0].message.content.strip()
    except Exception as e:
        console.print(f"[bold red]Gagal memanggil model {model}:[/bold red] {str(e)}")
        sys.exit(1)

# ==========================================
# DEFINISI AGEN & KONTRAK SISTEM
# ==========================================

SYSTEM_PLANNER = """
Anda adalah Agen 1: Lead Technical Architect & Bug Triage Specialist.
Tugas Anda: Menerima laporan bug/kode bermasalah, menganalisis akar masalah secara mendalam, dan merumuskan rencana perbaikan teknis.
Aturan:
1. JANGAN menulis implementasi kode final.
2. Keluarkan analisis dengan format:
   - ROOT CAUSE: Penjelasan akar masalah teknis.
   - ARCHITECTURAL IMPACT: Dampak terhadap bagian sistem lain.
   - SPECIFICATION FOR CODER: Langkah-langkah instruktif presisi yang harus dieksekusi Agen 2.
"""

SYSTEM_CODER = """
Anda adalah Agen 2: Senior Core Software Engineer.
Tugas Anda: Menerima spesifikasi dari Agen 1 dan kode asli, lalu menulis kode perbaikan yang bersih, teruji, dan sesuai standar industri.
Aturan:
1. Tulis kode perbaikan lengkap atau git diff yang jelas.
2. Buat minimal satu unit test/sanity test sederhana untuk memverifikasi perbaikan tersebut.
3. Berikan penjelasan singkat mengenai perubahan yang dilakukan.
"""

SYSTEM_REVIEWER = """
Anda adalah Agen 3: Staff Security & QA Reviewer.
Tugas Anda: Memeriksa kode perbaikan dari Agen 2 secara skeptis terhadap spesifikasi Agen 1.
Aturan:
1. Evaluasi potensi regresi, kebocoran memori, celah keamanan, dan kesesuaian logika.
2. Anda WAJIB memberikan putusan di baris pertama respon dengan tepat salah satu dari format berikut:
   VERDICT: APPROVED
   atau
   VERDICT: REJECTED
3. Jika REJECTED, berikan daftar komprehensif apa yang harus diperbaiki kembali oleh Agen 2.
4. Jika APPROVED, berikan ringkasan validasi sanity test.
"""

# ==========================================
# PIPELINE EKSEKUSI ORKESTRASI
# ==========================================

def run_swarm(bug_report: str, source_code: str, max_iterations: int = 2):
    console.print(Panel.fit("[bold cyan]Memulai Multi-Agent Terminal Swarm[/bold cyan]\nEngine: AiStudio.id API Gateway", border_style="cyan"))

    # FASE 1: Planning & Diagnosis
    with console.status("[bold yellow]Agen 1 (Planner) sedang menganalisis arsitektur & akar masalah...", spinner="dots"):
        planner_input = f"SOURCE CODE:\n

\n{source_code}\n``\n\nISSUE REPORT:\n{bug_report}"
plan_output = call_agent(MODEL_PLANNER, SYSTEM_PLANNER, planner_input)

# FASE 2: Coding & Patching
with console.status(f"[bold green]Agen 2 (Coder) sedang memproduksi patch & unit test (Iterasi {iteration})...", spinner="dots"):
coder_input = f"ORIGINAL CODE:\n`\n{source_code}\n`\n\nSPECIFICATION FROM PLANNER:\n{plan_output}"
if feedback:
coder_input += f"\n\nFEEDBACK FROM REVIEWER (PERBAIKI INI):\n{feedback}"

current_patch = call_agent(MODEL_CODER, SYSTEM_CODER, coder_input)

---

## Membedah Mekanisme Kerja: Aliran Sinyal dan Kontrak Data

Mengapa skrip sederhana di atas jauh lebih superior daripada satu sesi percakapan panjang di antarmuka web? Kuncinya ada pada tiga faktor arsitektural:

### 1. Isolasi Tanggung Jawab Melalui Kontrak Prompt
Perhatikan bagaimana Agen 1 diinstruksikan secara eksplisit: *“JANGAN menulis implementasi kode final”*. 

Aturan ini krusial. Begitu model penalaran mulai menulis kode sintaksis, sebagian kapasitas komputasinya beralih dari memahami gambaran besar sistem ke detail tokenisasi sintaks bahasa(misalnya kurung kurawal atau indentasi). Dengan membatasi Planner hanya untuk menghasilkan teks spesifikasi terstruktur, output yang dihasilkan menjadi panduan presisi bagi Agen 2.

### 2. Evaluasi Buta (*Blind Evaluation*) oleh Reviewer
Agen 3 tidak ikut merancang rencana perbaikan. Ia hanya menerima dua input: dokumen spesifikasi awal dari Planner dan hasil kode yang dibuat Coder. 

Pendekatan ini mirip dengan *double-blind code review* di tim *engineering* kelas dunia. Agen 3 bertindak seperti penguji independen yang tidak memiliki ikatan emosional terhadap keputusan baris kode yang ditulis Agen 2. Jika Agen 2 melupakan penanganan *exception* saat memutus *stream socket*, Agen 3 akan langsung menangkapnya dan menolak(*REJECTED*) patch tersebut.

### 3. Otomasi Feedback Loop
Ketika Agen 3 menolak patch, alur tidak berhenti. Skrip secara otomatis menyuntikkan catatan review dari Agen 3 kembali ke Agen 2 pada iterasi berikutnya. Agen 2 membaca apa saja kekurangan kodenya, memperbaikinya, dan menyerahkannya kembali ke Agen 3. Seluruh proses ini berjalan dalam hitungan detik di jendela terminal Anda tanpa perlu intervensi manual klik tombol copy-paste.

---

## Optimalisasi Biaya & Performa Token di Level Praktisi

Mengoperasikan tiga agen LLM untuk setiap masalah kode tentu memunculkan pertanyaan pragmatis: *Berapa biaya komputasi token yang dihabiskan?*

Jika Anda memanggil model *frontier* berbobot penuh untuk seluruh proses tanpa pertimbangan, biaya penggunaan token API akan membengkak cepat. Di sinilah kepiawaian merancang strategi *token routing* diuji.

Berikut tabel acuan strategi perutean model berbasis tugas yang paling efisien dari segi rasio harga terhadap performa:

| Peran Agen | Rekomendasi Model Utama via AiStudio.id | Alternatif Ringan / Hemat | Fokus Beban Kerja |
| :--- | :--- | :--- | :--- |
| **Agen 1: Planner** | `deepseek-r1` / `o3-mini` | `claude-3-5-haiku` | Penalaran logika rantai kejadian(*Chain-of-Thought*). |
| **Agen 2: Coder** | `claude-3-5-sonnet` | `qwen-2.5-coder-32b` | Ketepatan sintaksis, idiomatisasi bahasa, pembuatan unit test. |
| **Agen 3: Reviewer** | `gpt-4o` | `gpt-4o-mini` / `deepseek-v3` | Validasi audit statis, penemuan celah keamanan, verifikasi kontrak logika. |

Dengan menggunakan **AiStudio.id API Gateway**, pengembang di Indonesia mendapatkan keuntungan strategis berupa kemudahan beralih(*hot-swapping*) antar model-model di atas tanpa perlu menulis ulang adaptor klien SDK. Cukup ubah nilai variabel konstan di bagian atas file skrip Anda, dan arsitektur kawanan agen Anda langsung menyesuaikan diri dengan profil latensi atau anggaran yang ditargetkan.

---

## Praktik Terbaik Menjalankan Terminal Swarm di Repositori Nyata

Jika Anda ingin mengintegrasikan skrip ini ke dalam alur kerja harian tim(*daily workflow*), berikut beberapa pola praktis yang dapat diterapkan:

### 1. Parsing Langsung dari Git Staging
Alih-alih menaruh kode statis di dalam variabel string Python, modifikasi skrip agar mampu membaca diff aktif langsung dari repositori lokal Anda:

### 2. Batasi Loop Iterasi Maksimal
Selalu tetapkan ambang batas perulangan(`max_iterations = 2` atau `3`). Jika dua model saling berdebat lebih dari tiga kali mengenai pendekatan logika tertentu, intervensi manusia hampir pasti dibutuhkan untuk menentukan arah arsitektur yang diinginkan.

### 3. Format Output JSON Terstruktur untuk CI/CD
Jika ingin mengintegrasikan pipeline ini ke GitHub Actions atau GitLab CI, ubah sistem prompt Agen 3 untuk mengembalikan payload JSON valid:

json
{
"verdict": "APPROVED",
"confidence_score": 0.95,
"detected_risks": [],
"performance_impact": "O(1) memory cleanup overhead"
}
`

Hal ini memungkinkan skrip otomatis Anda untuk memblokir proses merge pull request jika nilai verdict bernilai REJECTED`.

Menatap Masa Depan Orkestrasi Kode

Pergeseran mendasar sedang terjadi dalam cara kita memandang pembuatan perangkat lunak. Nilai seorang engineer tidak lagi diukur dari seberapa cepat jari-jemarinya mengetik sintaksis boilerplate di editor teks, melainkan dari seberapa terstruktur ia merumuskan domain masalah, mendefinisikan batasan sistem, dan mengorkestrasi agen-agen cerdas untuk menyelesaikan masalah tersebut secara deterministik.

Membagi tugas kognitif ke dalam agen-agen terpisah yang bekerja harmonis di terminal bukan sekadar trik produktivitas. Ini adalah cara paling masuk akal untuk menjaga kualitas rekayasa perangkat lunak tetap berada pada standar tertinggi di tengah derasnya otomatisasi AI.

Terminal komputer kita tidak pernah mati; ia hanya berevolusi dari sekadar penerjemah perintah biner menjadi ruang konduktor orkestra kecerdasan artifisial. Dan dengan fondasi infrastruktur routing API yang solid serta desain peran agen yang presisi, tongkat kendali itu berada sepenuhnya di tangan Anda.

Catatan Penulis

> Sandra menulis seputar rekayasa prompt, efisiensi arsitektur AI, dan produk digital di AiStudio.id.