लोगों और एजेंटों के लिए साझा वर्कस्पेस बनाना

हमने हाल ही में Perplexity Computer में प्रोजेक्ट लॉन्च किया है, जहाँ लोग और एजेंट लंबे समय तक चलने वाले कार्यों पर साथ मिलकर काम करते हैं। हर प्रोजेक्ट एक साझा वर्कस्पेस पर आधारित होता है, जिसमें एक फ़ाइलसिस्टम होता है जो सत्रों, एजेंटों और उपयोगकर्ताओं के बीच संदर्भ इकट्ठा करता है। महीनों तक चलने वाले मल्टीप्लेयर सहयोग के लिए स्थायित्व, समवर्तिता और ट्रेसेबिलिटी ज़रूरी हैं:

• स्थायित्व: काम किसी एक एजेंट सत्र या सैंडबॉक्स के ख़त्म होने के बाद भी सुरक्षित रहना चाहिए, ताकि वही उपयोगकर्ता या एजेंट भविष्य में काम जारी रख सके और कोई भी सहयोगी उसे आगे बढ़ा सके।
• समवर्तिता: एक ही प्रोजेक्ट में कई उपयोगकर्ता, हर एक अपने कई एजेंटों के साथ, समानांतर रूप से संपादन कर सकते हैं, जो एक-दूसरे को ओवरराइड करने के बजाय एक साझा स्थिति को आगे बढ़ाते हैं।
• ट्रेसेबिलिटी: उपयोगकर्ता और एजेंट, दोनों इतिहास देख सकें, ताकि पूरे प्रोजेक्ट को दोबारा पढ़े बिना यह जाँच सकें कि उनके पिछले सत्र के बाद किसने क्या बदला, और ज़रूरत पड़ने पर संपादनों को रोल बैक कर सकें।

ये चुनौतियाँ सॉफ़्टवेयर इंजीनियरों को जानी-पहचानी लगेंगी। इन्हीं ज़रूरतों को पूरा करने के लिए दशकों पहले Git फ़ोर्ज सामने आए: एक होस्ट की गई सेवा, जो वर्शन कंट्रोल को सहयोगी सुविधाओं के साथ जोड़ती है, ताकि कई योगदानकर्ता सत्य के एक ही स्रोत पर एकजुट हो सकें। प्रोजेक्ट को चलाने वाला फ़ाइलसिस्टम ऐसा ही एक Git फ़ोर्ज है, जो इंसान-एजेंट और एजेंट-एजेंट सहयोग के लिए बनाया गया है।

बड़ा करें

आर्किटेक्चर

Git पहले से ही स्थायित्व, समवर्तिता और ट्रेसेबिलिटी को संभालता है। यह हर फ़ाइल को उसकी सामग्री से पहचानता है, इसलिए अपरिवर्तित फ़ाइलें केवल एक बार स्टोर होती हैं और सहेजी गई प्रतियाँ कभी पुरानी नहीं पड़तीं। हर कमिट सभी अपडेट की गई फ़ाइलों को एक साथ सहेजता है, इसलिए सहयोगियों को कभी अधूरी स्थिति नहीं दिखती। जब दो राइटर टकराते हैं, तो हारने वाला नए संस्करण पर अपने बदलाव दोबारा लागू करके फिर से कोशिश कर सकता है। कमिट की शृंखला दिखाती है कि किसने क्या बदला और पुराने संस्करणों को बहाल करना आसान बनाती है। एजेंटों को जिसकी ज़रूरत नहीं है, वह है इंसानों के लिए बनाए गए फ़ोर्ज का बाकी हिस्सा, जैसे समीक्षा स्क्रीन, ब्रांच प्रबंधन और सूचनाएँ।

हमारा आर्किटेक्चर पूरी प्रक्रिया को क्लाउड पर चलाता है और कोडिंग से आगे बढ़कर हर तरह के नॉलेज वर्क को सपोर्ट करता है। हर Computer प्रोजेक्ट एक Git रिपॉज़िटरी पर आधारित है, जिसे 5 कंपोनेंट्स सर्व करते हैं:

• CLI हर सैंडबॉक्स में लोकल चेकआउट बनाए रखता है, अपडेट सिंक करता है और एजेंट के बदलाव सबमिट करता है।
• कंट्रोल प्लेन प्रोजेक्ट रिपॉज़िटरी का पता लगाता है और उस तक पहुँचने के लिए अल्पकालिक क्रेडेंशियल जारी करता है।
• Git सेवा सैंडबॉक्स को रिपॉज़िटरी डेटा भेजती है, उनके सबमिट प्राप्त करती है, और तय करती है कि कौन-सा सबमिशन सबसे नया स्वीकृत कमिट बनेगा।
• AWS S3-आधारित स्टोरेज रिपॉज़िटरी डेटा को टिकाऊ रूप से स्टोर करता है।
• डाउनस्ट्रीम प्रोसेसिंग सहेजे गए दस्तावेज़ों से टेक्स्ट और अन्य उपयोगी जानकारी निकालती है और एजेंटों के प्रोजेक्ट लोड या रीफ़्रेश करने पर उसे उपलब्ध कराती है।

हर एजेंट का अपना पृथक सैंडबॉक्स होता है। उस सैंडबॉक्स के भीतर, वह रिपॉज़िटरी की एक लोकल कॉपी के साथ काम करता है, जिसे एक छोटा CLI मैनेज करता है। CLI रिपॉज़िटरी का पता लगाने के लिए कंट्रोल प्लेन से पूछता है, फिर Git सेवा के ज़रिए बदलाव फ़ेच और सबमिट करता है। सैंडबॉक्स के अनुरोधों के Git सेवा तक पहुँचने से पहले एक एजेंट प्रॉक्सी उनकी पहुँच की जाँच करता है। Git सेवा एक साझा फ़ाइलसिस्टम पर रिपॉज़िटरी को पढ़ती और लिखती है, और तय करती है कि हर सबमिशन सबसे नया स्वीकृत कमिट बनेगा या नहीं। यह फ़ाइलसिस्टम AWS S3Files द्वारा प्रदान किया जाता है, जो S3-आधारित स्टोरेज को सामान्य फ़ाइलों और डायरेक्टरी के रूप में एक्सेस करने योग्य बनाता है। स्टोरेज को पृथक सेल में बाँटा गया है, जिनमें से हर एक का अपना फ़ाइलसिस्टम और अपनी Git सेवा रेप्लिका होती हैं। किसी कमिट के स्वीकार होने के बाद, बैकग्राउंड वर्कर बदले गए दस्तावेज़ों से टेक्स्ट और अन्य उपयोगी जानकारी निकालते हैं, परिणामों को रिपॉज़िटरी इतिहास से अलग स्टोर करते हैं, और एजेंटों के प्रोजेक्ट लोड या रीफ़्रेश करने पर उन्हें उपलब्ध कराते हैं।

आगे, हम एक-एक करके इन कंपोनेंट्स के बारे में बताएँगे।

बड़ा करें

CLI: सैंडबॉक्स में लोकल फ़ाइलों के साथ काम करना

एजेंट SPACE में चलते हैं, जो हमारा इन-हाउस सैंडबॉक्स प्लेटफ़ॉर्म है। हर सैंडबॉक्स में एक छोटा CLI होता है, जो रिपॉज़िटरी को मटीरियलाइज़ करता है और उसे सिंक में रखता है। एजेंट द्वारा किए गए सार्थक काम की हर इकाई के लिए, यह बदलावों को एक कमिट के रूप में सबमिट करता है।

एजेंट आम तौर पर प्रोजेक्ट फ़ाइलों के केवल एक छोटे हिस्से को ही छूते हैं, इसलिए पूरी रिपॉज़िटरी को पहले से मटीरियलाइज़ करना ज़रूरी नहीं है। इसलिए CLI लेज़ी तरीके से मटीरियलाइज़ करता है: Git Large File Storage (LFS) के ज़रिए स्टोर की गई बड़ी और बाइनरी फ़ाइलें छोटी पॉइंटर फ़ाइलों के रूप में आती हैं, जिनमें ऑब्जेक्ट का वास्तविक आकार दर्ज होता है, ताकि एजेंट नाम और आकार के आधार पर तय कर सके कि डाउनलोड करना सार्थक है या नहीं। PDF जैसे दस्तावेज़ों के लिए, एजेंट पहले पार्स किया गया टेक्स्ट पढ़ता है और ज़रूरत पड़ने पर ही सोर्स फ़ाइलें डाउनलोड करता है।

एक और स्वाभाविक विकल्प वर्चुअल फ़ाइलसिस्टम का उपयोग करना होता। हमने FUSE-आधारित एक इम्प्लीमेंटेशन का परीक्षण किया, लेकिन फ़ाइलसिस्टम-प्रधान वर्कलोड पर यह लोकल फ़ाइलों की तुलना में लगभग 400 गुना धीमा था, क्योंकि हर अनुरोध के लिए नेटवर्क राउंडट्रिप की ज़रूरत होती है। इसके लिए आम तौर पर होस्ट से विशेषाधिकार-प्राप्त क्षमताओं की भी ज़रूरत होती है, इसलिए हर एजेंट को एक विशेषाधिकार-प्राप्त सैंडबॉक्स में चलाना पड़ता।

बड़ा करें

कंट्रोल प्लेन: रिपॉज़िटरी का पता लगाना और पहुँच जारी करना

कंट्रोल प्लेन यह पता लगाता है कि हर रिपॉज़िटरी कहाँ स्टोर है और उस तक पहुँच जारी करता है। जब कोई रिपॉज़िटरी बनाई जाती है, तो कंट्रोल प्लेन उसे एक स्टोरेज सेल को असाइन करता है, जो स्टोरेज की एक पृथक इकाई है और जिसकी अपनी Git सेवा रेप्लिका होती हैं। जब कोई एजेंट किसी प्रोजेक्ट पर काम शुरू करता है, तो CLI कंट्रोल प्लेन से पूछता है कि रिपॉज़िटरी कहाँ स्टोर है। कंट्रोल प्लेन लोकेशन और Git सेवा के लिए अस्थायी क्रेडेंशियल लौटाता है। कंट्रोल प्लेन कभी भी रिपॉज़िटरी डेटा न तो पढ़ता है, न लिखता है। रिपॉज़िटरी में क्या जाएगा, यह Git सेवा तय करती है।

Git सेवा: डेटा ट्रांसफ़र करना और अपडेट का समन्वय करना

Git सेवा Git ऑपरेशन चलाती है और सैंडबॉक्स और स्टोरेज के बीच रिपॉज़िटरी की सामग्री और वर्शन इतिहास को ट्रांसफ़र करती है। यह Git के अपने सर्विंग कमांड के ऊपर एक हल्का रैपर है। यह इनका समर्थन करती है: क्लाइंट को यह बताने के लिए कि रिपॉज़िटरी का हेड कहाँ है, ref डिस्कवरी; क्लोन और फ़ेच करने के लिए upload-pack; और नए ऑब्जेक्ट तथा रिपॉज़िटरी का हेड आगे बढ़ाने का अनुरोध प्राप्त करने के लिए receive-pack। यह Git LFS API भी सर्व करती है: बड़ी और बाइनरी फ़ाइलों के लिए, यह अल्पकालिक लिंक जारी करती है, ताकि सैंडबॉक्स उन फ़ाइलों को सीधे S3 पर अपलोड और वहाँ से डाउनलोड कर सकें।

हमने एक तैयार (ऑफ़-द-शेल्फ़) फ़ोर्ज सर्वर से शुरुआत की, ताकि अपना हल्का फ़ोर्ज बनाने के साथ-साथ हम एजेंट और उपयोगकर्ता इंटरफ़ेस का प्रोटोटाइप भी बना सकें। हमारा फ़ोर्ज केवल उन Git ऑपरेशनों पर केंद्रित है जिनकी हमें ज़रूरत है।

यह सेवा रेप्लिका के एक फ़्लीट से बनी है, जिनमें से हर एक उसी सर्वर का एक चालू इंस्टेंस है। एक सेल साझा स्टोरेज को रेप्लिका के एक सेट और उनकी सहायक सेवाओं के साथ समूहित करता है। इससे एक सेल के भीतर की रेप्लिका हर रिपॉज़िटरी की स्वतंत्र प्रतियाँ बनाए रखने के बजाय एक ही साझा फ़ाइलसिस्टम तक पहुँच सकती हैं।

इस साझा स्टोरेज की वजह से रेप्लिका स्टेटलेस रह सकती हैं। सेल की कोई भी रेप्लिका उसकी किसी भी रिपॉज़िटरी को सर्व कर सकती है, इसलिए रेप्लिका बदलने या जोड़ने के लिए सर्वरों के बीच रिपॉज़िटरी डेटा को स्थानांतरित करने की ज़रूरत नहीं पड़ती। किसी रिपॉज़िटरी के अनुरोध सामान्य रूप से एक ही रेप्लिका पर जाते हैं, ताकि उसके कैश उपयोगी बने रहें, लेकिन रिपॉज़िटरी उस विशेष इंस्टेंस के उपलब्ध रहने पर निर्भर नहीं करती।

स्वीकृति चरण रिपॉज़िटरी के इनवेरिएंट्स की जाँच करता है, ताकि यह सुनिश्चित हो सके कि स्वीकार किया गया कमिट रिपॉज़िटरी की एक वैध स्थिति है। हम हर रिपॉज़िटरी के लिए एक स्पष्ट अनुबंध परिभाषित करते हैं, ताकि स्वचालित जाँचें उसे बहुत बड़ी होने से रोक सकें। PDF और इमेज जैसी बड़ी और बाइनरी फ़ाइलें रॉ Git ब्लॉब के बजाय Git LFS के ज़रिए स्टोर की जाती हैं। कॉम्पैक्शन हाल का इतिहास उपलब्ध रखते हुए रिपॉज़िटरी के आकार को सीमित करता है। सफल सबमिट के बाद, CLI Git सेवा से पूछता है कि क्या रिपॉज़िटरी को कॉम्पैक्शन की ज़रूरत है। अगर रखे गए कमिट की संख्या एक तय सीमा से अधिक हो जाती है, तो Git सेवा केवल सबसे हाल के कमिट का एक छोटा सेट रखती है। पुराने इतिहास को एक प्रारंभिक स्नैपशॉट से बदल दिया जाता है, और कमिट आइडेंटिफ़ायर अपडेट करने के लिए हाल के कमिट दोबारा लागू (रीप्ले) किए जाते हैं।

बड़ा करें

एक सरल सिंक्रोनाइज़ेशन चरण समवर्ती राइटरों को नियंत्रित करता है। यह सबसे नए स्वीकृत कमिट, यानी हेड, को ट्रैक करता है। जब इसे कोई सबमिशन मिलता है, तो यह उसे केवल तभी स्वीकार करता है जब सबमिट उसी हेड पर आधारित हो। अगर ऐसा नहीं है, तो यह एक संरचित stale-base प्रतिक्रिया भेजता है; तब हारने वाले को अपना बदलाव नए हेड के ऊपर दोबारा लागू करके फिर से सबमिट करना होता है। यह डिज़ाइन सुनिश्चित करता है कि समवर्ती एजेंट चुपचाप एक-दूसरे के काम को ओवरराइट न करें, और इससे काम में कोई खास धीमापन भी नहीं आता। हमारे प्रोडक्शन वर्कफ़्लो में, 2% से कम सबमिट पुराने (stale) होने के कारण अस्वीकार होते हैं। कुल मिलाकर, सबमिट की मीडियन लेटेंसी 1.7 सेकंड से कम है, और p99 लेटेंसी 8 सेकंड से कम है।

बड़ा करें

Git सेवा हर स्वीकृत बदलाव को भी दर्ज करती है। हर स्वीकृत राइट के लिए, यह एक आउटबॉक्स में एक एंट्री जोड़ती है। आउटबॉक्स एक लॉग है, जिसमें रिपॉज़िटरी, नया कमिट, बदलाव करने वाला उपयोगकर्ता और बदले गए पाथ दर्ज होते हैं। पार्सर जैसी डाउनस्ट्रीम सेवाएँ नया काम खोजने के लिए इस लॉग को पढ़ती हैं।

ये सभी हिस्से मिलकर एक रिपॉज़िटरी प्रबंधन परत बनाते हैं, जिसमें वे हिस्से नहीं हैं जिनकी एजेंटों को ज़रूरत नहीं होती। Pull request की ज़रूरत नहीं पड़ती, क्योंकि कोई भी इंसान हर बदलाव की समीक्षा नहीं करता। इसके बजाय, Git सेवा सबमिट के समय अनुबंध की जाँच करती है, रेस हारने वाला एजेंट अपना बदलाव दोबारा लागू करता है, और कमिट इतिहास दर्ज करता है कि किसने क्या बदला। वृद्धि को संभालने के लिए किसी मानव ऑपरेटर पर निर्भर रहने के बजाय, नियतात्मक (डिटरमिनिस्टिक) जाँचें हर रिपॉज़िटरी को उसके अनुबंध के भीतर रखती हैं।

स्टोरेज: काम को टिकाऊ बनाए रखना

स्टोरेज परत सैंडबॉक्स और Git सेवा रेप्लिका से स्वतंत्र रूप से रिपॉज़िटरी डेटा को टिकाऊ ढंग से सहेजती है। रिपॉज़िटरी AWS S3Files पर रहती हैं, जो S3-आधारित स्टोरेज को एक फ़ाइलसिस्टम इंटरफ़ेस के ज़रिए उपलब्ध कराता है, जिसका उपयोग स्टॉक Git बिना किसी बदलाव के कर सकता है। हर रिपॉज़िटरी साझा फ़ाइलसिस्टम पर एक बेयर Git रिपॉज़िटरी है, जिसमें वर्किंग चेकआउट के बजाय रिपॉज़िटरी के ऑब्जेक्ट और रेफ़रेंस होते हैं।

स्टोरेज और कंप्यूट को अलग करने से सैंडबॉक्स अल्पकालिक बने रह सकते हैं। हर एजेंट को अपना सैंडबॉक्स मिलता है, और कई एजेंट एक मशीन साझा किए बिना एक ही प्रोजेक्ट पर काम कर सकते हैं। अगर कोई सैंडबॉक्स क्रैश हो जाता है, तो केवल वही काम जोखिम में होता है जो अभी तक सबमिट नहीं किया गया है।

इसके बजाय, हम हर प्रोजेक्ट को लंबे समय तक चलने वाला एक सैंडबॉक्स दे सकते थे, जिसे उसके सभी एजेंट साझा करते, ताकि प्रोजेक्ट की फ़ाइलें उस मशीन की डिस्क पर रहतीं। हालाँकि, इससे एजेंटों का कंप्यूट उस जगह से बँध जाता जहाँ मशीन चलती है, और मशीन का आकार उसके सबसे व्यस्त समय के हिसाब से तय करना पड़ता। उसे महीनों तक ठीक से चलते भी रहना होता, और बैकअप व रिकवरी को प्रोजेक्ट के स्टोरेज सिस्टम के हिस्से के रूप में मैनेज करना पड़ता।

बड़ा करें

डाउनस्ट्रीम प्रोसेसिंग: एजेंटों के लिए दस्तावेज़ों को पढ़ने योग्य बनाना

मुख्य डाउनस्ट्रीम कंपोनेंट एक पार्सर पाइपलाइन है, जो नए जोड़े गए या अपडेट किए गए दस्तावेज़ों से टेक्स्ट और मेटाडेटा निकालती है, ताकि एजेंट प्रोजेक्ट फ़ाइलों को आसानी से पढ़ सकें। एक पार्सर वर्कर चेंज स्ट्रीम कतार से अपडेट लेता है, कमिट मेटाडेटा से बदली गई फ़ाइलों का पता लगाता है, और कंटेंट हैश का उपयोग करके रॉ बाइट्स फ़ेच करता है। फिर यह दस्तावेज़ को पार्स करके निकाला गया टेक्स्ट और दस्तावेज़ का मेटाडेटा तैयार करता है।

पार्स किए गए आउटपुट रिपॉज़िटरी के बाहर, एक ऐसे स्टोर में रहते हैं जिसकी कुंजी सोर्स दस्तावेज़ का हैश होती है। इन आर्टिफ़ैक्ट्स को कभी भी रिपॉज़िटरी में वापस कमिट नहीं किया जाता, क्योंकि इससे इतिहास अनावश्यक रूप से दूषित होता और समवर्ती राइट की संख्या बढ़ जाती। इसके बजाय, पार्स किए गए आउटपुट चेकआउट और सिंक के ज़रिए सैंडबॉक्स तक पहुँचते हैं। हर चेकआउट में एक आरक्षित डायरेक्टरी होती है, जिसका उपयोग CLI आर्टिफ़ैक्ट्स को मटीरियलाइज़ करने के लिए करता है। पार्सिंग एसिंक्रोनस रूप से होती है, इसलिए बैकग्राउंड पार्सर वर्कर चेकआउट को ब्लॉक नहीं करता।

एजेंट वर्कस्पेस का उपयोग कैसे करते हैं

एजेंट मानक फ़ाइलसिस्टम टूल का उपयोग करके सैंडबॉक्स में लोड किए गए रिपॉज़िटरी संस्करण को एक्सप्लोर करते हैं। पहले-खोजो-फिर-पढ़ो वाली तय पाइपलाइन का पालन करने के बजाय, वे फ़ोल्डरों की सूची देखते हैं, grep से फ़ाइलों की सामग्री में खोजते हैं, प्रासंगिक अंश पढ़ते हैं, और जो मिलता है उसके आधार पर तय करते हैं कि आगे कहाँ देखना है।

Computer की तरह, Search भी अपने मानक फ़ाइल टूल के ज़रिए यही तरीका अपनाता है। एक अलग एक्सप्लोरेशन एजेंट अधिक सीमित बजट में प्रोजेक्ट में खोज करता है और प्रासंगिक फ़ाइल पाथ और सहायक अंश लौटाता है। फिर उत्तर देने वाला मॉडल चुनी गई फ़ाइलें पढ़ता है और उत्तर तैयार करता है। मौजूदा प्रोजेक्ट सैंडबॉक्स का दोबारा उपयोग करने से सेटअप का समय कम होता है: वार्म चेकआउट से जुड़ने में लगभग 2.9 सेकंड लगते हैं, जबकि कोल्ड स्टार्ट में लगभग 8 सेकंड लगते हैं।

बड़ा करें

पार्स किया गया टेक्स्ट PDF और Office फ़ाइलों जैसे बड़े दस्तावेज़ों को उन्हीं टूल से खोजने योग्य बनाता है। एजेंट पहले एक मैनिफ़ेस्ट देखता है, यानी एक सूची जो बताती है कि किन दस्तावेज़ों का निकाला गया टेक्स्ट उपलब्ध है, फिर उस टेक्स्ट को सामान्य फ़ाइलों की तरह खोजता और पढ़ता है। मूल दस्तावेज़ वह तभी डाउनलोड करता है जब टेक्स्ट पर्याप्त न हो, उदाहरण के लिए, चित्रों, लेआउट या एम्बेड किए गए डेटा की जाँच करने के लिए।

हमने इसी कॉर्पस के 150 सिंगल-डॉक्यूमेंट वित्तीय प्रश्नों पर इस तरीके को इंडेक्स-आधारित सिमेंटिक सर्च के मुकाबले बेंचमार्क किया। एक्सप्लोरेशन एजेंट ने सही दस्तावेज़ खोजने में 0.867 और सही उत्तर देने में 0.627 स्कोर किया, जबकि सिमेंटिक सर्च का स्कोर लगभग 0.39 और 0.37 रहा। यानी यह उत्तरों में लगभग 1.7 गुना और रिट्रीवल में 2 गुना बेहतर रहा, वह भी लगभग 25% कम लेटेंसी के साथ। एक्सप्लोरेशन एजेंट ज़्यादातर निकाले गए टेक्स्ट के साथ काम करता है और मूल PDF शायद ही कभी डाउनलोड करता है।

बड़ा करें

एक साझा इंफ्रास्ट्रक्चर

Computer की स्थायी मेमोरी भी इसी फ़ाइलसिस्टम इंफ्रास्ट्रक्चर का उपयोग करती है। Perplexity Brain, Computer का नॉलेज विकी, मेमोरी को ऐसी नॉलेज रिपॉज़िटरी में स्टोर करता है जिनका अपना इतिहास और अपनी नीतियाँ होती हैं। ज्ञान को प्रोजेक्ट फ़ाइलों से अलग रखने का मतलब है कि बैकग्राउंड मेमोरी अपडेट उन फ़ाइलों में होने वाले संपादनों से टकराते नहीं हैं। जिस सत्र को दोनों की ज़रूरत होती है, वह दोनों रिपॉज़िटरी लोड करता है।

बैकग्राउंड एजेंट मौजूदा ज्ञान पढ़ते हैं, नई जानकारी जोड़ते हैं, और अपडेट किए गए पेजों को कमिट के रूप में सहेजते हैं। अन्य एजेंट उन पेजों को सामान्य फ़ाइल टूल से पढ़ते हैं, और लोग भी उन्हें संपादित कर सकते हैं। राइटर हर रीडर के साथ सीधे समन्वय करने के बजाय रिपॉज़िटरी के ज़रिए अपना काम साझा करते हैं। कमिट इतिहास दर्ज करता है कि किसने क्या बदला, जबकि आउटबॉक्स स्वीकृत अपडेट की जानकारी डाउनस्ट्रीम सेवाओं को देता है। लोग और एजेंट एक-दूसरे के काम को आगे बढ़ा सकते हैं, और यह रिकॉर्ड भी रहता है कि ज्ञान कैसे विकसित हुआ।

निष्कर्ष

जब लोग और एजेंट एक प्रोजेक्ट साझा करते हैं, तो वर्कस्पेस सिर्फ़ फ़ाइलें स्टोर करने से कहीं ज़्यादा काम करता है। यह योगदानों को एक साथ जोड़ने और बदलावों पर नज़र रखने के लिए एक साझा जगह देता है। Git पहले से ही इस नींव का बड़ा हिस्सा प्रदान करता है। हम समन्वय और स्वचालित जाँचें जोड़ते हैं, ताकि एजेंट हर अपडेट के लिए किसी व्यक्ति की मंज़ूरी के बिना काम सबमिट कर सकें। नतीजा एक ऐसा फ़ोर्ज है जिसे सिर्फ़ उसकी बुनियादी चीज़ों तक सीमित कर दिया गया है, क्योंकि मूल रूप से क्रॉस-एजेंट सहयोग और कई योगदानकर्ताओं वाला सॉफ़्टवेयर डेवलपमेंट एक ही समस्या हैं।

एजेंट स्वतंत्र, अस्थायी सैंडबॉक्स में काम करते हुए टिकाऊ रिपॉज़िटरी में योगदान देते हैं। रिपॉज़िटरी की सीमाएँ वृद्धि को नियंत्रण में रखती हैं, स्पष्ट डाउनलोड से एजेंट चुन पाते हैं कि क्या फ़ेच करना है, और सामान्य फ़ाइलों की मदद से वे परिचित टूल के साथ खोजबीन कर पाते हैं। बैकग्राउंड अपडेट, इंटरैक्टिव संपादन और शेड्यूल किए गए कार्य सीधे समन्वय किए बिना एक-दूसरे के काम को आगे बढ़ा सकते हैं।

जैसे-जैसे अधिक एजेंट प्रोजेक्ट के भीतर स्वायत्त रूप से काम करते हैं, उनका साझा वर्कस्पेस भरोसेमंद और लोगों के लिए समझने योग्य बना रहना चाहिए। लक्ष्य सीधा है: हर बदलाव उसे बनाने वाले एजेंट से अधिक टिकाऊ होना चाहिए, अगले सहयोगी के लिए उपलब्ध होना चाहिए, और इस बात का स्पष्ट रिकॉर्ड छोड़ना चाहिए कि क्या बदला।

उद्धरण

@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}
}