Analisis Arsitektur Dua Lapis Router + Worker: 4 Desain Utama di Balik Pandangan DeepSeek bahwa Agen AI Tidak Seharusnya Hanya Memiliki Satu Sesi

Catatan penulis: Artikel ini membahas arsitektur dua lapis Router + Worker pada DeepSeek Super-agent, cara arsitektur tersebut memisahkan koordinasi global dari eksekusi mandiri, dan kapan developer perlu mempertimbangkan desain serupa untuk sistem Agent mereka.

Kalau kamu membuka empat atau lima jendela Coding Agent sekaligus, ada masalah praktis yang pasti muncul. Satu jendela sedang memperbaiki bug login, satu lagi meninjau migrasi database, sementara yang lain menunggu hasil CI. Kamu harus mengingat apa yang dikerjakan tiap jendela, mana yang menunggu responsmu, dan tugas mana saja yang saling berkaitan. Model memang makin mampu bekerja secara mandiri, tetapi beban mengelola semua sesi itu tetap berada di tangan manusia.

Pada 31 Oktober 2026, tim DeepSeek Harness menerbitkan artikel teknis “Eksplorasi Desain Super-agent: Menuju Sistem Agent yang Lebih Mandiri”, sekaligus merilis prototipe riset dsh-superagent-prototype sebagai proyek sumber terbuka dengan lisensi MIT. Desain utamanya adalah arsitektur dua lapis Router + Worker: satu Router yang selalu aktif menangani koordinasi global, sementara beberapa Worker yang terisolasi menjalankan tugas-tugas spesifik.

Ini bukan sekadar gimik untuk “membuat satu AI melakukan lebih banyak hal sekaligus”. Fokus Super-agent adalah memisahkan koordinasi global dari eksekusi mandiri melalui arsitektur sistem, sehingga beban manusia dalam mengelola banyak sesi berkurang. Artikel ini menguraikan motivasi desain, mekanisme utama, data eksperimen resmi, serta pelajaran untuk pemanggilan API dan pengelolaan biaya, dengan urutan “masalah—mekanisme—bukti—nilai rekayasa”.

Manfaat utama: Setelah membaca artikel ini, kamu akan memahami masalah yang sebenarnya diselesaikan oleh arsitektur dua lapis Router + Worker dan bisa menilai kapan sistem Agent milikmu layak menggunakan desain serupa.

Ringkasan Informasi Utama Router + Worker

Sebelum mendalami arsitekturnya, mari samakan dulu pemahaman tentang rilis ini. Perlu ditekankan: yang dibuka sebagai proyek sumber terbuka oleh DeepSeek adalah prototipe riset, bukan produk komersial resmi atau model fondasi baru.

DeepSeek menetapkan empat karakteristik sebagai target untuk Super-agent: Continuous (konteks berkelanjutan lintas kanal), Productive (menjalankan banyak tugas secara paralel), Proactive (merespons peristiwa secara proaktif dalam batas kewenangan), dan Persistent (terus aktif serta dapat pulih dari sebagian gangguan). Ini adalah target desain, bukan berarti semuanya sudah terwujud dalam prototipe sumber terbuka tersebut.

Mengapa AI Agent Tidak Sebaiknya Hanya Memiliki Satu Session

Menurut tim DeepSeek, hambatan utama pada alat pemrograman AI mulai bergeser dari “kemampuan model” ke “perhatian manusia”. Berdasarkan pengamatan sehari-hari tim, seseorang biasanya hanya bisa mengikuti sekitar 3–5 Agent Session aktif secara efektif. Ini merupakan penilaian berdasarkan pengalaman tim, bukan statistik pengguna berskala besar yang dipublikasikan, tetapi cukup menggambarkan pengalaman banyak developer.

Dilema Single Session dan Multi-Session

Dua pendekatan yang umum digunakan sama-sama punya kelemahan mendasar. Router + Worker diajukan untuk menyeimbangkan “kesinambungan konteks global” dan “kemampuan pemrosesan paralel di latar belakang”.

Masalah Single Session adalah “macet”, sedangkan masalah Multi-Session adalah “tersebar”. Pendekatan pertama membebankan langkah-langkah antara dari semua tugas ke satu jendela konteks, sementara pendekatan kedua menyerahkan seluruh beban koordinasi kepada manusia. Gagasan DeepSeek adalah menghadirkan peran khusus di tingkat sistem untuk “mengingat gambaran keseluruhan”, sehingga pelaksana bisa fokus mengerjakan tugas.

Cara kerja arsitektur dua lapis Router + Worker

Router: lapisan penjadwalan global yang hanya mengoordinasikan

Router adalah lapisan logika yang berjalan terus-menerus. Dalam eksplorasi arsitektur resmi saat ini, Router terutama diimplementasikan sebagai satu sesi LLM yang terus aktif. Namun, secara konsep, Router tidak harus selalu berupa satu sesi model. Tugasnya berfokus pada “mengelola”, bukan “mengerjakan”:

• Menerima semua pesan pengguna dan peristiwa eksternal dari GitHub, IM, CI, dan sebagainya;
• Mengelola keterkaitan tugas secara global dan menentukan apakah perlu membuat pekerjaan baru;
• Memeriksa otorisasi, menugaskan pekerjaan kepada Worker, dan menangani koordinasi antartugas;
• Merangkum informasi yang perlu disampaikan kepada manusia dan, bila perlu, mengambil kembali konteks tugas lama.

Satu detail penting: menurut tim resmi, Router bahkan bisa berjalan tanpa alat Bash. Dengan tidak membiarkan Router mengerjakan pemrograman yang rumit secara langsung, Router tidak akan terhambat oleh pemanggilan alat yang berlangsung lama. Selain itu, tugas Router sering kali tidak membutuhkan model dengan kemampuan penalaran paling kuat. Model yang lebih ringan terkadang sudah cukup untuk menangani interaksi dan pembagian tugas. Ini menjadi dasar teknis untuk “menggunakan model yang berbeda bagi setiap peran”.

Worker: lapisan tugas dengan eksekusi terpisah

Worker bertanggung jawab mengerjakan tugas secara langsung. Dalam prototipe yang dipublikasikan, satu Ticket berhubungan dengan satu Executor Session, dan setiap Ticket memiliki direktori kerja sendiri. Sesuai cakupan otorisasinya, Worker mengubah kode, menjalankan pengujian, dan menangani masukan lanjutan, lalu membuat Report setelah selesai. Jika diperlukan keputusan manusia, Worker menetapkan status Attention. Hasilnya disampaikan melalui kanal asal, misalnya GitHub PR.

Konteks model setiap Worker terpisah satu sama lain. Dengan begitu, langkah-langkah dari berbagai tugas tidak bercampur dalam satu jendela. Namun, perlu diingat bahwa sesi dan direktori yang terpisah tidak sama dengan isolasi keamanan yang kuat. Dokumentasi deployment resmi menjelaskan bahwa secara default, Worker menjalankan perintah menggunakan identitas pengguna sistem operasi milik operator.

Alur GitHub Issue dalam Router + Worker

Berdasarkan Domain Model pada implementasi sumber terbuka, alur tugas dapat diringkas sebagai Source → Trigger → Eval → Decision → Ticket → Assignment → Executor → Report. Sebagai contoh, berikut alurnya ketika “pengguna yang berwenang meminta perbaikan bug di GitHub Issue”:

1. GitHub Source menerima komentar pada Issue dan menghasilkan Trigger;
2. Sistem terlebih dahulu menyaring izin menggunakan aturan deterministik, lalu model menentukan apakah permintaan memenuhi aturan penerimaan tugas;
3. Router menerima tugas dan membuat Ticket yang mencatat cakupan tugas serta otorisasinya (Mandate);
4. Sistem membuat Assignment untuk Ticket dan menugaskannya kepada Worker yang sesuai;
5. Executor melakukan perbaikan dalam direktori dan sesi yang terpisah;
6. Worker melaporkan progres atau menyerahkan hasil, lalu membuat PR;
7. Sistem menyampaikan hasil kepada pengguna melalui Issue asal atau thread PR.

Jika pengguna kemudian memberikan masukan di PR tersebut, pesan baru dapat otomatis dikaitkan dengan tugas asal. Pengguna tidak perlu lagi mencari “sesi Agent mana yang dulu menangani pekerjaan ini”. Inilah contoh konkret bagaimana arsitektur dua lapis mengurangi beban pengelolaan bagi manusia.

4 desain utama Router + Worker

Arsitektur dua lapis hanyalah kerangkanya. Yang membuatnya benar-benar bisa digunakan adalah beberapa desain teknis yang ditujukan untuk mengatasi masalah tertentu:

Penerusan langsung melalui langganan Thread: mengurangi penugasan ulang oleh Router

Misalkan Worker A bertanggung jawab atas sebuah PR. Komentar lanjutan dan hasil CI untuk PR tersebut bisa langsung dikirim ke Worker A berdasarkan Thread-nya, tanpa Router harus membuat keputusan ulang untuk setiap pesan terkait. Ini contoh desain yang memindahkan keputusan yang sering muncul tetapi bernilai rendah dari node pusat.

Namun, penerusan langsung melalui langganan memiliki batas wewenang yang jelas. Dokumentasi otorisasi resmi menyatakan bahwa pesan langganan dapat memberikan konteks, tetapi tidak dapat memperluas Mandate pada Ticket awal. Jika komentar lanjutan meminta pekerjaan baru di luar cakupan wewenang, Worker harus menyerahkannya kembali ke sistem untuk dievaluasi ulang. Hal ini penting untuk mencegah instruksi yang melampaui wewenang dalam komentar eksternal.

Pemrosesan batch oleh Router: menangani lonjakan peristiwa

Saat Router sedang menjalankan satu putaran penalaran, Trigger yang baru masuk akan ditampung terlebih dahulu, lalu dianalisis bersama sebagai satu batch pada putaran berikutnya. Dengan begitu, “satu pemanggilan model untuk setiap pesan” berubah menjadi “beberapa pesan diproses dalam setiap putaran penalaran”. Saat peristiwa datang bertubi-tubi, cara ini secara signifikan mengurangi biaya penalaran per keputusan.

Inline & Spill dan penelusuran berantai: memperlakukan konteks sebagai cache

DeepSeek memperlakukan jendela konteks sebagai semacam cache. Inline berarti memasukkan informasi terbaru yang kemungkinan besar akan digunakan langsung ke jendela konteks, seperti komentar terbaru pada tugas saat ini, baris kode terkait, dan kode di sekitarnya yang diperlukan. Spill berarti menyimpan konten yang jarang digunakan atau terlalu panjang di luar jendela konteks, dengan hanya menyisakan ringkasan, ID terkait, dan cara untuk membacanya. Contohnya adalah diskusi lama yang sangat panjang. Pesan lama yang tidak relevan juga tidak perlu dimasukkan setiap kali.

Dari pendekatan ini berkembang Chain of Recall (penelusuran berantai): model dapat mengikuti hubungan antarobjek Trigger → Thread → Ticket → Worker untuk menemukan kembali informasi lama secara bertahap sesuai kebutuhan. Cara ini lebih hemat konteks daripada “memasukkan seluruh riwayat setiap kali” dan lebih mendekati konsep kueri database menggunakan indeks. Namun, pihak DeepSeek juga mengakui bahwa memori lintas bulan atau untuk jangka waktu yang lebih panjang masih menjadi masalah yang belum terpecahkan.

Memahami Data Eksperimen Router + Worker

DeepSeek melakukan serangkaian eksperimen awal dengan beban kerja sintetis. Setiap simulasi menjalankan sekitar 300 pesan, dengan sekitar 20 permintaan kerja dan sisanya berupa obrolan ringan, umpan balik lanjutan, permintaan pembatalan, serta pesan CI. Setiap skema dijalankan 5 kali. Pekerjaan pemrograman digantikan oleh alat simulasi yang membutuhkan waktu pemrosesan, jadi data ini mengukur kinerja sistem penjadwalan, bukan kualitas pembuatan kode.

Perbandingan penjadwalan end-to-end

Dibandingkan skema satu sesi dengan petunjuk netral, waktu penyelesaian P50 Super-agent turun sekitar 39%, sedangkan P95 turun sekitar 47%. Dibandingkan skema satu sesi yang memprioritaskan delegasi, keunggulan P50 hanya sedikit, tetapi waktu penyelesaian pada P95 jauh lebih pendek. Dengan kata lain, manfaat terbesar arsitektur dua lapis adalah mencegah kelompok tugas paling lambat memakan waktu terlalu lama.

Konsekuensinya juga jelas: pembacaan cache Super-agent sekitar 3,8 kali lebih besar daripada skema satu sesi dengan petunjuk netral. Skema ini menggunakan lebih banyak sesi paralel dan sumber daya inferensi untuk mendapatkan waktu penyelesaian yang lebih singkat dan stabil. Namun, ini tidak berarti biaya total naik 3,8 kali lipat. Biaya sebenarnya juga bergantung pada harga model, tingkat cache hit, Token input dan output biasa, pilihan model untuk Router dan Worker, serta pemanggilan alat. Pihak resmi juga belum mengumumkan biaya API rata-rata untuk tiket kerja nyata.

Eksperimen ablasi penerusan langganan juga layak dicermati. Setelah penerusan langganan dihapus, jumlah keputusan yang harus ditangani Router naik sekitar 30% dan Token pembacaan cache naik sekitar 37%, tetapi waktu penyelesaiannya hampir tidak berubah. Kesimpulannya, dalam pengujian ini penerusan langganan terutama menghemat pemanggilan model Router dan penggunaan konteks, bukan langsung mempercepat penyelesaian.

Uji beban batch Router

Dalam pengujian ini, Router menggunakan model nyata, sedangkan Worker menggunakan model simulasi:

Saat kepadatan peristiwa meningkat, setiap permintaan menjadi lebih lambat, tetapi waktu inferensi rata-rata per keputusan justru turun. Ini menunjukkan bahwa pemrosesan batch meningkatkan throughput efektif. Kesimpulan resminya cukup hati-hati: pada skala tim saat ini, satu Router untuk sementara masih memadai, tetapi ini tidak berarti satu Router dapat menangani pesan tanpa batas.

Dampak Router + Worker bagi developer

Pembagian model: Router memakai model ringan, Worker memilih model sesuai tugas

Pelajaran teknis paling langsung dari arsitektur dua lapis ini adalah: setiap peran tidak harus menggunakan model yang sama. Router bertugas mengklasifikasikan, mendistribusikan, dan merangkum, sehingga cocok menggunakan model yang cepat dan berbiaya rendah. Sementara itu, Worker memilih model dengan kemampuan penalaran yang lebih kuat sesuai kompleksitas tugas. Prototipe ini juga mendukung pemilihan penyedia dan model secara terpisah untuk Router dan Worker.

Berikut contoh sederhana yang menggunakan satu antarmuka kompatibel OpenAI agar Router dapat mengambil keputusan penugasan:

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # APIYI 统一接口，一个 Key 切换多家模型
)

ROUTER_MODEL = "your-fast-cheap-model"   # 替换为控制台中可用的轻量模型名

resp = client.chat.completions.create(
    model=ROUTER_MODEL,
    messages=[{"role": "user", "content": "判断这条 Issue 评论是否需要新建 Ticket:修复登录页 500 错误"}]
)
print(resp.choices[0].message.content)

import json
import openai
from typing import Dict

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

# 角色与模型分层:模型名请替换为你实际可用的模型
ROLE_MODELS: Dict[str, str] = {
    "router": "your-fast-cheap-model",
    "worker_simple": "your-mid-tier-model",
    "worker_complex": "your-strong-reasoning-model",
}

usage_log = []  # 按 Ticket 记录 Token 消耗

def call(role: str, ticket_id: str, prompt: str) -> str:
    resp = client.chat.completions.create(
        model=ROLE_MODELS[role],
        messages=[{"role": "user", "content": prompt}],
    )
    u = resp.usage
    usage_log.append({
        "ticket": ticket_id, "role": role,
        "input": u.prompt_tokens, "output": u.completion_tokens,
    })
    return resp.choices[0].message.content

def router_dispatch(ticket_id: str, event: str) -> str:
    prompt = (
        "你是任务调度器,只做分类,不执行任务。"
        "输出 JSON:{\"accept\": bool, \"complexity\": \"simple\"|\"complex\"}\n"
        f"事件:{event}"
    )
    decision = json.loads(call("router", ticket_id, prompt))
    if not decision["accept"]:
        return "ignored"
    role = "worker_complex" if decision["complexity"] == "complex" else "worker_simple"
    return call(role, ticket_id, f"在授权范围内处理任务:{event}")

print(router_dispatch("T-001", "CI 失败:单元测试 test_login 超时"))
print(usage_log)

🎯 Saran teknis: Saat membangun Agent berlapis, coba dulu model ringan dan model dengan penalaran kuat untuk peran Router dan Worker menggunakan satu kunci API melalui APIYI apiyi.com. Setelah itu, tentukan konfigurasi akhirnya agar tidak perlu memakai model termahal untuk semua peran.

Pengendalian biaya: Catat per Ticket, bukan hanya melihat total

Eksperimen resmi menunjukkan bahwa arsitektur dua lapis mengonsumsi lebih banyak sumber daya inferensi. Karena itu, biaya perlu dikelola dengan lebih terperinci. Beberapa cara praktis yang bisa diterapkan:

• Catat Token per Ticket: Pisahkan biaya keputusan Router dari biaya eksekusi Worker untuk mengetahui jenis tugas yang paling mahal;
• Pisahkan jenis biaya: Catat biaya model, biaya alat (seperti pencarian dan pengambilan halaman web), serta biaya lingkungan eksekusi secara terpisah;
• Perhatikan cache hit: Sebagian besar Token Super-agent digunakan untuk membaca cache, sementara harga per Token saat cache hit dan cache miss bisa sangat berbeda. Sebagai contoh, harga resmi DeepSeek untuk keduanya berbeda hingga puluhan kali lipat;
• Kurangi keputusan yang tidak perlu: Terapkan pendekatan penerusan langsung berbasis langganan agar peristiwa berikutnya langsung diteruskan ke Worker yang bertanggung jawab, tanpa penugasan ulang oleh Router.

💰 Optimasi biaya: Menjalankan beberapa Worker secara paralel berarti jumlah pemanggilan bisa meningkat berkali-kali lipat. Dengan memanggil model dari berbagai penyedia melalui APIYI apiyi.com menggunakan pembayaran sesuai pemakaian, Anda bisa membandingkan biaya aktual setiap peran dan model dalam satu tagihan. Ini memudahkan optimasi biaya di setiap lapisan.

Kapan Router + Worker layak digunakan?

Arsitektur dua lapis tidak selalu lebih baik jika dibuat semakin kompleks. Berikut beberapa pertimbangan:

• Cocok digunakan: Ada beberapa pekerjaan yang saling independen (misalnya Ticket A memperbaiki bug, Ticket B meninjau migrasi, dan Ticket C menangani CI), sementara peristiwa datang dari berbagai kanal dan membutuhkan respons berkelanjutan;
• Bisa ditunda: Jumlah tugas sedikit, tugas saling bergantung, atau pembagian kerja terutama berpusat pada satu tugas kompleks. Agent tunggal atau Agent Team tradisional lebih hemat sumber daya;
• Perlu menyiapkan infrastruktur terlebih dahulu: Jika isolasi izin, penanganan konflik perubahan file, dan log biaya per tugas belum siap, menjalankan tugas secara paralel justru bisa memperbesar risiko.

Perlu diingat juga bahwa Router + Worker dan Agent Team biasa punya fokus yang berbeda. Agent Team biasa umumnya membagi satu tugas kompleks ke dalam peran seperti riset, penulisan kode, dan pengujian. Sementara itu, Router pada Super-agent lebih berfokus pada koordinasi beberapa pekerjaan independen tanpa mendalami detail teknis masing-masing tugas. Pihak resmi juga menjelaskan bahwa struktur serupa bisa dibentuk jika sesi utama Agent Team biasa hanya menangani interaksi terpusat dan penugasan lintas tugas. Jadi, arsitektur dua lapis bukan konsep yang eksklusif untuk DeepSeek.

Keterbatasan Arsitektur Router + Worker dan Batasan Prototipe

Kesalahan yang paling mudah terjadi saat membahas arsitektur seperti ini adalah menganggap seluruh rancangan dalam artikel desain sudah tersedia sebagai fitur prototipe sumber terbuka. Berdasarkan dokumentasi, kita perlu membedakannya dengan jelas:

• Sudah didukung prototipe: memantau satu repositori GitHub, integrasi Feishu opsional, manajemen Ticket, sesi dan direktori Worker yang terpisah, pembuatan PR, panel manajemen untuk menampilkan tugas yang perlu ditangani manusia, serta melanjutkan pekerjaan berdasarkan pesan berikutnya;
• Masih dalam desain dan belum terbukti diimplementasikan sepenuhnya: pengelolaan otomatis beberapa repositori, operasi berkelanjutan di cloud dan lingkungan lintas perangkat yang siap produksi, serta perbaikan otomatis penuh oleh Watchdog yang independen. ReAct Loop asinkron sudah diimplementasikan di Harness, tetapi belum diaktifkan secara default;
• Proaktivitas memiliki batas: pekerjaan yang disimpulkan sistem menggunakan mode observe secara default, sehingga hanya dicatat tanpa dieksekusi; penggabungan PR otomatis juga dinonaktifkan secara default.

Di tingkat arsitektur, masih ada beberapa tantangan yang diakui secara terbuka. Pertama, skalabilitas Router tunggal: pihak resmi hanya menyatakan bahwa kapasitasnya cukup untuk ukuran tim saat ini, tetapi belum ada jawaban tentang cara membaginya ke beberapa shard pada skala yang lebih besar. Kedua, memori jangka panjang: Inline & Spill dan pemanggilan kembali berantai menangani konteks jangka pendek hingga menengah, tetapi memori lintas bulan masih belum terpecahkan. Ketiga, batasan izin: konfigurasi default Router dan Worker berjalan dalam mode danger-full-access dan mengeksekusi tugas sebagai pengguna sistem operator. Pihak resmi menyarankan penggunaan pengguna sistem terpisah; injeksi petunjuk melalui komentar eksternal dan pengelolaan kredensial juga tercantum sebagai masalah yang belum terselesaikan. Di komunitas, ada pula laporan audit kode sumber oleh pihak ketiga untuk commit tertentu, tetapi keseluruhan proses serangannya belum direproduksi secara independen, sehingga hanya bisa dianggap sebagai potensi risiko.

Pengujian komunitas juga menegaskan statusnya sebagai “prototipe”: ada pengguna yang berhasil menjalankan alur lengkap dari Issue hingga PR setelah melakukan clone baru dan mengikuti SETUP.md. Namun, mereka juga melaporkan masalah seperti pengenalan proses Node.js 24, pesan yang terlewat akibat keterlambatan notifikasi GitHub, dan kegagalan assertion pengujian ketika bahasa sistem diatur ke bahasa Mandarin.

Pertanyaan Umum FAQ

Poin Utama Router + Worker

• Posisi utama: Super-agent adalah arsitektur sistem di luar model. Yang dirilis sebagai open source adalah prototipe riset, bukan produk komersial;
• Inti masalah: Hambatan bergeser dari kemampuan model ke perhatian manusia. Satu sesi bisa “macet”, sedangkan banyak sesi bisa membuat pekerjaan “tersebar”;
• Pemisahan tugas: Router hanya menangani koordinasi global, bahkan bisa tanpa akses ke Bash. Worker menjalankan tugas secara mandiri dalam sesi yang terisolasi;
• Mekanisme utama: Penerusan langsung berbasis langganan mengurangi beban pengambilan keputusan Router, pemrosesan batch membagi overhead inferensi, dan Inline & Spill memperlakukan konteks sebagai cache;
• Batasan data: Eksperimen penjadwalan menunjukkan waktu penyelesaian untuk tugas yang paling lama lebih singkat, tetapi konsumsi token lebih tinggi. Hasilnya juga tidak mencerminkan kemampuan pemrograman;
• Cara memulai: Gunakan antarmuka terpadu APIYI apiyi.com untuk mengonfigurasi model berbeda bagi setiap peran, lalu kelola biaya berdasarkan tiket.

Kesimpulan

DeepSeek menggunakan Router + Worker untuk menjawab pertanyaan, “Mengapa AI Agent sebaiknya tidak hanya memiliki satu sesi?”:

1. Nilai arsitektur: Memisahkan koordinasi global dari eksekusi mandiri, sehingga sistem yang mengingat hubungan antartugas, bukan manusia;
2. Desain rekayasa: Penerusan langsung berbasis langganan, pemrosesan batch, Inline & Spill, dan penelusuran berantai masing-masing menjawab masalah beban pusat, throughput saat lonjakan, kapasitas konteks, dan penelusuran riwayat;
3. Pandang secara realistis: Eksperimen membuktikan adanya trade-off antara efisiensi penjadwalan dan penggunaan sumber daya. Skalabilitas Router tunggal, memori jangka panjang, dan isolasi izin masih perlu diselesaikan.

Jika sistem Anda sudah perlu menangani beberapa tugas independen sekaligus, arsitektur dua lapis ini layak dipertimbangkan. Jika tugasnya sedikit dan terpusat, satu Agent masih menjadi pilihan yang lebih hemat. Apa pun strukturnya, penjenjangan model dan pencatatan biaya per tugas adalah kunci pengendalian biaya.

Anda bisa menggunakan APIYI apiyi.com untuk menguji dengan cepat performa berbagai model dalam peran Router dan Worker. Platform ini menyediakan antarmuka yang kompatibel dengan OpenAI, pembayaran sesuai pemakaian, dan kuota uji coba gratis bagi pengguna baru.

📚 Referensi

1. Artikel arsitektur resmi DeepSeek: Eksplorasi desain Super-agent: menuju sistem Agent yang lebih mandiri
2. Tautan: x.com/DeepSeekHarness/article/2116857257245987236

3. Keterangan: Sumber utama untuk arsitektur dua lapisan, lima modul utama, data eksperimen, dan masalah yang belum terselesaikan

4. Repositori GitHub resmi DeepSeek: dsh-superagent-prototype

5. Tautan: github.com/deepseek-ai/dsh-superagent-prototype

6. Keterangan: Status proyek, kode sumber, protokol, dan cakupan penggunaan saat ini

7. Dokumentasi Domain Model sumber terbuka: Objek tugas dan model alur kerja

8. Tautan: github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/001-domain.md

9. Keterangan: Definisi konsep utama seperti Source, Trigger, Ticket, dan Assignment

10. Dokumentasi otorisasi dan langganan: Aturan langganan Mandate dan Thread

11. Tautan: github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/002-authorization.md

12. Keterangan: Penjelasan resmi bahwa pesan langganan tidak dapat memperluas cakupan otorisasi

13. Dokumentasi deployment: Dependensi, akun, dan tips keamanan

14. Tautan: github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/006-deployment.md

15. Keterangan: Mode operasi dengan hak akses tinggi dan saran untuk menggunakan pengguna sistem terpisah

16. Harga resmi DeepSeek API: Harga model dan alat

17. Tautan: api-docs.deepseek.com/quick_start/pricing
18. Keterangan: Perbedaan harga saat cache hit dan cache miss sebagai referensi estimasi biaya

Penulis: Tim Teknis APIYI
Diskusi teknis: Hubungi kami melalui halaman utama APIYI di apiyi.com untuk berdiskusi tentang arsitektur Agent dan praktik pemanggilan berbagai model. Untuk informasi lebih lanjut, kunjungi pusat dokumentasi di docs.apiyi.com.

Artikel terkait

• Satu orang maksimal memantau 5 sesi? Mengupas lima modul utama agen super DeepSeek: Mengulas artikel arsitektur agen super (Super-agent) tim DeepSeek Harness: lima modul utama, kondisi dan data eksperimen, empat pertanyaan terbuka, daftar penerapan untuk tim kecil, serta kombinasi model Router dan Worker dan estimasi biayanya.