agentic

DeepSeek Super-Agent: Apa Artinya, Cara Kerjanya, dan Apa yang Masih Hilang18 min read

Reading Time: 11 minutesPanduan untuk desain Super-agen DeepSeek dan prototipe dsh-superagent-nya: bagaimana router dan pekerja cocok satu sama lain, apa yang ditunjukkan oleh benchmark dan apa yang harus diperiksa sebelum menjalankannya.

DeepSeek Super-Agent cover: a GitHub issue routed to three worker sessions that end in a pull request

DeepSeek Super-Agent: Apa Artinya, Cara Kerjanya, dan Apa yang Masih Hilang18 min read

Reading Time: 11 minutes

Buka tiga agen coding sekaligus dan Anda bisa merasakan masalahnya. Yang satu sedang menunggu keputusan, yang satu sudah selesai dua puluh menit yang lalu, dan Anda sudah lupa mana yang sudah diperbaiki autentikasinya. Tim Harness DeepSeek memberikan nomornya: berdasarkan pengalamannya, seseorang hanya dapat mengikuti tiga hingga lima sesi agen aktif dalam satu waktu. Setelah itu, model tidak lagi menjadi hambatan. Anda.

Pada tanggal 31 Oktober 2026, tim menerbitkan artikel desain untuk apa yang disebut Agen Super dan membuat prototipe bersumber terbuka bernama dsh-superagent. Ini adalah agen pengkodean proaktif untuk satu repositori GitHub. Satu sesi router yang berumur panjang berbicara kepada orang-orang dan membagikan pekerjaan, dan setiap permintaan yang diterima mendapatkan sesi pekerjanya sendiri yang berakhir dengan permintaan tarik atau pertanyaan. Repositori ini melampaui 12.000 bintang dalam waktu sekitar dua hari. README-nya secara blak-blakan menyatakan bahwa ini adalah kode penelitian dan bukan produk resmi DeepSeek.

Panduan ini ditujukan untuk para insinyur dan pemimpin tim yang ingin mengetahui apa yang dilakukan prototipe, bagaimana desain router dan pekerja bekerja, apa yang dibuktikan dan tidak dibuktikan oleh angka benchmark, dan apa yang harus diperiksa sebelum mengarahkannya ke repositori sebenarnya.

Satu catatan sebelum detailnya. Jawaban pekerja untuk “memperbaiki bug ini” adalah permintaan tarik, dan GitHub adalah solusi yang tepat untuk itu. Hal-hal lain yang dihasilkan agen seputar kode lebih sulit untuk ditempatkan: penulisan akar penyebab, ringkasan pengujian, tabel perbandingan yang diminta oleh pengulas.AgenGrid.ioadalah ruang kerja bersama tempat orang dan agen AI membuat, mengedit, dan berbagi dokumen, aplikasi, dan file, dengan satu versi langsung, atribusi, dan riwayat. Kami kembali ke tempat yang cocok menjelang akhir.

Apa itu DeepSeek Super-Agent?

Dua hal muncul bersamaan. Yang pertama adalah artikel desain panjang, “Menjelajahi Desain Agen Super: Menuju Sistem Agen yang Lebih Otonom”. Tim Harness menulisnya dalam bahasa Mandarin dan memposting versi bahasa Inggris yang diterjemahkan mesin di X pada tanggal 1 November. Ini telah dilihat lebih dari 2,2 juta kali. Yang kedua adalah kode:deepseek-ai/dsh-superagent-prototipe, dirilis di bawah lisensi MIT.

Ini bukan model baru. dsh-superagent adalah paket untukTali Kekang DeepSeek, memanfaatkan agen sumber terbuka DeepSeek, yang digambarkan perusahaan sebagai pratinjau publik di seluruh dunia. Bundel ini mengawasi satu repositori GitHub dan, jika Anda mengaktifkannya, Feishu mengobrol. Ketika seseorang dalam daftar yang diizinkan meminta pekerjaan kepada agen, agen akan membuka item pekerjaan, menjalankannya di sesi dan direktorinya sendiri, dan menjawab dalam percakapan awal. Panel web hanya menampilkan apa yang dibutuhkan seseorang.

Namanya lebih mudah daripada kedengarannya. Cui Tianyi, dari departemen produk DeepSeek dan salah satu pengulas akhir artikel, menjelaskan dalam postingan Zhihu bahwa “super” berarti superskrip versus subskrip. Agen Super menambahkan lapisan di atas agen yang melakukan pekerjaan, kebalikan dari sub-agen yang menambahkan satu lapisan di bawahnya. Ini bukanlah klaim atas kecerdasan yang superior.

README dibuka dengan peringatan yang patut dibaca secara lengkap: “Prototipe penelitian hanya untuk referensi, bukan produk resmi DeepSeek.” Ia menambahkan bahwa sebagian besar rekayasa dilakukan oleh agen pengkodean, bahwa kode tersebut mungkin mengandung bug, dan bahwa beberapa desain dalam artikel tersebut merupakan arahan untuk pekerjaan di masa depan dan tidak diterapkan.

Sekilas dsh-superagent-prototipe
Apa itu Agen pengkodean proaktif untuk satu repositori GitHub, dikemas sebagai bundel DeepSeek Harness
Status Prototipe penelitian, “bukan perangkat lunak siap produksi” menurut README
Lisensi MIT
Bahasa skrip ketikan
Mendengarkan Masalah GitHub, permintaan penarikan, komentar, dan CI. Obrolan Feishu bersifat opsional
Dibuat 31 Oktober 2026. Lebih dari 12.000 bintang dan 1.200 cabang pada 2 November
Bagaimana cara mengaturnya Minta agen pengkodean Anda untuk membaca SETUP.md dan mengaturnya dengan Anda

Mengapa DeepSeek mengatakan hambatannya adalah perhatian manusia?

Artikel ini dimulai dari observasi sederhana. Selama setahun terakhir, agen pengkodean menjadi cukup baik sehingga satu tugas dibatasi oleh model. Namun begitu Anda menjalankan beberapa tugas sekaligus, batasannya berpindah ke Anda. Setiap sesi diisolasi, jadi Anda beralih di antara sesi tersebut secara manual dan melacak apa yang diketahui masing-masing sesi. Menyambungkan CLI, MCP, atau konektor obrolan ke satu sesi lokal memungkinkannya mendengar tentang peristiwa baru, namun tetap memblokir perintah yang panjang, mencampurkan konteks dari tugas yang berbeda, dan berhenti saat laptop Anda dalam mode tidur.

Jawaban DeepSeek adalah berhenti memperlakukan sesi sebagai unit yang Anda kelola. Ini mencantumkan empat sifat yang harus dimiliki seorang Agen Super:

  • Terus menerus.Anda berbicara dengannya di tempat Anda bekerja, seperti obrolan atau komentar GitHub, dan berperilaku seperti satu agen. Jika Anda meminta paket A di chat dan beralih ke paket B di komentar permintaan tarik, berikut ini.
  • Produktif.Ini menjalankan beberapa tugas kompleks secara paralel dan mengambil instruksi berikutnya sebelum yang terakhir selesai.
  • Proaktif.Ia mengamati kejadian-kejadian, mengambil tindakan berdasarkan hal-hal yang perlu ditangani, dan sebaliknya tetap diam.
  • Gigih.Itu tetap online dan pulih dari kegagalan tanpa Anda memulai ulang.

Penulis berpendapat bahwa tidak ada satu pun loop ReAct yang dapat memberikan keempatnya, sehingga kualitasnya harus berasal dari arsitektur di sekitar model. Itulah subjek sebenarnya dari artikel tersebut, dan penjelasan visual di bawah ini, yang dibagikan oleh Hesam, adalah cara cepat untuk melihat keseluruhan desain dalam satu halaman.

Bagaimana cara kerja desain router dan pekerja?

Bayangkan seorang manajer teknik yang baik yang tidak pernah menulis kode selama standup. Iturouteradalah satu sesi berumur panjang yang menerima setiap pesan dari setiap saluran. Itu tidak menjalankan tugas. Ia memutuskan pesan apa yang diminta, menyerahkan pekerjaan baru kepada pekerja, dan menulis setiap balasan kepada orang-orang yang terlibat. Artikel tersebut mengatakan bahwa ia dapat berjalan tanpa alat shell sama sekali, dan model yang lebih ringan dan lebih cepat biasanya sudah cukup untuk itu.

SEBUAHpekerjaadalah sesi terpisah dengan konteks terisolasi dan seperangkat alat lengkap, yang didedikasikan untuk satu tugas. Pekerja tidak pernah berbicara dengan orang secara langsung. Mereka melaporkan status ke router, yang menyimpan balasan dalam satu suara. Dalam prototipe, setiap tiket mendapatkan sesinya sendiri dan direktorinya sendiri, biasanya berupa git worktree, dan jumlah pekerja dibatasi. Standarnya adalah tiga sekaligus, dapat disesuaikan dari 1 hingga 16, dengan satu slot tambahan dibiarkan kosong sehingga pesan seseorang selalu dapat terkirim.

Dua detail menjadikan ini lebih dari sekadar antrian tugas.

Tindak lanjut lewati router.Setelah pekerja memiliki permintaan tarik atau thread obrolan, pekerja akan berlangganan thread tersebut. Komentar selanjutnya langsung menuju ke sana, tanpa panggilan model tambahan di router. Jika suatu komentar ternyata mengenai hal lain, pekerja tersebut akan mengembalikannya.

Semburan dikumpulkan.Pemicu yang tiba selama satu model akan mengantri dan dimasukkan bersama ke panggilan berikutnya. Penulis mengukur efeknya, dan kita melihat angka-angka di bawah ini.

Diagram dsh-superagent: sumber mengumpankan gerbang, lalu sesi router, lalu tiket ditangani oleh sesi pekerja terpisah yang membalas di thread asli
Diagram asli tentang bagaimana satu permintaan berpindah melalui dsh-superagent, berdasarkan dokumentasi proyek.

Satu hal lagi yang kontras. Artikel ini membedakannya dengan Tim Agen. Dalam tim agen, seorang pemimpin memecah satu tugas kompleks menjadi beberapa langkah dan mengoordinasikan peran yang mengerjakannya, yang merupakan beban penalaran yang berat. Router Super-agent hanya mengirimkan tugas independen dan melacak hubungannya pada tingkat tinggi. Itu tidak menguraikan karya itu sendiri.

Apa fungsinya jika tidak ada yang bertanya?

Di sinilah filosofi proyek menjadi praktis. Dokumen pertama dalam repositori menyatakan prinsip dalam satu baris: ambil perhatian manusia sesedikit mungkin, dan berikan nilai sebanyak mungkin. Setiap pesan yang dikirimkan agen membutuhkan perhatian rekan kerja, sehingga pesan tersebut hanya disampaikan ketika seseorang harus bertindak atau dapat menggunakan suatu hasil, dan pesan tersebut hanya bertindak ketika diminta atau ketika aturan yang dibuat oleh tim mengizinkannya.

Gerbang yang menerapkan ini adalah kode biasa, bukan model. Ia memeriksa siapa yang meminta berdasarkan daftar tim yang diizinkan dan mencatat seberapa kuat permintaan tersebut:

Kekuatan Contoh dari dokumen Apa yang terjadi
Eksplisit Seseorang di daftar yang diizinkan menyebutkan agennya, atau menindaklanjuti thread yang sudah memiliki tiket Agen menerima pekerjaan dalam setiap mode
Disimpulkan Bot di daftar bot Sumber, atau tindak lanjut orang yang tidak terdaftar. Pesan yang belum tertangani yang dipilih tim untuk diterima Dinilai berdasarkan aturan tertulis tim. Dalam mode pengamatan default, ini hanya dicatat sebagai “akan menerima”
Tidak diterima Bot lainnya, apa pun yang diabaikan oleh tabel penerimaan Dijatuhkan sebelum model apa pun dipanggil

Mode pengamatan itu adalah bagian yang paling saya sukai. Agen memulai dengan mencatat apa yang akan dilakukannya, sehingga tim dapat membaca catatan tersebut di tab Eval dan memperluas izinnya hanya jika sudah terlihat benar. Pesan, komentar dan dokumen yang dikutip diperlakukan sebagai masukan untuk mengambil keputusan. Mereka tidak dapat mengubah apa yang boleh dilakukan oleh agen.

Artikel desain menunjukkan seperti apa pekerjaan proaktif dalam praktiknya. Di grup pengguna internal DeepSeek Harness, tim mengonfigurasi kebijakan “reproduksi dan perbaiki secara diam-diam”. Saat seseorang melaporkan masalah atau mendiskusikan usulan perubahan, agen mencoba mereproduksinya dan menemukan perbaikan di latar belakang, dan agen memberikan hasil hanya setelah agen mengonfirmasi masalah dan menemukan perbaikan sederhana. Kalau tidak, ia akan tetap tenang. Artikel tersebut juga memberikan aturan yang jelas untuk saluran obrolan yang menurut penulis telah mereka verifikasi: batasi setiap balasan hingga 100 kata. Sebaliknya, pada GitHub, permintaan penarikan harus padat, dengan latar belakang masalah, deskripsi perubahan, dan hasil verifikasi.

Secara default, setiap pesan GitHub yang diposting agen dimulai dengan baris “Ini dilakukan oleh agen otomatis, bukan manusia”. Tim dapat mengeditnya, bersama dengan perintah lainnya.

Apakah angka benchmarknya bertahan?

Artikel tersebut memuat eksperimen kecil, dan penulis berhati-hati untuk menyebutnya hanya indikatif. Empat desain berjalan berdampingan pada aliran obrolan grup dan pesan CI: sekitar 300 pesan per proses, sekitar 20 di antaranya merupakan permintaan kerja nyata, masing-masing lima proses. Pekerjaan pengkodean disimulasikan oleh alat yang hanya menghabiskan waktu, sehingga pengujian ini mengukur penjadwalan dan koordinasi, bukan kualitas kode siapa pun.

Desain Waktu penyelesaian tugas, p50 / p95 (mnt) Token baca cache per proses
Agen super 12.4 / 15.7 23,2 juta
Agen super tanpa pass-through 12.6 / 15.5 31,8 juta
Sesi tunggal dengan alat subagen, perintah netral 20.4 / 29.5 6,1 juta
Sesi tunggal dengan alat subagen, perintah delegasi 13.8 / 29.0 10,8 juta

Bacalah tabelnya dua kali, karena judulnya bukanlah keseluruhan cerita. Desain router memotong waktu penyelesaian p95 menjadi sekitar setengah dari satu sesi, namun menggunakan sekitar dua hingga empat kali token pembacaan cache. Dan baris yang paling menarik adalah baris kedua: menghapus pintasan pass-through tidak membuat tugas selesai lebih cepat atau lebih lambat, itu hanya membuat router mengambil keputusan sekitar 30 persen lebih banyak dan membakar token 37 persen lebih banyak.

Bacaan saya adalah bahwa temuan sebenarnya berada di baris sesi tunggal. Dengan perintah netral, model tidak pernah memanggil subagen dalam lima proses yang dijalankan. Ia melakukan pekerjaannya sendiri, pesan-pesan baru terus mengganggunya, dan tugas-tugas paling lambat membutuhkan waktu 29,5 menit. Dengan perintah yang memerintahkannya untuk mendelegasikan, model tersebut mendelegasikan dalam empat dari lima proses, dan pada sisa proses, model menilai pekerjaan tersebut “kecil” dan melakukannya sendiri. Satu sesi tergantung pada mood model. Router yang tidak diperbolehkan menjalankan kode tidak dapat melakukan kesalahan itu.

Sebuah stress test terpisah pada router saja meningkatkan tingkat kedatangan peristiwa yang layak untuk diambil keputusan dari sekitar 1 menjadi sekitar 40 per menit. Batch rata-rata bertambah dari 1,0 menjadi 2,8 peristiwa, waktu per permintaan hanya meningkat dari 2,5 menjadi 3,9 detik, dan waktu diamortisasi per keputusan turun dari 6,4 menjadi 1,6 detik. Semakin banyak peristiwa yang dikumpulkan, semakin murah pula biaya yang didapat, hingga batas yang menurut penulis bergantung pada panjang konteks dan berapa banyak peristiwa yang dapat ditangani secara akurat oleh suatu model dalam satu putaran.

Ini adalah hasil yang dilaporkan sendiri pada pekerjaan sintetis. Mereka menunjukkan ide penjadwalan itu masuk akal. Mereka tidak menunjukkan bahwa prototipe memperbaiki bug Anda lebih cepat.

Apa pendapat orang-orang yang dekat dengan proyek mengenai keterbatasannya?

Segera setelah rilis, Cui Tianyi, dari departemen produk DeepSeek dan salah satu pengulas akhir artikel desain, menulis bagaimana dia melihat desain tersebut. Pembingkaiannya berguna karena sederhana. Dia menyebut trade-off utama sebagai kesinambungan antar tugas versus hasil tugas.

Mengenai batasannya, ulasannya langsung. Prototipe hanya mengimplementasikan sebagian dari desain yang diusulkan. Pada ulasannya, DeepSeek Harness tidak memiliki memori jangka panjang bawaan di seluruh sesi. Dan sistem tersebut hanya divalidasi di lingkungan kecil dan tepercaya di dalam perusahaan. Bagian masalah terbuka pada artikel ini mencantumkan penskalaan router, memori selama berbulan-bulan, bekerja tanpa sesi, batasan konteks antara agen dan bagaimana agen yang terisolasi harus berbicara satu sama lain, dan keamanan.

Apa yang harus Anda periksa sebelum menjalankannya?

Dokumentasinya lebih jujur ​​daripada kebanyakan postingan peluncuran, dan ada baiknya memperlakukan peringatannya sebagai persyaratan.

  • Pekerja mempunyai akses yang luas.Kedua preset izin, untuk router dan pekerja, dijalankan dengandanger-full-accesssebagai pengguna OS operator. Pembungkus akun memilih kredensial GitHub mana yang digunakan agen, namun dokumen mengatakan kredensial tersebut adalah default dan bukan batas keamanan, karena pekerja masih dapat menjalankan program dengan jalur absolut atau membaca direktori home Anda. Rekomendasinya adalah akun OS khusus yang hanya menyimpan kredensial agen.
  • Masukan yang tidak dipercaya adalah pertanyaan keamanan terbuka.Artikel ini memperingatkan bahwa jika injeksi cepat atau intrusi server membahayakan loop agen cloud, setiap perangkat yang terhubung dapat dijangkau, dan kredensial yang masuk ke dalam konteks model dapat bocor.
  • Manusia bergabung secara default.Agen tidak pernah mengaktifkan penggabungan otomatis di bawah akunnya sendiri. Penggabungan otomatis memerlukan CLI akun kedua yang disebutkan dalam permintaan Persyaratan pengiriman, dan instruksi default hanya mengizinkannya untuk permintaan penarikan kecil yang disetujui di bawah 200 baris yang diubah.
  • Itu dibangun di sekitar satu repositori.Setiap pengaturan mengawasi satu repositori GitHub, dan Feishu, alat obrolan tempat kerja yang umum di Tiongkok, adalah sumber kelas satu lainnya.
  • Anda memerlukan DeepSeek Harness dan penyedia model.Daftar pengaturan Node.js 22.19 atau lebih baru, pnpm, git 2.32 atau lebih baru, tmux, Python 3.8 atau lebih baru dan GitHub CLI 2.48 atau lebih baru. Mengonfigurasi penyedia model adalah langkah operator.
  • Kebisingan adalah biaya.Dokumen filosofi mengatakan untuk tidak menggunakan agen untuk menghasilkan volume. Permintaan penarikan massal dan pesan siaran membebani tim Anda lebih banyak daripada yang mereka keluarkan.

Bagaimana Anda mencobanya tanpa mempertaruhkan repositori utama Anda?

Penyiapannya memiliki banyak langkah, sehingga proyek meminta Anda untuk membiarkan agen pengkode melakukannya bersama Anda. Menurut README, agen mengajukan pertanyaan singkat satu per satu, menampilkan paket lengkap satu kali, lalu menginstal dan mengkonfigurasi semuanya. Proses pertama yang hati-hati terlihat seperti ini:

  1. Pilih repositori sekali pakaidan pengguna mesin khusus atau akun OS. Jangan gunakan login Anda sendiri.
  2. Buat akun GitHub terpisah untuk agen.Segala sesuatu yang ditulisnya muncul di bawah nama itu.
  3. Buka repositori di agen pengkodean Anda dan tempel perintah di bawah ini.Jawab pertanyaannya satu per satu.
  4. Simpan daftar yang diizinkan untuk Anda sendiridan biarkan mode terima di observasi.
  5. Minta sesuatu yang kecil.Dari akun yang diizinkan, beri komentar@<agent login> <request>pada suatu masalah. Tiket akan muncul di Ikhtisar panel dalam waktu sekitar satu menit.
  6. Baca tab Eval selama seminggu.Perluas daftar atau alihkan ke otomatis hanya jika rekaman “akan menerima” terlihat benar.
Prompt pengaturan dari proyek README
Read SETUP.md in this repository and set up dsh-superagent with me.

Dokumen filosofi proyek ini memberi operator empat aturan yang perlu diulangi: mulai dari yang sempit, sesuaikan dengan lebih sedikit kebisingan, jangan gunakan agen untuk menghasilkan volume, dan miliki apa yang tertulis di nama Anda.

Kemana perginya sisa pekerjaan agen?

Misalkan seorang pekerja menghabiskan satu jam untuk pengujian integrasi yang tidak stabil. Permintaan tarik adalah solusinya. Namun penyelidikan di balik hal tersebut, pengujian mana yang gagal, hipotesis mana yang dikesampingkan, apa yang ditunjukkan oleh tabel waktu, tidak termasuk dalam deskripsi PR, dan hal itulah yang ingin ditentang oleh pengulas. Jika itu hanya ada dalam balasan obrolan, agen atau rekan satu tim berikutnya memulai dari awal.

AgenGrid.iodibangun untuk handoff itu. Manusia dan agen AI bekerja pada dokumen, aplikasi, dan file langsung yang sama, dengan satu alamat stabil, akses terkontrol, dan riwayat versi. Dokumen AgentGrid.io menjelaskan cara menghubungkan agen berkemampuan perintah dengan menjalankannpx @animaapp/cli@latest login. Manusia menyetujui nama agen, tim, dan apa yang dapat dilakukannya: membaca, menulis, berbagi, atau mempublikasikan. Setelah itu, perubahan agen muncul di riwayat atas namanya sendiri. Prototipe ini tidak memiliki integrasi AgentGrid.io bawaan, jadi perlakukan ini sebagai pola untuk dicoba dengan pekerjanya, bukan fitur yang terdokumentasi.

Dalam praktiknya, pekerja menulis investigasinya sebagai file penurunan harga, pengulas berkomentar pada baris tabel, asisten lain memperketat ringkasan, dan permintaan penarikan menghubungkan ke satu versi saat ini, bukan tiga salinan yang ditempel.

Untuk pandangan lain tentang beberapa orang yang berbagi satu agen, lihat panduan kamiBot Tim Grok Bot. Dan jika Anda bertanya-tanya apa yang berjalan di bawah agen yang dihosting, panduan kami adalahClaude Managed Agentsmelihat versi Anthropic dari belahan otak dan tangan yang sama, yang dikutip dalam artikel DeepSeek.

Kapan sebaiknya Anda menggunakan dsh-superagent, dan kapan yang lain?

  • Gunakan dsh-superagentuntuk belajar dari desain yang serius dan terdokumentasi, untuk menjalankan eksperimen tertampung pada repositori berisiko rendah, atau untuk meminjam ide-idenya: router yang tidak pernah menjalankan kode, tiket dengan cakupan yang ditentukan, mode observasi sebelum mode otomatis.
  • Gunakan agen pengkodean interaktif tunggalketika Anda mengerjakan tugas satu per satu dan ingin mengarahkan langkah demi langkah. Agen Super dibangun untuk situasi sebaliknya.
  • Gunakan AgentGrid.ioketika keluarannya berupa dokumen, laporan, atau aplikasi yang perlu ditinjau, diedit, dan dipublikasikan oleh beberapa orang dan agen, agen mana pun yang memproduksinya.

Pertanyaan yang sering diajukan

Apa itu DeepSeek Super-Agent?

Ini adalah prototipe penelitian bernama dsh-superagent, dirilis oleh tim Harness DeepSeek pada tanggal 31 Oktober 2026 di bawah lisensi MIT. Ini adalah agen pengkodean proaktif untuk satu repositori GitHub. Sesi router yang berumur panjang menerima permintaan dan menugaskan setiap permintaan yang diterima ke sesi pekerjanya sendiri, yang menjawab dalam percakapan awal, biasanya dengan permintaan tarik.

Apakah DeepSeek Super-Agent merupakan produk resmi DeepSeek?

Tidak. README menyebutnya sebagai prototipe penelitian untuk referensi saja dan bukan produk resmi DeepSeek, dan meminta untuk meninjau dan mengadaptasinya sebelum menggunakannya di lingkungan Anda sendiri. Ini juga tidak identik dengan versi internal atau implementasi yang dijelaskan dalam artikel desain.

Apa perbedaan antara Agen Super dan Sub-Agen?

Sub-agen menambahkan lapisan di bawah agen yang bekerja. Agen Super menambahkan lapisan di atasnya. Dalam desain ini, router berada di atas banyak pekerja, berbicara dengan orang-orang dan mengirimkan tugas, sementara setiap pekerja menangani satu tugas secara terpisah. Namanya adalah tentang posisi, bukan klaim atas kecerdasan yang lebih tinggi.

Apakah perlu Feishu atau hanya GitHub?

GitHub saja sudah cukup. Feishu adalah sumber kedua opsional, dan dokumentasi mengatakan kegagalan pengaturan Feishu hanya menonaktifkan sumber Feishu.

Apakah aman dijalankan di repositori perusahaan?

Tidak sebagaimana adanya. Dokumen tersebut mengatakan bahwa pekerja dijalankan dengan akses penuh sebagai pengguna OS operator dan bahwa akun pembungkus bukanlah batas isolasi. Mereka merekomendasikan akun OS khusus, akun agen khusus di GitHub, daftar singkat yang diizinkan, dan mode pengamatan sambil mempelajari bagaimana agen berperilaku.

Apakah ini lebih cepat daripada sesi agen pengkodean tunggal?

Dalam pengujian simulasi penulis sendiri, desain router menyelesaikan tugas paling lambat dalam 15,7 menit dibandingkan 29,5 menit untuk satu sesi dengan alat subagen, menggunakan lebih banyak token. Pengujian ini menggunakan simulasi kerja pengkodean dan lima proses per desain, sehingga menunjukkan manfaat penjadwalan, bukan kualitas kode.