Apa yang terjadi ketika Anda merencanakan proyek besar tanpa ada yang memimpin? Sebagian besar tumpukan perangkat lunak mengasumsikan adanya satu orkestrator tunggal. Satu proses memegang status, mengantre pekerjaan, dan membagikan tugas. Jika koordinator tersebut dimulai ulang, seluruh alur kerja akan goyah. Proyek baru ini membalikkan asumsi tersebut sepenuhnya. Ia menunjukkan bagaimana sekawanan agen AI dapat menguraikan tujuan seperti "rencanakan perjalanan dua minggu ke Jepang" menjadi pohon tugas yang lengkap tanpa ada satu pun node yang memegang rencana lengkap pada satu waktu tertentu.
Mengapa Membangun Sistem Tanpa Pemimpin?
Perencana terpusat mudah untuk dipahami. Anda mengirim permintaan ke server, server membagi pekerjaan, dan pekerja melaporkan kembali. Masalahnya adalah server tersebut menjadi hambatan kognitif dan fisik. Ia memegang kendali atas kebenaran.
Dalam pengaturan terdistribusi, kebenaran berubah menjadi gambaran bersama yang disepakati oleh jaringan melalui gossip. Implementasi Python khusus ini menghubungkan dua konsep yang berbeda. Pertama adalah loop penyempurnaan iteratif: satu agen menulis proposal, agen lain memberinya skor, dan agen ketiga memolesnya. Kedua adalah lapisan jaringan peer-to-peer yang dibangun di atas libp2p, yang memungkinkan agen untuk saling menemukan secara otomatis tanpa registri atau load balancer. Hasilnya adalah sebuah klaster di mana rekan-rekan (peers) muncul, mengajukan proposal, memberikan suara, dan mengeksekusi tanpa ada yang berperan sebagai dirigen orkestra.
Empat Peran
Sistem ini menetapkan salah satu dari empat kepribadian kepada setiap partisipan. Anda tidak memerlukan empat mesin fisik. Mereka dapat hidup berdampingan di satu laptop atau tersebar di seluruh jaringan rumah. Peran-peran tersebut adalah:
Decomposer. Agen ini menerima tujuan tingkat atas dan mengajukan pembagian menjadi sub-tujuan. Karena sistem menjalankan beberapa decomposer secara paralel, Anda mungkin mendapatkan tiga skenario berbeda untuk perjalanan ke Jepang yang sama. Satu mungkin membagi perjalanan berdasarkan geografi: Tokyo, Kyoto, Osaka. Yang lain mungkin membagi berdasarkan aktivitas: transportasi, penginapan, makan, tamasya. Yang ketiga mungkin mengurutkan berdasarkan hari. Jaringan akan mempertimbangkan semuanya.
Scorer. Agen-agen ini bertindak sebagai dewan redaksi. Mereka memeriksa pembagian yang diusulkan dan memberinya nilai. Skor mencerminkan apakah sub-tujuan tersebut cukup konkret, tidak tumpang tindih, dan mencakup segalanya secara kolektif. Yang lebih penting, seorang scorer memutuskan apakah sebuah proposal cukup baik untuk diterima. Tanpa restunya, sebuah pembagian akan tetap dalam ketidakpastian.
Executor. Setelah pohon mencapai node daun yang cukup kecil untuk dikerjakan, para executor berlomba untuk mengklaimnya. Mereka tidak menunggu izin dari antrean pusat. Sebaliknya, mereka menggunakan protokol timestamp untuk menentukan siapa yang berhak atas sebuah tugas. Pemenangnya menjalankan pekerjaan tersebut melalui panggilan LLM lokal dan menyiarkan hasilnya.
Observer. Ini adalah pengamat pasif yang dibutuhkan oleh setiap jaringan. Ia mendengarkan gossip secara diam-diam, menyusun kembali pohon rencana dari percakapan tersebut, dan mencetak cuplikan yang dapat dibaca. Karena ia tidak pernah berbicara, ia membuktikan poin penting: siapa pun yang bergabung terlambat dapat memahami seluruh rencana hanya dengan mendengarkan percakapan yang ada.
Gossip sebagai Sumber Kebenaran
Lapisan libp2p menangani penemuan dan pengiriman pesan. Agen menemukan satu sama lain melalui fitur penemuan peer bawaan protokol, lalu menyiarkan pesan ke topik bersama. Tidak ada database utama, tidak ada cache Redis yang menyimpan rencana kanonikal.
Setiap peer menyimpan salinan pohon rencana mereka sendiri dan memperbaruinya berdasarkan gossip yang mereka dengar. Ketika seorang decomposer menyiarkan proposal, setiap node lain menerimanya, memvalidasi formatnya, dan menambahkan cabang tersebut ke pohon lokalnya. Ketika scorer memberikan suara, perhitungan suara menyebar dengan cara yang sama. Jika dua executor mempublikasikan klaim yang bertentangan untuk tugas yang sama, protokol timestamp akan menyelesaikan bentrokan tersebut. Jaringan akan menetapkan klaim yang lebih awal dan membuang klaim yang terlambat.
Seiring waktu, pohon tersebut tumbuh ke bawah dari tujuan asli melalui lapisan sub-tujuan yang diterima hingga mencapai tugas-tugas kecil yang mudah dikerjakan. Proses ini menyerupai blockchain yang mencapai konsensus, kecuali bahwa payload-nya adalah rencana perjalanan atau spesifikasi perangkat lunak, bukan buku besar koin.
Pemungutan Suara dan Perlombaan untuk Eksekusi
Demokrasi itu mahal, dan sistem ini membayar harganya dengan latensi. Sebuah pembagian hanya akan menang jika cukup banyak scorer yang setuju. Ambang batas tersebut bisa berupa mayoritas sederhana atau kuorum yang lebih ketat, tergantung pada bagaimana Anda mengonfigurasi klaster tersebut. Para decomposer tidak berhenti mengajukan proposal, sehingga jaringan sering kali mengevaluasi beberapa pohon yang bersaing secara bersamaan. Akhirnya, satu pohon mencapai jumlah suara yang diperlukan dan sub-tujuannya berubah dari draf menjadi diterima.
Executor menambahkan lapisan koordinasi lainnya. Karena tugas bersifat publik pada saluran gossip, beberapa executor mungkin mencoba mengambil leaf node yang sama yang menarik. Protokol timestamp bertindak sebagai tiebreaker. Setiap klaim membawa timestamp monotonik, dan jaringan akan memprioritaskan yang paling awal. Pihak yang kalah cukup beralih ke tugas berikutnya yang tersedia. Ini memang sederhana, tetapi menghindari kebutuhan akan penjadwal terpusat yang mengunci baris dalam database.
Resiliensi melalui Desain
Arsitektur ini membuktikan nilainya saat terjadi kegagalan. Jika sebuah decomposer crash setelah mengusulkan setengah dari subgoals, decomposer yang masih bertahan akan terus menawarkan split. Rencana tidak akan terhenti menunggu proses respawn. Jika sebuah scorer terputus dari jaringan, pemilih yang tersisa masih dapat mencapai quorum selama Anda mengatur ukuran klaster dengan tepat.
Keuntungan sebenarnya adalah late joins. Agen baru yang menyala di tengah proses tidak memerlukan snapshot atau sebuah