Pada 1 November, tim DeepSeek Harness menerbitkan artikel panjang di X berjudul《Menjelajahi Desain Super-agent》yang membahas arsitektur super-agent. Sekitar 15 jam setelah diterbitkan, artikel ini sudah mendapat sekitar 1,3 juta tayangan dan 9,4 ribu suka. Ini adalah artikel tentang konsep arsitektur, bukan pengenalan fitur produk.
Kesimpulan singkat: Desain ini menyerahkan pengelolaan sesi kepada sistem, sehingga pengguna hanya berhadapan dengan satu pintu masuk. Router (pengatur tugas di lini depan) menerima permintaan dan membagikan pekerjaan, Worker (sesi yang bekerja di belakang layar) menjalankan tugas secara paralel, sementara manusia hanya membuat keputusan tingkat tinggi dan memberikan persetujuan akhir.
Mengapa super-agent DeepSeek perlu melampaui sesi tunggal
Saat ini, Agent pada umumnya masih menggunakan satu sesi sebagai unit kerja. Ketika menjalankan beberapa tugas sekaligus, pengguna harus berpindah sesi dan mengingat konteksnya secara manual. Berdasarkan pengalaman tim DeepSeek Harness, satu orang biasanya hanya bisa menangani 3 hingga 5 sesi aktif sekaligus. Angka ini berasal dari pengalaman tim, bukan statistik umum, tetapi menunjukkan satu hambatan: tugas tunggal dibatasi oleh kemampuan model, sedangkan banyak tugas sekaligus dibatasi oleh perhatian manusia.
Menambahkan alat baris perintah dan konektor eksternal ke Agent lokal hanya memungkinkannya menerima pesan dari luar. Tiga keterbatasan berikut tetap ada:
- Pemblokiran sinkron: ReAct klasik (siklus berpikir sambil memanggil alat) akan menunggu saat menghadapi operasi yang memakan waktu, dan tidak bisa merespons pesan baru selama itu.
- Konteks tercampur: Detail proses dari berbagai tugas bercampur dalam satu jendela dan saling mengganggu.
- Terikat pada perangkat: Begitu perangkat lokal masuk mode tidur atau offline, Agent berhenti bekerja.
Karena itu, artikel tersebut mengusulkan agar Agent dipisahkan dari sesi tunggal mana pun yang digerakkan secara manual, sehingga menjadi entitas yang berkesinambungan. Agent ini perlu memiliki empat karakteristik berikut secara bersamaan. Satu siklus ReAct saja tidak cukup untuk mewujudkannya; diperlukan arsitektur sistem pendukung.
| Karakteristik super-agent | Artinya secara sederhana | Modul utama yang mendukung |
|---|---|---|
| Berkesinambungan | Berkomunikasi di IM dan GitHub, tetap terasa seperti Agent yang sama | Arsitektur dua lapis, interaksi multisaluran |
| Efisien | Bisa menerima instruksi baru sebelum perintah sebelumnya selesai, dengan banyak tugas berjalan paralel | Arsitektur dua lapis, interaksi dupleks penuh |
| Proaktif | Memantau peristiwa di lingkungan dan bertindak jika memang perlu ditangani | Berbasis peristiwa |
| Persisten | Selalu online dan dapat pulih otomatis saat terjadi gangguan | Pemisahan daya komputasi dan status, Watchdog |
Membedah lima modul super agent DeepSeek
Kita mulai dari tabel ringkasan. Perhatikan kolom “Bisa digunakan sekarang?”, karena artikel ini membahas arah desain, bukan berarti semua fiturnya sudah tersedia.
| Modul | Masalah yang diselesaikan | Pendekatan utama | Bisa digunakan sekarang? |
|---|---|---|---|
| Arsitektur dua lapis | Sulit menjaga kesinambungan sekaligus menjalankan tugas secara bersamaan | Router hanya berinteraksi dan membagikan tugas, Worker menjalankannya secara terisolasi | Prototipe punya alur serupa, tetapi desain lengkap perlu dibangun sendiri |
| Berbasis peristiwa | Agent hanya bisa menunggu instruksi, sementara derau peristiwa terlalu banyak | Kode menyaring cepat, model menilai lebih mendalam, langganan Thread diteruskan langsung | Prototipe bisa memantau GitHub, dengan Feishu sebagai opsi |
| Full-duplex multikanal | Tugas panjang menghambat percakapan, log mengganggu pengguna | Pemanggilan alat secara asinkron, dengan aturan respons sesuai kanal | DeepSeek Harness sudah mendukung tugas asinkron, tetapi belum aktif secara default |
| Pemisahan komputasi, status, dan lingkungan | Proses berhenti saat perangkat offline dan tidak bisa menjangkau lingkungan lain | Loop berjalan di cloud, status disimpan di database, endpoint tetap di lokasinya masing-masing | Artikel asli tidak menyebutkan bahwa fitur ini sudah tersedia untuk umum; perlu dibangun sendiri |
| Watchdog | Proses masih berjalan, tetapi tugas macet atau menyimpang | Sesi independen di luar sistem utama melakukan pemeriksaan berkala | Artikel asli tidak menyebutkan bahwa fitur ini sudah tersedia untuk umum; perlu dibangun sendiri |
Modul satu: Arsitektur dua lapis Router/Worker pada superagen DeepSeek
Analogi: Router seperti resepsionis restoran yang menerima tamu dan meneruskan pesanan; Worker seperti staf dapur, dengan setiap kompor hanya memasak satu hidangan.
Jika semua peristiwa masuk ke satu sesi, konteks terjaga dengan baik, tetapi throughput rendah. Sebaliknya, jika setiap peristiwa membuka sesi baru, konkurensinya tinggi, tetapi konteks global hilang. Selain itu, beberapa sesi bisa membalas pengguna secara terpisah dan menimbulkan kebingungan. Arsitektur dua lapis memisahkan kedua urusan ini: Router yang terus aktif menangani interaksi dengan manusia dan koordinasi global, bahkan bisa bekerja tanpa alat Bash sama sekali. Konteks setiap Worker terisolasi; masing-masing hanya menangani satu tugas, tidak langsung berbicara kepada pengguna, dan melaporkan statusnya ke Router. Intinya, sesi seharusnya menjadi detail implementasi sistem, bukan sesuatu yang harus dipikirkan pengguna.
Router mungkin terlihat berpotensi menjadi hambatan, tetapi Trigger (peristiwa di lingkungan) yang datang selama satu putaran penalaran akan mengantre dan diproses bersama pada putaran berikutnya. Permintaannya biasanya memiliki input panjang dan output pendek. Peristiwa yang digabungkan dihitung secara paralel pada tahap Prefill (tahap awal saat model memproses input), sehingga durasi satu permintaan bertambah lebih lambat daripada ukuran batch. Pengalaman tim menunjukkan bahwa pekerjaan Router sering kali lebih sederhana dari perkiraan, sehingga model ringan biasanya sudah cukup. Saat implementasi, Anda bisa mencoba deepseek-v4.1-flash sebagai Router melalui APIYI · apiyi.com, lalu mengamati akurasi pembagian tugasnya.
Worker secara langsung menentukan hasil tugas dan kualitas kode, sehingga artikel asli menyarankan penggunaan model paling kuat. Anda bisa membandingkan deepseek-v4-pro dan claude-opus-5-5 pada kumpulan tugas yang sama melalui APIYI · apiyi.com, lalu menentukan model default.
Modul Dua: Trigger Berbasis Peristiwa untuk Super Agent DeepSeek
Analogi: Petugas keamanan menyaring orang berdasarkan daftar, lalu meminta manajer memutuskan jika ada yang meragukan. Urusan lanjutan dari pelanggan lama langsung diteruskan ke penanggung jawab sebelumnya.
Agar agent bisa bekerja secara proaktif, input utamanya perlu bergeser dari petunjuk manual ke peristiwa di lingkungan, seperti pesan grup, hasil CI, dan komentar review kode. Aliran peristiwa di dunia nyata mengandung banyak noise. Jika setiap peristiwa diserahkan kepada Model Bahasa Besar untuk dinilai, latensi dan kebutuhan komputasinya akan terlalu tinggi. Karena itu, artikel ini merancang dua lapisan penyaringan:
- Fast Path (penyaringan cepat dengan kode): Pemeriksaan deterministik berdasarkan daftar sumber, grup, pengguna, atau bot yang diizinkan. Setiap sumber dapat diatur agar “hanya merespons permintaan eksplisit”, “dianggap sebagai kandidat peristiwa”, atau “diabaikan”.
- Slow Path (penilaian lambat oleh model): Hanya kandidat yang lolos penyaringan cepat yang diserahkan ke LLM. Model kemudian memutuskan apakah perlu bertindak berdasarkan konteks dan kebijakan yang ditulis sebagai petunjuk.
Perutean juga memiliki jalur cepat dan lambat. Rangkaian peristiwa pada PR, topik IM, atau utas email yang sama membentuk satu Thread. Setelah Worker berlangganan Thread tersebut, peristiwa berikutnya diteruskan langsung oleh kode tanpa perlu keputusan Router lagi. Jika beberapa Worker berlangganan Thread yang sama, semuanya menerima notifikasi yang sama dan dapat menemukan serta menyelesaikan konflik sendiri.
Konteks dikelola seperti cache. Informasi yang akan segera digunakan dimasukkan langsung ke jendela konteks (Inline). Informasi lengkap yang jarang digunakan disimpan di luar jendela, dengan hanya menyisakan rujukan atau ringkasan (Spill). Artikel ini juga membahas tindakan antisipatif: memeriksa kalender atau mereproduksi issue terlebih dahulu di latar belakang. Hanya hasil yang berguna yang disampaikan, sementara sisanya dibuang. Pendekatan ini memakai komputasi tambahan untuk mengurangi waktu tunggu dan keterlibatan manusia.
Modul tiga: Interaksi full-duplex multikanal pada superagent DeepSeek
Analogi: Saat merebus air, kamu tidak perlu berdiri di dekat ketel. Ketika air mendidih, ada pemberitahuan. Sambil menunggu, kamu bisa terus mengobrol dengan orang lain.
ReAct asinkron mengganti pemanggilan yang memakan waktu dengan start() dan stop(). start() langsung mengembalikan respons, sementara tool berjalan di latar belakang. Setelah selesai, hasilnya dikirim kembali ke sesi sebagai peristiwa baru. Model juga bisa menggunakan stop() untuk menghentikan perintah yang berjalan terlalu lama. Dengan begitu, masukan baru dari pengguna dapat diproses setelah langkah penalaran saat ini selesai. Artikel aslinya menyebutkan bahwa DeepSeek Harness sudah menerapkan mekanisme tugas asinkron ini, tetapi belum mengaktifkannya secara default.
Multikanal menjawab pertanyaan “bagaimana cara berkomunikasi”. Di IM, respons harus ringan dan minim gangguan, dengan notifikasi hanya saat keputusan atau persetujuan dibutuhkan. Salah satu aturan tegas yang sudah divalidasi tim adalah setiap balasan tidak boleh melebihi 100 kata. Sementara itu, GitHub, email, dan dokumen membutuhkan output yang terstruktur dan padat informasi, misalnya dengan menjelaskan latar belakang masalah, perubahan, dan hasil verifikasi secara jelas dalam PR.
Modul empat: Pemisahan komputasi, status, dan lingkungan pada superagent DeepSeek
Analogi: Arsip disimpan di ruang arsip perusahaan, sehingga karyawan tetap bisa melanjutkan pekerjaan meski pindah tempat duduk. Jika membutuhkan tool di mesin tertentu, seseorang dikirim untuk mengoperasikannya di mesin tersebut.
Artikel ini memisahkannya dalam dua langkah. Pertama, siklus Agent berjalan di kontainer cloud tanpa status, sedangkan status sesi disimpan dalam database. Dengan begitu, kontainer dapat dimulai ulang atau diganti tanpa mengganggu kelangsungan tugas. Kedua, lingkungan eksekusi tetap berada di tempatnya. Setiap endpoint hanya dipasangi daemon ringan (program kecil yang terus berjalan di latar belakang). Daemon ini tidak menyimpan status sesi, melainkan hanya menjalankan perintah dan mengembalikan hasilnya.
Desain ini juga mendukung BYOM (Bring Your Own Machine, yaitu menghubungkan komputer sendiri ke Agent di cloud). Dengan begitu, perubahan yang belum di-commit dan kredensial lokal tidak perlu seluruhnya disinkronkan ke cloud. Setelah perangkat kembali online, Agent di cloud bisa melanjutkan tugas yang perlu dijalankan di perangkat tersebut. Artikel Anthropic “Decoupling the brain from the hands” juga menggunakan pendekatan pemisahan yang serupa dan bisa dibaca sebagai perbandingan.
Modul lima: Pemantauan eksternal oleh Watchdog DeepSeek Super Agent
Analogi: Supervisor yang bertugas tidak ikut mengerjakan tugas, tetapi memeriksa secara berkala siapa yang berhenti bekerja dan siapa yang keluar jalur.
Banyak masalah Agent tidak berupa kerusakan total. Prosesnya masih berjalan, tetapi model terjebak dalam siklus tanpa hasil yang tidak bisa dideteksi pemeriksaan status hidup biasa. Watchdog adalah sesi independen yang berjalan di luar sistem utama dan dipicu oleh pesan terjadwal. Selain menangani gangguan infrastruktur seperti kesalahan API dan kegagalan pemulihan status, Watchdog juga menggunakan model untuk menilai apakah setiap Worker benar-benar membuat kemajuan. Pengelola dapat bertanya dalam bahasa sehari-hari, “Mengapa ini gagal?”, atau memintanya menyesuaikan petunjuk dan aturan pemicu saat sistem berjalan.
Sejauh mana prototipe DeepSeek Super Agent bisa dicoba saat ini
Repositori pendampingnya adalah github.com/deepseek-ai/dsh-superagent-prototype, menggunakan lisensi MIT, dan memiliki 8.636 stars serta 863 forks saat data diambil pada 2026-11-02. Ini adalah prototipe riset, bukan produk resmi DeepSeek. Prototipe ini juga tidak sama dengan versi internal tim maupun implementasi lengkap yang dijelaskan dalam artikel. Beberapa desain dalam artikel merupakan rencana pengembangan dan belum diterapkan pada prototipe.
Prototipe ini adalah Agent pemrograman proaktif untuk satu repositori GitHub, yang dikemas sebagai bundle DeepSeek Harness. Agent ini memantau GitHub dan dapat dihubungkan ke Feishu sebagai opsi. Ketika seseorang memberinya tugas, Agent akan membuat item kerja dan menyelesaikannya dalam sesi serta direktorinya sendiri. Setelah itu, Agent kembali ke percakapan asal untuk memberikan respons, misalnya dengan mengajukan PR. Ada juga panel web yang menampilkan hal-hal yang perlu ditangani manusia.
Apa yang Ditunjukkan Dua Kelompok Data Eksperimen Super-agent DeepSeek?
Semua data berikut dilaporkan sendiri dalam artikel resmi. Eksperimen menggunakan beban kerja sintetis dan lingkungan yang disederhanakan; penulis menyebut hasilnya hanya sebagai referensi. Setiap uji pada eksperimen pertama melibatkan sekitar 300 pesan, dengan sekitar 20 permintaan kerja. Setiap desain diuji sebanyak 5 kali. Pekerjaan pemrograman disimulasikan menggunakan tool yang hanya menghabiskan waktu, sehingga yang diukur adalah penjadwalan dan koordinasi, bukan kualitas pengerjaan tugas.
Dalam tabel, p50 berarti separuh tugas selesai dalam waktu tersebut, sedangkan p95 berarti 95% tugas selesai dalam waktu tersebut. Cache-read tokens adalah jumlah token yang dibaca dari cache—konteks yang sudah tersimpan digunakan kembali tanpa diproses ulang. Angka di sini merupakan total dari semua sesi.
| Desain | p50 (menit) | p95 (menit) | Cache-read tokens / uji |
|---|---|---|---|
| Super-agent | 12.4 | 15.7 | 23.2M |
| Tanpa Pass-through (penerusan langsung langganan) | 12.6 | 15.5 | 31.8M |
| Sesi tunggal + sub-Agent (petunjuk netral) | 20.4 | 29.5 | 6.1M |
| Sesi tunggal + sub-Agent (petunjuk yang mengutamakan delegasi) | 13.8 | 29.0 | 10.8M |
Dengan petunjuk netral, model tidak memanggil sub-Agent dalam kelima uji. Dengan petunjuk yang mengutamakan delegasi, model mendelegasikan tugas dalam 4 dari 5 uji; pada uji lainnya, model menganggap tugasnya kecil dan mengerjakannya sendiri. Ini menunjukkan bahwa pada beban kerja tersebut, performa sesi tunggal sangat bergantung pada petunjuk dan penilaian model saat itu, sedangkan arsitektur dua lapis menjadikan delegasi sebagai bagian dari sistem. Konsekuensinya juga jelas: Super-agent menggunakan token cache-read jauh lebih banyak untuk mendapatkan waktu penyelesaian yang lebih singkat dan stabil.
Tanpa penerusan langsung, waktu penyelesaian hampir tidak berubah, tetapi jumlah keputusan Router naik sekitar 30% dan cache-read tokens naik sekitar 37%. Jadi, pada beban kerja ini, penerusan langsung tidak mempercepat penyelesaian; fungsi utamanya adalah mengurangi beban Router.
Eksperimen kedua menguji tekanan pada lapisan Router secara terpisah: Router memanggil model nyata, sementara Worker menggunakan model simulasi. Laju kedatangan Trigger yang memerlukan keputusan Router kemudian dinaikkan secara bertahap.
| Laju kedatangan (kali/menit) | Ukuran batch rata-rata | Waktu per permintaan | Waktu inferensi yang dialokasikan per keputusan |
|---|---|---|---|
| Sekitar 1 | 1.0 | 2.5 detik | 6.4 detik |
| Sekitar 40 | 2.8 | 3.9 detik | 1.6 detik |
Satu keputusan dapat melibatkan beberapa permintaan LLM, sehingga waktu yang dialokasikan per keputusan bisa lebih besar daripada waktu per permintaan. Data ini mendukung kesimpulan bahwa saat terjadi lonjakan peristiwa, penggabungan otomatis dapat meningkatkan throughput efektif Router. Namun, data ini tidak membuktikan bahwa hasilnya akan sama di lingkungan produksi nyata, dan tidak menjelaskan kualitas tugas maupun performa pada basis kode yang berbeda.
Empat pertanyaan terbuka tentang Super-agent DeepSeek
Artikel ini secara jelas mengakui bahwa masalah berikut belum terselesaikan dan perlu diperhitungkan saat mengevaluasi rencana penerapan:
- Bagaimana arsitekturnya diperluas: Ketika tugas makin besar dan saling terkait, belum ada kepastian apakah Router perlu dipecah menjadi beberapa shard, seberapa rinci pembagiannya, dan kapan Worker perlu berkomunikasi secara langsung. Semakin rinci pembagiannya, semakin tinggi tingkat konkurensinya, tetapi semakin sedikit memori dan konteks yang dibagikan. Memori jangka panjang juga menjadi hambatan utama.
- Bagaimana menggunakannya tanpa sesi: Masih dibutuhkan cara interaksi baru untuk menampilkan tugas dan memungkinkan manusia mengarahkan detail penting tanpa mengganggu pekerjaan di latar belakang.
- Batas konteks dan A2A: A2A (agent-to-agent) secara umum mengacu pada komunikasi dan kolaborasi antar-Agent. Ketika organisasi membesar, konfigurasi Super-agent pada dasarnya menentukan konteks mana yang dibagikan dan mana yang diisolasi. Belum ada jawaban tentang cara berkolaborasi secara aman melintasi batas hak akses.
- Keamanan dan privasi: Inilah aspek yang paling perlu diprioritaskan dalam evaluasi. Siklus di cloud terus menerima peristiwa dari luar, sementara endpoint menyimpan kode privat dan kredensial lokal. Jika server disusupi atau siklus tersebut ditembus melalui prompt injection (instruksi berbahaya yang disembunyikan dalam input), semua endpoint yang terhubung bisa diambil alih. Menurut artikel ini, Agent membutuhkan cara untuk “menggunakan kredensial tanpa bisa melihatnya”.
Daftar langkah minimum untuk menerapkan agen super DeepSeek di tim kecil
Urutan berikut adalah saran kami berdasarkan gagasan dalam artikel asli, bukan panduan resmi. Mulailah dengan uji coba di satu repositori dalam lingkungan tepercaya; pembagian Router menjadi beberapa shard belum perlu dilakukan.
Langkah pertama: pisahkan Router dan Worker
- Kode: Buat Router sebagai titik masuk yang selalu aktif, tanpa akses ke alat Bash. Jalankan Worker terpisah untuk setiap tugas, masing-masing dengan konteks dan direktori kerja sendiri. Worker hanya melaporkan hasilnya kepada Router.
- Model: Gunakan model ringan untuk Router dan model yang lebih andal untuk Worker. Konfigurasikan keduanya secara terpisah agar mudah diganti.
- Manusia: Berinteraksi hanya dengan Router, serta bertanggung jawab menetapkan batas tugas, menangani permintaan keputusan, dan memberikan persetujuan akhir.
Langkah kedua: tambahkan penyaringan Trigger
- Kode: Konfigurasikan daftar sumber yang diizinkan dan kebijakan tiga tingkat. Petakan PR dan topik IM menjadi Thread, lalu teruskan peristiwa lanjutan yang sudah dilanggan langsung ke Worker.
- Model: Lakukan penilaian semantik hanya pada peristiwa kandidat untuk menentukan apakah perlu bertindak dan apakah perlu memulai Worker baru.
- Manusia: Jelaskan kondisi untuk bertindak dalam petunjuk. Periksa secara berkala pemicu yang keliru dan peristiwa yang terlewat, lalu sesuaikan daftar sumber dan kebijakan.
Langkah ketiga: tambahkan Watchdog
- Kode: Terapkan Watchdog di luar sistem utama dan jalankan dengan pesan terjadwal untuk memeriksa masalah infrastruktur, seperti kesalahan API dan kegagalan pemulihan status.
- Model: Baca catatan kemajuan Worker untuk menilai apakah pekerjaannya benar-benar berkembang, terhenti, atau menyimpang dari tujuan.
- Manusia: Tetapkan izin perbaikan untuk Watchdog, setujui perubahan yang dibuatnya pada petunjuk dan aturan pemicu, serta evaluasi penyebab kegagalan.
Sejak hari pertama, hindari memasukkan kredensial produksi langsung ke konteks model dan batasi izin seminimal mungkin. Pemanggilan alat secara asinkron dan pemisahan sumber daya komputasi bisa menunggu sampai tiga langkah pertama berjalan stabil dan masalah seperti proses yang terhambat atau perangkat yang offline benar-benar muncul.
Kombinasi model dan estimasi biaya Super Agent DeepSeek
Tabel berikut menggunakan daftar model APIYI · apiyi.com yang diperiksa pada 2026-11-02, dengan satuan $/1 juta token. Model dan harga mengacu pada daftar model di platform, sedangkan biaya aktual mengacu pada konsol.
| Model | Input | Output | Pembacaan cache |
|---|---|---|---|
| deepseek-v4.1-flash | 0.3 | 1.2 | 0.006 |
| deepseek-v4-flash | 0.44 | 1.32 | 0.01408 |
| deepseek-v4-pro | 1.32 | 3.96 | 0.043996 |
| claude-opus-5-5 | 4 | 20 | 0.2 |
Semua angka berikut adalah estimasi berdasarkan harga publik, bukan hasil pengukuran langsung. Dengan asumsi satu pemanggilan menggunakan 20 ribu token input dan 2 ribu token output, tanpa memperhitungkan cache:
deepseek-v4.1-flashsekitar $0.0084,deepseek-v4-prosekitar $0.0343, danclaude-opus-5-5sekitar $0.12.- Satu pemanggilan Router dengan
deepseek-v4.1-flashdan satu pemanggilan Worker dengandeepseek-v4-prototalnya sekitar $0.0427. Jika keduanya menggunakanclaude-opus-5-5, totalnya sekitar $0.24, atau 5,6 kali lebih mahal. - Jika menjalankan 20 set dengan penggunaan tersebut setiap hari, kombinasi model menghabiskan sekitar $0.85, sedangkan penggunaan
claude-opus-5-5untuk semuanya sekitar $4.8. Dalam praktiknya, Worker sering melakukan lebih dari satu putaran pemanggilan, jadi hitung ulang menggunakan jumlah token dari log Anda sendiri.
Untuk sistem yang berjalan lama, biaya pembacaan cache juga perlu dihitung terpisah. Berdasarkan estimasi 23,2 juta token pembacaan cache dalam eksperimen, biayanya sekitar $0.14 jika seluruhnya dihitung dengan tarif deepseek-v4.1-flash, sekitar $1.02 dengan deepseek-v4-pro, dan sekitar $4.64 dengan claude-opus-5-5. Ini hanya gambaran kisaran biaya: eksperimen tersebut tidak mengungkap distribusi token di setiap lapisan dan angka ini belum mencakup biaya input maupun output.
Sebaiknya jadikan model Router dan Worker sebagai opsi konfigurasi. Melalui APIYI · apiyi.com, Anda dapat beralih antara model-model ini dengan satu kunci API. Nilai base_url untuk antarmuka yang kompatibel dengan OpenAI adalah https://api.apiyi.com/v1; saat beralih, Anda terutama perlu mengubah nama model. Dengan begitu, kualitas dan biaya bisa dibandingkan menggunakan kumpulan tugas yang sama. Harga hanyalah salah satu pertimbangan: model default Worker tetap perlu dipilih berdasarkan tingkat keberhasilan tugas dan jumlah pengerjaan ulang.
Grafik di atas merupakan estimasi berdasarkan harga standar pada daftar model APIYI · apiyi.com. Gunakan jumlah token Anda sendiri sebelum menyusun anggaran.
FAQ Super-agent DeepSeek
Q1: Apakah ini model baru?
Bukan. Ini adalah artikel tentang arsitektur sistem Agent, yang berfokus pada cara sistem pendukung mengatur sesi, peristiwa, status, dan pemantauan. Tidak ada model baru yang dirilis.
Q2: Apakah developer biasa bisa langsung menggunakannya?
Kelima modul tersebut belum bisa langsung digunakan sebagai fitur siap pakai. Saat ini, Anda bisa mencoba prototipe riset atau membangunnya sendiri berdasarkan pendekatan dalam artikel. Satu-satunya implementasi yang sudah ada dan disebutkan secara jelas dalam artikel asli adalah mekanisme tugas asinkron DeepSeek Harness, yang secara default belum diaktifkan.
Q3: Apakah dsh-superagent-prototype produk resmi?
Bukan. README-nya menyatakan bahwa proyek ini hanya untuk referensi riset. Ini bukan produk resmi DeepSeek, dan tidak sama dengan versi internal maupun implementasi lengkap yang dijelaskan dalam artikel.
Q4: Apakah penggunaan banyak Agent lebih mahal?
Dalam rangkaian eksperimen ini, jumlah token yang dibaca dari cache memang lebih banyak: 23,2M untuk Super-agent, dibandingkan 6,1M hingga 10,8M untuk pendekatan satu sesi. Sebagai gantinya, waktu penyelesaian lebih singkat dan stabil. Total biaya sebenarnya juga bergantung pada kombinasi model dan skala tugas. Menggunakan model ringan untuk Router dan mengaktifkan mode langsung Thread dapat membantu mengendalikan biaya.
Q5: Bagaimana cara mengakses model-model ini di Tiongkok?
Anda bisa mendaftar dan mendapatkan kunci API melalui APIYI · apiyi.com. Pengguna baru mendapat kuota pengujian gratis. Setelah itu, ubah base_url klien ke alamat di atas dan isi parameter model dengan nama model dalam tabel. Model DeepSeek dan Claude tersebut mendukung endpoint chat dan messages. Sebelum digunakan secara luas, sebaiknya lakukan pengujian dengan lalu lintas kecil terlebih dahulu.
Kesimpulan
Nilai artikel tentang super agent DeepSeek ini terletak pada penerapan prinsip rekayasa sistem klasik ke dalam Agent. Berikut poin-poin utamanya:
- Identifikasi masalah: Untuk tugas tunggal, model semakin sedikit membutuhkan campur tangan manusia. Dalam multitugas, hambatan utamanya mulai bergeser ke keterbatasan perhatian manusia.
- Lima modul: Arsitektur dua lapis, berbasis peristiwa, multikanal dupleks penuh, pemisahan komputasi, status, dan lingkungan, serta Watchdog mendukung empat karakteristik: berkelanjutan, efisien, proaktif, dan tahan lama.
- Batasan bukti: Kedua eksperimen merupakan hasil beban kerja sintetis yang dilaporkan sendiri oleh penulis, sehingga hanya bisa dijadikan referensi desain.
- Urutan penerapan: Pisahkan Router dan Worker terlebih dahulu, tambahkan filter Trigger, lalu tambahkan Watchdog. Sepanjang prosesnya, utamakan batasan keamanan.
Kombinasi model tidak harus langsung ditetapkan secara permanen. Melalui APIYI · apiyi.com, Anda bisa membandingkan beberapa model dalam skala kecil dengan kumpulan tugas yang sama, lalu menentukan konfigurasi berdasarkan tingkat keberhasilan dan tagihan.
Lepaskan diri dari peran sebagai “Router manual” terlebih dahulu, baru pertimbangkan untuk menambah Agent.
Penulis: Tim Teknis APIYI
Diskusi teknis: Hubungi kami melalui halaman utama situs APIYI. Untuk informasi selengkapnya, kunjungi pusat dokumentasi di docs.apiyi.com
