AI ഏജന്റ് ഓർക്കസ്ട്രേഷൻ: പരാജയങ്ങൾ, അംഗീകാരങ്ങൾ, റീട്രൈകൾ

ഒരേ പ്രോജക്റ്റിൽ നിരവധി ഏജന്റുകൾ പ്രവർത്തിക്കുന്നത് അങ്ങേയറ്റം കാര്യക്ഷമമായി തോന്നാം. ഒന്ന് ജോലി ആസൂത്രണം ചെയ്യുന്നു, മറ്റൊന്ന് ഡിസൈൻ കൈകാര്യം ചെയ്യുന്നു, മൂന്നാമത്തേത് കോഡ് എഴുതുന്നു. പരാജയപ്പെടുന്നതുവരെ എല്ലാം നന്നായി നടക്കും. നിങ്ങൾ ആഗ്രഹിക്കുന്നതിലും കൂടുതൽ തവണ പരാജയങ്ങൾ സംഭവിക്കുകയും ചെയ്യുന്നു.

ഈ പരാജയങ്ങൾ തടയാൻ ശ്രദ്ധാപൂർവ്വമായ വർക്ക്ഫ്ലോ എഞ്ചിനീയറിംഗ് ആവശ്യമാണ്. അതിനാൽ, ഓർക്കസ്ട്രേറ്റ് ചെയ്ത വർക്ക്ഫ്ലോകളെ വിശ്വാസ്യതയില്ലാത്തതാക്കുന്നത് എന്താണെന്ന് പരിശോധിക്കുകയും, പ്രൊഡക്ഷൻ വിശ്വാസ്യതയ്ക്കായുള്ള ഓർക്കസ്ട്രേഷൻ മികച്ച രീതികൾ പര്യവേക്ഷണം ചെയ്യുകയും ചെയ്യാം.

ഒരു മൾട്ടി-സ്റ്റെപ്പ് ടാസ്ക് പൂർത്തിയാക്കാൻ AI ഏജന്റ് ഓർക്കസ്ട്രേഷൻ ഒന്നിലധികം AI ഏജന്റുകളെയും മോഡലുകളെയും ടൂളുകളെയും ഏകോപിപ്പിക്കുന്നു. എന്നാൽ ഏത് ഏജന്റ് ആദ്യം പ്രവർത്തിക്കണം, അതിന് എന്ത് വിവരങ്ങൾ ലഭിക്കണം, അത് പൂർത്തിയായ ശേഷം എന്ത് സംഭവിക്കണം എന്നിവ ആരെങ്കിലും — അല്ലെങ്കിൽ എന്തെങ്കിലും — ഇപ്പോഴും തീരുമാനിക്കേണ്ടതുണ്ട്. ഇതാണ് ഓർക്കസ്ട്രേറ്ററിന്റെ പങ്ക് — ഒരു മാനേജറായി പ്രവർത്തിക്കുന്ന AI ഏജന്റ് അല്ലെങ്കിൽ സോഫ്റ്റ്‌വെയർ നിയന്ത്രിത എക്സിക്യൂഷൻ ലെയർ.

ലളിതമായി പറഞ്ഞാൽ, ഒരു ഓർക്കസ്ട്രേഷൻ ലെയർ ഒരു ലക്ഷ്യത്തെ ചെറിയ ടാസ്കുകളായി വിഭജിക്കുകയും, ഡിപൻഡൻസികൾ ട്രാക്ക് ചെയ്യുകയും, എക്സിക്യൂഷൻ ശരിയായ ഏജന്റുകളെ ഏൽപ്പിക്കുകയും, പങ്കിട്ട കോൺടെക്സ്റ്റ് കൈകാര്യം ചെയ്യുകയും, ഔട്ട്പുട്ടുകൾ ഒരുമിച്ച് ചേർക്കുകയും ചെയ്യുന്നു.

ഓർക്കസ്ട്രേഷൻ എക്സിക്യൂഷൻ എഞ്ചിന്റെ ഡയഗ്രം: ലക്ഷ്യവും പ്ലാനും, ഏജന്റുകളിലേക്ക് റൂട്ട് ചെയ്യൽ, ടൂളുകൾ വേർതിരിച്ച് എക്സിക്യൂട്ട് ചെയ്യൽ, ഘടനാപരമായ ഫലങ്ങൾ, സ്ഥിരമായ വർക്ക്ഫ്ലോ സ്റ്റേറ്റ്, വീണ്ടും ശ്രമിക്കുകയോ തിരികെ നൽകുകയോ താൽക്കാലികമായി നിർത്തുകയോ കാത്തിരിക്കുകയോ അടുത്ത ടാസ്കിലേക്ക് നീങ്ങുകയോ ചെയ്യുന്ന ഒരു സാധൂകരണ-തീരുമാന ഘട്ടം.

ഒരു ഓർക്കസ്ട്രേറ്ററിന് ഒരു ടാസ്ക് നൽകിയ ശേഷം എന്ത് സംഭവിക്കുന്നുവെന്ന് നോക്കാം.

Perplexity-യുടെ Computer വർക്ക്‌ഷോപ്പിൽ നിന്നുള്ള ഒരു ഉദാഹരണം പരിഗണിക്കുക: Salesforce, Snowflake, ഇമെയിൽ, കലണ്ടർ, സമീപകാല വാർത്തകൾ എന്നിവയിൽ നിന്നുള്ള വിവരങ്ങൾ ഉപയോഗിച്ച് ഒരു അക്കൗണ്ട് ഇന്റലിജൻസ് ഡാഷ്‌ബോർഡ് നിർമ്മിക്കൽ.

ലക്ഷ്യം മനസ്സിലാക്കി ജോലി ആസൂത്രണം ചെയ്യുക. ഓർക്കസ്ട്രേറ്റർ ആവശ്യപ്പെട്ട ഫലത്തിൽ നിന്ന് ആരംഭിച്ച്, അതിനെ വ്യക്തമായ ഡിപൻഡൻസികളുള്ള ടാസ്കുകളായി വിഭജിക്കുന്നു. ഞങ്ങളുടെ ഡാഷ്‌ബോർഡ് ഉദാഹരണത്തിൽ, വ്യത്യസ്ത ഉറവിടങ്ങളിൽ നിന്ന് വിവരങ്ങൾ ശേഖരിച്ച് അതിനെ പൂർത്തിയായ ഒരു ഡെലിവറബിളാക്കി മാറ്റുന്നത് ഇതിൽ ഉൾപ്പെടുന്നു. ഏതൊക്കെ ഘട്ടങ്ങൾ മറ്റുള്ളവയെ ആശ്രയിക്കുന്നുവെന്നും ഏതൊക്കെ സ്വതന്ത്രമായി പ്രവർത്തിക്കാമെന്നും പ്ലാനർ നിർണ്ണയിക്കുന്നു.
ടാസ്കുകൾ ഉചിതമായ ഏജന്റുകളിലേക്ക് റൂട്ട് ചെയ്യുക. ഡിപൻഡൻസികൾ നിറവേറ്റപ്പെട്ട ടാസ്കുകൾ ഓർക്കസ്ട്രേറ്റർ തിരിച്ചറിയുകയും, ജോലി പ്രത്യേക വൈദഗ്ധ്യമുള്ള ഏജന്റുകളെയോ മോഡലുകളെയോ ഏൽപ്പിക്കുകയും ചെയ്യുന്നു. ആശ്രിത ടാസ്കുകൾ അവയുടെ മുൻവ്യവസ്ഥകൾക്കായി കാത്തിരിക്കുന്നു. Perplexity Computer ഒന്നിലധികം ഫ്രണ്ടിയർ മോഡലുകൾ ഉപയോഗിക്കുന്നു, വർക്ക്ഫ്ലോയുടെ വ്യത്യസ്ത ഭാഗങ്ങൾ ആ ടാസ്കുകൾക്ക് അനുയോജ്യമായ സിസ്റ്റങ്ങളിലേക്ക് റൂട്ട് ചെയ്യുന്നു. ഇത് സ്വതന്ത്രമായ ജോലികൾ സമാന്തരമായി പ്രവർത്തിപ്പിക്കാനും സഹായിക്കുന്നു.
നിയന്ത്രിത എൻവയോൺമെന്റുകൾക്കുള്ളിൽ ടൂൾ കോളുകൾ എക്സിക്യൂട്ട് ചെയ്യുക. വെബ് സെർച്ച്, API-കൾ, കണക്റ്റ് ചെയ്ത ആപ്ലിക്കേഷനുകൾ, ഫയൽ ഓപ്പറേഷനുകൾ, അല്ലെങ്കിൽ കോഡ് എക്സിക്യൂഷൻ പോലുള്ള ടൂളുകളിലൂടെ ഏജന്റുകൾ അവയുടെ എൻവയോൺമെന്റുമായി ഇടപഴകുന്നു. എക്സിക്യൂഷൻ ലെയർ ഈ പ്രവർത്തനങ്ങൾ നടപ്പിലാക്കുകയും ഫലങ്ങൾ ഏജന്റുകൾക്ക് തിരികെ നൽകുകയും ചെയ്യുന്നു.
ഏജന്റുകൾക്കിടയിൽ ഫലങ്ങളും കോൺടെക്സ്റ്റും കൈമാറുക. ഒരു ഏജന്റ് അതിന്റെ ടാസ്ക് പൂർത്തിയാക്കിക്കഴിഞ്ഞാൽ, തുടരാൻ അടുത്ത ഡൗൺസ്ട്രീം ഏജന്റിന് പ്രസക്തമായ ഔട്ട്പുട്ട് ആവശ്യമാണ്. ഒരു ഹാൻഡ്ഓഫ് റെക്കോർഡിൽ ടാസ്ക് ID, ഔട്ട്പുട്ട് റഫറൻസ്, സ്കീമ പതിപ്പ്, ഉറവിട മെറ്റാഡാറ്റ എന്നിവ അടങ്ങിയിരിക്കാം. തുടർന്നുള്ള ഘട്ടങ്ങൾക്ക് ആവശ്യമായ കോൺടെക്സ്റ്റ് നിലനിർത്തിക്കൊണ്ട് ഓർക്കസ്ട്രേറ്റർ ഈ ഹാൻഡ്ഓഫുകൾ ഏകോപിപ്പിക്കുന്നു. പ്രധാനമായി, മറ്റെല്ലാ ഏജന്റുകളുടെയും ജോലിയുടെ മുഴുവൻ ചരിത്രവും ഏജന്റുകൾ സ്വന്തം കോൺടെക്സ്റ്റ് വിൻഡോകളിൽ വഹിക്കേണ്ടതില്ല.
എക്സിക്യൂഷൻ സ്റ്റേറ്റ് ഏജന്റ് കോൺടെക്സ്റ്റിൽ നിന്ന് വേറിട്ട് രേഖപ്പെടുത്തുക. ഏജന്റുകൾ ടാസ്കുകൾ ആരംഭിക്കുകയോ പൂർത്തിയാക്കുകയോ അവയിൽ പരാജയപ്പെടുകയോ ചെയ്യുമ്പോൾ, എക്സിക്യൂഷൻ എഞ്ചിൻ ടാസ്ക് സ്റ്റാറ്റസുകൾ, എക്സിക്യൂഷൻ ശ്രമങ്ങൾ, ഔട്ട്പുട്ട് റഫറൻസുകൾ, ശേഷിക്കുന്ന ജോലി എന്നിവ ഉപയോഗിച്ച് ഒരു സ്ഥിരമായ വർക്ക്ഫ്ലോ റെക്കോർഡ് അപ്ഡേറ്റ് ചെയ്യുന്നു. സംഭാഷണ ചരിത്രത്തിൽ നിന്ന് വർക്ക്ഫ്ലോ പുനർനിർമ്മിക്കാൻ ഒരു LLM-നെ ആശ്രയിക്കാതെ തന്നെ പുരോഗതി ട്രാക്ക് ചെയ്യാനും തടസ്സങ്ങൾക്ക് ശേഷം പുനരാരംഭിക്കാനും ഈ റെക്കോർഡ് ഓർക്കസ്ട്രേറ്ററിനെ സഹായിക്കുന്നു.
ഫലങ്ങൾ സാധൂകരിച്ച് അടുത്തതായി എന്ത് സംഭവിക്കണമെന്ന് തീരുമാനിക്കുക. ഒരു ടാസ്ക് തിരികെയെത്തുമ്പോൾ, അതിന്റെ ഔട്ട്പുട്ട് പ്രതീക്ഷിക്കുന്ന കോൺട്രാക്റ്റ് പാലിക്കുന്നുണ്ടോ എന്നും അടുത്ത ടാസ്കിന്റെ ഡിപൻഡൻസികൾ നിറവേറ്റപ്പെട്ടിട്ടുണ്ടോ എന്നും ഓർക്കസ്ട്രേഷൻ ലെയർ പരിശോധിക്കുന്നു. ഒരു പ്രശ്നം കണ്ടെത്തിയാൽ, തിരുത്തലിനായി വർക്ക്ഫ്ലോയ്ക്ക് മുമ്പത്തെ ഒരു ഘട്ടത്തിലേക്ക് മടങ്ങാം, അല്ലെങ്കിൽ അത് താൽക്കാലികമായി നിർത്തിവയ്ക്കാം. അല്ലാത്തപക്ഷം, അത് പൂർത്തീകരണത്തിലേക്ക് നീങ്ങുന്നു.

ലളിതമെന്ന് തോന്നുന്ന AI ഏജന്റ് ഓർക്കസ്ട്രേഷന് പിന്നിൽ നിരവധി ഘടകങ്ങൾ പ്രവർത്തിക്കുന്നുണ്ട്. ഏജന്റ് ഏകോപനം നിങ്ങൾ എങ്ങനെ ക്രമീകരിക്കുന്നു എന്നതാണ് എക്സിക്യൂഷനിൽ നിങ്ങൾക്ക് എത്രത്തോളം നിയന്ത്രണമുണ്ടെന്ന് നിർണ്ണയിക്കുന്നത്. തീർച്ചയായും, ആ ഏകോപനമെല്ലാം അധിക ഭാരം കൂട്ടുന്നു. അതിനാൽ അത് എല്ലായ്പ്പോഴും മൂല്യവത്തായിരിക്കില്ല.

ടാസ്കിന്റെ വ്യത്യസ്ത ഭാഗങ്ങൾക്ക് വ്യത്യസ്ത വൈദഗ്ധ്യം ആവശ്യമുള്ളപ്പോഴോ, സ്വതന്ത്രമായ ജോലികൾ സമാന്തരമായി പ്രവർത്തിപ്പിക്കാനാകുമ്പോഴോ, അടുത്ത ഘട്ടം മുൻകൂട്ടി നിർണ്ണയിക്കാൻ കഴിയാത്തപ്പോഴോ മൾട്ടി-ഏജന്റ് ഓർക്കസ്ട്രേഷൻ പരിഗണിക്കുക.

അതിനാൽ, മൂന്ന് സാഹചര്യങ്ങളിൽ ഓർക്കസ്ട്രേഷൻ സഹായകമാണ്:

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

ഇവ ഒഴികെ, ഓർക്കസ്ട്രേഷൻ ചെലവേറിയ ഒരു ട്രെൻഡ് മാത്രമാണ്. കൂടുതൽ ഏജന്റുകൾ എന്നാൽ കൂടുതൽ ഏകോപനവും ഒരുപക്ഷേ ഉയർന്ന ടോക്കൺ ചെലവുകളും എന്നാണ് അർത്ഥം.

“ഞാൻ സാധാരണയായി ഏറ്റവും ലളിതമായ ഓപ്ഷനിൽ തുടങ്ങി അവിടെ നിന്ന് മുന്നോട്ട് നിർമ്മിക്കുന്നു. ഘട്ടങ്ങൾ ഞങ്ങൾക്ക് അറിയാമെങ്കിൽ, അവ ആവർത്തിക്കാവുന്നവയാണെങ്കിൽ, അത് മിക്കവാറും ഒരു വർക്ക്ഫ്ലോ ആയിരിക്കും. വ്യത്യസ്ത ഉത്തരവാദിത്തങ്ങളോ അനുമതികളോ ഉപയോക്താക്കളോ ഉള്ളപ്പോൾ മാത്രമാണ് ഒന്നിലധികം ഏജന്റുകളെ അവതരിപ്പിക്കാൻ ഞാൻ കാരണം കാണുന്നത്,” എന്ന് Josh Spilker പറയുന്നു. AirOps-ലെ സെർച്ച് മാർക്കറ്റിംഗ് മേധാവിയാണ് അദ്ദേഹം.

അപ്പോഴും, അധിക മോഡൽ കോളുകൾ, ഹാൻഡ്ഓഫുകൾ, ലേറ്റൻസി, പരാജയ സാധ്യതയുള്ള പോയിന്റുകൾ എന്നിവയുമായി നേട്ടങ്ങൾ താരതമ്യം ചെയ്ത് വിലയിരുത്തുക.

ഏജന്റ് ഏകോപനം ക്രമീകരിക്കാൻ മൂന്ന് സാധാരണ മാർഗ്ഗങ്ങളുണ്ട് — കേന്ദ്രീകൃത, വികേന്ദ്രീകൃത, ശ്രേണീപരമായ ഓർക്കസ്ട്രേഷൻ. ശരിയായ ആർക്കിടെക്ചർ തിരഞ്ഞെടുക്കുന്നത് ഒരൊറ്റ ചോദ്യത്തെ ആശ്രയിച്ചിരിക്കുന്നു: ജോലി ആരാണ് നിയന്ത്രിക്കുന്നത്, ഏജന്റുകൾ പരസ്പരം എങ്ങനെ ഏകോപിപ്പിക്കുന്നു?

കേന്ദ്രീകൃത ഓർക്കസ്ട്രേഷനിൽ, ഒരു ഓർക്കസ്ട്രേറ്റർ പ്രക്രിയ കൈകാര്യം ചെയ്യുന്നു. അത് ടാസ്കിനെ വിഭജിക്കുകയും, ജോലി സ്പെഷ്യലിസ്റ്റ് ഏജന്റുകളെ ഏൽപ്പിക്കുകയും, അവയുടെ പുരോഗതി ട്രാക്ക് ചെയ്യുകയും, അവയുടെ ഫലങ്ങൾ ഒരുമിച്ച് ചേർക്കുകയും ചെയ്യുന്നു.

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

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

വികേന്ദ്രീകൃത ഓർക്കസ്ട്രേഷനിൽ, ഓരോ തീരുമാനവും എടുക്കാൻ ഒരു മാനേജറെ ആശ്രയിക്കുന്നതിന് പകരം ഏജന്റുകൾ കൂടുതൽ നേരിട്ട് ഏകോപിപ്പിക്കുന്നു. അവയ്ക്ക് സന്ദേശങ്ങൾ കൈമാറാനും, പങ്കിട്ട സ്റ്റേറ്റ് വായിക്കാനും, അവയുടെ അടുത്ത ഘട്ടങ്ങൾ സ്വതന്ത്രമായി നിർണ്ണയിക്കാനും കഴിയും.

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

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

ശ്രേണീപരമായ ഓർക്കസ്ട്രേഷൻ മാനേജർ സമീപനത്തെ ഒന്നിലധികം തലങ്ങളിലേക്ക് വ്യാപിപ്പിക്കുന്നു. ഒരു ഉന്നതതല ഓർക്കസ്ട്രേറ്റർ കീഴ്‌തല ഓർക്കസ്ട്രേറ്ററുകളെ ഉത്തരവാദിത്തം ഏൽപ്പിക്കുന്നു, അവ സ്വന്തം സ്പെഷ്യലിസ്റ്റ് ഏജന്റ് ഗ്രൂപ്പുകളെ ഏകോപിപ്പിക്കുന്നു.

സെയിൽസ്, ഫിനാൻസ്, ലീഗൽ ടീമുകൾ ഉൾപ്പെടുന്ന ഒരു എന്റർപ്രൈസ് വർക്ക്ഫ്ലോ സങ്കൽപ്പിക്കുക. ഒരു ഉന്നതതല ഓർക്കസ്ട്രേറ്ററിന് ഓരോ വർക്ക്സ്ട്രീമും ഒരു ഡൊമെയ്ൻ-നിർദ്ദിഷ്ട കോർഡിനേറ്ററെ ഏൽപ്പിക്കാം. തുടർന്ന് ആ കോർഡിനേറ്റർമാർ സ്വന്തം സ്പെഷ്യലിസ്റ്റ് ഏജന്റുകളെ കൈകാര്യം ചെയ്യുകയും ഏകീകൃത ഫലങ്ങൾ റിപ്പോർട്ട് ചെയ്യുകയും ചെയ്യും.

ഒരു ഓർക്കസ്ട്രേറ്ററിന് ഫലപ്രദമായി കൈകാര്യം ചെയ്യാൻ കഴിയാത്തത്ര വിശാലമാണ് വർക്ക്ഫ്ലോകളെങ്കിൽ ഈ ഘടന സഹായിക്കും.

ശ്രേണീപരമായ ഓർക്കസ്ട്രേഷന്റെ ഡയഗ്രം: ഒരു ഉന്നതതല ഓർക്കസ്ട്രേറ്റർ സെയിൽസ്, ഫിനാൻസ്, ലീഗൽ ഓർക്കസ്ട്രേറ്ററുകളെ ജോലി ഏൽപ്പിക്കുന്നു; ഓരോന്നും രണ്ട് സ്പെഷ്യലിസ്റ്റ് ഏജന്റുകളെ കൈകാര്യം ചെയ്യുന്നു, അവയുടെ ജോലി ഒരു ഏകീകൃത ഔട്ട്പുട്ടായി സംയോജിക്കുന്നു.

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

ഈ ആർക്കിടെക്ചറുകൾ തമ്മിലുള്ള താരതമ്യം:

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

മനസ്സിലാക്കേണ്ട ഒരു വ്യത്യാസം കൂടിയുണ്ട്. ഏജന്റുകളെ ആര് ഏകോപിപ്പിക്കുന്നു എന്ന് ആർക്കിടെക്ചർ നിർണ്ണയിക്കുന്നു. അവയുടെ ടാസ്ക്കുകൾ എങ്ങനെ മുന്നോട്ട് പോകുന്നു എന്ന് എക്സിക്യൂഷൻ പാറ്റേൺ നിർണ്ണയിക്കുന്നു.

മൂന്ന് എക്സിക്യൂഷൻ പാറ്റേണുകൾ ഇവയാണ്:

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

ഈ പാറ്റേണുകൾ പരസ്പരം ഒഴിവാക്കുന്നവയല്ല, ഓർക്കസ്ട്രേഷൻ ആർക്കിടെക്ചറുകളുമായി അവ ഒന്നിനൊന്ന് പൊരുത്തപ്പെടുന്നുമില്ല. നിങ്ങളുടെ വർക്ക്ഫ്ലോയുടെ ഡിപൻഡൻസികൾ, ഏകോപന ആവശ്യകതകൾ, സ്വീകാര്യമായ പ്രവർത്തന ഓവർഹെഡ് എന്നിവയെ പിന്തുണയ്ക്കുന്ന ഏറ്റവും ലളിതമായ ഘടന തിരഞ്ഞെടുക്കുക എന്നതാണ് ലക്ഷ്യം.

ലളിതമായ ശ്രദ്ധക്കുറവുകൾ മുതൽ സങ്കീർണ്ണമായ തടസ്സങ്ങൾ വരെ, ഓർക്കസ്ട്രേഷനിൽ എന്തും തെറ്റാം. ചിലപ്പോൾ, മൊത്തത്തിലുള്ള വർക്ക്ഫ്ലോ പരാജയപ്പെടുമ്പോഴും ഒരു ഏജന്റ് അതിന്റെ ജോലി ശരിയായി ചെയ്യുന്നതായി തോന്നിയേക്കാം. പ്രാക്ടീഷണർമാരുടെ അനുഭവങ്ങളെ അടിസ്ഥാനമാക്കി, വിശ്വസനീയമല്ലാത്ത ഓർക്കസ്ട്രേറ്റഡ് വർക്ക്ഫ്ലോകൾക്ക് പിന്നിലെ ചില സാധാരണ തെറ്റുകൾ ഞങ്ങൾ സമാഹരിച്ചിട്ടുണ്ട് — അവ ശ്രദ്ധിക്കുക:

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

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

അവ്യക്തമായ ലക്ഷ്യങ്ങളും വ്യക്തതയില്ലാത്ത പൂർത്തീകരണ നിർവചനവും പലപ്പോഴും നിരാശാജനകമായ ഏജന്റ്-ജനറേറ്റഡ് ഫലങ്ങളിലേക്ക് നയിക്കുന്നു. ഇതിനുള്ള പരിഹാരം ഒരു പ്രോംപ്റ്റ് കരാർ (ഒരു ഏജന്റിനുള്ള ജോലിയുടെ വ്യാപ്തി) ആണ്: എക്സിക്യൂഷൻ ആരംഭിക്കുന്നതിന് മുമ്പ് ലക്ഷ്യം, പരിമിതികൾ, ഔട്ട്പുട്ട് ഫോർമാറ്റ്, പരാജയ വ്യവസ്ഥകൾ എന്നിവയിൽ ധാരണയിലെത്തുക.

ഉദാഹരണത്തിന്, ഇടയ്ക്കിടെ പരാജയപ്പെടുന്ന ഒരു ഇന്റഗ്രേഷൻ ടെസ്റ്റ് പരിഹരിക്കാൻ ചുമതലയുള്ള ഒരു ഏജന്റിനായി ഒരു കരാർ എങ്ങനെ നിർവചിക്കാമെന്ന് നോക്കാം:

ലക്ഷ്യം: ഫ്ലേക്കി ആയ ഒരു ചെക്ക്ഔട്ട് API ഇന്റഗ്രേഷൻ ടെസ്റ്റിന്റെ കാരണം കണ്ടെത്തി പരിഹരിക്കുക.
ഇൻപുട്ടുകൾ: ടെസ്റ്റ് സോഴ്സ് കോഡ്, CI പരാജയ ലോഗുകൾ, സമീപകാല കമ്മിറ്റുകൾ, ബന്ധപ്പെട്ട ആപ്ലിക്കേഷൻ കോഡ്.
പരിമിതികൾ: ടെസ്റ്റുകൾ പ്രവർത്തനരഹിതമാക്കുകയോ അസേർഷനുകൾ അയവുവരുത്തുകയോ ബന്ധമില്ലാത്ത ആപ്ലിക്കേഷൻ പെരുമാറ്റം മാറ്റുകയോ ചെയ്യരുത്.
പ്രതീക്ഷിക്കുന്ന ഔട്ട്പുട്ട്: ഒരു കോഡ് പാച്ച്, മൂലകാരണത്തിന്റെ വിശദീകരണം, ടെസ്റ്റ് എക്സിക്യൂഷൻ ഫലങ്ങൾ.
സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ: മുമ്പ് പരാജയപ്പെട്ടിരുന്ന ടെസ്റ്റ് തുടർച്ചയായ 10 റണ്ണുകളിൽ വിജയിക്കുകയും ബന്ധപ്പെട്ട റിഗ്രഷൻ സ്യൂട്ട് വിജയിക്കുകയും ചെയ്യുന്നു.
പരാജയ വ്യവസ്ഥകൾ: മൂലകാരണം കണ്ടെത്താനാകുന്നില്ല, പരിഹാരം റിഗ്രഷനുകൾക്ക് കാരണമാകുന്നു, അല്ലെങ്കിൽ ആവശ്യമായ ടെസ്റ്റ് എൻവയോൺമെന്റ് ലഭ്യമല്ല.

എന്നാൽ മറ്റൊരു പ്രധാന ഭാഗം കൂടിയുണ്ട്: ഏജന്റ് എപ്പോഴാണ് നിർത്തേണ്ടത്?

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

നമ്മുടെ CI ഉദാഹരണത്തിലേക്ക് മടങ്ങാം. നിങ്ങൾക്ക് ഇനിപ്പറയുന്ന നിർത്തൽ വ്യവസ്ഥകൾ നിർവചിക്കാം:

വിജയം: പരിഹാരം തുടർച്ചയായ 10 ടെസ്റ്റ് റണ്ണുകളിലും ബന്ധപ്പെട്ട റിഗ്രഷൻ സ്യൂട്ടിലും വിജയിക്കുന്നു.
ഇറ്ററേഷൻ പരിധി: ഏജന്റിന് പരമാവധി രണ്ട് സാധ്യതാ പരിഹാരങ്ങൾ മാത്രമേ ശ്രമിക്കാനാകൂ.
എക്സിക്യൂഷൻ ബജറ്റ്: പ്രശ്നം പരിഹരിക്കപ്പെടാതെ തുടർന്നാലും 60 മിനിറ്റിന് ശേഷം ഏജന്റ് നിർത്തണം.
ഡെലിഗേഷൻ പരിധി: ഏജന്റിന് ഒരു സ്പെഷ്യലിസ്റ്റ് ഏജന്റിന് ജോലി ഏൽപ്പിക്കാം, അതിനപ്പുറം സബ്ഏജന്റ് ഡെലിഗേഷൻ അനുവദനീയമല്ല.
ഭാഗിക പൂർത്തീകരണം: രണ്ട് ശ്രമങ്ങളും പരാജയപ്പെടുകയോ സമയപരിധി കഴിയുകയോ ചെയ്താൽ, ഏജന്റ് അതിന്റെ കണ്ടെത്തലുകൾ, ശ്രമിച്ച മാറ്റങ്ങൾ, ടെസ്റ്റ് ഫലങ്ങൾ എന്നിവ തിരികെ നൽകുന്നു.
തടസ്സപ്പെട്ട എക്സിക്യൂഷൻ: ടെസ്റ്റ് എൻവയോൺമെന്റ് ലഭ്യമല്ലെങ്കിൽ, വിജയം അവകാശപ്പെടുന്നതിന് പകരം ഏജന്റ് നിർത്തുകയും തടസ്സം റിപ്പോർട്ട് ചെയ്യുകയും ചെയ്യുന്നു.

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

അതിനാൽ ഓർക്കസ്ട്രേറ്ററുകളെ അവയുടെ ജോലി ചെയ്യാൻ അനുവദിക്കുക, ഒപ്പം മൂർത്തമായ ആർട്ടിഫാക്ടുകളെ പരാമർശിച്ചുകൊണ്ട് ഹാൻഡ്ഓഫുകൾ നടപ്പാക്കുക: യഥാർത്ഥ ടാസ്ക്, ബന്ധപ്പെട്ട ഇൻപുട്ടുകൾ, ഔട്ട്പുട്ട് ആർട്ടിഫാക്ടുകൾ, എക്സിക്യൂഷൻ സ്റ്റാറ്റസ്, പരിഹരിക്കപ്പെടാത്ത ഏതെങ്കിലും പ്രശ്നങ്ങൾ.

ഈ ഉദാഹരണം പരിഗണിക്കുക: status: completed എന്നത് ഏജന്റിന് ഏൽപ്പിച്ച ജോലിയെയാണ് സൂചിപ്പിക്കുന്നത്, മുഴുവൻ വർക്ക്ഫ്ലോയെയുമല്ല. ടെസ്റ്റുകൾ ഇപ്പോഴും pending ആയതിനാൽ, ഓർക്കസ്ട്രേറ്റർ അന്തിമ ഫലം അംഗീകരിക്കരുത്.

json

{
  "task_id": "fix-42",
  "status": "completed",
  "artifact_ref": "patch-17",
  "test_status": "pending",
  "blockers": []
}

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

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

അതിനാൽ എക്സിക്യൂഷൻ സ്റ്റേറ്റ് ഏജന്റിന്റെ വർക്കിംഗ് കോൺടെക്സ്റ്റിൽ നിന്ന് വേറിട്ട് സൂക്ഷിക്കുക. ടാസ്ക് സ്റ്റാറ്റസുകൾ, എക്സിക്യൂഷൻ ശ്രമങ്ങൾ, പൂർത്തിയായ ഘട്ടങ്ങൾ, ആർട്ടിഫാക്ട് റഫറൻസുകൾ എന്നിവ ഡ്യൂറബിൾ സ്റ്റോറേജിൽ സേവ് ചെയ്യുക. അതേസമയം, മുഴുവൻ എക്സിക്യൂഷൻ ചരിത്രവും ഏജന്റിന്റെ കോൺടെക്സ്റ്റ് വിൻഡോയിൽ കുത്തിനിറയ്ക്കുന്നതിന് പകരം, അതിന്റെ നിലവിലെ ടാസ്ക്കിന് പ്രസക്തമായ നിർദ്ദേശങ്ങളും ഇൻപുട്ടുകളും ഫലങ്ങളും മാത്രം ലോഡ് ചെയ്യുക.

നിങ്ങളുടെ CI ഏജന്റ് ഒരു ടെസ്റ്റ് റൺ ട്രിഗർ ചെയ്യുന്നു, എന്നാൽ API അഭ്യർത്ഥന ടൈം ഔട്ട് ആകുന്നു എന്ന് കരുതുക. ടെസ്റ്റ് റൺ ആരംഭിക്കുന്നതിൽ പരാജയപ്പെട്ടോ, അതോ CI സേവനം അത് ക്യൂവിൽ ചേർത്ത ശേഷം പ്രതികരണം നഷ്ടപ്പെട്ടോ?

ഒരു ടൈംഔട്ട് എന്നതിനർത്ഥം ഒരു പ്രവർത്തനം പരാജയപ്പെട്ടു എന്ന് നിർബന്ധമില്ല. അതുകൊണ്ടാണ് അടുത്തതായി എന്ത് സംഭവിക്കണമെന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് പിശകുകൾ തമ്മിൽ വേർതിരിച്ചറിയേണ്ടത്:

താൽക്കാലിക പിശകുകൾ (429, 503): പരിധിയുള്ള എക്സ്പോണൻഷ്യൽ ബാക്ക്ഓഫും ജിറ്ററും ഉപയോഗിച്ച് വീണ്ടും ശ്രമിക്കുക, Retry-After നൽകിയിട്ടുണ്ടെങ്കിൽ അത് മാനിക്കുക.
വാലിഡേഷൻ അല്ലെങ്കിൽ പെർമിഷൻ പിശകുകൾ (400, 403): ഒരേ അഭ്യർത്ഥന ആവർത്തിക്കുന്നതിന് പകരം നിർത്തുകയോ അടിസ്ഥാന പ്രശ്നം പരിഹരിക്കുകയോ ചെയ്യുക.
അവ്യക്തമായ ഫലങ്ങൾ (സാധ്യമായ ഒരു റൈറ്റിന് ശേഷമുള്ള ടൈംഔട്ട്): വീണ്ടും ശ്രമിക്കുന്നതിന് മുമ്പ് പ്രവർത്തനം വിജയിച്ചോ എന്ന് പരിശോധിക്കുക.

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

ബാഹ്യ സൈഡ് ഇഫക്റ്റുകളുള്ള പ്രവർത്തനങ്ങൾക്ക്, ഓരോ ലോജിക്കൽ പ്രവർത്തനത്തിനും ഒരു സ്ഥിരമായ ഐഡംപൊട്ടൻസി കീ നൽകുകയും റീട്രൈകളിലുടനീളം അത് വീണ്ടും ഉപയോഗിക്കുകയും ചെയ്യുക. API സെർവർ-സൈഡ് ഡീഡ്യൂപ്ലിക്കേഷൻ പിന്തുണയ്ക്കുന്നുവെങ്കിൽ, പ്രവർത്തനം രണ്ടുതവണ നടത്താതെ തന്നെ ആവർത്തിച്ചുള്ള അഭ്യർത്ഥനകൾ തിരിച്ചറിയാൻ അതിന് കഴിയും. ഇല്ലെങ്കിൽ, ഒരു കോറിലേഷൻ ID അല്ലെങ്കിൽ മറ്റ് ആധികാരിക റഫറൻസ് ഉപയോഗിച്ച് ബാഹ്യ സിസ്റ്റത്തിൽ ക്വറി ചെയ്യുക.

എന്താണ് സംഭവിച്ചതെന്ന് സ്ഥിരീകരിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, നിർത്തി എസ്കലേറ്റ് ചെയ്യുക.

നമ്മുടെ CI ഏജന്റിനായുള്ള റീട്രൈ ലോജിക്കിന്റെ ഒരു ഉദാഹരണം, സ്യൂഡോകോഡായി:

python

op_id = get_or_create_operation_id(
    task_id=task_id,
    patch_id=patch_id,
    action="start_ci_run"
)

try:
    return ci.start_run(commit, request_id=op_id)
except TimeoutError:
    run = ci.find_by_request_id(op_id)
    if run:
        return run

    if ci.supports_idempotency:
        return bounded_retry(
            lambda: ci.start_run(commit, request_id=op_id)
        )

    raise NeedsReconciliation(op_id)

കോഡ് കുറിപ്പ്: അഭ്യർത്ഥന ID ഉപയോഗിച്ച് റണ്ണുകൾ കണ്ടെത്തുന്നത് CI API പിന്തുണയ്ക്കുന്നുവെന്ന് ഈ ഉദാഹരണം അനുമാനിക്കുന്നു. request_id പ്രൊവൈഡർ ഐഡംപൊട്ടൻസി വ്യക്തമായി ഉറപ്പുനൽകുന്നുണ്ടെങ്കിൽ മാത്രമേ ഡ്യൂപ്ലിക്കേറ്റുകൾ തടയുകയുള്ളൂ. bounded_retry() ഉദാഹരണത്തിനുള്ള സ്യൂഡോകോഡ് മാത്രമാണ്. പ്രൊഡക്ഷനിൽ, ഓരോ പ്രവർത്തനത്തിനുമുള്ള റീട്രൈ ബജറ്റും (പരമാവധി ശ്രമങ്ങൾ അല്ലെങ്കിൽ ചെലവഴിച്ച സമയം) മൊത്തത്തിലുള്ള വർക്ക്ഫ്ലോ ഡെഡ്‌ലൈനും ഉപയോഗിച്ച് റീട്രൈകൾ പരിമിതപ്പെടുത്തണം.

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

ഇവിടെ സന്തുലിതമാക്കേണ്ട രണ്ട് കാര്യങ്ങളുണ്ട്: ഓരോ ടാസ്ക്കിനും എത്രമാത്രം മോഡൽ ശേഷി ആവശ്യമാണ്, ഒരേസമയം എത്ര ടാസ്ക്കുകൾ പ്രവർത്തിപ്പിക്കാം. ഇവയിലേതെങ്കിലും തെറ്റിയാൽ, ഏജന്റുകൾ പങ്കിട്ട API ക്വോട്ടകൾക്കായി മത്സരിക്കുകയോ ചെലവേറിയ റീസണിംഗ് മോഡലുകളെ മാത്രം ആശ്രയിക്കുകയോ ചെയ്യുന്ന അപകടസാധ്യതയുണ്ട്.

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

ഉദാഹരണത്തിന്, Perplexity Computer-ന്റെ Effort Mode ഉപയോഗിച്ച്, ഒരു മോഡൽ സ്വമേധയാ തിരഞ്ഞെടുക്കാതെ തന്നെ ഒരു ടാസ്ക്കിന് എത്രമാത്രം എഫർട്ട് നൽകണമെന്ന് നിങ്ങൾക്ക് തിരഞ്ഞെടുക്കാം. Light, Standard, High, അല്ലെങ്കിൽ Ultra തിരഞ്ഞെടുക്കുക, Perplexity ഓർക്കസ്ട്രേറ്റിംഗ് മോഡലും അതിന്റെ റീസണിംഗ് ലെവലും സ്വയമേവ തിരഞ്ഞെടുക്കും. തുടർന്ന് ആ ഓർക്കസ്ട്രേറ്റർ സബ്‌ടാസ്ക്കുകൾ സപ്പോർട്ടിംഗ് ഏജന്റുകൾക്ക് ഏൽപ്പിക്കുന്നു, അവയ്ക്ക് വ്യത്യസ്ത പ്രൊവൈഡർമാരിൽ നിന്നുള്ള മോഡലുകൾ ഉപയോഗിക്കാനാകും.

Perplexity ഗുണനിലവാരത്തിനും ചെലവിനുമായി മോഡൽ കോൺഫിഗറേഷനുകൾ വിലയിരുത്തുന്നു, താരതമ്യപ്പെടുത്താവുന്ന ഫലങ്ങൾ നൽകുന്ന ചെലവ് കുറഞ്ഞ ഓപ്ഷനുകൾക്ക് മുൻഗണന നൽകുന്നു. മോഡലും റീസണിംഗ് ലെവലും സ്വയം തിരഞ്ഞെടുക്കാൻ താൽപ്പര്യമുണ്ടെങ്കിൽ നിങ്ങൾക്ക് Custom നിയന്ത്രണങ്ങളും ഉപയോഗിക്കാം.

പാരലലിസത്തിന്റെ കാര്യത്തിൽ, പരിധി നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിൽ നിന്നും ബാഹ്യ ഡിപൻഡൻസികളിൽ നിന്നുമാണ് വരേണ്ടത്. പങ്കിട്ട API-കളുടെ അഭ്യർത്ഥന, ടോക്കൺ റേറ്റ് പരിധികൾ പരിശോധിക്കുക, തുടർന്ന് വർദ്ധിച്ചുവരുന്ന കൺകറൻസിയോടെ നിങ്ങളുടെ വർക്ക്ഫ്ലോ ലോഡ്-ടെസ്റ്റ് ചെയ്യുക. ത്രൂപുട്ട് മെച്ചപ്പെടുന്നുണ്ടോ, അതോ അഭ്യർത്ഥനകൾ ക്യൂവിൽ കുടുങ്ങുകയോ മന്ദഗതിയിലാകുകയോ 429 പിശകുകൾ നൽകുകയോ ചെയ്യാൻ തുടങ്ങുന്നുണ്ടോ എന്ന് നിരീക്ഷിക്കുക.

റിസോഴ്‌സ് ഉപഭോഗം പ്രവചിക്കാവുന്നതായി നിലനിർത്താൻ, റിസോഴ്‌സ് പരിധികളും ഷെഡ്യൂളിംഗ് നിയന്ത്രണങ്ങളും നടപ്പാക്കുക:

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

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

“അമിതമായി സങ്കീർണ്ണമായ മൾട്ടി-ഏജന്റ് സിസ്റ്റങ്ങളെക്കുറിച്ച് എനിക്ക് സംശയമുണ്ട്, പ്രത്യേകിച്ച് ഏജന്റുകൾ പരസ്പരം ജോലി റിവ്യൂ ചെയ്യുകയും അംഗീകരിക്കുകയും ചെയ്യുമ്പോൾ. ആരും യഥാർത്ഥത്തിൽ കണ്ടെത്താതെ, നിരവധി ഏജന്റുകൾ ഒരേ തെറ്റ് ആത്മവിശ്വാസത്തോടെ കൈമാറുന്ന അവസ്ഥയിൽ നിങ്ങൾ എത്തിയേക്കാം,” Spilker മുന്നറിയിപ്പ് നൽകുന്നു.

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

മനുഷ്യ അംഗീകാരം ആവശ്യമുള്ള പ്രവർത്തനങ്ങൾക്ക്, എക്സിക്യൂഷൻ താൽക്കാലികമായി നിർത്തി നിർദ്ദേശിക്കപ്പെട്ട പ്രവർത്തനം അതേപടി സേവ് ചെയ്യുക:

അതിന്റെ പാരാമീറ്ററുകൾ
അതിന്റെ ടാർഗെറ്റ് റിസോഴ്‌സ്
അതിന്റെ കമ്മിറ്റ് അല്ലെങ്കിൽ സ്റ്റേറ്റ് പതിപ്പ്
റിവ്യൂവറുടെ തീരുമാനം

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

അതിനാൽ അംഗീകാരം നിരസിക്കപ്പെടുകയോ കാലഹരണപ്പെടുകയോ ചെയ്താൽ, അഭ്യർത്ഥന അടയ്ക്കപ്പെടും. എക്സിക്യൂഷന് മുമ്പ് ടാർഗെറ്റ് കമ്മിറ്റോ പാരാമീറ്ററുകളോ പെർമിഷനുകളോ മാറുകയാണെങ്കിൽ, അംഗീകാരം അസാധുവാക്കി പുതിയൊരെണ്ണം അഭ്യർത്ഥിക്കുക.

ലക്ഷ്യമായി കണക്കാക്കപ്പെടുന്ന, പൂർണ്ണമായും സ്വയംഭരണാധികാരമുള്ള എൻഡ്-ടു-എൻഡ് ഏജന്റുകൾ എന്ന ആശയത്തെയും Spilker പിന്തുണയ്ക്കുന്നില്ല. “എന്നെ സംബന്ധിച്ചിടത്തോളം, വ്യക്തമായ ഉത്തരവാദിത്തങ്ങളും നിർവചിക്കപ്പെട്ട പെർമിഷനുകളും ശരിയായ ഘട്ടങ്ങളിൽ മനുഷ്യ റിവ്യൂവുമുള്ള, ശ്രദ്ധ കേന്ദ്രീകരിച്ച ഏതാനും ഏജന്റുകളെ നിർമ്മിക്കുന്നതാണ് മികച്ച സമീപനം. പൂർണ്ണ നിയന്ത്രണം കൈവിടാതെ തന്നെ നിങ്ങൾക്ക് കാര്യക്ഷമത ലഭിക്കും,” അദ്ദേഹം ഉപസംഹരിക്കുന്നു.

യഥാർത്ഥത്തിൽ പരാജയപ്പെട്ടിട്ടും ഒരു ഏജന്റ് Success എന്ന് റിപ്പോർട്ട് ചെയ്തിട്ടുണ്ടോ? ദേഷ്യം പിടിപ്പിക്കുന്നില്ലെങ്കിൽ പോലും അലോസരപ്പെടുത്തുന്ന കാര്യമാണിത്, ഏജന്റിന്റെ അന്തിമ സന്ദേശം എവിടെയാണ് കാര്യങ്ങൾ തെറ്റിയതെന്ന് നിർബന്ധമായും പറയണമെന്നില്ലാത്തതിനാൽ പരിഹാരം എളുപ്പമല്ല.

അന്വേഷിക്കാൻ, എക്സിക്യൂഷൻ സമയത്ത് എന്താണ് സംഭവിച്ചതെന്ന് ട്രേസ് ചെയ്യുകയും ഫലങ്ങൾ സ്വതന്ത്രമായി പരിശോധിക്കുകയും ചെയ്യുക. അതിനാൽ പ്രശ്നം വേർതിരിച്ച് കണ്ടെത്താനും പരിഹരിക്കാനും കുറച്ച് സമയം ചെലവഴിക്കാം.

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

OpenTelemetry-യുടെ GenAI സെമാന്റിക് കൺവെൻഷനുകൾ ഈ പ്രവർത്തനങ്ങളെ വിവരിക്കാൻ ഒരു സ്റ്റാൻഡേർഡ് മാർഗം നൽകുന്നു. ഉദാഹരണത്തിന്, invoke_workflow വർക്ക്ഫ്ലോ എക്സിക്യൂഷനെയും invoke_agent ഒരു ഏജന്റ് ഇൻവൊക്കേഷനെയും execute_tool ഒരു ടൂൾ കോളിനെയും തിരിച്ചറിയുന്നു. ഓരോ പ്രവർത്തനവും അതിന്റെ സമയം, സ്റ്റാറ്റസ്, ബന്ധപ്പെട്ട മെറ്റാഡാറ്റ എന്നിവയോടൊപ്പം ഒരു span ആയി രേഖപ്പെടുത്താം.

ഈ ഘട്ടം എക്സിക്യൂഷൻ പാതയുടെ ഒരു ട്രേസ് നൽകുന്നു, അതിനാൽ ഒരു ഏജന്റിന് എവിടെയാണ് പിഴവ് സംഭവിച്ചതെന്ന് നിങ്ങൾക്ക് തിരിച്ചറിയാം.

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

ഒരു ഉദാഹരണ എക്സിക്യൂഷൻ ട്രേസ്.

സാധ്യമായിടത്തെല്ലാം പ്രോഗ്രാമാറ്റിക് പരിശോധനകൾ ഉപയോഗിക്കുക. JSON സ്കീമകൾക്കെതിരെ ഔട്ട്പുട്ടുകൾ സാധൂകരിക്കുക, യൂണിറ്റ്, ഇന്റഗ്രേഷൻ ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുക, ആവശ്യമായ ആർട്ടിഫാക്ടുകൾ നിലവിലുണ്ടോ എന്ന് പരിശോധിക്കുക, പ്രവർത്തനങ്ങൾ യഥാർത്ഥത്തിൽ വിജയിച്ചുവെന്ന് സ്ഥിരീകരിക്കാൻ ബാഹ്യ സിസ്റ്റങ്ങളിൽ ക്വറി ചെയ്യുക.

ആത്മനിഷ്ഠമായ വിലയിരുത്തൽ ആവശ്യമുള്ളതും അതിനാൽ പ്രോഗ്രാമാറ്റിക് പരിശോധനകളിലൂടെ വിലയിരുത്താൻ കഴിയാത്തതുമായ ഔട്ട്പുട്ടുകൾക്ക്, ഒരു സ്വതന്ത്ര റിവ്യൂവർ ഏജന്റിനെ ഉൾപ്പെടുത്തുക. ഒരു സമീപനം ഇംപ്ലിമെന്റർ–റിവ്യൂവർ–റിസോൾവർ ലൂപ്പ് ആണ്: ഇതിൽ ഒരു ഏജന്റ് ഒരു ആർട്ടിഫാക്ട് നിർമ്മിക്കുന്നു, പുതിയ കോൺടെക്സ്റ്റുള്ള ഒരു റിവ്യൂവർ പ്രശ്നങ്ങൾ കണ്ടെത്തുന്നു, വാലിഡേഷൻ വീണ്ടും പ്രവർത്തിക്കുന്നതിന് മുമ്പ് ഒരു റിസോൾവർ അവ പരിഹരിക്കുന്നു.

സാധ്യമാകുന്നിടത്ത് റിവ്യൂവറുടെ കണ്ടെത്തലുകൾ നിങ്ങൾ ഇപ്പോഴും സാധൂകരിക്കേണ്ടതുണ്ട്, ആവർത്തിച്ചുള്ള വിലയിരുത്തലുകൾക്ക് LLM അധിഷ്ഠിത ഗ്രേഡറുകൾ ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ, മനുഷ്യർ റിവ്യൂ ചെയ്ത ഉദാഹരണങ്ങളുമായി താരതമ്യം ചെയ്ത് അവയുടെ വിധിനിർണ്ണയങ്ങൾ കാലിബ്രേറ്റ് ചെയ്യുക.

ഇതുവരെ, ഏജന്റുകൾ എന്താണ് നിർവ്വഹിച്ചതെന്ന് നിങ്ങൾ ട്രേസ് ചെയ്യുകയും അവയുടെ ഔട്ട്‌പുട്ടുകൾ ശരിയാണോ എന്ന് പരിശോധിക്കുകയും ചെയ്തു. എന്നാൽ ഒരു ടാസ്‌ക്കിന്റെ പാതിവഴിയിൽ ഒരു വർക്കർ ക്രാഷ് ആകുകയോ ഒരു അഭ്യർത്ഥന സ്വീകരിച്ചതിന് ശേഷം ഒരു API ടൈംഔട്ട് ആകുകയോ ചെയ്താൽ എന്ത് സംഭവിക്കും? അതിശയകരമെന്നു പറയട്ടെ, നിങ്ങളുടെ വർക്ക്ഫ്ലോ സാധാരണ സാഹചര്യങ്ങളിൽ നന്നായി പ്രവർത്തിച്ചേക്കാം, പക്ഷേ റിക്കവറി സമയത്ത് പരാജയപ്പെട്ടേക്കാം.

ഇത് പരിശോധിക്കാൻ, ഒരു ടെസ്റ്റ് എൻവയോൺമെന്റിൽ മനഃപൂർവ്വം തകരാറുകൾ ഇൻജെക്റ്റ് ചെയ്യുക:

API ടൈംഔട്ടുകൾ സിമുലേറ്റ് ചെയ്യുക
എക്സ്റ്റേണൽ റൈറ്റുകൾക്കും ചെക്ക്‌പോയിന്റുകൾക്കും ഇടയിൽ വർക്കറുകളെ ക്രാഷ് ചെയ്യിക്കുക
തെറ്റായ ഫോർമാറ്റിലുള്ള ടൂൾ ഔട്ട്‌പുട്ടുകൾ തിരികെ നൽകുക
അംഗീകാരങ്ങൾ കാലഹരണപ്പെടുത്തുക

ഓരോ ടെസ്റ്റിനും ശേഷം, ഏതൊക്കെ ഘട്ടങ്ങൾ പ്രവർത്തിച്ചു, വർക്ക്ഫ്ലോ എവിടെ നിന്ന് പുനരാരംഭിച്ചു, ഏതെങ്കിലും പ്രവർത്തനങ്ങൾ ആവർത്തിക്കുകയോ ഒഴിവാക്കപ്പെടുകയോ ചെയ്തോ എന്നിവ കാണാൻ എക്സിക്യൂഷൻ ട്രേസ് പരിശോധിക്കുക. തുടർന്ന് യഥാർത്ഥ ഫലങ്ങൾ അവലോകനം ചെയ്യുക.

നിങ്ങളുടെ CI ഏജന്റ് ഒരു ടെസ്റ്റ് റൺ ആരംഭിക്കാൻ ഒരു അഭ്യർത്ഥന അയയ്ക്കുന്നു എന്ന് കരുതുക, പക്ഷേ API പ്രതികരണം ടൈംഔട്ട് ആകുന്നു. ഏജന്റ് വീണ്ടും ശ്രമിക്കുന്നു, വിജയകരമായ ഒരു പ്രതികരണം ലഭിക്കുന്നു, തുടർന്ന് Success എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. CI സേവനം പരിശോധിച്ച് ഒന്നിന് പകരം രണ്ട് ടെസ്റ്റ് റണ്ണുകൾ സൃഷ്ടിക്കപ്പെട്ടതായി കണ്ടെത്തുന്നതുവരെ എല്ലാം ശരിയാണെന്ന് തോന്നും.

അതുകൊണ്ടാണ് വർക്ക്ഫ്ലോയുടെ രേഖപ്പെടുത്തിയ സ്റ്റേറ്റും എക്സ്റ്റേണൽ സിസ്റ്റങ്ങളിലെ യഥാർത്ഥ മാറ്റങ്ങളും നിങ്ങൾ പരിശോധിക്കേണ്ടത്. ഉദ്ദേശിക്കാത്ത പാർശ്വഫലങ്ങളില്ലാതെ വർക്ക്ഫ്ലോ പ്രതീക്ഷിച്ച സ്റ്റേറ്റിൽ എത്തുമ്പോൾ മാത്രമേ ഒരു റിക്കവറി ടെസ്റ്റ് പാസാകാവൂ.

ഭാവിയിലെ മാറ്റങ്ങൾ അവ വീണ്ടും കൊണ്ടുവരാതിരിക്കാൻ, നിങ്ങൾ കണ്ടെത്തുന്ന പരാജയങ്ങൾ നിങ്ങളുടെ റിഗ്രഷൻ ടെസ്റ്റുകളിൽ ചേർക്കുക.

ആത്യന്തികമായി, വിജയം എന്നതിനർത്ഥം വർക്ക്ഫ്ലോ അതിന് ആവശ്യമായ പരിശോധനകൾ പാസായി, അതിന്റെ എക്സ്റ്റേണൽ ഫലങ്ങൾ സ്ഥിരീകരിക്കപ്പെട്ടു എന്നാണ്.

ഒറ്റപ്പെട്ട ഏജന്റുകൾക്ക് അവയുടെ വ്യക്തിഗത ടാസ്‌ക്കുകൾ ശരിയായി പൂർത്തിയാക്കാൻ കഴിയുമെങ്കിലും, ഒരുമിച്ച് അവ പൊരുത്തമില്ലാത്ത ഫലങ്ങൾ നൽകിയേക്കാം. 10:00-ന് ഒരു സെയിൽസ് ഏജന്റ് ഉപഭോക്തൃ നിബന്ധനകൾ വീണ്ടെടുക്കുന്നു, 10:05-ന് ഒരു പ്രൈസിംഗ് ഏജന്റ് പുതുക്കിയ വിലകൾ ഉപയോഗിച്ച് ഒരു ക്വോട്ട് കണക്കാക്കുന്നു, 10:07-ന് മാറിയ ഒരു കരാർ ഒരു ലീഗൽ ഏജന്റ് പരിശോധിക്കുന്നു എന്ന് സങ്കൽപ്പിക്കുക. ഓരോ ഏജന്റും ബിസിനസ്സിന്റെ വ്യത്യസ്തമായ ഒരു സ്നാപ്പ്ഷോട്ട് ഉപയോഗിച്ചാണ് പ്രവർത്തിക്കുന്നത്, അതിനാൽ അവയുടെ ഔട്ട്‌പുട്ടുകൾ പരസ്പരം വിരുദ്ധമായേക്കാം.

എന്റർപ്രൈസ് തലത്തിൽ ഈ പ്രശ്നം കൂടുതൽ രൂക്ഷമാകുന്നു, കാരണം ഏജന്റുകൾ ഇടപഴകുന്നത് ഒന്നിലധികം സിസ്റ്റങ്ങളുമായാണ്; അവ സ്വതന്ത്രമായി അപ്ഡേറ്റ് ചെയ്യപ്പെടുന്നു, വ്യത്യസ്ത അനുമതികളോടെ പ്രവർത്തിക്കുന്നു, കോൺടെക്സ്റ്റോ എക്സിക്യൂഷൻ സ്റ്റേറ്റോ പങ്കിടണമെന്നുമില്ല.

ഒന്നിലധികം തലങ്ങളിൽ പരിധികൾ നിശ്ചയിക്കുക: പരമാവധി ടൂൾ-കോൾ റീട്രൈകൾ, പരമാവധി ഏജന്റ് ഇറ്ററേഷനുകൾ, ഡെലിഗേഷൻ ഡെപ്ത്, മൊത്തത്തിലുള്ള ഒരു വർക്ക്ഫ്ലോ ഡെഡ്‌ലൈൻ. വീണ്ടും ശ്രമിക്കുന്നതിന് മുമ്പ് പരാജയങ്ങളെ തരംതിരിക്കുക. താൽക്കാലിക 429 പ്രതികരണങ്ങൾക്ക്, Retry-After നൽകിയിട്ടുണ്ടെങ്കിൽ അത് പാലിക്കുക. അല്ലാത്തപക്ഷം, ജിറ്റർ സഹിതമുള്ള പരിമിതമായ എക്സ്പോണൻഷ്യൽ ബാക്ക്ഓഫ് ഉപയോഗിക്കുക.

വാലിഡേഷൻ അല്ലെങ്കിൽ അനുമതി പിശകുകൾക്ക് ശേഷം മാറ്റമില്ലാത്ത അഭ്യർത്ഥനകൾ വീണ്ടും ശ്രമിക്കുന്നത് നിർത്തുക. ഒരു ഡൗൺസ്ട്രീം സേവനം ആവർത്തിച്ച് പരാജയപ്പെടുകയാണെങ്കിൽ, ഏജന്റുകൾ അധിക ലോഡ് സൃഷ്ടിക്കുന്നത് തടയാൻ ഒരു സർക്യൂട്ട് ബ്രേക്കറിന് കഴിയും.

റിക്കവറി സംവിധാനം നിങ്ങളുടെ റൺടൈമിനെ ആശ്രയിച്ചിരിക്കുന്നു. LangGraph-ൽ, PostgresSaver പോലുള്ള ഒരു പെർസിസ്റ്റന്റ് ചെക്ക്‌പോയിന്റർ ഗ്രാഫ് സ്റ്റേറ്റ് ഒരു thread_id-ന് കീഴിൽ സംഭരിക്കുന്നു, ഇത് സംഭരിച്ച സ്റ്റേറ്റിൽ നിന്ന് എക്സിക്യൂഷൻ തുടരാൻ അനുവദിക്കുന്നു. Temporal-ൽ, മറ്റൊരു വർക്കറിന് ഒരു വർക്ക്ഫ്ലോയുടെ ഇവന്റ് ഹിസ്റ്ററി റീപ്ലേ ചെയ്തുകൊണ്ട് അതിനെ പുനർനിർമ്മിക്കാൻ കഴിയും. റീപ്ലേ സമയത്ത്, മുമ്പ് രേഖപ്പെടുത്തിയ ആക്റ്റിവിറ്റി ഫലങ്ങൾ അത് വീണ്ടും ഉപയോഗിക്കുന്നു.

വർക്ക്ഫ്ലോകൾ പ്രവർത്തിച്ചുകൊണ്ടിരിക്കുമ്പോൾ ആപ്ലിക്കേഷൻ വീണ്ടും ഡിപ്ലോയ് ചെയ്യുകയാണെങ്കിൽ, സംരക്ഷിച്ച സ്റ്റേറ്റും എക്സിക്യൂഷൻ ഹിസ്റ്ററികളും പിന്നീട് പൊരുത്തപ്പെടണമെന്നില്ല. Worker Versioning, വർക്ക്ഫ്ലോ പാച്ചിംഗ് എന്നിവയിലൂടെ Temporal ഇത് പരിഹരിക്കുന്നു. ചെക്ക്‌പോയിന്റ് അധിഷ്ഠിത സിസ്റ്റങ്ങൾക്കായി, പൊരുത്തപ്പെടാത്ത മാറ്റങ്ങൾ റോൾ ഔട്ട് ചെയ്യുന്നതിന് മുമ്പ് സ്കീമ മൈഗ്രേഷനുകൾ ആസൂത്രണം ചെയ്യുകയും നിലവിലുള്ള സംരക്ഷിച്ച സ്റ്റേറ്റുകൾക്കെതിരെ റിക്കവറി പരീക്ഷിക്കുകയും ചെയ്യുക.

ഒരേ പ്രാതിനിധ്യ ടാസ്‌ക്കുകൾ ഒന്നിലധികം തവണ പ്രവർത്തിപ്പിക്കുകയും pass@k (k ശ്രമങ്ങളിൽ കുറഞ്ഞത് ഒന്നെങ്കിലും വിജയിക്കുന്നുണ്ടോ എന്നത്), pass^k (എല്ലാ k ശ്രമങ്ങളും വിജയിക്കുന്നുണ്ടോ എന്നത്) എന്നിവ തമ്മിൽ വേർതിരിക്കുകയും ചെയ്യുക

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

എന്താണ് AI ഏജന്റ് ഓർക്കസ്ട്രേഷൻ?

AI ഏജന്റ് ഓർക്കസ്ട്രേഷൻ എങ്ങനെ പ്രവർത്തിക്കുന്നു: എക്സിക്യൂഷൻ എഞ്ചിനുള്ളിൽ

എപ്പോഴാണ് AI ഏജന്റ് ഓർക്കസ്ട്രേഷൻ ഉപയോഗിക്കേണ്ടത്?

AI ഏജന്റ് ഓർക്കസ്ട്രേഷൻ ആർക്കിടെക്ചറുകളും അവയുടെ ഗുണദോഷങ്ങളും

കേന്ദ്രീകൃത ഓർക്കസ്ട്രേഷൻ

വികേന്ദ്രീകൃത ഓർക്കസ്ട്രേഷൻ

ശ്രേണീപരമായ ഓർക്കസ്ട്രേഷൻ

ക്രമാനുഗത, സമാന്തര, ഹാൻഡ്ഓഫ് അധിഷ്ഠിത എക്സിക്യൂഷൻ

AI ഏജന്റ് ഓർക്കസ്ട്രേഷനിലെ സാധാരണ പരാജയങ്ങൾ

പ്രൊഡക്ഷൻ വിശ്വാസ്യതയ്ക്കായുള്ള 7 AI ഏജന്റ് ഓർക്കസ്ട്രേഷൻ മികച്ച രീതികൾ

1. വ്യക്തമായ ടാസ്ക് കരാറുകൾ, സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ, നിർത്തൽ വ്യവസ്ഥകൾ എന്നിവ നിർവചിക്കുക

2. ഓർക്കസ്ട്രേറ്ററുകളെ ലളിതമായി നിലനിർത്തുകയും ഘടനാപരമായ ഹാൻഡ്ഓഫുകൾ നടപ്പാക്കുകയും ചെയ്യുക

3. വർക്ക്ഫ്ലോ സ്റ്റേറ്റ് സ്ഥിരമായി സൂക്ഷിക്കുകയും കോൺടെക്സ്റ്റ് വളർച്ച നിയന്ത്രിക്കുകയും ചെയ്യുക

4. പരാജയങ്ങൾ കണക്കിലെടുക്കുന്ന റീട്രൈകളും വീണ്ടെടുക്കാവുന്ന ടൂൾ എക്സിക്യൂഷനും രൂപകൽപ്പന ചെയ്യുക

5. വ്യക്തമായ റിസോഴ്‌സ് ബജറ്റുകളോടെ ജോലി റൂട്ട് ചെയ്യുകയും സമാന്തരമാക്കുകയും ചെയ്യുക

6. അംഗീകാരങ്ങൾ നടപ്പാക്കുകയും ഏജന്റ് എക്സിക്യൂഷൻ ഐസൊലേറ്റ് ചെയ്യുകയും ചെയ്യുക

7. ഔട്ട്പുട്ടുകൾ സ്വതന്ത്രമായി പരിശോധിക്കുകയും റിക്കവറി പെരുമാറ്റം ടെസ്റ്റ് ചെയ്യുകയും ചെയ്യുക

എന്താണ് തെറ്റിയതെന്ന് കണ്ടെത്താൻ വർക്ക്ഫ്ലോ ട്രേസ് ചെയ്യുക

ഔട്ട്പുട്ട് സ്വതന്ത്രമായി റിവ്യൂ ചെയ്യുക

റിക്കവറി ടെസ്റ്റ് ചെയ്യാൻ പരാജയങ്ങൾ ഇൻജക്റ്റ് ചെയ്യുക

AI ഏജന്റ് ഓർക്കസ്ട്രേഷൻ: പതിവുചോദ്യങ്ങൾ

ഒറ്റപ്പെട്ട AI ഏജന്റുകൾ എന്റർപ്രൈസ് തലത്തിൽ പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്?

AI ഏജന്റുകളിലെ അനന്തമായ റീട്രൈ ലൂപ്പുകൾ എങ്ങനെ തടയാം?

ഒരു ക്രാഷിന് ശേഷം AI ഏജന്റ് വർക്ക്ഫ്ലോ എങ്ങനെ പുനരാരംഭിക്കാം?

AI ഏജന്റ് ഓർക്കസ്ട്രേഷന്റെ വിശ്വാസ്യത എങ്ങനെ പരീക്ഷിക്കാം?