Bedah “Desain Agen Super” DeepSeek Harness: 12 Praktik yang Dapat Diterapkan untuk 3 Masalah Desain: Dupleks Penuh, Memori, dan Kredensial

Catatan penulis: Artikel ini mengupas tiga persoalan dalam desain Super Agent DeepSeek Harness—full-duplex, memori, dan kredensial—serta menjelaskan praktik yang sudah bisa diterapkan, hal-hal yang masih menjadi “masalah terbuka”, dan kontrak antarmuka beserta daftar penerapannya.

Agent yang berjalan dalam waktu lama sering menghadapi tiga masalah sekaligus. Selama pengujian berlangsung selama 6 menit, pertanyaan baru dari pengguna hanya bisa mengantre; konteks kemarin terdorong keluar dari jendela konteks oleh peristiwa hari ini; dan saat melakukan debug, Agent membuka .env sehingga kunci masuk ke riwayat percakapan. Pada 2026-11-01, tim DeepSeek Harness menerbitkan artikel desain panjang berjudul “Exploring Super-agent Design” yang merangkum ketiga masalah ini sebagai full-duplex, memori (Chain of Recall), dan “menggunakan kredensial tanpa melihatnya”.

Ini bukan ulasan peluncuran produk. Artikel aslinya menjelaskan sebuah arsitektur, bukan fitur yang bisa langsung diaktifkan: full-duplex sudah diterapkan di DeepSeek Harness, tetapi dinonaktifkan secara default. Sebagian implementasinya ada dalam plugin prototipe dsh-superagent-prototype, yang secara tegas disebut penulisnya “bukan produk resmi DeepSeek”. Memori jangka panjang dan kredensial juga masih tercantum sebagai masalah terbuka.

Manfaat utama: Setelah membaca artikel ini, kamu akan tahu praktik mana dari ketiga persoalan desain tersebut yang bisa langsung diterapkan, kontrak apa yang harus dipenuhi API di balik masing-masing praktik, dan langkah pertama untuk proyek Agent-mu sendiri.

Pokok Desain Super Agent DeepSeek Harness

Tabel berikut merangkum posisi tiga masalah desain dalam artikel asli dan bagian yang bisa langsung diterapkan.

Masalah desain	Gagasan utama dalam artikel asli	Status dalam artikel asli	Bagian yang bisa langsung diterapkan
Full-duplex	Memisahkan `run()` yang bersifat blocking menjadi `start()` dan `stop()`, sehingga Agent tetap bisa menerima instruksi saat bekerja	Sudah diimplementasikan, tetapi nonaktif secara default	Kontrak tool asinkron, penyisipan kembali event, pemrosesan batch
Memori	Konteks hanya memuat ID stabil, ringkasan singkat, dan pesan di sekitarnya. Konten lain disimpan di luar konteks dengan pointer, lalu diambil melalui penelusuran bertingkat berdasarkan tautan ID	Memori jangka panjang masih menjadi pertanyaan terbuka	ID stabil, inline/spill, pengambilan tepat berdasarkan ID
Kredensial	Agent harus bisa menggunakan kredensial tanpa memasukkannya ke konteks	Masih menjadi pertanyaan terbuka	Pola rekayasa yang memasukkan nama ke konteks, tetapi menyimpan nilainya di luar konteks

Arsitektur keseluruhan Super Agent DeepSeek Harness

Super Agent dalam artikel asli terdiri dari Router dan Worker. Router adalah pintu masuk penjadwalan yang selalu aktif dan mendengarkan event dari berbagai sumber, seperti chat, GitHub, dan CI. Worker adalah sesi Agent yang terisolasi, dengan satu Worker menangani satu tugas. Setiap event yang masuk ke sistem disebut Trigger. Serangkaian event terkait pada PR yang sama, topik pesan instan yang sama, atau rangkaian email yang sama dikelompokkan sebagai satu Thread.

Arsitektur ini juga memiliki ciri khas dalam penerapannya: loop Agent berjalan di cloud, sedangkan lingkungan eksekusi pengguna tetap berada di mesin lokal. Sebuah daemon kecil menghubungkan keduanya, dan kredensial tetap berada di lingkungan lokal. Ketiga masalah desain tersebut berangkat dari premis ini. Setelah memahami empat konsep Router, Worker, Trigger, dan Thread, desain full-duplex dan memori berikutnya akan lebih mudah diikuti.

Cara menerapkan desain full-duplex DeepSeek Harness

Full-duplex mengatasi masalah “satu tool yang lambat membuat seluruh Agent terhenti”. Cara tradisional adalah menunggu secara sinkron setelah memanggil tool. Kueri yang memakan waktu 200 ms mungkin tidak masalah, tetapi pengujian selama 6 menit bisa menimbulkan tiga masalah: latensi permintaan berikutnya terus bertambah; Agent tidak mendengar ketika pengguna berkata “lewati tes e2e” di tengah proses; dan gateway memutus koneksi yang terlalu lama tertunda, sehingga pemanggilan dilaporkan timeout meskipun pekerjaan sebenarnya berhasil.

Artikel aslinya menyebut kondisi ideal ini sebagai “productive”: Agent sudah bisa menerima instruksi berikutnya meskipun instruksi sebelumnya belum selesai. Caranya adalah memecah satu run() yang memblokir menjadi serangkaian kontrak kecil: start() langsung mengembalikan handle tugas, status() melaporkan progres, stop() mengajukan pembatalan, dan hasilnya dikirim kembali ke percakapan sebagai event. Perbedaannya terletak pada siapa yang menunggu: dengan run(), model yang menunggu; dengan start(), runtime yang menunggu.

Kontrak tool asinkron untuk full-duplex DeepSeek Harness

Dalam definisi tool, setiap kemampuan yang memakan waktu lama disediakan melalui tiga tool, bukan satu. Contohnya untuk pengujian, start_test_run hanya mengembalikan job_id dan status queued, tanpa data hasil; get_job_status mengembalikan salah satu status queued, running, done, atau failed beserta penjelasan singkat tentang progres; stop_job mengajukan pembatalan dan mengembalikan status aktual yang tercapai.

Ada dua aturan agar model tidak menyimpang. Pertama, cantumkan “jangan tunggu hasil” dalam deskripsi tool agar model tidak terus-menerus melakukan polling ke get_job_status. Kedua, start tidak boleh mengembalikan data agar model tidak perlu menebak struktur yang diterimanya. API tugas di balik tool dapat dirancang seperti tabel berikut. RFC 9110 mendefinisikan 202 Accepted sebagai “permintaan telah diterima untuk diproses, tetapi pemrosesannya belum selesai”.

Pemanggilan	Respons	Tool terkait
`POST /jobs` (dengan header permintaan `Idempotency-Key`)	202, mengembalikan `job_id` dan status `queued`, `Location` mengarah ke `/jobs/{id}`	start
`GET /jobs/{id}`	200, mengembalikan queued / running / done / failed	status, listener tugas
`GET /jobs/{id}/result`	200 dengan hasil saat selesai, 409 jika belum selesai	Tool pengambil hasil
`DELETE /jobs/{id}`	202 berarti permintaan pembatalan telah diterima; pemanggilan berikutnya mengembalikan 404 atau 409	stop
URL callback opsional	Mengirim POST ke pemanggil saat tugas selesai	Listener tugas

Penyisipan Kembali Hasil Full-Duplex dan Pemrosesan Batch DeepSeek Harness

Polling hanyalah solusi cadangan. Desain yang lebih baik adalah membiarkan runtime memantau tugas, lalu mengirimkan peristiwa penyelesaian singkat ke percakapan setelah tugas selesai. Isinya mencakup job_id, status, dan ringkasan satu baris, misalnya “412 berhasil, 3 gagal”. Log lengkap disediakan melalui alat pengambilan hasil, sehingga log sepanjang 40.000 baris tidak langsung masuk ke konteks.

Artikel aslinya juga menjelaskan pemrosesan batch pada Router: Trigger yang tiba selama satu putaran generasi akan diantrekan, lalu digabungkan ke pemanggilan model berikutnya. Pemanggilan semacam ini memiliki input panjang dan output pendek, sehingga sebagian besar biayanya terjadi pada tahap prefill. Dalam pengujian artikel tersebut, ketika frekuensi Trigger naik dari 1 menjadi 40 per menit, ukuran batch rata-rata naik dari 1,0 menjadi 2,8, sementara waktu per keputusan turun dari 6,4 s menjadi 1,6 s. Ini adalah data pengujian penulis, bukan tolok ukur universal. Namun, idenya bisa langsung diterapkan: antrekan peristiwa dan pesan pengguna selama model melakukan generasi, lalu kirimkan semuanya sesuai urutan kedatangan setelah putaran tersebut selesai.

Detail Teknis Pengurutan, Pembatalan, dan Idempotensi

Detail berikut mudah terlewat saat membuat prototipe, tetapi bisa menimbulkan masalah setelah sistem dirilis:

Pengurutan: Urutan penyelesaian tugas tidak selalu sama. Jika B bergantung pada A, nyatakan dependensinya secara eksplisit: tunggu peristiwa penyelesaian A sebelum memulai B, atau buat API mendukung depends_on.
Pembatalan: stop hanyalah permintaan dan tidak dijamin berhasil. Kembalikan status akhir yang sebenarnya. Jika tugas sudah selesai sebelum dibatalkan, kembalikan done agar model dapat menyampaikan kondisi yang benar kepada pengguna.
Kunci idempotensi: Model dapat mencoba ulang, dan respons yang hilang bisa memicu start kedua. Wajibkan idempotency_key pada setiap start dan kembalikan tugas yang sudah ada untuk kunci yang sama. Tanpanya, satu perintah “jalankan migrasi” bisa dieksekusi dua kali.
Hasil parsial dan batas waktu: Sediakan output awal melalui antarmuka hasil yang menggunakan kursor. Tetapkan juga batas waktu untuk setiap tugas dan kirimkan peristiwa job_timed_out saat batas tersebut terlampaui.

Jika alat Anda menggunakan MCP, perhatikan ekstensi opsional Tasks dalam spesifikasi MCP versi 2026-07-28. Server dapat merespons pemanggilan alat dengan hasil yang menyertakan taskId. Klien kemudian dapat melakukan polling melalui tasks/get atau mendengarkan notifications/tasks, serta menggunakan tasks/cancel untuk meminta pembatalan. Ekstensi ini harus diaktifkan secara eksplisit oleh klien dan server. Tingkat dukungannya juga berbeda di setiap host, jadi pastikan dulu sebelum menggunakannya.

Kapan tidak perlu menggunakan proses asinkron: Jika pemanggilan selesai dalam satu atau dua detik, langkah berikutnya harus menunggu hasilnya, atau tidak ada API tugas yang sesungguhnya di baliknya. Jika alat sebenarnya bersifat blocking, membungkusnya sebagai asinkron hanya akan menambah kompleksitas. Pembagian yang cukup praktis adalah mempertahankan operasi baca sebagai blocking, lalu menjadikan operasi tulis dan komputasi yang memakan waktu sebagai asinkron.

Meniru desain memori DeepSeek Harness: Chain of Recall

Agen yang berjalan lama cepat atau lambat akan mencapai batas konteks karena pekerjaan baru terus berdatangan. Tiga pendekatan yang umum digunakan masing-masing punya kekurangan: menyimpan semuanya membuat jendela konteks penuh dan biaya meningkat setiap putaran; merangkum secara berkala bisa menghilangkan pesan error atau nomor PR yang dibutuhkan kemudian; sementara pencarian berdasarkan kemiripan bisa gagal jika fakta yang dicari dan kalimat kueri tidak mirip secara harfiah.

Gagasan dalam artikel aslinya adalah memperlakukan konteks sebagai cache, dengan hanya dua operasi. Inline menyimpan hal yang paling mungkin dibutuhkan Agen saat ini, termasuk ID, ringkasan singkat, dan pesan-pesan di sekitarnya. Spill menangani sisanya: konten dipotong dan diganti dengan penunjuk agar bisa diambil kembali saat diperlukan. Konten yang terkena spill tidak dihapus; hanya penunjuknya yang tersisa di petunjuk. Misalnya, untuk peristiwa kegagalan CI, konteks hanya menyimpan ringkasan satu baris: “CI untuk PR #412 gagal, 3 dari 118 pengujian di direktori payments gagal.” Log lengkap berukuran 41 KB hanya diwakili oleh jalur untuk mengambilnya kembali. Jika ringkasan itu sudah cukup, Agen tidak perlu mengeluarkan biaya untuk memproses 41 KB tersebut.

ID yang stabil dan graf referensi dalam desain memori DeepSeek Harness

Chain of Recall bergantung pada ID yang tidak pernah berubah. Dalam artikel aslinya, ada tiga jenis objek yang memiliki ID:

Objek	Arti	Contoh ID	Hubungan
Trigger	Peristiwa yang masuk ke sistem: pesan chat, Webhook, atau callback CI	`trg_8f21`	Termasuk dalam sebuah Thread
Thread	Sekumpulan peristiwa terkait pada PR, topik pesan instan, atau rangkaian email yang sama	`thr_pr_412`	Dimiliki oleh satu atau lebih Worker
Worker	Sesi Agen terisolasi yang menangani satu tugas	`wkr_77a0`	Mereferensikan Trigger yang pernah ditanganinya dalam laporan

Hubungan ini membentuk graf referensi yang menjadi memori Agen. Saat melakukan recall, Agen mengikuti tautan satu per satu, tanpa memuat seluruh riwayat atau mencari teks berdasarkan kemiripan. Misalnya, pada hari Jumat seseorang bertanya kepada Router, “Mengapa mekanisme percobaan ulang ditambahkan ke klien pembayaran?” Padahal, diskusi terkait terjadi pada hari Selasa dan sudah terkena spill. Langkah pertama, Router menggunakan indeks satu baris yang masih tersimpan dalam konteks untuk mengambil thr_pr_412. Langkah kedua, Router membaca Worker pemilik Thread dari catatannya, lalu mengambil laporan akhir Worker tersebut. Langkah ketiga, laporan itu mereferensikan Trigger kegagalan CI; Router mengambil log-nya dan menemukan error batas waktu. Dengan tiga kueri kecil yang tepat sasaran, jawaban ditemukan tanpa perlu menebak.

Empat kontrak yang harus dipenuhi API memori DeepSeek Harness

Setiap langkah dalam rantai penelusuran memori adalah satu panggilan API. Jika salah satu panggilan mengembalikan catatan yang berbeda atau tidak mengembalikan apa pun, rantai akan terputus. Akibatnya, Agent bisa macet atau menjawab dengan menebak. Karena itu, API yang mendasarinya harus memenuhi empat kontrak:

ID tidak pernah berubah: ID yang dikembalikan hari ini harus tetap merujuk ke objek yang sama bulan depan. ID tidak digunakan kembali setelah penghapusan dan tidak diberi nomor ulang setelah migrasi.
Pengambilan berdasarkan ID harus murah dan tepat: GET /threads/{id} hanya mengembalikan catatan tersebut, tanpa melakukan pencarian atau mengembalikan “kecocokan terdekat”.
ID yang tidak dikenal harus menghasilkan kegagalan yang jelas: Kembalikan 404 dengan isi respons error yang jelas. Jika responsnya 200 dengan objek kosong, Agent akan mengira memori tersebut ada.
Paginasi berbasis kursor tanpa celah: Thread yang panjang dibagi ke dalam halaman secara berurutan, setiap peristiwa hanya muncul sekali, dan kursor tetap valid saat peristiwa baru ditambahkan.

Kontrak-kontrak ini mudah rusak tanpa disadari saat refactoring. Karena itu, buat pengujian otomatis yang dijalankan setiap kali ada penggabungan kode.

Ada dua batasan yang perlu dilihat secara objektif. Pertama, Chain of Recall tidak bisa menggantikan pencarian vektor: pencarian vektor menjawab “apa yang mirip dengan ini”, sedangkan Chain of Recall menjawab “apa yang terhubung dengan ini”. Dalam proyek nyata, kombinasi yang umum adalah menggunakan indeks vektor untuk menemukan ID Thread awal, lalu mengikuti tautannya hingga mencapai fakta yang tepat. Kedua, angka “37%” dalam artikel asli merujuk pada penerusan Thread: setelah penerusan dihilangkan, jumlah token yang dibaca dari cache per eksekusi naik dari 23.2M menjadi 31.8M. Ini adalah biaya akibat tidak adanya suatu fitur, bukan penghematan yang dihasilkan Chain of Recall itu sendiri. Jangan tertukar saat mengutipnya.

Belajar dari desain kredensial DeepSeek Harness: bisa menggunakan kredensial tanpa melihatnya

Artikel asli menyebut ini sebagai masalah yang masih terbuka: kredensial bisa bocor jika masuk ke konteks Agent. Karena itu, Agent perlu bisa menggunakan kredensial tanpa melihatnya. Ada empat jalur kebocoran yang umum: membaca .env untuk menelusuri masalah; menulis header permintaan dalam teks biasa di perintah debug, atau menjalankan echo untuk “memastikan variabel sudah diatur”; memasukkan nilai asli ke deskripsi PR, komentar Issue, atau fixture pengujian; serta terdorong oleh injeksi petunjuk dalam respons halaman web atau API untuk mencetak variabel lingkungan. OWASP menempatkan injeksi petunjuk sebagai risiko utama aplikasi LLM dan menggolongkan paparan kredensial sebagai kebocoran informasi sensitif.

Semua cara perlindungan mengikuti aturan yang sama: hanya nama yang masuk ke konteks, sementara nilainya tetap berada di luar model. Konteks boleh memuat nama variabel STRIPE_KEY, referensi ke pengelola kunci, placeholder seperti {{token}}, atau nilai yang sudah disamarkan. Namun, konteks tidak boleh memuat kunci asli, nilai yang sudah di-resolve, atau baris log yang belum disanitasi. Begitu nilai asli muncul dalam percakapan, rotasi kunci tersebut pada hari yang sama. Riwayat percakapan bisa dicatat, disimpan dalam cache, dan diekspor; token yang sudah terkirim tidak bisa ditarik kembali.

Empat pola penerapan untuk masalah kredensial DeepSeek Harness

Pola	Cara kerja	Apakah Agent memegang nilainya?	Keterbatasan utama
Variabel lingkungan + penyamaran	Tulis `$NAME` dalam perintah agar shell yang menggantinya dengan nilai; larang pembacaan `.env`; samarkan output sebelum dikembalikan	Dipegang oleh shell	Mencegah kesalahan tak sengaja, tetapi tidak mencegah nilai dicetak dengan sengaja setelah Agent terkena injeksi
Referensi pengelola kredensial	Konfigurasi hanya berisi referensi seperti `op://vault/item/field`, yang diurai CLI ke dalam subprocess saat dijalankan	Dipegang oleh subprocess	Keterbatasannya sama dengan variabel lingkungan
Proksi injeksi kredensial	Agent mengirim permintaan tanpa kunci ke proksi lokal; proksi menambahkan header autentikasi dan meneruskan permintaan sesuai daftar izin	Tidak pernah memegang	Proksi perlu dipasang dan dikelola secara terpisah
Token berumur pendek dengan izin terbatas	Setiap sesi mendapat token yang kedaluwarsa dalam beberapa menit dan hanya bisa melakukan satu tugas	Memegang, tetapi nilainya sangat terbatas	Hanya sebagai perlindungan terakhir; token masih bisa disalahgunakan selama berlaku

Dari keempat pola ini, hanya proksi injeksi kredensial yang benar-benar membuat Agent tidak memegang kunci. Daftar izin dan injeksi kredensial pada proksi sama pentingnya: misalnya, izinkan GET /v1/charges dan tolak DELETE /v1/customers. Sekalipun Agent terkena injeksi, ia hanya bisa melakukan pemanggilan yang sudah kamu setujui dan tidak bisa membawa kuncinya keluar. Jalankan proksi sebagai pengguna terpisah atau di container terpisah agar Agent tidak bisa membaca konfigurasinya. Ini sejalan dengan pendekatan deployment dalam artikel asli: kredensial tetap berada secara lokal bersama lingkungannya.

Jika Agent kamu memanggil model melalui APIYI, pendekatan yang sama bisa diterapkan pada kunci model: biarkan proksi menyuntikkan kunci saat meneruskan permintaan ke APIYI, sementara Agent hanya tahu bahwa ia harus “menggunakan proksi lokal”. Dengan begitu, sekalipun riwayat percakapan diekspor, tidak ada kunci APIYI yang bisa digunakan di dalamnya. Untuk alamat integrasi dan metode autentikasi, rujuk dokumentasi APIYI di docs.apiyi.com.

Lapisan terakhir adalah penyamaran. Output alat, log CI, dan sesi yang disimpan harus menyamarkan awalan yang sudah dikenal, termasuk sk_live_, ghp_, github_pat_, AKIA, dan xoxb-. Samarkan juga semua nilai header permintaan Authorization dan X-API-Key, serta nilai spesifik yang pernah disuntikkan dalam sesi tersebut. Satu baris saja yang tidak tersamarkan bisa membuat semua perlindungan sebelumnya sia-sia.

Panduan Cepat Desain DeepSeek Harness: Daftar Implementasi dan Pemilihan Model

Tiga masalah desain ini tidak harus diselesaikan sekaligus. Berdasarkan perbandingan usaha dan manfaatnya, urutan implementasi yang disarankan adalah:

Mulai dari keamanan kredensial: Larang Agent membaca .env, tulis di CLAUDE.md atau AGENTS.md agar “tidak mencetak variabel apa pun yang berakhiran _KEY, _TOKEN, atau _SECRET”, lalu tambahkan filter penyamaran data pada output. Langkah ini bisa selesai dalam setengah hari dan manfaatnya langsung terasa.
Ubah tool yang lambat menjadi asinkron: Mulai dari tool pengujian, build, dan deployment yang sering membutuhkan waktu lebih dari beberapa detik. Pisahkan operasinya menjadi start / status / stop, lalu tambahkan kunci idempotensi dan batas waktu.
Buat ID yang stabil: Tetapkan ID yang tidak berubah untuk setiap event, thread percakapan, dan subtugas. Dalam konteks, simpan hanya ID dan ringkasan satu baris; pindahkan konten panjang ke luar konteks dan sisakan pointer.
Terakhir, terapkan proksi injeksi dan token berumur pendek: Deploy proksi untuk API pihak ketiga dan konfigurasikan daftar izin, lalu terbitkan token terpisah untuk setiap sesi Agent.

Untuk pemilihan model, Router memiliki karakteristik input panjang dan output pendek serta sering membuat keputusan secara batch. Karena itu, model yang murah, cepat, dan memiliki harga cache hit rendah cocok untuk peran ini. Worker bertugas menulis kode dan melakukan penalaran kompleks, sehingga lebih cocok menggunakan model yang lebih andal. Harga dalam tabel berikut dikutip dari halaman harga APIYI di docs.apiyi.com/models. Ketentuan penagihan dan harga terbaru mengacu pada data terkini di halaman tersebut; artikel ini tidak menjanjikan harga lain.

Model (nama model APIYI)	Harga input	Harga output	Harga cache	Peran yang disarankan	Platform yang tersedia
deepseek-v4.1-flash	$0.3	$1.2	$0.006	Keputusan batch Router, ringkasan event	APIYI apiyi.com
claude-sonnet-5-5	$2	$10	$0.1	Worker untuk coding sehari-hari	APIYI apiyi.com
kimi-k3.1-pro	$2	$10	$0.2	Worker dengan konteks panjang, tugas terkait dokumen	APIYI apiyi.com
claude-opus-5-5	$4	$20	$0.2	Worker untuk refaktor kompleks dan keputusan penting	APIYI apiyi.com

Perlu dicatat bahwa eksperimen pemrosesan batch dan penerusan Thread dalam artikel asli sama-sama menekankan besarnya jumlah token yang dibaca dari cache. Sebagian besar biaya di sisi Router berasal dari prefill dan pembacaan cache. Karena itu, harga cache sering kali lebih penting untuk dipertimbangkan daripada harga output saat memilih model.

🚀 Mulai cepat: APIYI menyediakan akses API untuk model-model di atas dan mendukung format antarmuka OpenAI maupun Anthropic. Router dapat menggunakan format OpenAI untuk terhubung ke deepseek-v4.1-flash, sedangkan Worker menggunakan format Anthropic untuk terhubung ke claude-sonnet-5-5. Keduanya bisa dikelola dengan satu akun. Panduan integrasi tersedia di dokumentasi APIYI di docs.apiyi.com, dan harga mengacu pada docs.apiyi.com/models.

Pertanyaan yang Sering Diajukan (FAQ)

Q1: Apa itu «Desain Super Agent» dari DeepSeek Harness?

Ini adalah artikel desain mendalam berjudul “Exploring Super-agent Design” yang diterbitkan oleh tim DeepSeek Harness pada 2026-11-01. Artikel ini membahas cara merancang Super Agent yang terus aktif dan memantau beberapa sumber peristiwa sekaligus. Isinya menjelaskan arsitektur, bukan fitur yang sudah dirilis secara resmi. Sebagian isinya tersedia dalam plugin prototipe `dsh-superagent-prototype`, yang menurut penulisnya bukan produk resmi DeepSeek.

Q2: Apa perbedaan antara full-duplex dan pemanggilan alat secara paralel?

Pemanggilan alat secara paralel menjalankan beberapa alat sekaligus dalam satu putaran, tetapi model tetap harus menunggu semuanya mengembalikan hasil. Dalam full-duplex, pemanggilan alat asinkron langsung mengembalikan handle, lalu hasilnya tiba sebagai peristiwa pada putaran berikutnya. Selama menunggu, model bisa melanjutkan percakapan, menerima instruksi baru, dan memulai tugas baru.

Q3: Apakah Chain of Recall bisa langsung diaktifkan? Bisakah ia menggantikan RAG?

Tidak untuk keduanya. Chain of Recall adalah pola desain dalam artikel asli, bukan fitur yang bisa langsung diaktifkan. Anda perlu mengimplementasikan sendiri ID yang stabil dan antarmuka untuk mengambil data berdasarkan ID. Chain of Recall dan RAG menyelesaikan masalah yang berbeda: RAG mencari konten yang mirip, sedangkan Chain of Recall mengambil data melalui tautan yang tepat. Dalam proyek nyata, pencarian vektor biasanya digunakan untuk menemukan titik awal, lalu tautan ID diikuti hingga mencapai fakta tertentu. Artikel asli juga mencantumkan memori jangka panjang sebagai masalah terbuka, bukan menyatakan bahwa Chain of Recall sudah menyelesaikannya.

Q4: Untuk aplikasi seperti apa ketiga aspek desain ini paling cocok?

– **Full-duplex**: tugas seperti pengujian, build, crawling, rendering, dan deployment yang sering memakan waktu lebih dari beberapa detik, terutama ketika pengguna terus berbicara dengan Agent selama tugas berjalan.
– **Memori**: riwayat yang terdiri atas peristiwa terpisah dan bisa saling ditautkan, seperti PR, tiket, riwayat eksekusi CI, percakapan layanan pelanggan, dan catatan rilis.
– **Kredensial**: Agent coding dan operasional yang perlu memanggil API pihak ketiga yang berbayar atau sensitif.

Q5: Bagaimana cara cepat menghubungkan Router dan Worker ke model yang berbeda?

Cara yang praktis adalah menggunakan satu platform yang kompatibel dengan format antarmuka OpenAI dan Anthropic. Setelah mendaftar di APIYI apiyi.com, dapatkan kunci API, lalu isi nama model yang sesuai pada Router dan Worker untuk beralih model. Lihat dokumentasi APIYI di docs.apiyi.com untuk alamat integrasi. Sebelum digunakan dalam produksi, sebaiknya uji kualitas keputusan deepseek-v4.1-flash dan claude-sonnet-5-5 menggunakan kumpulan peristiwa nyata yang sama, lalu tentukan pembagian tugasnya.

Q6: Di mana saya bisa memeriksa model atau harga yang disebutkan dalam artikel asli?

Harga semua model yang dibahas dalam artikel ini mengacu pada data terkini di halaman harga APIYI, docs.apiyi.com/models. Angka dalam artikel asli dan materi pihak ketiga hanya digunakan sebagai referensi pembanding. Jika suatu model tidak ditemukan di halaman tersebut, berarti APIYI belum menyediakannya saat ini. Model tersebut akan tersedia sesegera mungkin, dan harganya nanti dapat dilihat di halaman harga.

Q7: Apa saja batasan yang diketahui dari pendekatan ini?

Full-duplex membutuhkan dukungan API tugas yang benar-benar asinkron. “Asinkron semu” yang hanya membungkus implementasi blocking justru menambah kompleksitas. Chain of Recall tidak bisa menemukan konten yang belum ditautkan, dan kontrak ID mudah rusak saat migrasi atau refactoring. Untuk kredensial, variabel lingkungan maupun referensi kunci tidak dapat mencegah Agent mencetak nilainya setelah terkena injeksi. Hanya proksi injeksi yang memungkinkan Agent sama sekali tidak memegang nilai kredensial; token berumur pendek hanya bisa menjadi langkah cadangan. Artikel asli juga mencantumkan memori dan kredensial sebagai masalah terbuka.

Poin-Poin Utama Desain Super Agent DeepSeek Harness

Posisi artikel: Ini adalah artikel tentang desain arsitektur. Mode full-duplex dinonaktifkan secara default, dan plugin prototipenya bukan produk resmi.
Full-duplex: Gunakan start / status / stop sebagai pengganti run yang memblokir proses. Hasil dikirim kembali sebagai peristiwa dan digabungkan per batch.
Kontrak API tugas: Kembalikan 202 saat tugas diterima, gunakan kunci idempoten untuk deduplikasi, kembalikan status sebenarnya saat pembatalan, dan tetapkan batas waktu untuk setiap tugas.
Desain memori: Konteks hanya berisi ID stabil dan ringkasan singkat. Sisanya disimpan di luar dengan pointer; saat diperlukan, data diambil melalui beberapa langkah mengikuti tautan ID.
Kontrak API memori: ID tidak berubah, data diambil secara tepat, ID yang tidak dikenal mengembalikan 404, dan paginasi berbasis cursor tidak melewatkan data.
Prinsip kredensial: Nama masuk ke konteks, nilainya tetap di luar. Utamakan proksi injeksi, gunakan token jangka pendek sebagai cadangan, dan samarkan seluruh data sensitif dalam log.
Pembagian tugas model: Router memilih model yang murah dan memiliki harga cache rendah, sedangkan Worker memilih model dengan kemampuan lebih tinggi. Keduanya bisa dibandingkan dan diuji dengan satu akun di APIYI.

Kesimpulan

Ada lebih banyak hal yang bisa langsung diadopsi dari Desain Super Agent DeepSeek Harness daripada yang terlihat dari statusnya sebagai “prototipe”:

Full-duplex: Kontrak alat asinkron dan pengiriman kembali hasil sebagai peristiwa adalah praktik rekayasa yang matang. API tugas di baliknya bisa diuji terlebih dahulu sebelum diintegrasikan ke Agent.
Memori: ID stabil ditambah inline/spill adalah cara berbiaya paling rendah untuk membangun memori yang presisi bagi Agent berbasis peristiwa, tetapi tidak dapat menggantikan pencarian vektor.
Kredensial: Aturan “nama masuk ke konteks, nilai tetap di luar” bisa diterapkan mulai hari ini. Proksi injeksi adalah satu-satunya solusi yang membuat Agent sama sekali tidak memegang kunci.

Mulailah dengan pengelolaan kredensial yang aman dan mengubah alat yang lambat menjadi asinkron. Terapkan ID stabil dan proksi injeksi pada tahap kedua. Jika perlu memasangkan model yang berbeda untuk Router dan Worker, Anda bisa mengujinya melalui APIYI di apiyi.com menggunakan satu antarmuka yang kompatibel dengan format OpenAI dan Anthropic. Lihat harga di docs.apiyi.com/models.

📚 Referensi

What Is Chain of Recall？ How Stable IDs Give AI Agents Memory: Penjelasan desain memori Chain of Recall
Tautan: apidog.com/blog/chain-of-recall-ai-agent-memory
Keterangan: Mencakup ID stabil, inline/spill, contoh pengambilan kembali multi-hop, dan empat kontrak API
Async Tool Calls for AI Agents: Why start（） Beats a Blocking run（）: Penjelasan desain alat asinkron full-duplex
Tautan: apidog.com/blog/async-tool-calls-ai-agents
Keterangan: Mencakup kontrak start/status/stop, data eksperimen pemrosesan batch, dan penjelasan ekstensi MCP Tasks
How to Let AI Agents Use API Keys Without Seeing Them: Praktik keamanan kredensial untuk agen
Tautan: apidog.com/blog/ai-agents-use-api-keys-without-seeing-them
Keterangan: Mencakup empat pola kredensial, jalur kebocoran, dan daftar periksa penyamaran data sensitif
Dokumentasi dan halaman harga APIYI: Panduan integrasi dan data biaya untuk model yang dibahas dalam artikel ini
Tautan: docs.apiyi.com dan docs.apiyi.com/models
Keterangan: Nama model, format antarmuka, dan harga terkini mengacu pada halaman tersebut

Penulis: Tim teknis APIYI
Diskusi teknis: Untuk pertanyaan tentang pemilihan arsitektur agen dan integrasi multimodel, hubungi kami melalui beranda APIYI di apiyi.com. Materi lainnya tersedia di pusat dokumentasi docs.apiyi.com