Membangun ruang kerja bersama untuk manusia dan agen

Bagaimana Proyek Perplexity menjaga pekerjaan jangka panjang tetap persisten, konkuren, dan dapat dilacak.

PenulisPerplexity Engineering

Kami baru saja meluncurkan Proyek, tempat manusia dan agen bekerja sama dalam tugas jangka panjang di Perplexity Computer. Setiap proyek berada di atas ruang kerja bersama dengan sistem file yang mengakumulasi konteks lintas sesi, agen, dan pengguna. Kolaborasi multipemain yang berlangsung selama berbulan-bulan membutuhkan persistensi, konkurensi, dan keterlacakan:

  • Persistensi: Pekerjaan harus tetap tahan lama melampaui sesi agen atau kotak pasir individual mana pun, sehingga pekerjaan di masa mendatang dapat dilanjutkan oleh pengguna atau agen yang sama dan dikembangkan lebih lanjut oleh kolaborator mana pun.
  • Konkurensi: Beberapa pengguna dalam proyek yang sama masing-masing dapat memiliki beberapa agen yang melakukan pengeditan secara paralel, yang memajukan status bersama alih-alih saling menimpa.
  • Keterlacakan: Pengguna dan agen sama-sama harus dapat melihat riwayat sehingga mereka dapat memeriksa siapa mengubah apa sejak sesi terakhir mereka tanpa membaca ulang seluruh proyek, serta membatalkan pengeditan bila diperlukan.

Tantangan-tantangan ini terasa familier bagi para insinyur perangkat lunak. Git forge muncul beberapa dekade lalu untuk memenuhi kebutuhan ini: layanan terhosting yang membungkus kontrol versi dengan fitur kolaboratif sehingga banyak kontributor dapat bertemu pada satu sumber kebenaran. Sistem file yang mendukung Proyek adalah salah satu Git forge semacam itu, yang dibangun untuk kolaborasi manusia-agen dan agen-agen.

Satu Proyek: agen interaktif, agen terjadwal, dan agen milik pengguna lain semuanya bermuara pada repositori yang sama.

Arsitektur

Git sudah menangani persistensi, konkurensi, dan keterlacakan. Git mengidentifikasi setiap file berdasarkan isinya, sehingga file yang tidak berubah hanya disimpan sekali dan salinan yang tersimpan tidak pernah menjadi usang. Setiap commit menyimpan semua file yang diperbarui sekaligus, sehingga kolaborator tidak pernah melihat keadaan yang setengah jadi. Ketika dua penulis bertabrakan, pihak yang kalah dapat menerapkan ulang perubahannya pada versi baru dan mencoba lagi. Rangkaian commit menunjukkan siapa mengubah apa dan memudahkan pemulihan versi sebelumnya. Yang tidak dibutuhkan agen adalah bagian lain dari forge yang dibuat untuk manusia, seperti layar peninjauan, manajemen branch, dan notifikasi.

Arsitektur kami menjalankan seluruh proses di cloud dan mendukung semua bentuk pekerjaan berbasis pengetahuan di luar pemrograman. Setiap proyek Computer didukung oleh repositori Git yang dilayani oleh 5 komponen:

  • CLI mengelola checkout lokal, menyinkronkan pembaruan, dan mengirimkan perubahan agen di setiap kotak pasir.
  • Control plane menemukan repositori proyek dan menerbitkan kredensial berumur pendek untuk mengaksesnya.
  • Layanan Git mengirimkan data repositori ke kotak pasir, menerima kiriman dari kotak pasir, dan memutuskan kiriman mana yang menjadi commit terbaru yang diterima.
  • Penyimpanan berbasis AWS S3 menyimpan data repositori secara tahan lama.
  • Pemrosesan hilir mengekstrak teks dan informasi berguna lainnya dari dokumen yang disimpan dan menyediakannya saat agen memuat atau memperbarui proyek.

Setiap agen memiliki kotak pasir terisolasinya sendiri. Di dalam kotak pasir tersebut, agen bekerja dengan salinan lokal repositori yang dikelola oleh CLI kecil. CLI meminta control plane untuk menemukan repositori, lalu mengambil dan mengirimkan perubahan melalui layanan Git. Proxy agen memeriksa akses untuk permintaan dari kotak pasir sebelum permintaan tersebut mencapai layanan Git. Layanan Git membaca dan menulis repositori di sistem file bersama, serta memutuskan apakah setiap kiriman menjadi commit terbaru yang diterima. Sistem file tersebut disediakan oleh AWS S3Files, yang membuat penyimpanan berbasis S3 dapat diakses sebagai file dan direktori biasa. Penyimpanan dibagi menjadi sel-sel terisolasi, masing-masing dengan sistem file dan replika layanan Git-nya sendiri. Setelah commit diterima, worker latar belakang mengekstrak teks dan informasi berguna lainnya dari dokumen yang berubah, menyimpan hasilnya secara terpisah dari riwayat repositori, dan menyediakannya saat agen memuat atau memperbarui proyek.

Selanjutnya, kami akan membahas komponen-komponen tersebut satu per satu.

CLI menghubungi control plane untuk menemukan repositorinya, lalu mengambil dan mengirimkan perubahan melalui layanan Git via proxy agen. Layanan Git memeriksa kiriman serta memperbarui head yang diterima dan outbox di DynamoDB. Replika lokal sel menggunakan penyimpanan S3Files, sementara worker hilir mengekstrak teks untuk checkout dan sinkronisasi.

CLI: Bekerja dengan file lokal di kotak pasir

Agen berjalan di SPACE, platform kotak pasir internal kami. Setiap kotak pasir memiliki CLI kecil yang mematerialisasi repositori dan menjaganya tetap tersinkron. Untuk setiap unit pekerjaan bermakna yang diselesaikan agen, CLI mengirimkan perubahan sebagai commit.

Agen biasanya hanya menyentuh sebagian kecil file proyek, sehingga tidak perlu mematerialisasi seluruh repositori di awal. Karena itu, CLI melakukan materialisasi secara lazy: file besar dan biner yang disimpan melalui Git Large File Storage (LFS) tiba sebagai file pointer kecil yang menyimpan ukuran asli objek, sehingga agen dapat menggunakan nama dan ukurannya untuk memutuskan apakah file tersebut layak diunduh. Untuk dokumen seperti PDF, agen terlebih dahulu membaca teks hasil parsing dan hanya mengunduh file sumber bila diperlukan.

Opsi alami lainnya adalah menggunakan sistem file virtual. Kami menguji implementasi berbasis FUSE, tetapi kinerjanya kira-kira 400 kali lebih lambat pada beban kerja yang intensif sistem file dibandingkan dengan file lokal, karena setiap permintaan memerlukan perjalanan pulang-pergi jaringan. Implementasi ini juga biasanya memerlukan kapabilitas istimewa dari host, sehingga setiap agen harus berjalan di kotak pasir dengan hak istimewa.

Ukuran pointer dan manifes parsing yang menentukan: baca teks hasil parsing, unduh sumber, atau lewati.

Control plane: Menemukan repositori dan memberikan akses

Control plane menemukan lokasi penyimpanan setiap repositori dan memberikan akses ke repositori tersebut. Saat repositori dibuat, control plane menetapkannya ke sel penyimpanan, yaitu unit penyimpanan terisolasi dengan replika layanan Git miliknya sendiri. Saat agen mulai mengerjakan proyek, CLI menanyakan kepada control plane di mana repositori disimpan. Control plane mengembalikan lokasi dan kredensial sementara untuk layanan Git. Control plane tidak pernah membaca atau menulis data repositori. Layanan Git-lah yang memutuskan apa yang masuk ke repositori.

Layanan Git: Memindahkan data dan mengoordinasikan pembaruan

Layanan Git menjalankan operasi Git dan mentransfer isi repositori serta riwayat versi antara kotak pasir dan penyimpanan. Layanan ini adalah pembungkus tipis di sekitar perintah penyajian bawaan Git. Layanan ini mendukung penemuan ref untuk memberi tahu klien di mana head repositori berada, upload-pack untuk kloning dan pengambilan, serta receive-pack untuk menerima objek baru dan permintaan untuk memajukan head repositori. Layanan ini juga menyajikan API Git LFS: untuk file besar dan biner, layanan ini menerbitkan tautan berumur pendek sehingga kotak pasir dapat mengunggah dan mengunduh file tersebut langsung dari S3.

Kami memulai dengan server forge siap pakai, sehingga kami dapat membuat prototipe antarmuka agen dan pengguna secara paralel sambil membangun forge ringan kami sendiri yang hanya berfokus pada operasi Git yang kami butuhkan.

Layanan ini terdiri atas armada replika, yang masing-masing merupakan instans berjalan dari server yang sama. Sel mengelompokkan penyimpanan bersama dengan sekumpulan replika dan layanan pendukungnya. Replika dalam satu sel kemudian dapat mengakses sistem file bersama yang sama, alih-alih memelihara salinan independen dari setiap repositori.

Penyimpanan bersama ini memungkinkan replika tetap stateless. Replika mana pun di dalam sel dapat melayani repositori mana pun di sel tersebut, sehingga mengganti atau menambah replika tidak memerlukan pemindahan data repositori antarserver. Permintaan untuk suatu repositori biasanya diarahkan ke replika yang sama agar cache-nya tetap berguna, tetapi repositori tidak bergantung pada ketersediaan instans tertentu tersebut.

Langkah penerimaan memeriksa invarian repositori untuk memastikan bahwa commit yang diterima merupakan status repositori yang valid. Kami mendefinisikan kontrak eksplisit untuk setiap repositori, sehingga pemeriksaan mekanis dapat mencegahnya tumbuh terlalu besar. File berukuran besar dan biner seperti PDF dan gambar disimpan melalui Git LFS, bukan sebagai blob Git mentah. Pemadatan (compaction) menjaga riwayat terbaru tetap tersedia sekaligus membatasi ukuran repositori. Setelah pengiriman berhasil, CLI menanyakan kepada layanan Git apakah repositori perlu dipadatkan. Jika jumlah commit yang disimpan melebihi ambang batas, layanan Git hanya menyimpan sekumpulan kecil commit terbaru. Riwayat yang lebih lama diganti dengan satu snapshot awal, dan commit terbaru diputar ulang untuk memperbarui pengidentifikasi commit.

Pemadatan mempertahankan commit terbaru, melipat riwayat lama menjadi satu root snapshot, dan memutar ulang commit terbaru dengan pengidentifikasi baru; head yang baru tetap memiliki file yang sama.

Langkah sinkronisasi sederhana menangani penulis yang bekerja secara bersamaan. Langkah ini melacak commit terbaru yang diterima, atau head. Saat menerima pengiriman, langkah ini hanya menerimanya jika pengiriman tersebut dibangun di atas head itu. Jika tidak, langkah ini mengirimkan respons stale-base yang terstruktur; pihak yang kalah kemudian perlu memutar ulang perubahannya di atas head yang baru dan mengirim ulang. Desain ini memastikan agen yang bekerja bersamaan tidak saling menimpa secara diam-diam, tanpa menyebabkan perlambatan yang signifikan. Dalam alur kerja produksi kami, kurang dari 2% pengiriman ditolak karena usang. Secara keseluruhan, median latensi pengiriman di bawah 1,7 detik, dan latensi p99 di bawah 8 detik.

Dua agen mengirimkan perubahan secara bersamaan; satu diterima, sedangkan yang lain menerima respons stale-base, memutar ulang perubahan di atas head yang baru, lalu mengirim ulang.

Layanan Git juga mencatat setiap perubahan yang diterima. Untuk setiap penulisan yang diterima, layanan ini menambahkan entri ke outbox, yaitu log yang mencantumkan repositori, commit baru, pengguna yang membuat perubahan, dan path yang berubah. Layanan hilir seperti parser membaca log ini untuk menemukan pekerjaan baru.

Bersama-sama, komponen-komponen ini membentuk lapisan manajemen repositori, tanpa bagian-bagian yang tidak dibutuhkan agen. Pull request tidak diperlukan karena tidak ada manusia yang meninjau setiap perubahan. Sebagai gantinya, layanan Git memeriksa kontrak saat pengiriman, agen yang kalah dalam perlombaan menerapkan ulang perubahannya sendiri, dan riwayat commit mencatat siapa mengubah apa. Pemeriksaan deterministik menjaga setiap repositori tetap sesuai kontraknya, alih-alih mengandalkan operator manusia untuk mengelola pertumbuhan.

Penyimpanan: Menjaga pekerjaan tetap tahan lama

Lapisan penyimpanan menyimpan data repositori secara tahan lama, terpisah dari kotak pasir dan replika layanan Git. Repositori disimpan di AWS S3Files, yang mengekspos penyimpanan berbasis S3 melalui antarmuka sistem file yang dapat digunakan Git standar tanpa modifikasi. Masing-masing merupakan repositori Git bare di sistem file bersama, yang berisi objek dan referensi repositori, bukan checkout kerja.

Memisahkan penyimpanan dan komputasi memungkinkan kotak pasir tetap bersifat sementara. Setiap agen mendapatkan kotak pasirnya sendiri, dan banyak agen dapat bekerja pada proyek yang sama tanpa berbagi mesin. Jika kotak pasir mengalami crash, hanya pekerjaan yang belum dikirimkan yang berisiko hilang.

Sebagai alternatif, kami dapat memberi setiap proyek kotak pasir berumur panjang yang digunakan bersama oleh semua agennya, sehingga file proyek akan berada di disk mesin tersebut. Namun, cara ini akan mengikat komputasi agen ke lokasi mesin itu berjalan dan mengharuskan mesin tersebut berukuran cukup untuk periode tersibuknya. Mesin itu juga harus tetap sehat selama berbulan-bulan, dengan pencadangan dan pemulihan yang dikelola sebagai bagian dari sistem penyimpanan proyek.

Satu kotak pasir berumur panjang yang digunakan bersama oleh agen-agen proyek, dibandingkan dengan kotak pasir berumur pendek per agen yang menjangkau penyimpanan bersama yang tahan lama melalui replika layanan Git stateless.

Pemrosesan hilir: Membuat dokumen dapat dibaca oleh agen

Komponen hilir utama adalah pipeline parser yang mengekstrak teks dan metadata dari dokumen yang baru ditambahkan atau diperbarui agar file proyek mudah dibaca oleh agen. Worker parser mengonsumsi pembaruan dari antrean aliran perubahan, menurunkan daftar file yang berubah dari metadata commit, dan mengambil byte mentah menggunakan hash konten. Kemudian, worker tersebut mem-parsing dokumen untuk menghasilkan teks hasil ekstraksi dan metadata dokumen.

Output hasil parsing disimpan di luar repositori, dalam penyimpanan yang menggunakan hash dokumen sumber sebagai kunci. Artefak ini tidak pernah di-commit kembali ke repositori, karena hal itu akan mencemari riwayat secara tidak perlu dan meningkatkan jumlah penulisan bersamaan. Sebagai gantinya, output hasil parsing sampai ke kotak pasir melalui checkout dan sinkronisasi. Setiap checkout membawa direktori khusus yang digunakan CLI untuk materialisasi artefak. Parsing berlangsung secara asinkron, sehingga worker parser latar belakang tidak memblokir checkout.

Cara agen menggunakan ruang kerja

Agen menjelajahi versi repositori yang dimuat ke dalam kotak pasir menggunakan alat sistem file standar. Alih-alih mengikuti pipeline cari-lalu-baca yang tetap, agen menampilkan daftar folder, mencari isi file dengan grep, membaca bagian yang relevan, dan menggunakan temuan mereka untuk memutuskan ke mana harus mencari berikutnya.

Serupa dengan Computer, Search menggunakan pendekatan yang sama melalui alat file standarnya. Agen eksplorasi terpisah menelusuri proyek dengan anggaran yang lebih terbatas dan mengembalikan path file yang relevan beserta kutipan pendukung. Model penjawab kemudian membaca file yang dipilih dan menghasilkan jawaban. Menggunakan kembali kotak pasir proyek yang sudah ada mengurangi waktu penyiapan: menyambung ke checkout yang sudah hangat memerlukan sekitar 2,9 detik, dibandingkan dengan sekitar 8 detik untuk cold start.

Kotak pasir Computer, subagen eksplorasi Ask, penulis pengetahuan latar belakang, dan worker parser semuanya membaca dari dan menulis ke repositori dan outbox yang sama.

Teks hasil parsing membuat dokumen yang lebih besar seperti PDF dan file Office dapat dicari dengan alat yang sama. Agen terlebih dahulu memeriksa manifes, yaitu daftar yang menunjukkan dokumen mana yang memiliki teks hasil ekstraksi, lalu mencari dan membaca teks tersebut sebagai file biasa. Agen hanya mengunduh dokumen asli jika teks tidak memadai, misalnya untuk memeriksa gambar, tata letak, atau data yang disematkan.

Kami membandingkan pendekatan ini dengan pencarian semantik berbasis indeks pada 150 pertanyaan keuangan dokumen tunggal atas korpus yang sama. Agen eksplorasi mencetak skor 0,867 dalam menemukan dokumen yang benar dan 0,627 dalam menjawab dengan benar, dibandingkan sekitar 0,39 dan 0,37 untuk pencarian semantik, atau sekitar 1,7x lebih baik dalam jawaban dan 2x lebih baik dalam pengambilan, dengan latensi sekitar 25% lebih rendah. Agen eksplorasi sebagian besar bekerja dengan teks hasil ekstraksi dan jarang mengunduh PDF aslinya.

Eksplorasi versus pencarian file semantik pada tolok ukur internal.

Satu infrastruktur bersama

Memori persisten Computer menggunakan infrastruktur sistem file yang sama. Perplexity Brain, wiki pengetahuan Computer, menyimpan memori di repositori pengetahuan dengan riwayat dan kebijakannya sendiri. Memisahkan pengetahuan dari file proyek berarti pembaruan memori di latar belakang tidak bersaing dengan pengeditan pada file-file tersebut. Sesi yang membutuhkan keduanya akan memuat kedua repositori.

Agen latar belakang membaca pengetahuan yang ada, memasukkan informasi baru, dan menyimpan halaman yang diperbarui sebagai commit. Agen lain membaca halaman tersebut dengan alat file biasa, dan manusia juga dapat mengeditnya. Penulis berbagi pekerjaan mereka melalui repositori alih-alih berkoordinasi langsung dengan setiap pembaca. Riwayat commit mencatat siapa mengubah apa, sementara outbox melaporkan pembaruan yang diterima ke layanan hilir. Manusia dan agen dapat saling melanjutkan pekerjaan satu sama lain, dengan catatan tentang bagaimana pengetahuan itu berkembang.

Kesimpulan

Ketika manusia dan agen berbagi proyek, ruang kerja melakukan lebih dari sekadar menyimpan file. Ruang kerja menyediakan tempat bersama untuk menggabungkan kontribusi dan melacak apa yang berubah. Git sudah menyediakan sebagian besar fondasi tersebut. Kami menambahkan koordinasi dan pemeriksaan otomatis sehingga agen dapat mengirimkan pekerjaan tanpa perlu persetujuan manusia untuk setiap pembaruan. Hasilnya adalah forge yang dipangkas hingga ke intinya, karena kolaborasi lintas agen dan pengembangan perangkat lunak dengan banyak kontributor pada dasarnya adalah masalah yang sama.

Agen bekerja di kotak pasir yang independen dan sementara sambil berkontribusi pada repositori yang tahan lama. Batas repositori menjaga pertumbuhan tetap terkendali, unduhan eksplisit memungkinkan agen memilih apa yang akan diambil, dan file biasa memungkinkan mereka menjelajah dengan alat yang sudah dikenal. Pembaruan di latar belakang, pengeditan interaktif, dan tugas terjadwal dapat saling melanjutkan pekerjaan satu sama lain tanpa koordinasi langsung.

Seiring semakin banyaknya agen yang bekerja secara otonom di dalam Proyek, ruang kerja bersama mereka harus tetap andal dan mudah dipahami oleh manusia. Tujuannya sederhana: setiap perubahan harus lebih tahan lama daripada agen yang menghasilkannya, tersedia bagi kolaborator berikutnya, dan meninggalkan catatan yang jelas tentang apa yang berubah.

Sitasi

BibTeX
@online{perplexity2026BuildingSharedWorkspacesForPeopleAndAgents,
  author = {{Perplexity} and Se Won Jang and Peter Hart and Kartik Kapur and Kevin Lau and Sidhant Rajadnya and Ishbir Singh and Thomas Wang and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Building shared workspaces for people and agents}},
  date = {2026-10-12},
  url = {https://www.perplexity.ai/hub/blog/building-shared-workspaces-for-people-and-agents}
}