İnsanlar ve ajanlar için ortak çalışma alanları oluşturmak
Perplexity'nin Projeler özelliği, uzun soluklu çalışmaları nasıl kalıcı, eşzamanlı ve izlenebilir kılıyor?
Kısa süre önce Perplexity Computer'da Projeler'i kullanıma sunduk; burada insanlar ve ajanlar uzun soluklu görevler üzerinde birlikte çalışıyor. Her proje, oturumlar, ajanlar ve kullanıcılar arasında bağlam biriktiren bir dosya sistemine sahip ortak bir çalışma alanında yer alır. Aylarca süren çok kullanıcılı iş birliği kalıcılık, eşzamanlılık ve izlenebilirlik gerektirir:
- Kalıcılık: Çalışmalar, tek bir ajan oturumunun veya korumalı alanın ömründen daha uzun süre kalıcı olmalıdır; böylece gelecekte aynı kullanıcı veya ajan çalışmaya devam edebilir ve diğer katılımcılar bu çalışmanın üzerine inşa edebilir.
- Eşzamanlılık: Aynı projedeki birden fazla kullanıcının her biri, paralel olarak düzenleme yapan birden fazla ajana sahip olabilir; bu ajanlar birbirlerinin üzerine yazmak yerine ortak bir durumu ilerletir.
- İzlenebilirlik: Hem kullanıcılar hem de ajanlar geçmişi görebilmelidir; böylece projenin tamamını yeniden okumadan son oturumlarından bu yana kimin neyi değiştirdiğini kontrol edebilir ve gerektiğinde düzenlemeleri geri alabilirler.
Bu zorluklar yazılım mühendislerine tanıdık gelecektir. Git forge'ları bu gereksinimleri karşılamak için onlarca yıl önce ortaya çıktı: Sürüm kontrolünü iş birliği özellikleriyle saran ve birçok katkıda bulunanın tek bir doğruluk kaynağında buluşmasını sağlayan, barındırılan bir hizmet. Projelere güç veren dosya sistemi de insan-ajan ve ajan-ajan iş birlikleri için oluşturulmuş böyle bir Git forge'udur.
Mimari
Git kalıcılığı, eşzamanlılığı ve izlenebilirliği zaten sağlıyor. Her dosyayı içeriğine göre tanımladığı için değişmeyen dosyalar yalnızca bir kez depolanır ve kaydedilen kopyalar asla güncelliğini yitirmez. Her commit, güncellenen tüm dosyaları tek seferde kaydeder; böylece katılımcılar hiçbir zaman yarım kalmış bir durum görmez. İki yazıcı çakıştığında, kaybeden taraf değişikliklerini yeni sürüm üzerine yeniden uygulayıp tekrar deneyebilir. Commit zinciri kimin neyi değiştirdiğini gösterir ve önceki sürümleri geri yüklemeyi kolaylaştırır. Ajanların ihtiyaç duymadığı şey ise inceleme ekranları, dal yönetimi ve bildirimler gibi, insanlar için tasarlanmış bir forge'un geri kalanıdır.
Mimarimiz tüm süreci bulutta yürütür ve kodlamanın ötesinde her türlü bilgi işini destekler. Her Computer projesi, 5 bileşen tarafından sunulan bir Git deposuyla desteklenir:
- CLI, her korumalı alanda yerel checkout'ları yönetir, güncellemeleri senkronize eder ve ajanın değişikliklerini gönderir.
- Kontrol düzlemi, proje deposunu bulur ve depoya erişmek için kısa ömürlü kimlik bilgileri verir.
- Git hizmeti, depo verilerini korumalı alanlara gönderir, onlardan gelen gönderimleri alır ve hangi gönderimin en son kabul edilen commit olacağına karar verir.
- AWS S3 destekli depolama, depo verilerini kalıcı olarak saklar.
- Aşağı akış işleme, kaydedilen belgelerden metin ve diğer yararlı bilgileri çıkarır ve ajanlar projeyi yüklediğinde veya yenilediğinde bunları kullanıma sunar.
Her ajanın kendine ait yalıtılmış bir korumalı alanı vardır. Ajan bu korumalı alanda, küçük bir CLI tarafından yönetilen yerel bir depo kopyasıyla çalışır. CLI, depoyu bulmak için kontrol düzlemine başvurur, ardından değişiklikleri Git hizmeti üzerinden getirir ve gönderir. Bir ajan proxy'si, korumalı alan isteklerinin erişim yetkisini bu istekler Git hizmetine ulaşmadan önce denetler. Git hizmeti depoları paylaşılan bir dosya sisteminde okuyup yazar ve her gönderimin en son kabul edilen commit olup olmayacağına karar verir. Bu dosya sistemi, S3 destekli depolamaya sıradan dosyalar ve dizinler olarak erişilmesini sağlayan AWS S3Files tarafından sunulur. Depolama, her biri kendi dosya sistemine ve Git hizmeti replikalarına sahip yalıtılmış hücrelere ayrılmıştır. Bir commit kabul edildikten sonra arka plan çalışanları, değişen belgelerden metin ve diğer yararlı bilgileri çıkarır; sonuçları depo geçmişinden ayrı olarak saklar ve ajanlar projeyi yüklediğinde veya yenilediğinde kullanıma sunar.
Şimdi bileşenleri tek tek ele alalım.
CLI: Korumalı alanlarda yerel dosyalarla çalışma
Ajanlar, şirket içinde geliştirdiğimiz korumalı alan platformu SPACE üzerinde çalışır. Her korumalı alanda, depoyu yerelde oluşturan ve senkronize tutan küçük bir CLI bulunur. CLI, ajanın gerçekleştirdiği her anlamlı iş birimi için değişiklikleri bir commit olarak gönderir.
Ajanlar genellikle proje dosyalarının yalnızca küçük bir kısmına dokunur; bu nedenle deponun tamamını baştan yerelde oluşturmak gerekmez. Bu yüzden CLI dosyaları gecikmeli olarak oluşturur: Git Large File Storage (LFS) üzerinden depolanan büyük ve ikili dosyalar, nesnenin gerçek boyutunu içeren küçük işaretçi dosyaları olarak gelir; böylece ajan, indirmeye değip değmeyeceğine dosyanın adına ve boyutuna bakarak karar verebilir. PDF gibi belgelerde ajan önce ayrıştırılmış metni okur ve kaynak dosyaları yalnızca gerektiğinde indirir.
Bir diğer doğal seçenek de sanal bir dosya sistemi kullanmak olurdu. FUSE destekli bir uygulamayı test ettik; ancak her istek bir ağ gidiş-dönüşü gerektirdiğinden, dosya sistemi yoğun iş yüklerinde yerel dosyalara kıyasla yaklaşık 400 kat daha yavaştı. Ayrıca bu yöntem genellikle ana makineden ayrıcalıklı yetenekler gerektirdiğinden her ajanın ayrıcalıklı bir korumalı alanda çalışması gerekirdi.
Kontrol düzlemi: Depoları bulma ve erişim yetkisi verme
Kontrol düzlemi, her deponun nerede depolandığını belirler ve depoya erişim yetkisi verir. Bir depo oluşturulduğunda kontrol düzlemi onu bir depolama hücresine atar; depolama hücresi, kendi Git hizmeti replikalarına sahip yalıtılmış bir depolama birimidir. Bir ajan bir proje üzerinde çalışmaya başladığında CLI, deponun nerede depolandığını kontrol düzlemine sorar. Kontrol düzlemi, konumu ve Git hizmeti için geçici kimlik bilgilerini döndürür. Kontrol düzlemi depo verilerini hiçbir zaman okumaz veya yazmaz. Bir depoya neyin gireceğine Git hizmeti karar verir.
Git hizmeti: Verileri taşıma ve güncellemeleri koordine etme
Git hizmeti, Git işlemlerini yürütür ve depo içeriklerini ve sürüm geçmişini korumalı alanlar ile depolama arasında aktarır. Git'in kendi sunma komutlarını saran ince bir katmandır. İstemciye deponun head'inin nerede olduğunu bildirmek için ref keşfini, klonlama ve getirme için upload-pack'i, yeni nesneleri ve deponun head'ini ilerletme isteğini almak için de receive-pack'i destekler. Ayrıca Git LFS API'sini de sunar: Büyük ve ikili dosyalar için kısa ömürlü bağlantılar oluşturur; böylece korumalı alanlar bu dosyaları doğrudan S3'e yükleyip S3'ten indirebilir.
Hazır bir forge sunucusuyla başladık; böylece yalnızca ihtiyaç duyduğumuz Git işlemlerine odaklanan kendi hafif forge'umuzu geliştirirken ajan ve kullanıcı arayüzlerinin prototiplerini paralel olarak oluşturabildik.
Hizmet, her biri aynı sunucunun çalışan bir örneği olan bir replika filosundan oluşur. Hücre, paylaşılan depolamayı bir dizi replika ve bunların destekleyici hizmetleriyle bir araya getirir. Böylece bir hücredeki replikalar, her deponun bağımsız kopyalarını tutmak yerine aynı paylaşılan dosya sistemine erişebilir.
Bu paylaşılan depolama, replikaların durumsuz kalmasını sağlar. Hücredeki herhangi bir replika, hücrenin depolarından herhangi birine hizmet verebilir; bu nedenle replikaları değiştirmek veya yeni replika eklemek, depo verilerinin sunucular arasında taşınmasını gerektirmez. Bir depoya yönelik istekler, önbelleklerin işe yaraması için normalde aynı replikaya gider; ancak depo, söz konusu örneğin erişilebilir kalmasına bağlı değildir.
Kabul adımı, kabul edilen bir commit'in geçerli bir depo durumu olmasını sağlamak için depo değişmezlerini denetler. Her depo için açık bir sözleşme tanımlıyoruz; böylece mekanik denetimler deponun aşırı büyümesini önleyebilir. PDF'ler ve görseller gibi büyük ve ikili dosyalar, ham Git blob'ları olarak değil Git LFS üzerinden depolanır. Sıkıştırma, deponun boyutunu sınırlarken yakın geçmişin erişilebilir kalmasını sağlar. Başarılı bir gönderimin ardından CLI, Git hizmetine deponun sıkıştırılması gerekip gerekmediğini sorar. Saklanan commit sayısı bir eşiği aşarsa Git hizmeti yalnızca en son commit'lerden oluşan daha küçük bir kümeyi tutar. Eski geçmiş tek bir başlangıç anlık görüntüsüyle değiştirilir ve commit tanımlayıcılarını güncellemek için son commit'ler yeniden oynatılır.
Basit bir senkronizasyon adımı, eşzamanlı yazıcıları denetim altında tutar. Bu adım, en son kabul edilen commit'i, yani head'i izler. Bir gönderim aldığında, yalnızca gönderim bu head üzerine oluşturulmuşsa kabul eder. Aksi takdirde yapılandırılmış bir eski temel (stale-base) yanıtı gönderir; kaybeden taraf da değişikliğini yeni head üzerine yeniden oynatıp tekrar göndermelidir. Bu tasarım, belirgin yavaşlamalara yol açmadan eşzamanlı ajanların birbirinin üzerine sessizce yazmasını önler. Üretim iş akışlarımızda gönderimlerin %2'sinden azı, eski temele dayandığı gerekçesiyle reddediliyor. Genel olarak medyan gönderim gecikmesi 1,7 saniyenin, p99 gecikmesi ise 8 saniyenin altındadır.
Git hizmeti ayrıca kabul edilen her değişikliği kaydeder. Kabul edilen her yazma işlemi için bir giden kutusuna (outbox) kayıt ekler; giden kutusu, depoyu, yeni commit'i, değişikliği yapan kullanıcıyı ve değişen yolları listeleyen bir günlüktür. Ayrıştırıcı gibi aşağı akış hizmetleri, yeni işleri bulmak için bu günlüğü okur.
Bu parçalar bir araya gelerek, ajanların ihtiyaç duymadığı kısımlar olmadan bir depo yönetim katmanı oluşturur. Hiçbir insan her değişikliği tek tek incelemediği için pull request'lere gerek yoktur. Bunun yerine Git hizmeti gönderim sırasında sözleşmeyi denetler, yarışı kaybeden ajan kendi değişikliğini yeniden uygular ve commit geçmişi kimin neyi değiştirdiğini kaydeder. Deterministik denetimler, büyümeyi yönetmek için bir insan operatöre güvenmek yerine her depoyu kendi sözleşmesinin sınırları içinde tutar.
Depolama: Çalışmaları kalıcı tutma
Depolama katmanı, depo verilerini korumalı alanlardan ve Git hizmeti replikalarından bağımsız olarak kalıcı biçimde saklar. Depolar, S3 destekli depolamayı standart Git'in değişiklik yapılmadan kullanabileceği bir dosya sistemi arayüzü üzerinden sunan AWS S3Files'ta bulunur. Her biri, paylaşılan dosya sisteminde yer alan ve çalışma checkout'u yerine deponun nesnelerini ve referanslarını içeren yalın (bare) bir Git deposudur.
Depolama ile işlem gücünü birbirinden ayırmak, korumalı alanların geçici kalabilmesini sağlar. Her ajan kendi korumalı alanını alır ve birçok ajan bir makineyi paylaşmadan aynı proje üzerinde çalışabilir. Bir korumalı alan çökerse yalnızca henüz gönderilmemiş çalışmalar risk altında olur.
Bunun yerine her projeye, tüm ajanlarının paylaştığı uzun ömürlü bir korumalı alan verebilirdik; böylece projenin dosyaları o makinenin diskinde bulunurdu. Ancak bu, ajanların işlem gücünü makinenin çalıştığı yere bağlar ve makinenin en yoğun dönemlerine göre boyutlandırılmasını gerektirirdi. Ayrıca makinenin aylarca sağlıklı kalması, yedekleme ve kurtarma işlemlerinin de projenin depolama sisteminin bir parçası olarak yönetilmesi gerekirdi.
Aşağı akış işleme: Belgeleri ajanlar için okunabilir hale getirme
Başlıca aşağı akış bileşeni, proje dosyalarını ajanlar için kolayca okunabilir hale getirmek amacıyla yeni eklenen veya güncellenen belgelerden metin ve meta verileri çıkaran bir ayrıştırıcı işlem hattıdır. Bir ayrıştırıcı çalışanı, değişiklik akışı kuyruğundaki güncellemeleri tüketir, değişen dosyaları commit meta verilerinden belirler ve ham baytları içerik karmasını kullanarak getirir. Ardından belgeyi ayrıştırarak çıkarılan metni ve belge meta verilerini üretir.
Ayrıştırılmış çıktılar depo dışında, kaynak belgenin karma değerini anahtar olarak kullanan ayrı bir veri deposunda tutulur. Bu yapıtlar hiçbir zaman depoya geri commit edilmez; çünkü bu, geçmişi gereksiz yere kirletir ve eşzamanlı yazma sayısını artırırdı. Bunun yerine ayrıştırılmış çıktılar, korumalı alana checkout ve senkronizasyon yoluyla ulaşır. Her checkout, CLI'ın yapıtları yerelde oluşturmak için kullandığı ayrılmış bir dizin içerir. Ayrıştırma eşzamansız olarak gerçekleştiği için arka plandaki ayrıştırıcı çalışanı checkout'ları engellemez.
Ajanlar çalışma alanını nasıl kullanıyor
Ajanlar, korumalı alana yüklenen depo sürümünü standart dosya sistemi araçlarıyla keşfeder. Sabit bir önce ara, sonra oku işlem hattını izlemek yerine klasörleri listeler, grep ile dosya içeriklerinde arama yapar, ilgili bölümleri okur ve bulduklarına göre bir sonraki adımda nereye bakacaklarına karar verirler.
Computer'a benzer şekilde Search de standart dosya araçları aracılığıyla aynı yaklaşımı kullanır. Ayrı bir keşif ajanı, projeyi daha sınırlı bir bütçeyle tarar ve ilgili dosya yollarını ve destekleyici alıntıları döndürür. Ardından yanıt modeli seçilen dosyaları okur ve yanıtı oluşturur. Mevcut bir proje korumalı alanını yeniden kullanmak kurulum süresini kısaltır: Hazır (warm) bir checkout'a bağlanmak yaklaşık 2,9 saniye sürerken soğuk başlatma yaklaşık 8 saniye sürer.
Ayrıştırılmış metin, PDF'ler ve Office dosyaları gibi daha büyük belgelerin de aynı araçlarla aranabilmesini sağlar. Ajan önce, hangi belgeler için çıkarılmış metin bulunduğunu gösteren bir liste olan manifesti denetler; ardından bu metni sıradan dosyalar gibi arar ve okur. Orijinal belgeyi yalnızca metin yetersiz kaldığında, örneğin şekilleri, düzeni veya gömülü verileri incelemek için indirir.
Bu yaklaşımı, aynı derlem üzerinde tek belgeli 150 finansal soruda, bir dizin üzerinden yapılan anlamsal aramayla karşılaştırdık. Keşif ajanı doğru belgeyi bulmada 0,867, doğru yanıt vermede 0,627 puan aldı; anlamsal aramada bu değerler sırasıyla yaklaşık 0,39 ve 0,37 oldu. Bu, yaklaşık %25 daha düşük gecikmeyle yanıtlarda yaklaşık 1,7 kat, bulmada ise 2 kat daha iyi sonuç anlamına geliyor. Keşif ajanı çoğunlukla çıkarılmış metinle çalışır ve orijinal PDF'leri nadiren indirir.
Tek bir ortak altyapı
Computer'ın kalıcı belleği de aynı dosya sistemi altyapısını kullanır. Computer'ın bilgi wiki'si olan Perplexity Brain, belleği kendi geçmişine ve politikalarına sahip bilgi depolarında saklar. Bilgiyi proje dosyalarından ayrı tutmak, arka plandaki bellek güncellemelerinin bu dosyalardaki düzenlemelerle çakışmamasını sağlar. Her ikisine de ihtiyaç duyan bir oturum, iki depoyu da yükler.
Arka plan ajanları mevcut bilgileri okur, yeni bilgileri ekler ve güncellenen sayfaları commit olarak kaydeder. Diğer ajanlar bu sayfaları sıradan dosya araçlarıyla okur; insanlar da bu sayfaları düzenleyebilir. Yazıcılar, her okuyucuyla doğrudan koordinasyon kurmak yerine çalışmalarını depo aracılığıyla paylaşır. Commit geçmişi kimin neyi değiştirdiğini kaydederken giden kutusu, kabul edilen güncellemeleri aşağı akış hizmetlerine bildirir. İnsanlar ve ajanlar, bilginin nasıl geliştiğinin kaydını tutarak birbirlerinin çalışmalarını temel alıp ilerleyebilir.
Sonuç
İnsanlar ve ajanlar bir projeyi paylaştığında çalışma alanı, dosya depolamaktan fazlasını yapar. Katkıları birleştirmek ve nelerin değiştiğini izlemek için ortak bir yer sağlar. Git bu temelin büyük bölümünü zaten sunuyor. Biz de ajanların, her güncellemenin bir kişi tarafından onaylanmasına gerek kalmadan çalışmalarını gönderebilmeleri için koordinasyon ve otomatik denetimler ekliyoruz. Sonuç, özüne indirgenmiş bir forge; çünkü ajanlar arası iş birliği ile çok katılımcılı yazılım geliştirme, temelde aynı sorundur.
Ajanlar, kalıcı depolara katkıda bulunurken bağımsız ve geçici korumalı alanlarda çalışır. Depo sınırları büyümeyi yönetilebilir tutar, açık indirmeler ajanların neyi getireceğini seçmesine olanak tanır ve sıradan dosyalar tanıdık araçlarla keşif yapmalarını sağlar. Arka plan güncellemeleri, etkileşimli düzenlemeler ve zamanlanmış görevler, doğrudan koordinasyon gerektirmeden birbirlerinin çalışmalarını temel alarak ilerleyebilir.
Projelerde özerk olarak çalışan ajanların sayısı arttıkça, ortak çalışma alanlarının güvenilir ve insanlar için anlaşılır kalması gerekir. Hedef basit: Her değişiklik, onu üreten ajandan daha kalıcı olmalı, bir sonraki katılımcının erişimine açılmalı ve neyin değiştiğine dair net bir kayıt bırakmalıdır.
Atıf
@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}
}