Untuk membangun super-agent seperti yang dipaparkan oleh DeepSeek Harness, bagi agen Anda menjadi dua lapisan: satu sesi Router yang aktif terus-menerus (long-lived) untuk berinteraksi dengan manusia dan mendistribusikan tugas, serta banyak sesi Worker terisolasi yang masing-masing menjalankan satu tugas dengan peralatan lengkap. Salurkan input ke keduanya melalui Triggers berbasis event (obrolan, GitHub, CI), arahkan tindak lanjut berdasarkan Thread, dan tambahkan Watchdog terpisah yang memantau segalanya.
Panduan ini merangkum esai desain DeepSeek Harness, "Exploring Super-agent Design", menjadi sebuah tahapan implementasi. Satu catatan penting: esai tersebut memaparkan konsep arsitektur, bukan fitur yang sudah dirilis. Sebagian implementasinya terdapat dalam plugin prototipe bernama dsh-superagent-prototype, yang menurut penulisnya "bukan produk resmi DeepSeek". Setiap cuplikan kode di bawah ini murni bersifat ilustratif, bukan kode milik DeepSeek.
Apa itu super-agent?
Super-agent adalah rekan tim AI tunggal yang selalu aktif (always-online). Agen ini menerima event dari berbagai saluran (obrolan, pull request, CI), menjalankan banyak tugas secara paralel di dalam sesi-sesi terisolasi, dan merespons pengguna dengan satu identitas yang konsisten.
Masalahnya: sesi agen umumnya bersifat terisolasi, dan "seseorang biasanya hanya bisa memantau 3 hingga 5 sesi aktif sekaligus." Satu tugas dibatasi oleh kemampuan model, sedangkan pengerjaan banyak tugas sekaligus dibatasi oleh fokus perhatian manusia. Super-agent dirancang untuk mengatasi batasan kedua tersebut.
Arsitektur ini memiliki empat karakteristik utama:
- Continuous: satu agen untuk berbagai platform seperti IM dan GitHub. Anda mendiskusikan Rencana A di ruang obrolan, beralih ke Rencana B di komentar PR, dan agen tetap dapat mengikutinya.
- Productive: mampu menjalankan tugas secara paralel dan siap menerima instruksi berikutnya sebelum tugas sebelumnya selesai.
- Proactive: memantau berbagai event dan tetap hening kecuali jika bantuannya benar-benar dibutuhkan.
- Persistent: selalu online dan dapat pulih secara mandiri saat terjadi kendala.
Jika Anda baru mengenal harness ini, mulailah dengan membaca apa itu DeepSeek Harness dan perbandingannya dengan Claude Code.
Arsitektur super-agent: lima modul utama
Esai tersebut membagi sistem ke dalam lima modul. Berikut adalah rincian modul beserta langkah pembangunannya:
| Modul | Fungsi | Langkah pembangunan |
|---|---|---|
| Two-level architecture | Router mendisposisikan tugas, Worker mengeksekusi | 1 |
| Event-driven Triggers | Mengubah event obrolan, GitHub, dan CI menjadi input agen | 2 |
| Full-duplex, multi-channel | Alat asinkron, balasan yang disesuaikan dengan saluran | 4 |
| Compute, state, environment split | Loop stateless, state disimpan di database, mesin tidak dipindah | 5 |
| Watchdog | Sesi terpisah untuk memantau progres dan error | 6 |
Langkah 1: Pisahkan Router dari Worker
Router adalah satu sesi yang aktif terus-menerus (long-lived). Router menangani seluruh interaksi dengan manusia dan semua pembagian tugas, serta tidak pernah mengeksekusi tugas secara langsung. Router dapat berjalan tanpa alat Bash, dan model yang lebih ringan serta hemat biaya sudah memadai. Ketika beberapa Trigger masuk di tengah-tengah giliran kerja Router, semuanya akan digabungkan (batch) untuk pemanggilan berikutnya: input panjang, output ringkas, dan digabungkan pada fase prefill.
Setiap Worker merupakan sesi terisolasi untuk satu tugas tertentu. Worker mendapatkan akses alat lengkap dan model terkuat yang mampu Anda sediakan. Worker tidak pernah berinteraksi langsung dengan manusia; ia hanya melapor kembali ke Router. Sebuah Worker juga dapat menggunakan subagen sendiri atau bahkan berupa satu tim agen utuh.
Jangan keliru membedakan ini dengan tim agen (agent team). Pemimpin tim memecah satu tugas yang saling terkait, sedangkan Router hanya mendistribusikan tugas-tugas yang independen. Anda dapat menggabungkan keduanya secara bertingkat.
# Illustrative sketch, not DeepSeek's code
class Router:
def on_events(self, batch): # triggers arriving mid-turn are batched
plan = self.llm_light.decide(batch) # dispatch, reply, or ignore
for task in plan.new_tasks:
Worker.spawn(task, model="strongest", tools="all", report_to=self)
for msg in plan.replies:
self.channels.send(msg) # only the Router speaks to humans
Langkah 2: Ubah event menjadi Triggers
Setiap input yang masuk ke super-agent merupakan Trigger: pesan obrolan, event webhook GitHub, payload Slack Events API, atau callback CI. Sebagian besar dari event tersebut sebenarnya tidak perlu sampai ke model, sehingga esai ini menerapkan penyaringan dalam dua tahap.
- Jalur cepat (fast path), melalui kode program. Menyaring berdasarkan sumber, grup, serta daftar izin (allowlist) pengguna atau bot. Setiap sumber diberi mode: "hanya tanggapi permintaan eksplisit", "kandidat", atau "abaikan".
- Jalur lambat (slow path), menggunakan LLM. Pesan yang masuk kategori kandidat dikirim ke model yang menerapkan aturan dalam bentuk prompt, misalnya "balas jika seseorang melaporkan bug di saluran ini".
Endpoint penerimaan (intake endpoint) Anda harus memberikan konfirmasi cepat dan memproses tugasnya belakangan. Praktik terbaik webhook GitHub menyarankan Anda merespons dengan status 2XX dalam waktu 10 detik—hal yang sulit dijamin jika harus menunggu pemanggilan model. Cukup kembalikan status 202 Accepted, masukkan Trigger ke dalam antrean, dan biarkan Router mengambilnya. Panduan kami tentang merancang webhook yang andal membahas mekanisme retry dan idempotensi untuk lapisan ini.
Langkah 3: Rutekan pesan lanjutan berdasarkan Thread
Sebuah Thread merupakan rangkaian event berurutan pada satu PR, satu topik obrolan IM, atau satu utas email. Worker yang dibuat untuk event pertama suatu Thread akan berlangganan (subscribe) ke Thread tersebut. Event-event lanjutan selanjutnya akan langsung diteruskan ke Worker tersebut tanpa perlu melalui pemanggilan Router.
Pemetaannya bersifat many-to-many. Jika ada dua Worker yang menangani PR yang sama, keduanya akan menerima event dari PR tersebut, dan mereka dapat menyelesaikan konflik melalui PR itu sendiri tanpa perlu berkirim pesan secara langsung.
Jika Anda melewatkan langkah ini, ada konsekuensi biaya yang harus dibayar: dalam eksperimen di esai tersebut, menghapus mekanisme pass-through membuat Router mengambil sekitar 30% lebih banyak keputusan dan meningkatkan penggunaan token sekitar 37%.
Langkah 4: Perlakukan konteks sebagai cache dan jadikan alat bersifat asinkron
Router tidak dapat menampung semuanya, sehingga esai tersebut memperlakukan konteks layaknya sebuah cache:
- Inline data yang kemungkinan besar dibutuhkan: ID, ringkasan singkat, dan pesan-pesan di sekitarnya.
- Spill sisanya: pangkas detailnya dan tinggalkan pointer yang dapat ditelusuri oleh agen.
ID yang konsisten pada Triggers, Threads, dan Workers membentuk graf referensi yang oleh penulis disebut sebagai "Chain of Recall". Agen dapat berpindah dari Trigger ke Thread terkait hingga ke Worker yang menanganinya, memberikan kemampuan penarikan informasi multi-tahap (multi-hop recall) tanpa memerlukan prompt berukuran raksasa.
Selanjutnya, terapkan sistem full-duplex. Ganti alat run() yang bersifat blocking dengan start() dan stop() yang asinkron. Fungsi start() langsung mengembalikan status "Started", sementara hasilnya akan menyusul kemudian sebagai event baru. Hal inilah yang memungkinkan agen menerima instruksi Anda berikutnya selagi instruksi sebelumnya masih berjalan. Esai tersebut menyebutkan bahwa DeepSeek Harness sudah mengimplementasikan pendekatan ini, namun belum mengaktifkannya secara default.
Terakhir, buat balasan yang menyesuaikan saluran (channel-aware). Aturan yang mereka uji membatasi balasan di IM maksimal 100 kata, sementara GitHub, email, dan dokumen mendapatkan penjelasan tertulis yang terstruktur dan mendalam.
Arsitektur ini juga memungkinkan eksekusi spekulatif (speculative execution): dalam grup pengguna mereka, kebijakan "reproduksi dan perbaiki secara diam-diam" hanya memberikan perbaikan sederhana yang sudah terbukti berhasil, dan selebihnya tetap hening.
Langkah 5: Pisahkan komputasi, state, dan lingkungan
Jalankan loop agen dalam kontainer cloud stateless dan simpan status (state) sesi di dalam database. Lingkungan kerja tetap berada di tempatnya masing-masing: setiap mesin menjalankan daemon ringan, yang dalam esai tersebut disebut sebagai BYOM (Bring Your Own Machine). Jika loop mengalami crash, ia dapat dimulai ulang di mana saja dan memuat kembali statusnya, sementara repositori kode tetap berada di mesin asalnya.
Esai tersebut merujuk pada artikel Anthropic, "Scaling Managed Agents: Decoupling the brain from the hands", yang mengusung gagasan serupa, namun ditujukan untuk sandbox terkelola alih-alih mesin milik Anda sendiri.
Langkah 6: Tambahkan Watchdog
Watchdog merupakan sesi terpisah yang berjalan terjadwal di luar sistem utama. Modul ini menangani error API dan menanyakan kepada model apakah setiap Worker sedang membuat kemajuan atau justru menyimpang (drifting). Para pemelihara sistem (maintainer) juga dapat bertanya langsung kepadanya mengenai penyebab kegagalan suatu proses. Pastikan untuk menempatkannya di luar proses Router agar Router yang mengalami hang tidak ikut mematikan sistem pemantaunya.
Hasil eksperimen
Para penulis menguji sekitar 300 pesan obrolan dan CI yang memuat sekitar 20 permintaan tugas, menyimulasikan proses coding menggunakan timer, dan menjalankan tiap konfigurasi sebanyak 5 kali. Mereka menegaskan bahwa hasil ini "hanya bersifat indikatif".
| Setup | p50 (min) | p95 (min) | Cache-read tokens per run |
|---|---|---|---|
| Super-agent | 12.4 | 15.7 | 23.2M |
| Without Thread pass-through | 12.6 | 15.5 | 31.8M |
| Single session + subagent tool, neutral prompt | 20.4 | 29.5 | 6.1M |
| Single session, delegation-first prompt | 13.8 | 29.0 | 10.8M |
Ada dua temuan utama. Dengan prompt netral, sesi tunggal tidak pernah mendelegasikan tugas dalam 5 kali pengujian, sehingga p95-nya hampir dua kali lipat lebih lama dibanding super-agent. Prompt yang memprioritaskan delegasi berhasil memperbaiki nilai median, tetapi tidak pada tail latency. Super-agent mengonsumsi lebih banyak token dibanding sesi tunggal, yang berarti Anda menukar efisiensi token demi latensi yang lebih rendah dan penghematan perhatian manusia.
Uji coba kedua membebani Router secara terpisah. Ketika Trigger meningkat dari 1 menjadi 40 per menit, ukuran batch naik dari 1,0 menjadi 2,8 dan durasi per permintaan berubah dari 2,5 detik menjadi 3,9 detik, sementara waktu per keputusan turun dari 6,4 detik menjadi 1,6 detik. Mekanisme batching inilah yang menjaga satu Router agar tidak cepat menjadi bottleneck.
Uji penerimaan Trigger Anda dengan Apidog CLI
Setiap Trigger berawal dari permintaan HTTP yang masuk ke endpoint penerimaan Anda, sehingga endpoint tersebut adalah hal pertama yang penting untuk diuji. Jika endpoint tersebut melewatkan komentar PR atau menetapkan thread_id baru untuk setiap event, perutean Thread akan terganggu dan setiap pesan lanjutan harus melewati Router kembali. Manfaatkan coding agent Anda untuk menulis dan menjalankan pengujian tersebut menggunakan Apidog CLI.
npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com # pick your agent when prompted
Kemudian, berikan prompt berikut kepada agen Anda:
In Apidog project <id>, create POST /triggers/github for a GitHub
pull_request_review_comment webhook. Add a test case that sends two
comments on the same PR and asserts: status 202, a trigger_id in the
body, and the same thread_id both times. Run it against staging and
summarize any failures.
Agen akan membaca setiap skema payload, memvalidasi JSON-nya, menyusun endpoint serta test case, dan menjalankannya:
apidog cli-schema get endpoint-create
apidog cli-schema validate endpoint-create --file endpoint.json
apidog endpoint create --project <id> --file endpoint.json
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <stagingEnvId> -r cli,json
Pemanggilan apidog run yang sama dengan opsi -r junit dapat langsung diintegrasikan ke dalam pipeline Anda; pelajari Apidog CLI di CI/CD. Jika agen Anda adalah DeepSeek Harness, ikuti panduan penyiapan ini; untuk Claude Code, gunakan panduan ini. Paket Free dari Apidog mencakup hingga 4 pengguna.
Tantangan terbuka
Esai tersebut merangkum beberapa tantangan yang masih belum terpecahkan:
- Penskalaan Router dan penentuan topologi Worker seiring bertambahnya beban kerja.
- Memori jangka panjang di luar skema Chain of Recall.
- UX tanpa sesi: mengarahkan agen tanpa bergantung pada satu jendela obrolan tunggal.
- Batasan konteks dan protokol komunikasi antar-agen, di mana A2A menjadi salah satu kandidat potensial.
- Keamanan. Prompt injection yang menembus loop cloud dapat menjangkau setiap mesin yang terhubung, dan kredensial di dalam konteks berisiko bocor. Penulis menginginkan agen dapat memanfaatkan kredensial tanpa pernah melihatnya secara langsung.
FAQ
Apakah super-agent merupakan fitur DeepSeek Harness yang bisa langsung saya aktifkan?
Tidak. Esai tersebut memaparkan konsep arsitektur. Sebagian komponennya tersedia dalam plugin prototipe dsh-superagent-prototype, yang menurut para penulisnya bukan produk resmi DeepSeek. Alat full-duplex sudah diimplementasikan, tetapi dinonaktifkan secara default.
Mengapa Router menggunakan model yang lebih ringan?
Karena Router hanya mendistribusikan tugas dan berkomunikasi dengan manusia; Router tidak pernah mengeksekusi tugas secara langsung maupun membutuhkan Bash. Worker-lah yang menangani penalaran berat menggunakan model terkuat.
Apa perbedaan antara super-agent dan tim agen (agent team)?
Seorang ketua tim membagi satu tugas yang saling terkait menjadi beberapa bagian, sedangkan Router mendistribusikan tugas-tugas yang independen. Sebuah Worker bahkan dapat menjalankan tim agennya sendiri di dalam super-agent.
Apa itu Thread pass-through?
Event-event lanjutan pada PR, topik IM, atau utas email langsung diteruskan ke Worker yang menangani Thread tersebut, melewati Router sepenuhnya. Tanpa mekanisme ini, setiap pesan lanjutan harus diproses ulang oleh Router—dalam eksperimen mereka, Router mengambil sekitar 30% lebih banyak keputusan dan penggunaan token naik sekitar 37%.
Apa itu Chain of Recall?
Graf referensi yang terbentuk dari ID konsisten pada Triggers, Threads, dan Workers. Agen dapat menelusuri dari Trigger ke Thread terkait hingga ke Worker yang menanganinya, sehingga penarikan informasi multi-tahap (multi-hop recall) tetap mungkin tanpa prompt berukuran raksasa.
Apa fungsi Watchdog, dan mengapa harus terpisah dari Router?
Watchdog adalah sesi terjadwal yang berjalan di luar sistem utama: menangani error API dan memeriksa apakah setiap Worker membuat kemajuan atau justru menyimpang (drifting). Ditempatkan di luar proses Router agar Router yang mengalami hang tidak ikut mematikan sistem pemantaunya—maintainer juga bisa menanyakan kepadanya penyebab kegagalan suatu proses.
Top comments (0)