Pada 31 Oktober 2026, tim DeepSeek Harness membuka kode sebuah prototype bernama dsh-superagent: agen coding yang tidak menunggu dipanggil. Ia mendengarkan event di sebuah repositori GitHub, membuka pekerjaan sendiri, mengerjakannya di sesi dan direktori terisolasi, lalu menjawab langsung di percakapan yang memintanya, biasanya dalam bentuk pull request. Yang sama pentingnya dengan rilisnya: README-nya sendiri menyebut ini prototype riset untuk referensi, bukan produk resmi DeepSeek dan belum layak produksi. Ringkasan ini disusun dari dua repositori resmi dan halaman produk DeepSeek, yang kami periksa pada 3 November 2026.
Apa yang sebenarnya diluncurkan DeepSeek?
Dua artefak, di dua waktu berbeda. Yang pertama adalah DeepSeek Harness sendiri: runtime agen open-source berlisensi MIT dengan prinsip “Everything is a Plugin”, dibangun di atas pustaka Cordis, dan sudah berjalan sebagai preview publik di halaman resminya sejak Agustus 2026. Runtime ini menyediakan CLI bernama dsh dan aplikasi desktop; repositorinya sudah mencatat 25.588 commit dan sekitar 270 ribu bintang GitHub. Yang kedua adalah dsh-superagent-prototype, sebuah “research bundle” yang diumumkan tim Harness pada akhir Oktober 2026 dan diunggah sebagai satu commit: “feat: add the dsh-superagent research prototype”.
Perlu ditegaskan sejak awal: prototype ini bukan versi publik dari produk internal DeepSeek. README-nya menyatakan kodenya diadaptasi khusus untuk publikasi, berbeda dari versi internal mereka, dan sebagian desain di artikel pendampingnya, “Towards a More Autonomous Agent System”, belum diimplementasikan. Sebagian kodenya bahkan ditulis oleh agen coding sendiri, dan README mengakui itu bisa berarti bug.
Bagaimana cara kerja agen proaktif ini?
Alurnya berputar di satu lingkaran: mendengar, mengizinkan, mengerjakan, melapor. README prototype menjelaskan bahwa agen mendengarkan event GitHub, issue dan pull request, plus pesan Feishu secara opsional. Ketika orang yang berwenang meminta pekerjaan, ia membuka work item dan mengerjakannya di sesi agen miliknya sendiri, di direktori kerja terisolasi, kemudian menjawab di percakapan asli tempat permintaan datang, umumnya dengan pull request. Sebuah panel web menampung hal-hal yang butuh perhatian manusia.
Dua aturan perilaku dari README-nya justru bagian paling menarik untuk tim yang menatau otomasi. Pertama, agen hanya bertindak ketika diminta atau ketika aturan yang ditulis tim mengizinkan; ia tidak berimprovisasi soal kapan boleh bekerja. Kedua, ia hanya bicara ketika ada orang yang harus bertindak atau bisa memanfaatkan hasilnya. Ini filosofi, bukan fitur kecil: pola “aktif hanya dalam batas otorisasi tertulis” adalah pola yang sama dengan guard yang kami bangun untuk agen dengan akses MCP.
flowchart TD
A["Event GitHub atau pesan Feishu"] --> B{"Aturan otorisasi tim mengizinkan?"}
B -->|"Tidak"| C["Agen diam"]
B -->|"Ya, atau ada permintaan eksplisit"| D["Work item dibuka"]
D --> E["Sesi agen dan direktori kerja terisolasi"]
E --> F["Jawaban di percakapan asli, misalnya pull request"]
F --> G["Panel web: antrean yang butuh keputusan manusia"]Rincian arsitektur di dalamnya, seperti pembagian kerja antara komponen perute dan pelaksana yang disebut beberapa liputan, dijelaskan di dokumen bernomor di folder docs: filosofi, model domain, otorisasi, eksekusi, prompt, panel, deployment, arsitektur, dan cookbook. Kami belum menjalankan prototype ini, jadi pemaparan kita di sini setia pada README, bukan pada hasil uji sendiri.
Apa bedanya dengan agen coding yang ada?
Pembeda utamanya bukan kecerdasan, melainkan model pemicu. Agen coding yang populer hari ini bekerja reaktif: insinyur membuka sesi, memberi tugas, agen mengerjakan, sesi berakhir. Prototype ini dibangun untuk proaktif dalam batas: ia berlangganan event, membuka work item sendiri ketika aturan mengizinkan, dan pekerjaannya menetap sampai selesai dilaporkan. Beberapa liputan menyandingkannya dengan agen gaya Claude Code dan Codex; dari README-nya sendiri, pembanding yang lebih adil adalah kategori “agen yang mendengarkan”, bukan model bahasa tertentu.
Perbandingan jujurnya sebaiknya dijalankan pada kriteria yang bisa Anda periksa sendiri, dan ini kriteria kami, bukan klaim DeepSeek:
- Pemicu: sesi manual versus event repositori dan pesan tim.
- Unit kerja: satu tugas per sesi versus work item yang hidup sampai beres.
- Permukaan pengawasan: riwayat terminal versus panel web berisi antrean perhatian.
- Batas tindakan: konvensi tim versus aturan otorisasi tertulis di konfigurasi.
- Kematangan: produksi versus prototype riset dengan peringatan eksplisit.
Kalau tim Anda sudah memakai agen coding harian, prototype ini terbaca sebagai eksperimen arah: bagaimana kalau agen ikut berlangganan repositori, bukan hanya dipanggil. Nilai eksperimennya tinggi justru karena kodenya bisa dibaca.
Bagaimana satu siklus kerjanya dalam praktik?
Ini skenario ilustrasi yang kami susun dari deskripsi README, bukan hasil uji yang kami jalankan. Bayangkan sebuah repositori internal dengan aturan tim: agen boleh bekerja pada issue berlabel triage atas permintaan dua maintainer. Senin pagi, QA mengisi issue bug replikasi dan memberi label itu. Event masuk, aturan mengizinkan, dan prototype membuka satu work item di antreannya. Ia mengkloning repositori ke direktori kerjanya sendiri, membaca issue dan kode di sekitarnya, lalu menulis percobaan replikasi sampai kegagalannya konsisten. Keluarannya berupa satu pull request berisi test regresi dan, kalau akar masukannya jelas, satu perbaikan kandidat. Jawabannya muncul di thread issue yang sama: apa yang ia temukan, apa yang ia ubah, dan apa yang belum ia sentuh. Panel web menandai PR itu sebagai item yang menunggu keputusan manusia; maintainer mereview seperti mereview PR kontributor mana pun, merge atau minta revisi.
Dua hal dari skenario ini yang penting dipahami apa adanya. Pertama, setiap langkah yang menyentuh kode tetap berakhir di pull request, artinya keputusan merge tetap milik manusia; prototype ini tidak mendorong apa pun langsung ke branch utama. Kedua, README tidak menjanjikan kualitas apa pun untuk hasil kerjanya; satu-satunya ukuran yang tersedia bagi publik adalah bahwa tim pembuatnya sendiri menyebut kode ini prototype riset.
Konteksnya: runtime Harness di bawahnya
Prototype ini adalah plugin di atas DeepSeek Harness, dan itu penting untuk menilai jangkauannya. Harness memakai prinsip everything-is-a-plugin di atas Cordis, dengan CLI dsh; perintah npx @deepseek-ai/dsh web menyalakan antarmuka web di lokal. Lisensinya MIT. Yang perlu dicatat untuk perencanaan: repositori Harness sendiri masih berlabel fase preview dengan peringatan perubahan yang merusak kompatibilitas, dan commit terbaru menunjukkan versi paket masih 0.2.2-alpha.3. Angka adopsinya besar, sekitar 270 ribu bintang dan 32,9 ribu fork, tapi fase preview berarti API-nya belum dijanjikan stabil.
Apa yang belum boleh dipakai untuk produksi?
Banyak, dan README-nya yang mengatakannya, bukan kami. Poin-poin eksplisitnya: prototype ini hanya untuk referensi riset, bukan produk resmi DeepSeek; sebagian kodenya dibuat oleh agen coding dan bisa mengandung bug; versi yang dipublikasikan disesuaikan sehingga berbeda dari versi internal dan dari artikel pendampingnya; dan sebagian desain di artikel tersebut memang belum diimplementasikan. Tambahkan fase preview Harness yang izinnya bisa berubah, dan kesimpulan teknisnya sederhana: jangan arahkan prototype ini ke repositori produksi tanpa pemisahan yang ketat.
Untuk tim yang ingin menilainya sendiri, berikut urutan yang kami sarankan sebagai checklist editorial, bukan panduan resmi DeepSeek:
- Jalankan pilot di organisasi atau repositori terpisah yang berisi data tiruan, jauh dari produksi.
- Baca dokumen otorisasi dan eksekusi di folder docs sebelum menulis satu aturan pun; aturan otorisasi adalah permukaan serangnya.
- Mulai dari satu jenis event saja, misalnya komentar dari satu personel berwenang, sebelum menyalakan listener yang lebih luas.
- Tetapkan siapa yang menutup antrean panel; agen proaktif tanpa pemilik antrean perhatian hanya memindahkan pekerjaan, bukan menguranginya.
- Kunci jalur persetujuan: hasil kerjanya berupa pull request, jadi perlakukan setiap PR-nya seperti PR dari kontributor asing yang belum Anda kenal.
Pola di atas, izin tertulis, eksekusi terisolasi, persetujuan manusia di titik yang berisiko, adalah pola yang kami kerjakan setiap hari di layanan agen AI kami, terlepas dari runtime yang dipilih.
Apa yang tidak dibahas artikel ini?
Tiga hal. Pertama, versi model yang dipakai prototype tidak disebut di README, jadi kami tidak mengutip klaim model apa pun. Kedua, tanggal 31 Oktober 2026 adalah hasil gabungan penanda waktu commit GitHub, tiga hari sebelum pemeriksaan kami, dan liputan publik yang konsisten; halaman berdatanggal resminya tidak kami temukan, jadi perlakukan tanggal itu sebagai perkiraan yang kuat. Ketiga, kami tidak menjalankan prototype-nya, tidak mengukur kualitas PR-nya, dan tidak mengutip angka kinerja dari pihak mana pun. Semua sumber diperiksa pada 3 November 2026. Kalau Anda ingin menimbang pola agen proaktif untuk alur kerja internal Anda, bicara dengan kami.
