Pengaturan

Bahasa

Membangun AI Agent dengan Berbagai Model: Panduan Arsitektur Praktis

T
TokenLab
ยท26 Februari 2026ยท9 menit bacaยทDiperbarui 14 Juli 2026ยท1315 tampilan
#agen AI#multi model#arsitektur#tutorial#langchain
Membangun AI Agent dengan Berbagai Model: Panduan Arsitektur Praktis

Kebanyakan AI agent mengandalkan satu model untuk menangani setiap fase eksekusi. Langkah perencanaan, pemanggilan tool, ekstraksi data, peringkasan, dan pemulihan kesalahan semuanya dijalankan melalui LLM yang sama. Meskipun pendekatan ini mudah untuk prototipe awal, hal ini menimbulkan inefisiensi yang signifikan di lingkungan produksi.

Langkah perencanaan yang memerlukan penalaran mendalam tidak membutuhkan model yang sama dengan langkah ekstraksi JSON dasar. Tugas pembuatan kode memiliki kebutuhan yang berbeda dibandingkan tugas klasifikasi. Menggunakan model penalaran tingkat tinggi seperti Claude Fable 5 atau Claude Opus 4.8 untuk memformat string tanggal adalah pemborosan sumber daya yang mahal.

Membangun AI agent dengan berbagai model memungkinkan Anda untuk mengarahkan setiap langkah alur kerja ke model yang paling sesuai untuk tugas spesifik tersebut. Panduan ini membahas cara merancang, mengimplementasikan, dan mengelola arsitektur multi-model ini.

Jika Anda bekerja pada lapisan API alih-alih lapisan orkestrasi agent, silakan merujuk ke Agent-First API Design dan Why Teams Switch from Direct Model APIs to a Unified AI API bersama dengan panduan ini. Agent multi-model beroperasi paling andal ketika permukaan API yang mendasarinya cukup stabil untuk menukar model tanpa menulis ulang kode orkestrasi.

:::info

Poin Utama

  1. Sesuaikan Model dengan Kompleksitas Tugas: Gunakan model yang kecil dan cepat untuk perutean, ekstraksi, dan pemformatan, serta cadangkan model penalaran yang lebih besar untuk perencanaan dan analisis kompleks.
  2. Standardisasi Skema: Terapkan validasi output yang ketat (seperti Pydantic) pada setiap serah terima untuk mencegah pergeseran kontrak (contract drift) saat berpindah antar penyedia model yang berbeda.
  3. Rancang untuk Fallback: Bangun jalur fallback otomatis untuk menangani limit rate, pemadaman penyedia, atau lonjakan latensi tanpa mengganggu alur kerja agent.
  4. Sentralisasi Telemetri: Lacak latensi, jumlah token input/output, dan biaya per langkah untuk terus mengoptimalkan logika perutean Anda. :::

Arsitektur AI Agent Multi-Model

Arsitektur agent multi-model mendistribusikan tugas ke berbagai model khusus berdasarkan kebutuhan kompleksitas, biaya, dan latensi.

Permintaan Pengguna
    โ”‚
    โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚   Router     โ”‚  โ† Mengklasifikasikan kompleksitas tugas
โ”‚ (model cepat)โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”˜
       โ”‚
   โ”Œโ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”
   โ–ผ       โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ” โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚Model  โ”‚ โ”‚Model  โ”‚
โ”‚Sederhanaโ”‚ โ”‚Kompleksโ”‚
โ””โ”€โ”€โ”ฌโ”€โ”€โ”€โ”˜ โ””โ”€โ”€โ”ฌโ”€โ”€โ”€โ”˜
   โ”‚        โ”‚
   โ–ผ        โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  Aggregator  โ”‚  โ† Menggabungkan hasil
โ”‚ (model cepat)โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

Arsitektur inti terdiri dari lima komponen utama:

  1. Router: Model yang cepat dan berbiaya rendah yang mengklasifikasikan tugas masuk berdasarkan kompleksitas dan tujuan.
  2. Kumpulan Model (Model Pool): Koleksi model yang disesuaikan dengan berbagai jenis tugas (seperti penalaran, ekstraksi, atau pembuatan kode).
  3. Aggregator: Model cepat yang menggabungkan hasil dari langkah-langkah paralel menjadi respons akhir.
  4. Kebijakan Fallback: Aturan yang menentukan model mana yang akan digunakan jika pilihan utama gagal, mengalami timeout, atau mencapai limit rate.
  5. Lapisan Telemetri: Sistem logging yang mencatat pilihan model, latensi, dan biaya token yang tepat per langkah.

Tanpa kebijakan fallback dan telemetri, agent multi-model bisa menjadi sulit untuk di-debug, dengan profil latensi dan biaya yang tidak dapat diprediksi.


Implementasi dengan OpenAI SDK

Menggunakan gateway API terpadu memungkinkan Anda mengakses model dari berbagai penyedia menggunakan satu SDK dan kunci API. Ini menyederhanakan pertukaran dan perutean model.

Contoh berikut menunjukkan implementasi perutean dasar. Ketersediaan dan harga model harus diverifikasi di direktori model TokenLab.

from openai import OpenAI

client = OpenAI(
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

# Kumpulan model dengan tingkat biaya dan kemampuan
MODELS = {
    "router": "deepseek-v4-flash",        # Klasifikasi cepat
    "simple": "deepseek-v4-flash",        # Ekstraksi, pemformatan
    "reasoning": "claude-sonnet-5",       # Perencanaan, analisis
    "complex": "gpt-5.5",                 # Pembuatan kode, logika kompleks
    "budget": "deepseek-v4-flash",        # Pemrosesan massal
}

def route_task(task: str) -> str:
    """Gunakan model berbiaya rendah untuk mengklasifikasikan kompleksitas tugas."""
    response = client.chat.completions.create(
        model=MODELS["router"],
        messages=[
            {"role": "system", "content": """Klasifikasikan tugas ini ke dalam satu kategori:
- simple: ekstraksi data, pemformatan, terjemahan
- reasoning: analisis, perencanaan, perbandingan
- complex: pembuatan kode, pemecahan masalah multi-langkah
- budget: pemrosesan massal, tugas tidak kritis
Balas hanya dengan nama kategori dalam huruf kecil."""},
            {"role": "user", "content": task}
        ],
        max_tokens=10
    )
    category = response.choices[0].message.content.strip().lower()
    return MODELS.get(category, MODELS["simple"])

def execute_task(task: str, context: str = "") -> str:
    """Arahkan tugas ke model yang dipilih dan eksekusi."""
    model = route_task(task)
    messages = []
    if context:
        messages.append({"role": "system", "content": context})
    messages.append({"role": "user", "content": task})

    response = client.chat.completions.create(
        model=model,
        messages=messages
    )
    return response.choices[0].message.content

Agent Dunia Nyata: Pipeline Peninjauan Kode

Untuk melihat dampak praktis dari membangun AI agent dengan berbagai model, pertimbangkan pipeline yang dirancang untuk meninjau pull request. Alur kerja ini memecah peninjauan menjadi langkah-langkah khusus alih-alih mengirimkan seluruh diff kode ke satu model yang mahal.

def review_pr(diff: str) -> dict:
    """Pipeline peninjauan PR multi-model."""

    # Langkah 1: Klasifikasikan perubahan menggunakan model cepat dan murah
    classification = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{
            "role": "user",
            "content": f"Klasifikasikan perubahan kode ini: {diff[:2000]}\n"
                       "Kategori: bugfix, feature, refactor, docs, test"
        }],
        max_tokens=20
    ).choices[0].message.content

    # Langkah 2: Lakukan pemindaian keamanan menggunakan model penalaran yang kuat
    security = client.chat.completions.create(
        model="claude-sonnet-5",
        messages=[{
            "role": "system",
            "content": "Anda adalah peninjau keamanan. Periksa: "
                       "SQL injection, XSS, auth bypass, rahasia dalam kode, "
                       "deserialisasi tidak aman. Spesifik mengenai nomor baris."
        }, {
            "role": "user",
            "content": f"Tinjau diff ini untuk masalah keamanan:\n{diff}"
        }]
    ).choices[0].message.content

    # Langkah 3: Analisis kualitas kode menggunakan model tujuan umum
    quality = client.chat.completions.create(
        model="gpt-5.5",
        messages=[{
            "role": "user",
            "content": f"Tinjau kualitas kode: penamaan, struktur, "
                       f"penanganan kesalahan, cakupan pengujian.\n{diff}"
        }]
    ).choices[0].message.content

    # Langkah 4: Hasilkan ringkasan menggunakan model cepat dan murah
    summary = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{
            "role": "user",
            "content": f"Ringkas peninjauan PR ini dalam 3 poin:\n"
                       f"Tipe: {classification}\n"
                       f"Keamanan: {security[:500]}\n"
                       f"Kualitas: {quality[:500]}"
        }]
    ).choices[0].message.content

    return {
        "classification": classification,
        "security": security,
        "quality": quality,
        "summary": summary
    }

Optimasi Biaya dan Efisiensi

Tabel di bawah ini menguraikan alokasi model untuk pipeline ini. Harga tepat bervariasi tergantung penyedia dan volume; verifikasi tarif saat ini di direktori model TokenLab.

Langkah Model Token Input Peran / Spesialisasi
1. Klasifikasi DeepSeek V4 Flash ~2.100 Klasifikasi cepat, perutean murah
2. Keamanan Claude Sonnet 5 ~2.500 Penalaran mendalam, analisis keamanan
3. Kualitas GPT-5.5 ~2.500 Kualitas kode tingkat lanjut dan tinjauan struktural
4. Ringkasan DeepSeek V4 Flash ~1.200 Agregasi teks cepat dan murah

Menjalankan keempat langkah melalui model penalaran unggulan seperti Claude Sonnet 5 atau GPT-5.5 akan meningkatkan biaya secara signifikan. Dengan mengarahkan tugas yang lebih sederhana ke model berbiaya lebih rendah seperti DeepSeek V4 Flash, pipeline multi-model mengurangi pengeluaran token secara keseluruhan sambil tetap mempertahankan penalaran mendalam untuk langkah analisis keamanan yang kritis.


Perutean berdasarkan Kemampuan, Bukan Hanya Harga

Meskipun pengurangan biaya adalah tujuan umum, keputusan perutean juga harus memperhitungkan kemampuan model tertentu. Kebijakan perutean yang kuat mengevaluasi model berdasarkan empat dimensi utama:

  • Kedalaman Penalaran: Logika kompleks, perencanaan, dan deduksi multi-langkah.
  • Jendela Konteks (Context Window): Volume informasi latar belakang atau kode yang diperlukan untuk tugas tersebut.
  • Keandalan Penggunaan Tool: Akurasi pemanggilan fungsi dan pembuatan output terstruktur.
  • Sensitivitas Latensi: Persyaratan kecepatan aplikasi yang dihadapi pengguna.

Dimensi ini membantu menetapkan aturan perutean yang jelas:

  • Tugas dekomposisi dan perencanaan diarahkan ke model yang berat dalam penalaran.
  • Tugas ekstraksi dan pemformatan data diarahkan ke model yang cepat dan berbiaya rendah.
  • Pembuatan kode dan analisis sintaksis diarahkan ke model yang dioptimalkan untuk tugas pengkodean.
  • Tugas analisis seluruh repositori diarahkan ke model dengan jendela konteks besar.

Untuk menyelaraskan router Anda dengan persyaratan ini, konsultasikan perbandingan model pengkodean dan perbandingan harga untuk mencocokkan langkah alur kerja Anda dengan benchmark model saat ini.


Integrasi LangChain

Anda juga dapat mengimplementasikan perutean multi-model dalam kerangka kerja orkestrasi seperti LangChain. Contoh berikut mengonfigurasi model yang berbeda menggunakan URL dasar API terpadu:

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate

# Inisialisasi model dengan konfigurasi berbeda
fast_model = ChatOpenAI(
    model="deepseek-v4-flash",
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

reasoning_model = ChatOpenAI(
    model="claude-sonnet-5",
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

# Tentukan rantai khusus
classify_chain = ChatPromptTemplate.from_template(
    "Klasifikasikan tujuan dari permintaan ini: {input}"
) | fast_model

analyze_chain = ChatPromptTemplate.from_template(
    "Lakukan analisis mendetail terhadap masalah ini: {input}"
) | reasoning_model

Kapan Menggunakan AI Agent Multi-Model

Memperkenalkan beberapa model menambah kompleksitas arsitektur. Pendekatan ini biasanya paling bermanfaat ketika:

  • Persyaratan Tugas Beragam: Agent menangani campuran tugas sederhana (seperti klasifikasi atau pemformatan) dan tugas kompleks (seperti perencanaan strategis atau pembuatan kode).
  • Volume dan Biaya Tinggi: Pengeluaran API bulanan cukup tinggi sehingga optimasi menghasilkan penghematan yang berarti.
  • Kekuatan Model Khusus: Alur kerja mendapat manfaat dari kekuatan penyedia tertentu, seperti jendela konteks Gemini, kemampuan pengkodean Claude, atau kecepatan penggunaan tool GPT.
  • Kebutuhan Latensi Asimetris: Bagian tertentu dari alur kerja harus mengembalikan hasil secara instan, sementara langkah latar belakang lainnya bisa memakan waktu lebih lama.

Untuk agent tujuan tunggal atau antarmuka obrolan sederhana, satu model seringkali lebih mudah dipelihara. Overhead operasional perutean mungkin tidak dibenarkan jika setiap permintaan memerlukan tingkat kemampuan yang sama.


Mode Kegagalan Umum

Arsitektur multi-model memperkenalkan mode kegagalan spesifik yang memerlukan mitigasi:

1. Router yang Terlalu Rumit

Jika prompt router menjadi terlalu kompleks, langkah klasifikasi itu sendiri bisa menjadi lambat dan mahal. Jaga agar prompt perutean tetap ringkas dan kategori klasifikasi tetap luas.

2. Pergeseran Kontrak Output (Output Contract Drift)

Model yang berbeda mungkin memformat output secara berbeda, bahkan ketika diinstruksikan untuk mengembalikan JSON. Satu model mungkin mengembalikan JSON mentah, sementara yang lain membungkusnya dalam blok markdown. Untuk mencegah kegagalan parser hilir, terapkan skema ketat menggunakan pustaka validasi seperti Pydantic pada setiap serah terima langkah.

3. Penurunan Kualitas Senyap

Jika kebijakan fallback mengarahkan permintaan ke model tingkat bawah selama pemadaman penyedia utama, agent mungkin mengembalikan jawaban berkualitas lebih rendah tanpa memunculkan kesalahan. Menerapkan strategi pembatasan rate yang jelas dan sistem peringatan membantu melacak kapan fallback aktif.

4. Telemetri Terfragmentasi

Ketika penggunaan model dibagi di beberapa API penyedia langsung, menggabungkan metrik biaya dan kinerja menjadi sulit. Memusatkan permintaan melalui satu gateway menyederhanakan logging dan pelacakan biaya.


Loop Evaluasi Minimal

Untuk memelihara agent multi-model, buat loop evaluasi dasar untuk melacak kinerja. Anda dapat mencatat metrik berikut untuk setiap eksekusi ke tabel database:

  • Kategori Tugas: Klasifikasi yang ditetapkan oleh router.
  • Model yang Dipilih: Model yang dipilih untuk setiap langkah.
  • Latensi Langkah: Waktu yang diperlukan untuk menyelesaikan setiap langkah.
  • Penggunaan Token: Jumlah token input dan output yang tepat.
  • Status Fallback: Apakah model fallback dipicu.
  • Umpan Balik Pengguna: Indikator biner apakah output akhir berhasil.

Menganalisis data ini membantu menentukan apakah router memilih model yang benar, langkah mana yang mendorong sebagian besar biaya Anda, dan apakah model fallback mempertahankan kualitas yang dapat diterima.


FAQ

Bagaimana Anda menangani format prompt yang berbeda di berbagai model?

Model yang berbeda merespons paling baik terhadap struktur prompt yang berbeda. Misalnya, beberapa model berkinerja lebih baik dengan prompt sistem, sementara yang lain lebih menyukai instruksi yang disematkan dalam prompt pengguna. Untuk menangani ini, abstrakkan prompt Anda ke dalam template yang beradaptasi berdasarkan model target, alih-alih mengirim string mentah yang identik ke setiap model di kumpulan Anda.

Apakah perutean menambah terlalu banyak latensi pada aplikasi yang dihadapi pengguna?

Perutean memang memperkenalkan sedikit latensi untuk langkah klasifikasi. Anda dapat meminimalkan ini dengan menggunakan model latensi rendah yang sangat dioptimalkan untuk router, menjaga batas token maksimum tetap rendah (di bawah 10 token), atau memparalelkan langkah-langkah ketika klasifikasi dapat disimpulkan dari status aplikasi atau titik masuk pengguna.

Bagaimana Anda mencegah kesalahan parsing JSON saat berpindah antar model?

Untuk mencegah kesalahan parsing, gunakan fitur output terstruktur (seperti mode JSON atau pemanggilan tool) yang didukung oleh penyedia model. Selain itu, bungkus semua output model dalam lapisan validasi menggunakan Pydantic atau pustaka serupa untuk mengurai, memvalidasi, dan memperbaiki payload sebelum meneruskannya ke langkah berikutnya dalam pipeline Anda.


Akses setiap model melalui satu API: Mulai dengan TokenLab untuk mengakses lebih dari 300 model dengan satu kunci API. Bangun agent multi-model tanpa mengelola banyak akun penyedia atau menulis ulang logika perutean untuk API yang berbeda.

Sumber

Harga diamati pada 2026-07-07

Bagikan:

Model terkait

Model publik terbaru

Bangun dengan model dalam panduan ini

Bandingkan harga, uji rute, dan ubah riset menjadi panggilan API yang berjalan.