लोक आणि एजंट्ससाठी सामायिक वर्कस्पेस तयार करणे

आम्ही नुकतेच प्रोजेक्ट्स लाँच केले, जिथे लोक आणि एजंट्स Perplexity Computer मध्ये दीर्घकाळ चालणाऱ्या कार्यांवर एकत्र काम करतात. प्रत्येक प्रोजेक्ट एका सामायिक वर्कस्पेसवर आधारित असतो, ज्यातील फाइलसिस्टम सत्रे, एजंट्स आणि वापरकर्त्यांमधील संदर्भ जमा करत जाते. अनेक महिने चालणाऱ्या मल्टीप्लेयर सहयोगासाठी टिकाऊपणा, समवर्तीता आणि मागोवा-क्षमता आवश्यक असते:

• टिकाऊपणा: काम कोणत्याही एका एजंट सत्राच्या किंवा सँडबॉक्सच्या पलीकडे टिकले पाहिजे, जेणेकरून तोच वापरकर्ता किंवा एजंट पुढील काम सुरू ठेवू शकेल आणि कोणतेही सहयोगी त्यावर आधारित पुढे काम करू शकतील.
• समवर्तीता: एकाच प्रोजेक्टमधील अनेक वापरकर्त्यांचे प्रत्येकी अनेक एजंट्स समांतरपणे संपादने करू शकतात, जी एकमेकांना ओव्हरराइड करण्याऐवजी एक सामायिक स्थिती पुढे नेतात.
• मागोवा-क्षमता: वापरकर्ते आणि एजंट्स दोघांनाही इतिहास पाहता यायला हवा, जेणेकरून संपूर्ण प्रोजेक्ट पुन्हा न वाचता त्यांच्या मागील सत्रानंतर कोणी काय बदलले हे त्यांना तपासता येईल आणि गरज पडल्यास संपादने मागे घेता येतील.

ही आव्हाने सॉफ्टवेअर अभियंत्यांना परिचित वाटतील. या गरजा पूर्ण करण्यासाठी दशकांपूर्वी Git फोर्जेस उदयास आले: व्हर्जन कंट्रोलभोवती सहयोगी वैशिष्ट्ये जोडणारी होस्टेड सेवा, ज्यामुळे अनेक योगदानकर्ते सत्याच्या एकाच स्रोतावर एकत्र येऊ शकतात. प्रोजेक्ट्सना चालना देणारी फाइलसिस्टम म्हणजे मानव-एजंट आणि एजंट-एजंट सहयोगासाठी तयार केलेला असाच एक Git फोर्ज आहे.

विस्तृत करा

आर्किटेक्चर

Git आधीपासूनच टिकाऊपणा, समवर्तीता आणि मागोवा-क्षमता हाताळते. ते प्रत्येक फाइल तिच्या मजकुरावरून ओळखते, त्यामुळे न बदललेल्या फाइल्स एकदाच संग्रहित होतात आणि जतन केलेल्या प्रती कधीही कालबाह्य होत नाहीत. प्रत्येक कमिट सर्व अपडेट केलेल्या फाइल्स एकाच वेळी जतन करतो, त्यामुळे सहयोगींना कधीही अर्धवट स्थिती दिसत नाही. दोन लेखकांच्या बदलांमध्ये टक्कर झाली, तर हरलेला लेखक नवीन आवृत्तीवर आपले बदल पुन्हा लागू करून पुन्हा प्रयत्न करू शकतो. कमिट्सची साखळी कोणी काय बदलले हे दाखवते आणि आधीच्या आवृत्त्या पुनर्संचयित करणे सोपे करते. एजंट्सना गरज नसते ती माणसांसाठी बनवलेल्या फोर्जमधील उर्वरित गोष्टींची, जसे की पुनरावलोकन स्क्रीन, ब्रँच व्यवस्थापन आणि सूचना.

आमचे आर्किटेक्चर संपूर्ण प्रक्रिया क्लाउडवर चालवते आणि कोडिंगपलीकडील सर्व प्रकारच्या ज्ञानकार्याला सपोर्ट करते. प्रत्येक Computer प्रोजेक्टमागे 5 घटकांद्वारे सर्व्ह केली जाणारी एक Git रिपॉझिटरी असते:

• 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 discovery, क्लोनिंग आणि फेचिंगसाठी upload-pack, आणि नवीन ऑब्जेक्ट्स व रिपॉझिटरीचा हेड पुढे नेण्याची विनंती स्वीकारण्यासाठी receive-pack यांना सपोर्ट करते. ती Git LFS API देखील सर्व्ह करते: मोठ्या आणि बायनरी फाइल्ससाठी, ती अल्पकालीन लिंक्स देते, जेणेकरून सँडबॉक्स त्या फाइल्स थेट S3 वर अपलोड करू शकतील आणि तिथून डाउनलोड करू शकतील.

आम्ही बाजारात तयार उपलब्ध असलेल्या फोर्ज सर्व्हरपासून सुरुवात केली, जेणेकरून आम्हाला लागणाऱ्या Git ऑपरेशन्सवरच लक्ष केंद्रित करणारा आमचा स्वतःचा हलका फोर्ज तयार करत असतानाच, समांतरपणे एजंट आणि वापरकर्ता इंटरफेसचे प्रोटोटाइप बनवता येतील.

ही सेवा रेप्लिकांच्या ताफ्याने बनलेली असते; प्रत्येक रेप्लिका म्हणजे त्याच सर्व्हरचा एक चालू इन्स्टन्स. सेल म्हणजे सामायिक स्टोरेज, रेप्लिकांचा एक संच आणि त्यांच्या सहाय्यक सेवा यांचा एक गट. त्यामुळे सेलमधील रेप्लिका प्रत्येक रिपॉझिटरीच्या स्वतंत्र प्रती सांभाळण्याऐवजी एकाच सामायिक फाइलसिस्टमचा ॲक्सेस घेऊ शकतात.

या सामायिक स्टोरेजमुळे रेप्लिका स्टेटलेस राहू शकतात. सेलमधील कोणतीही रेप्लिका त्या सेलमधील कोणतीही रिपॉझिटरी सर्व्ह करू शकते, त्यामुळे रेप्लिका बदलण्यासाठी किंवा जोडण्यासाठी सर्व्हर्समध्ये रिपॉझिटरीचा डेटा हलवावा लागत नाही. एखाद्या रिपॉझिटरीसाठीच्या विनंत्या, तिचे कॅशे उपयुक्त राहावेत म्हणून, सामान्यतः त्याच रेप्लिकाकडे जातात, पण रिपॉझिटरी त्या विशिष्ट इन्स्टन्सच्या उपलब्धतेवर अवलंबून नसते.

स्वीकृती टप्पा रिपॉझिटरीचे इन्व्हेरिएंट्स तपासतो, जेणेकरून स्वीकारलेला कमिट ही रिपॉझिटरीची वैध स्थिती असल्याची खात्री होते. आम्ही प्रत्येक रिपॉझिटरीसाठी एक स्पष्ट करार निश्चित करतो, त्यामुळे यांत्रिक तपासण्या तिला फार मोठी होण्यापासून रोखू शकतात. PDF आणि प्रतिमांसारख्या मोठ्या व बायनरी फाइल्स कच्च्या Git ब्लॉब्सऐवजी Git LFS द्वारे संग्रहित केल्या जातात. कॉम्पॅक्शनमुळे अलीकडील इतिहास उपलब्ध राहतो आणि रिपॉझिटरीचा आकारही मर्यादित राहतो. यशस्वी सबमिटनंतर, CLI Git सेवेला विचारतो की रिपॉझिटरीला कॉम्पॅक्शनची गरज आहे का. राखून ठेवलेल्या कमिट्सची संख्या ठरावीक मर्यादेपेक्षा जास्त झाल्यास, Git सेवा फक्त सर्वात अलीकडील कमिट्सचा एक लहान संच ठेवते. जुना इतिहास एकाच सुरुवातीच्या स्नॅपशॉटने बदलला जातो आणि कमिट आयडेंटिफायर्स अद्ययावत करण्यासाठी अलीकडील कमिट्स पुन्हा लागू केले जातात.

विस्तृत करा

एक साधा सिंक्रोनायझेशन टप्पा एकाच वेळी लिहिणाऱ्या लेखकांवर नियंत्रण ठेवतो. तो नवीनतम स्वीकारलेला कमिट, म्हणजेच हेड, ट्रॅक करतो. एखादे सबमिशन मिळाल्यावर, ते सबमिट त्या हेडवर आधारित असेल तरच तो ते स्वीकारतो. तसे नसल्यास, तो एक संरचित कालबाह्य-बेस प्रतिसाद पाठवतो; त्यानंतर हरलेल्याला आपला बदल नवीन हेडवर पुन्हा लागू करून पुन्हा सबमिट करावा लागतो. या रचनेमुळे, लक्षणीय गती न गमावता, एकाच वेळी काम करणारे एजंट्स एकमेकांचे काम नकळत ओव्हरराइट करत नाहीत याची खात्री होते. आमच्या प्रॉडक्शन वर्कफ्लोमध्ये, 2% पेक्षा कमी सबमिट्स कालबाह्य म्हणून नाकारले जातात. एकूणच, सबमिटची मध्यक लेटन्सी 1.7 सेकंदांपेक्षा कमी आहे आणि p99 लेटन्सी 8 सेकंदांपेक्षा कमी आहे.

विस्तृत करा

Git सेवा प्रत्येक स्वीकारलेल्या बदलाची नोंदही ठेवते. प्रत्येक स्वीकारलेल्या राइटसाठी, ती आउटबॉक्समध्ये एक नोंद जोडते; आउटबॉक्स हा एक लॉग आहे ज्यात रिपॉझिटरी, नवीन कमिट, बदल करणारा वापरकर्ता आणि बदललेले पाथ्स नोंदवलेले असतात. पार्सरसारख्या डाउनस्ट्रीम सेवा नवीन काम शोधण्यासाठी हा लॉग वाचतात.

हे सर्व घटक मिळून एक रिपॉझिटरी व्यवस्थापन स्तर तयार करतात, ज्यात एजंट्सना आवश्यक नसलेले भाग नाहीत. येथे pull requests ची गरज नसते, कारण प्रत्येक बदलाचे पुनरावलोकन कोणीही माणूस करत नाही. त्याऐवजी, Git सेवा सबमिटच्या वेळी करार तपासते, शर्यत हरणारा एजंट स्वतःचा बदल पुन्हा लागू करतो आणि कोणी काय बदलले याची नोंद कमिट इतिहासात राहते. वाढ व्यवस्थापित करण्यासाठी मानवी ऑपरेटरवर अवलंबून राहण्याऐवजी, निश्चित स्वरूपाच्या (डिटरमिनिस्टिक) तपासण्या प्रत्येक रिपॉझिटरीला तिच्या कराराच्या मर्यादेत ठेवतात.

स्टोरेज: काम टिकाऊ ठेवणे

स्टोरेज स्तर सँडबॉक्स आणि Git सेवा रेप्लिकांपासून स्वतंत्रपणे रिपॉझिटरीचा डेटा टिकाऊपणे जतन करतो. रिपॉझिटरीज AWS S3Files वर असतात, जे S3-आधारित स्टोरेज एका फाइलसिस्टम इंटरफेसद्वारे उपलब्ध करून देते, जो मूळ Git कोणत्याही बदलाशिवाय वापरू शकतो. प्रत्येक रिपॉझिटरी ही सामायिक फाइलसिस्टमवरील एक bare Git रिपॉझिटरी असते, ज्यात वर्किंग चेकआउटऐवजी रिपॉझिटरीचे ऑब्जेक्ट्स आणि रेफरन्सेस असतात.

स्टोरेज आणि कंप्युट वेगळे केल्यामुळे सँडबॉक्स अल्पकालीन राहू शकतात. प्रत्येक एजंटला स्वतःचा सँडबॉक्स मिळतो आणि अनेक एजंट्स एकच मशीन शेअर न करता एकाच प्रोजेक्टवर काम करू शकतात. एखादा सँडबॉक्स क्रॅश झाला, तर फक्त सबमिट न केलेले कामच धोक्यात येते.

त्याऐवजी आम्ही प्रत्येक प्रोजेक्टला एक दीर्घकाळ चालणारा सँडबॉक्स देऊ शकलो असतो, जो त्याचे सर्व एजंट्स शेअर करतील, म्हणजे प्रोजेक्टच्या फाइल्स त्या मशीनच्या डिस्कवर राहतील. मात्र, यामुळे एजंट्सचे कंप्युट ते मशीन जिथे चालते तिथेच बांधले गेले असते आणि ते मशीन सर्वाधिक व्यस्त कालावधींसाठी पुरेसे मोठे ठेवावे लागले असते. तसेच ते मशीन अनेक महिने सुस्थितीत राहणे आवश्यक ठरले असते आणि बॅकअप व रिकव्हरी प्रोजेक्टच्या स्टोरेज प्रणालीचा भाग म्हणून व्यवस्थापित कराव्या लागल्या असत्या.

विस्तृत करा

डाउनस्ट्रीम प्रक्रिया: दस्तऐवज एजंट्ससाठी वाचनीय बनवणे

मुख्य डाउनस्ट्रीम घटक म्हणजे पार्सर पाइपलाइन, जी प्रोजेक्ट फाइल्स एजंट्सना सहज वाचता याव्यात म्हणून नव्याने जोडलेल्या किंवा अपडेट केलेल्या दस्तऐवजांमधून मजकूर आणि मेटाडेटा काढते. पार्सर वर्कर चेंज स्ट्रीम रांगेतून अपडेट्स घेतो, कमिट मेटाडेटावरून बदललेल्या फाइल्स ओळखतो आणि कंटेंट हॅश वापरून मूळ बाइट्स फेच करतो. त्यानंतर तो दस्तऐवज पार्स करून काढलेला मजकूर आणि दस्तऐवज मेटाडेटा तयार करतो.

पार्स केलेले आउटपुट्स रिपॉझिटरीच्या बाहेर, सोर्स दस्तऐवजाच्या हॅशनुसार की केलेल्या स्टोअरमध्ये राहतात. हे आर्टिफॅक्ट्स कधीही रिपॉझिटरीमध्ये परत कमिट केले जात नाहीत, कारण त्यामुळे इतिहास विनाकारण दूषित होईल आणि एकाच वेळी होणाऱ्या राइट्सची संख्या वाढेल. त्याऐवजी, पार्स केलेले आउटपुट्स चेकआउट आणि सिंकद्वारे सँडबॉक्सपर्यंत पोहोचतात. प्रत्येक चेकआउटमध्ये एक राखीव डिरेक्टरी असते, जी CLI आर्टिफॅक्ट्स मटेरियलाइझ करण्यासाठी वापरतो. पार्सिंग असिंक्रोनस पद्धतीने होते, त्यामुळे बॅकग्राउंड पार्सर वर्कर चेकआउट्स अडवत नाही.

एजंट्स वर्कस्पेस कसे वापरतात

सँडबॉक्समध्ये लोड केलेल्या रिपॉझिटरी आवृत्तीचा एजंट्स मानक फाइलसिस्टम टूल्स वापरून शोध घेतात. आधी शोध, मग वाचन अशा ठरावीक पाइपलाइनचे पालन करण्याऐवजी, ते फोल्डर्सची यादी पाहतात, grep ने फाइल्समधील मजकूर शोधतात, संबंधित उतारे वाचतात आणि जे सापडेल त्यावरून पुढे कुठे पाहायचे ते ठरवतात.

Computer प्रमाणेच, Search देखील त्याच्या मानक फाइल टूल्सद्वारे हीच पद्धत वापरते. एक स्वतंत्र अन्वेषण एजंट अधिक मर्यादित बजेटमध्ये प्रोजेक्टमध्ये शोध घेतो आणि संबंधित फाइल पाथ्स व त्यांना आधार देणारे उतारे परत करतो. त्यानंतर उत्तर देणारे मॉडेल निवडलेल्या फाइल्स वाचते आणि उत्तर तयार करते. विद्यमान प्रोजेक्ट सँडबॉक्सचा पुन्हा वापर केल्याने सेटअपचा वेळ कमी होतो: वॉर्म चेकआउटशी जोडण्यास सुमारे 2.9 सेकंद लागतात, तर कोल्ड स्टार्टसाठी सुमारे 8 सेकंद लागतात.

विस्तृत करा

पार्स केलेल्या मजकुरामुळे PDF आणि Office फाइल्ससारखे मोठे दस्तऐवज त्याच टूल्सद्वारे शोधता येतात. एजंट आधी मॅनिफेस्ट तपासतो, म्हणजे कोणत्या दस्तऐवजांचा काढलेला मजकूर उपलब्ध आहे हे दाखवणारी यादी, आणि मग तो मजकूर सामान्य फाइल्सप्रमाणे शोधतो व वाचतो. मजकूर अपुरा असेल तेव्हाच, उदाहरणार्थ आकृत्या, मांडणी किंवा अंतर्भूत डेटा तपासण्यासाठी, तो मूळ दस्तऐवज डाउनलोड करतो.

याच कॉर्पसवरील 150 एकल-दस्तऐवज आर्थिक प्रश्नांवर आम्ही या पद्धतीची इंडेक्सवरील सिमँटिक शोधाशी बेंचमार्क तुलना केली. अन्वेषण एजंटने योग्य दस्तऐवज पुनर्प्राप्त करण्यात 0.867 आणि योग्य उत्तर देण्यात 0.627 गुण मिळवले, तर सिमँटिक शोधाचे गुण अनुक्रमे सुमारे 0.39 आणि 0.37 होते; म्हणजेच उत्तरांमध्ये सुमारे 1.7x आणि पुनर्प्राप्तीमध्ये 2x चांगली कामगिरी, तीही सुमारे 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}
}