ആളുകൾക്കും ഏജന്റുകൾക്കുമായി പങ്കിട്ട വർക്ക്‌സ്‌പേസുകൾ നിർമ്മിക്കുന്നു

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-ന്റെ സ്വന്തം സെർവിംഗ് കമാൻഡുകൾക്ക് ചുറ്റുമുള്ള ഒരു നേർത്ത റാപ്പറാണിത്. റിപ്പോസിറ്ററിയുടെ ഹെഡ് എവിടെയാണെന്ന് ക്ലയന്റിനെ അറിയിക്കുന്നതിനുള്ള റെഫ് ഡിസ്കവറി, ക്ലോൺ ചെയ്യുന്നതിനും ഫെച്ച് ചെയ്യുന്നതിനുമുള്ള upload-pack, പുതിയ ഒബ്ജക്റ്റുകളും റിപ്പോസിറ്ററിയുടെ ഹെഡ് മുന്നോട്ട് നീക്കാനുള്ള അഭ്യർത്ഥനയും സ്വീകരിക്കുന്നതിനുള്ള receive-pack എന്നിവയെ ഇത് പിന്തുണയ്ക്കുന്നു. ഇത് Git LFS API-യും സെർവ് ചെയ്യുന്നു: വലിയ ഫയലുകൾക്കും ബൈനറി ഫയലുകൾക്കുമായി, സാൻഡ്‌ബോക്സുകൾക്ക് ആ ഫയലുകൾ S3-ലേക്ക് നേരിട്ട് അപ്‌ലോഡ് ചെയ്യാനും S3-ൽ നിന്ന് നേരിട്ട് ഡൗൺലോഡ് ചെയ്യാനും കഴിയുന്ന തരത്തിൽ ഇത് ഹ്രസ്വകാല ലിങ്കുകൾ നൽകുന്നു.

ഞങ്ങൾക്ക് ആവശ്യമുള്ള Git പ്രവർത്തനങ്ങളിൽ മാത്രം ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്ന, ഞങ്ങളുടെ സ്വന്തം ലഘുവായ ഫോർജ് നിർമ്മിക്കുന്നതിനൊപ്പം തന്നെ ഏജന്റ്, ഉപയോക്തൃ ഇന്റർഫേസുകളുടെ പ്രോട്ടോടൈപ്പുകൾ സമാന്തരമായി തയ്യാറാക്കാനായി, റെഡിമെയ്ഡ് ആയി ലഭ്യമായ ഒരു ഫോർജ് സെർവർ ഉപയോഗിച്ചാണ് ഞങ്ങൾ തുടങ്ങിയത്.

ഈ സേവനത്തിൽ റെപ്ലിക്കകളുടെ ഒരു ഫ്ലീറ്റ് അടങ്ങിയിരിക്കുന്നു; ഓരോന്നും ഒരേ സെർവറിന്റെ പ്രവർത്തിക്കുന്ന ഒരു ഇൻസ്റ്റൻസാണ്. ഒരു സെൽ, പങ്കിട്ട സ്റ്റോറേജിനെ ഒരു കൂട്ടം റെപ്ലിക്കകളുമായും അവയുടെ പിന്തുണാ സേവനങ്ങളുമായും ഒന്നിച്ച് ചേർക്കുന്നു. അങ്ങനെ, ഓരോ റിപ്പോസിറ്ററിയുടെയും സ്വതന്ത്ര പകർപ്പുകൾ പരിപാലിക്കുന്നതിന് പകരം, ഒരു സെല്ലിനുള്ളിലെ റെപ്ലിക്കകൾക്ക് ഒരേ പങ്കിട്ട ഫയൽസിസ്റ്റം ആക്‌സസ് ചെയ്യാനാകും.

ഈ പങ്കിട്ട സ്റ്റോറേജ് റെപ്ലിക്കകളെ സ്റ്റേറ്റ്‌ലെസ് ആയി നിലനിർത്താൻ സഹായിക്കുന്നു. സെല്ലിലെ ഏത് റെപ്ലിക്കയ്ക്കും അതിലെ ഏത് റിപ്പോസിറ്ററിയും സെർവ് ചെയ്യാനാകും, അതിനാൽ റെപ്ലിക്കകൾ മാറ്റിസ്ഥാപിക്കുന്നതിനോ ചേർക്കുന്നതിനോ സെർവറുകൾക്കിടയിൽ റിപ്പോസിറ്ററി ഡാറ്റ നീക്കേണ്ടതില്ല. കാഷെകൾ ഉപയോഗപ്രദമായി നിലനിർത്താൻ, ഒരു റിപ്പോസിറ്ററിക്കായുള്ള അഭ്യർത്ഥനകൾ സാധാരണയായി ഒരേ റെപ്ലിക്കയിലേക്കാണ് പോകുന്നത്, എന്നാൽ ആ പ്രത്യേക ഇൻസ്റ്റൻസ് ലഭ്യമായി തുടരുന്നതിനെ റിപ്പോസിറ്ററി ആശ്രയിക്കുന്നില്ല.

സ്വീകരിക്കപ്പെട്ട ഒരു കമ്മിറ്റ് സാധുവായ റിപ്പോസിറ്ററി അവസ്ഥയാണെന്ന് ഉറപ്പാക്കാൻ അക്സെപ്റ്റൻസ് ഘട്ടം റിപ്പോസിറ്ററി ഇൻവേരിയന്റുകൾ പരിശോധിക്കുന്നു. ഓരോ റിപ്പോസിറ്ററിക്കും ഞങ്ങൾ വ്യക്തമായ ഒരു കരാർ നിർവചിക്കുന്നു, അതിനാൽ യാന്ത്രിക പരിശോധനകൾക്ക് അത് അമിതമായി വലുതാകുന്നത് തടയാനാകും. PDF-കൾ, ചിത്രങ്ങൾ പോലുള്ള വലിയ ഫയലുകളും ബൈനറി ഫയലുകളും റോ Git ബ്ലോബുകളായല്ല, Git LFS വഴിയാണ് സംഭരിക്കുന്നത്. റിപ്പോസിറ്ററിയുടെ വലുപ്പം പരിമിതപ്പെടുത്തുന്നതിനൊപ്പം സമീപകാല ചരിത്രം ലഭ്യമാക്കി നിലനിർത്താൻ കോംപാക്ഷൻ സഹായിക്കുന്നു. വിജയകരമായ ഒരു സബ്മിറ്റിന് ശേഷം, റിപ്പോസിറ്ററിക്ക് കോംപാക്ഷൻ ആവശ്യമുണ്ടോ എന്ന് CLI, Git സേവനത്തോട് ചോദിക്കുന്നു. നിലനിർത്തിയിരിക്കുന്ന കമ്മിറ്റുകളുടെ എണ്ണം ഒരു പരിധി കവിഞ്ഞാൽ, ഏറ്റവും പുതിയ കമ്മിറ്റുകളുടെ ഒരു ചെറിയ കൂട്ടം മാത്രം Git സേവനം നിലനിർത്തുന്നു. പഴയ ചരിത്രം ഒരൊറ്റ ആരംഭ സ്നാപ്‌ഷോട്ടായി മാറ്റിസ്ഥാപിക്കുകയും, കമ്മിറ്റ് ഐഡന്റിഫയറുകൾ പുതുക്കുന്നതിനായി സമീപകാല കമ്മിറ്റുകൾ റീപ്ലേ ചെയ്യുകയും ചെയ്യുന്നു.

വലുതാക്കുക

ലളിതമായ ഒരു സിൻക്രൊണൈസേഷൻ ഘട്ടം ഒരേസമയം എഴുതുന്ന റൈറ്റർമാരെ നിയന്ത്രിക്കുന്നു. ഏറ്റവും ഒടുവിൽ സ്വീകരിച്ച കമ്മിറ്റ്, അഥവാ ഹെഡ്, ഇത് ട്രാക്ക് ചെയ്യുന്നു. ഒരു സബ്മിഷൻ ലഭിക്കുമ്പോൾ, ആ ഹെഡിനെ അടിസ്ഥാനമാക്കിയാണ് സബ്മിറ്റ് നിർമ്മിച്ചതെങ്കിൽ മാത്രമേ ഇത് അത് സ്വീകരിക്കൂ. അല്ലെങ്കിൽ, ഇത് ഒരു ഘടനാപരമായ സ്റ്റെയ്ൽ-ബേസ് പ്രതികരണം അയയ്ക്കുന്നു; തുടർന്ന് പിന്നിലായ ഏജന്റ് പുതിയ ഹെഡിന് മുകളിൽ അതിന്റെ മാറ്റം റീപ്ലേ ചെയ്ത് വീണ്ടും സമർപ്പിക്കണം. കാര്യമായ വേഗതക്കുറവ് സൃഷ്ടിക്കാതെ തന്നെ, ഒരേസമയം പ്രവർത്തിക്കുന്ന ഏജന്റുകൾ നിശ്ശബ്ദമായി പരസ്പരം ഓവർറൈറ്റ് ചെയ്യുന്നില്ലെന്ന് ഈ രൂപകൽപ്പന ഉറപ്പാക്കുന്നു. ഞങ്ങളുടെ പ്രൊഡക്ഷൻ വർക്ക്ഫ്ലോകളിൽ, 2%-ൽ താഴെ സബ്മിറ്റുകൾ മാത്രമാണ് സ്റ്റെയ്ൽ ആയി നിരസിക്കപ്പെടുന്നത്. മൊത്തത്തിൽ, മീഡിയൻ സബ്മിറ്റ് ലേറ്റൻസി 1.7 സെക്കൻഡിൽ താഴെയും p99 ലേറ്റൻസി 8 സെക്കൻഡിൽ താഴെയുമാണ്.

വലുതാക്കുക

സ്വീകരിക്കുന്ന ഓരോ മാറ്റവും Git സേവനം രേഖപ്പെടുത്തുകയും ചെയ്യുന്നു. സ്വീകരിക്കുന്ന ഓരോ റൈറ്റിനും, ഇത് ഒരു ഔട്ട്‌ബോക്സിലേക്ക് ഒരു എൻട്രി ചേർക്കുന്നു. റിപ്പോസിറ്ററി, പുതിയ കമ്മിറ്റ്, മാറ്റം വരുത്തിയ ഉപയോക്താവ്, മാറ്റം വന്ന പാത്തുകൾ എന്നിവ ലിസ്റ്റ് ചെയ്യുന്ന ഒരു ലോഗാണ് ഔട്ട്‌ബോക്സ്. പാഴ്‌സർ പോലുള്ള ഡൗൺസ്ട്രീം സേവനങ്ങൾ പുതിയ ജോലി കണ്ടെത്താൻ ഈ ലോഗ് വായിക്കുന്നു.

ഏജന്റുകൾക്ക് ആവശ്യമില്ലാത്ത ഭാഗങ്ങൾ ഒഴിവാക്കിക്കൊണ്ട്, ഈ ഘടകങ്ങൾ ഒരുമിച്ച് ഒരു റിപ്പോസിറ്ററി മാനേജ്‌മെന്റ് ലെയർ രൂപപ്പെടുത്തുന്നു. ഓരോ മാറ്റവും ഒരു മനുഷ്യനും അവലോകനം ചെയ്യാത്തതിനാൽ pull request-കൾ ആവശ്യമില്ല. പകരം, സബ്മിറ്റ് സമയത്ത് Git സേവനം കരാർ പരിശോധിക്കുന്നു, മത്സരത്തിൽ പിന്നിലാകുന്ന ഏജന്റ് സ്വന്തം മാറ്റം വീണ്ടും പ്രയോഗിക്കുന്നു, ആര് എന്ത് മാറ്റി എന്ന് കമ്മിറ്റ് ചരിത്രം രേഖപ്പെടുത്തുന്നു. വളർച്ച നിയന്ത്രിക്കാൻ ഒരു മനുഷ്യ ഓപ്പറേറ്ററെ ആശ്രയിക്കുന്നതിന് പകരം, ഡിറ്റർമിനിസ്റ്റിക് പരിശോധനകൾ ഓരോ റിപ്പോസിറ്ററിയെയും അതിന്റെ കരാറിനുള്ളിൽ നിലനിർത്തുന്നു.

സ്റ്റോറേജ്: ജോലി സ്ഥായിയായി സൂക്ഷിക്കൽ

സാൻഡ്‌ബോക്സുകളിൽ നിന്നും Git സേവന റെപ്ലിക്കകളിൽ നിന്നും സ്വതന്ത്രമായി, സ്റ്റോറേജ് ലെയർ റിപ്പോസിറ്ററി ഡാറ്റ സ്ഥായിയായി സംരക്ഷിക്കുന്നു. റിപ്പോസിറ്ററികൾ AWS S3Files-ലാണ് സ്ഥിതി ചെയ്യുന്നത്; സാധാരണ Git-ന് മാറ്റങ്ങളൊന്നും കൂടാതെ ഉപയോഗിക്കാൻ കഴിയുന്ന ഒരു ഫയൽസിസ്റ്റം ഇന്റർഫേസിലൂടെ ഇത് S3 അടിസ്ഥാനമാക്കിയുള്ള സ്റ്റോറേജ് ലഭ്യമാക്കുന്നു. ഓരോന്നും പങ്കിട്ട ഫയൽസിസ്റ്റത്തിലെ ഒരു ബെയർ Git റിപ്പോസിറ്ററിയാണ്; ഒരു വർക്കിംഗ് ചെക്ക്ഔട്ടിന് പകരം റിപ്പോസിറ്ററിയുടെ ഒബ്ജക്റ്റുകളും റഫറൻസുകളുമാണ് ഇതിൽ അടങ്ങിയിരിക്കുന്നത്.

സ്റ്റോറേജിനെയും കമ്പ്യൂട്ടിനെയും വേർപെടുത്തുന്നത് സാൻഡ്‌ബോക്സുകളെ ക്ഷണികമായി നിലനിർത്താൻ സഹായിക്കുന്നു. ഓരോ ഏജന്റിനും സ്വന്തം സാൻഡ്‌ബോക്സ് ലഭിക്കുന്നു, ഒരു മെഷീൻ പങ്കിടാതെ തന്നെ നിരവധി ഏജന്റുകൾക്ക് ഒരേ പ്രോജക്റ്റിൽ പ്രവർത്തിക്കാനാകും. ഒരു സാൻഡ്‌ബോക്സ് ക്രാഷ് ആയാൽ, സമർപ്പിക്കാത്ത ജോലി മാത്രമേ അപകടത്തിലാകൂ.

പകരമായി, ഓരോ പ്രോജക്റ്റിനും അതിലെ എല്ലാ ഏജന്റുകളും പങ്കിടുന്ന, ദീർഘകാലം നിലനിൽക്കുന്ന ഒരു സാൻഡ്‌ബോക്സ് നൽകാമായിരുന്നു; അങ്ങനെയെങ്കിൽ പ്രോജക്റ്റിന്റെ ഫയലുകൾ ആ മെഷീന്റെ ഡിസ്കിലായിരിക്കും. എന്നിരുന്നാലും, ഇത് ഏജന്റുകളുടെ കമ്പ്യൂട്ട് ശേഷിയെ ആ മെഷീൻ പ്രവർത്തിക്കുന്ന ഇടവുമായി ബന്ധിപ്പിക്കുകയും, ഏറ്റവും തിരക്കേറിയ സമയങ്ങൾക്ക് അനുസൃതമായി അതിന്റെ വലുപ്പം നിശ്ചയിക്കേണ്ടി വരികയും ചെയ്യും. പ്രോജക്റ്റിന്റെ സ്റ്റോറേജ് സിസ്റ്റത്തിന്റെ ഭാഗമായി ബാക്കപ്പുകളും വീണ്ടെടുക്കലും കൈകാര്യം ചെയ്തുകൊണ്ട്, മാസങ്ങളോളം അത് ആരോഗ്യകരമായി തുടരുകയും വേണം.

വലുതാക്കുക

ഡൗൺസ്ട്രീം പ്രോസസ്സിംഗ്: ഡോക്യുമെന്റുകൾ ഏജന്റുകൾക്ക് വായിക്കാവുന്നതാക്കൽ

പ്രധാന ഡൗൺസ്ട്രീം ഘടകം ഒരു പാഴ്‌സർ പൈപ്പ്‌ലൈനാണ്. പ്രോജക്റ്റ് ഫയലുകൾ ഏജന്റുകൾക്ക് എളുപ്പത്തിൽ വായിക്കാൻ കഴിയുന്ന തരത്തിലാക്കാൻ, പുതുതായി ചേർത്തതോ അപ്‌ഡേറ്റ് ചെയ്തതോ ആയ ഡോക്യുമെന്റുകളിൽ നിന്ന് ഇത് ടെക്സ്റ്റും മെറ്റാഡാറ്റയും വേർതിരിച്ചെടുക്കുന്നു. ഒരു പാഴ്‌സർ വർക്കർ ചേഞ്ച് സ്ട്രീം ക്യൂവിൽ നിന്ന് അപ്‌ഡേറ്റുകൾ സ്വീകരിക്കുകയും, കമ്മിറ്റ് മെറ്റാഡാറ്റയിൽ നിന്ന് മാറ്റം വന്ന ഫയലുകൾ കണ്ടെത്തുകയും, കണ്ടന്റ് ഹാഷ് ഉപയോഗിച്ച് റോ ബൈറ്റുകൾ ലഭ്യമാക്കുകയും ചെയ്യുന്നു. തുടർന്ന് ഇത് ഡോക്യുമെന്റ് പാഴ്‌സ് ചെയ്ത് വേർതിരിച്ചെടുത്ത ടെക്സ്റ്റും ഡോക്യുമെന്റ് മെറ്റാഡാറ്റയും സൃഷ്ടിക്കുന്നു.

പാഴ്‌സ് ചെയ്ത ഔട്ട്‌പുട്ടുകൾ റിപ്പോസിറ്ററിക്ക് പുറത്താണ്, സോഴ്സ് ഡോക്യുമെന്റിന്റെ ഹാഷ് കീ ആയി ഉപയോഗിക്കുന്ന ഒരു സ്റ്റോറിൽ. ഈ ആർട്ടിഫാക്ടുകൾ ഒരിക്കലും റിപ്പോസിറ്ററിയിലേക്ക് തിരികെ കമ്മിറ്റ് ചെയ്യപ്പെടുന്നില്ല, കാരണം അത് അനാവശ്യമായി ചരിത്രം മലിനമാക്കുകയും ഒരേസമയമുള്ള റൈറ്റുകളുടെ എണ്ണം വർദ്ധിപ്പിക്കുകയും ചെയ്യും. പകരം, പാഴ്‌സ് ചെയ്ത ഔട്ട്‌പുട്ടുകൾ ചെക്ക്ഔട്ടിലൂടെയും സിങ്കിലൂടെയും സാൻഡ്‌ബോക്സിൽ എത്തുന്നു. ഓരോ ചെക്ക്ഔട്ടിലും, ആർട്ടിഫാക്ട് മെറ്റീരിയലൈസേഷനായി CLI ഉപയോഗിക്കുന്ന ഒരു റിസർവ് ചെയ്ത ഡയറക്ടറി ഉണ്ട്. പാഴ്‌സിംഗ് അസിൻക്രണസായി നടക്കുന്നതിനാൽ, ഒരു പശ്ചാത്തല പാഴ്‌സർ വർക്കർ ചെക്ക്ഔട്ടുകളെ തടസ്സപ്പെടുത്തുന്നില്ല.

ഏജന്റുകൾ വർക്ക്‌സ്‌പേസ് എങ്ങനെ ഉപയോഗിക്കുന്നു

സാൻഡ്‌ബോക്സിലേക്ക് ലോഡ് ചെയ്ത റിപ്പോസിറ്ററി പതിപ്പ്, സാധാരണ ഫയൽസിസ്റ്റം ടൂളുകൾ ഉപയോഗിച്ച് ഏജന്റുകൾ പര്യവേക്ഷണം ചെയ്യുന്നു. ആദ്യം തിരയുക, പിന്നെ വായിക്കുക എന്ന ഒരു നിശ്ചിത പൈപ്പ്‌ലൈൻ പിന്തുടരുന്നതിന് പകരം, അവ ഫോൾഡറുകൾ ലിസ്റ്റ് ചെയ്യുന്നു, grep ഉപയോഗിച്ച് ഫയൽ ഉള്ളടക്കങ്ങൾ തിരയുന്നു, പ്രസക്തമായ ഭാഗങ്ങൾ വായിക്കുന്നു, കണ്ടെത്തുന്നവ ഉപയോഗിച്ച് അടുത്തതായി എവിടെ നോക്കണമെന്ന് തീരുമാനിക്കുന്നു.

Computer-ന് സമാനമായി, Search അതിന്റെ സാധാരണ ഫയൽ ടൂളുകളിലൂടെ ഇതേ സമീപനം ഉപയോഗിക്കുന്നു. ഒരു പ്രത്യേക എക്സ്പ്ലൊറേഷൻ ഏജന്റ് കൂടുതൽ പരിമിതമായ ബജറ്റിനുള്ളിൽ പ്രോജക്റ്റിൽ തിരയുകയും പ്രസക്തമായ ഫയൽ പാത്തുകളും പിന്തുണയ്ക്കുന്ന ഉദ്ധരണികളും തിരികെ നൽകുകയും ചെയ്യുന്നു. തുടർന്ന് ഉത്തരം നൽകുന്ന മോഡൽ തിരഞ്ഞെടുത്ത ഫയലുകൾ വായിച്ച് ഉത്തരം സൃഷ്ടിക്കുന്നു. നിലവിലുള്ള ഒരു പ്രോജക്റ്റ് സാൻഡ്‌ബോക്സ് പുനരുപയോഗിക്കുന്നത് സജ്ജീകരണ സമയം കുറയ്ക്കുന്നു: ഒരു വാം ചെക്ക്ഔട്ടിലേക്ക് അറ്റാച്ച് ചെയ്യാൻ ഏകദേശം 2.9 സെക്കൻഡ് എടുക്കുമ്പോൾ, ഒരു കോൾഡ് സ്റ്റാർട്ടിന് ഏകദേശം 8 സെക്കൻഡ് എടുക്കുന്നു.

വലുതാക്കുക

പാഴ്‌സ് ചെയ്ത ടെക്സ്റ്റ്, PDF-കളും Office ഫയലുകളും പോലുള്ള വലിയ ഡോക്യുമെന്റുകളെ അതേ ടൂളുകൾ ഉപയോഗിച്ച് തിരയാവുന്നതാക്കുന്നു. ഏതെല്ലാം ഡോക്യുമെന്റുകൾക്കാണ് വേർതിരിച്ചെടുത്ത ടെക്സ്റ്റ് ലഭ്യമായിട്ടുള്ളതെന്ന് കാണിക്കുന്ന ഒരു ലിസ്റ്റായ മാനിഫെസ്റ്റ് ഏജന്റ് ആദ്യം പരിശോധിക്കുന്നു, തുടർന്ന് ആ ടെക്സ്റ്റ് സാധാരണ ഫയലുകളായി തിരയുകയും വായിക്കുകയും ചെയ്യുന്നു. ടെക്സ്റ്റ് മതിയാകാത്തപ്പോൾ മാത്രമേ, ഉദാഹരണത്തിന് ഫിഗറുകൾ, ലേഔട്ട്, അല്ലെങ്കിൽ ഉൾച്ചേർത്ത ഡാറ്റ പരിശോധിക്കാൻ, ഇത് യഥാർത്ഥ ഡോക്യുമെന്റ് ഡൗൺലോഡ് ചെയ്യുന്നുള്ളൂ.

ഒരേ കോർപ്പസിലെ 150 സിംഗിൾ-ഡോക്യുമെന്റ് സാമ്പത്തിക ചോദ്യങ്ങളിൽ, ഒരു ഇൻഡെക്സിന് മുകളിലുള്ള സെമാന്റിക് സെർച്ചുമായി ഈ സമീപനത്തെ ഞങ്ങൾ ബെഞ്ച്മാർക്ക് ചെയ്തു. ശരിയായ ഡോക്യുമെന്റ് വീണ്ടെടുക്കുന്നതിൽ എക്സ്പ്ലൊറേഷൻ ഏജന്റ് 0.867-ഉം ശരിയായി ഉത്തരം നൽകുന്നതിൽ 0.627-ഉം സ്കോർ ചെയ്തു; സെമാന്റിക് സെർച്ചിന് ഇത് യഥാക്രമം ഏകദേശം 0.39-ഉം 0.37-ഉം ആയിരുന്നു. അതായത്, ഏകദേശം 25% കുറഞ്ഞ ലേറ്റൻസിയിൽ, ഉത്തരങ്ങളിൽ ഏകദേശം 1.7 മടങ്ങും വീണ്ടെടുക്കലിൽ 2 മടങ്ങും മികച്ച പ്രകടനം. എക്സ്പ്ലൊറേഷൻ ഏജന്റ് കൂടുതലും വേർതിരിച്ചെടുത്ത ടെക്സ്റ്റ് ഉപയോഗിച്ചാണ് പ്രവർത്തിക്കുന്നത്, യഥാർത്ഥ PDF-കൾ അപൂർവമായി മാത്രമേ ഡൗൺലോഡ് ചെയ്യാറുള്ളൂ.

വലുതാക്കുക

ഒരൊറ്റ പങ്കിട്ട ഇൻഫ്രാസ്ട്രക്ചർ

Computer-ന്റെ സ്ഥിരമായ മെമ്മറിയും ഇതേ ഫയൽസിസ്റ്റം ഇൻഫ്രാസ്ട്രക്ചർ തന്നെയാണ് ഉപയോഗിക്കുന്നത്. Computer-ന്റെ നോളജ് വിക്കിയായ Perplexity Brain, സ്വന്തം ചരിത്രവും നയങ്ങളുമുള്ള നോളജ് റിപ്പോസിറ്ററികളിലാണ് മെമ്മറി സംഭരിക്കുന്നത്. അറിവിനെ പ്രോജക്റ്റ് ഫയലുകളിൽ നിന്ന് വേർതിരിച്ച് സൂക്ഷിക്കുന്നതിനാൽ, പശ്ചാത്തല മെമ്മറി അപ്‌ഡേറ്റുകൾ ആ ഫയലുകളിലെ എഡിറ്റുകളുമായി മത്സരിക്കുന്നില്ല. രണ്ടും ആവശ്യമുള്ള ഒരു സെഷൻ രണ്ട് റിപ്പോസിറ്ററികളും ലോഡ് ചെയ്യുന്നു.

പശ്ചാത്തല ഏജന്റുകൾ നിലവിലുള്ള അറിവ് വായിക്കുകയും പുതിയ വിവരങ്ങൾ ഉൾപ്പെടുത്തുകയും അപ്‌ഡേറ്റ് ചെയ്ത പേജുകൾ കമ്മിറ്റുകളായി സംരക്ഷിക്കുകയും ചെയ്യുന്നു. മറ്റ് ഏജന്റുകൾ സാധാരണ ഫയൽ ടൂളുകൾ ഉപയോഗിച്ച് ആ പേജുകൾ വായിക്കുന്നു, ആളുകൾക്കും അവ എഡിറ്റ് ചെയ്യാം. ഓരോ റീഡറുമായും നേരിട്ട് ഏകോപിപ്പിക്കുന്നതിന് പകരം, റൈറ്റർമാർ റിപ്പോസിറ്ററിയിലൂടെ തങ്ങളുടെ ജോലി പങ്കിടുന്നു. ആര് എന്ത് മാറ്റി എന്ന് കമ്മിറ്റ് ചരിത്രം രേഖപ്പെടുത്തുന്നു, അതേസമയം സ്വീകരിച്ച അപ്‌ഡേറ്റുകൾ ഔട്ട്‌ബോക്സ് ഡൗൺസ്ട്രീം സേവനങ്ങളെ അറിയിക്കുന്നു. അറിവ് എങ്ങനെ വികസിച്ചു എന്നതിന്റെ രേഖയോടെ, ആളുകൾക്കും ഏജന്റുകൾക്കും പരസ്പരം ചെയ്ത ജോലിയുടെ മേൽ കെട്ടിപ്പടുക്കാം.

ഉപസംഹാരം

ആളുകളും ഏജന്റുകളും ഒരു പ്രോജക്റ്റ് പങ്കിടുമ്പോൾ, വർക്ക്‌സ്‌പേസ് ഫയലുകൾ സംഭരിക്കുന്നതിനപ്പുറം പലതും ചെയ്യുന്നു. സംഭാവനകൾ സംയോജിപ്പിക്കാനും എന്ത് മാറി എന്ന് ട്രാക്ക് ചെയ്യാനും ഇത് ഒരു പൊതു ഇടം നൽകുന്നു. ആ അടിത്തറയുടെ ഭൂരിഭാഗവും 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}
}