AI एजेंट ऑर्केस्ट्रेशन के सर्वोत्तम तरीके: विफलताओं, अनुमोदनों और रीट्राई को संभालना

यह गाइड बताती है कि AI एजेंट ऑर्केस्ट्रेशन कैसे काम करता है, केंद्रीकृत, विकेंद्रीकृत और पदानुक्रमित आर्किटेक्चर की तुलना करती है, और प्रोडक्शन में विफलताओं, अनुमोदनों और रीट्राई को संभालने के सात सर्वोत्तम तरीकों के बारे में बताती है।

Diagram of AI agent orchestration: a user's multi-step goal goes to an orchestrator, which routes work to agents, models, and tools to produce a final output, while breaking down tasks, tracking dependencies, delegating execution, managing shared context, and combining outputs.

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

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

AI एजेंट ऑर्केस्ट्रेशन क्या है?

AI एजेंट ऑर्केस्ट्रेशन किसी बहु-चरणीय कार्य को पूरा करने के लिए कई AI एजेंट, मॉडल और टूल का समन्वय करता है। लेकिन फिर भी किसी व्यक्ति — या किसी चीज़ — को यह तय करना होता है कि कौन-सा एजेंट पहले चलेगा, उसे कौन-सी जानकारी मिलेगी और उसके काम पूरा करने के बाद क्या होगा। यही ऑर्केस्ट्रेटर की भूमिका है — एक AI एजेंट जो मैनेजर की तरह काम करता है, या सॉफ़्टवेयर से नियंत्रित एक्ज़ीक्यूशन लेयर।

आसान शब्दों में, ऑर्केस्ट्रेशन लेयर किसी लक्ष्य को छोटे कार्यों में बाँटती है, निर्भरताओं को ट्रैक करती है, सही एजेंट को एक्ज़ीक्यूशन सौंपती है, साझा संदर्भ को मैनेज करती है और आउटपुट को एक साथ जोड़ती है।

AI एजेंट ऑर्केस्ट्रेशन कैसे काम करता है: एक्ज़ीक्यूशन इंजन के अंदर

आइए देखें कि ऑर्केस्ट्रेटर को कोई कार्य देने के बाद क्या होता है।

Perplexity की Computer वर्कशॉप का एक उदाहरण लें: Salesforce, Snowflake, ईमेल, कैलेंडर और हाल की खबरों से मिली जानकारी का उपयोग करके अकाउंट इंटेलिजेंस डैशबोर्ड बनाना।

  1. लक्ष्य को समझें और काम की योजना बनाएँ। ऑर्केस्ट्रेटर अनुरोध किए गए नतीजे से शुरुआत करता है और उसे स्पष्ट निर्भरताओं वाले कार्यों में बाँटता है। हमारे डैशबोर्ड उदाहरण में, इसमें अलग-अलग स्रोतों से जानकारी इकट्ठा करना और उसे एक तैयार डिलीवरेबल में बदलना शामिल है। प्लानर तय करता है कि कौन-से चरण दूसरों पर निर्भर हैं और कौन-से स्वतंत्र रूप से चल सकते हैं।
  2. कार्यों को उपयुक्त एजेंट तक रूट करें। ऑर्केस्ट्रेटर उन कार्यों की पहचान करता है जिनकी निर्भरताएँ पूरी हो चुकी हैं, और काम को विशेषज्ञ एजेंट या मॉडल को सौंपता है। निर्भर कार्य अपनी पूर्वापेक्षाओं के पूरा होने का इंतज़ार करते हैं। Perplexity Computer कई फ़्रंटियर मॉडल का उपयोग करता है और वर्कफ़्लो के अलग-अलग हिस्सों को उन सिस्टम तक रूट करता है जो उन कार्यों के लिए उपयुक्त हैं। इससे स्वतंत्र काम समानांतर रूप से भी चल पाता है।
  3. नियंत्रित परिवेश में टूल कॉल एक्ज़ीक्यूट करें। एजेंट वेब सर्च, API, कनेक्ट किए गए ऐप्लिकेशन, फ़ाइल ऑपरेशन या कोड एक्ज़ीक्यूशन जैसे टूल के ज़रिए अपने परिवेश से इंटरैक्ट करते हैं। एक्ज़ीक्यूशन लेयर इन कार्रवाइयों को चलाती है और नतीजे एजेंट को लौटाती है।
  4. एजेंट के बीच नतीजे और संदर्भ पास करें। जब कोई एजेंट अपना कार्य पूरा कर लेता है, तो आगे के अगले एजेंट को काम जारी रखने के लिए प्रासंगिक आउटपुट चाहिए होता है। हैंडऑफ़ रिकॉर्ड में टास्क ID, आउटपुट रेफ़रेंस, स्कीमा वर्शन और स्रोत मेटाडेटा हो सकता है। ऑर्केस्ट्रेटर इन हैंडऑफ़ का समन्वय करता है और साथ ही अगले चरणों के लिए ज़रूरी संदर्भ बनाए रखता है। सबसे अहम बात यह है कि एजेंट को अपनी कॉन्टेक्स्ट विंडो में हर दूसरे एजेंट के काम का पूरा इतिहास साथ लेकर नहीं चलना पड़ता।
  5. एक्ज़ीक्यूशन स्टेट को एजेंट संदर्भ से अलग रिकॉर्ड करें। जैसे-जैसे एजेंट कार्य शुरू करते हैं, पूरा करते हैं या उनमें विफल होते हैं, एक्ज़ीक्यूशन इंजन कार्य की स्थितियों, एक्ज़ीक्यूशन के प्रयासों, आउटपुट रेफ़रेंस और बचे हुए काम के साथ एक स्थायी वर्कफ़्लो रिकॉर्ड अपडेट करता है। इस रिकॉर्ड की मदद से ऑर्केस्ट्रेटर प्रगति ट्रैक कर सकता है और रुकावटों के बाद काम फिर से शुरू कर सकता है, वह भी बातचीत के इतिहास से वर्कफ़्लो को दोबारा बनाने के लिए किसी LLM पर निर्भर हुए बिना।
  6. नतीजों का सत्यापन करें और तय करें कि आगे क्या होगा। जब कोई कार्य नतीजा लौटाता है, तो ऑर्केस्ट्रेशन लेयर जाँचती है कि उसका आउटपुट अपेक्षित कॉन्ट्रैक्ट को पूरा करता है या नहीं, और अगले कार्य की निर्भरताएँ पूरी हुई हैं या नहीं। अगर कोई समस्या मिलती है, तो वर्कफ़्लो सुधार के लिए किसी पिछले चरण पर लौट सकता है या रोका जा सकता है। अन्यथा, यह पूरा होने की ओर आगे बढ़ता है।

जो AI एजेंट ऑर्केस्ट्रेशन आसान लगता है, उसके पीछे कई गतिशील हिस्से काम करते हैं। आप एजेंट के समन्वय को कैसे व्यवस्थित करते हैं, इससे तय होता है कि एक्ज़ीक्यूशन पर आपका कितना नियंत्रण है। और बेशक, यह सारा समन्वय अतिरिक्त ओवरहेड जोड़ता है। इसलिए यह हमेशा फ़ायदेमंद नहीं होता।

AI एजेंट ऑर्केस्ट्रेशन का उपयोग कब करना चाहिए?

मल्टी-एजेंट ऑर्केस्ट्रेशन पर तब विचार करें जब कार्य के अलग-अलग हिस्सों के लिए अलग विशेषज्ञता चाहिए, स्वतंत्र काम समानांतर रूप से चल सकता हो, या आप अगला चरण पहले से तय न कर सकें।

इसलिए, ऑर्केस्ट्रेशन तीन स्थितियों में मददगार होता है:

  • कार्यों के लिए अलग-अलग विशेषज्ञता चाहिए। उदाहरण के लिए, किसी कोडिंग प्रोजेक्ट में योजना, डिज़ाइन, डेवलपमेंट और समीक्षा के लिए अलग-अलग एजेंट फ़ायदेमंद हो सकते हैं।
  • स्वतंत्र कार्य समानांतर रूप से चल सकते हैं। एक ही एजेंट से सब कुछ क्रम से पूरा करवाने के बजाय, कई एजेंट एक साथ काम कर सकते हैं और अपने नतीजे ऑर्केस्ट्रेटर को लौटा सकते हैं।
  • समस्या का कोई तय दायरा नहीं है। एजेंट को पहले से तय क्रम का पालन करने के बजाय अलग-अलग तरीके आज़माने, निर्णय लेने और मिलकर काम करने की ज़रूरत पड़ सकती है।

इसके अलावा, ऑर्केस्ट्रेशन बस एक महँगा ट्रेंड है। ज़्यादा एजेंट का मतलब ज़्यादा समन्वय और संभावित रूप से ज़्यादा टोकन लागत भी है।

“मैं आम तौर पर सबसे सरल विकल्प से शुरुआत करता हूँ और वहीं से आगे बढ़ता हूँ। अगर हमें चरण पता हैं और वे दोहराए जा सकते हैं, तो वह शायद एक वर्कफ़्लो है। मुझे कई एजेंट लाने की वजह तभी दिखती है जब उनकी ज़िम्मेदारियाँ, अनुमतियाँ या उपयोगकर्ता अलग-अलग हों,” Josh Spilker कहते हैं, जो AirOps में सर्च मार्केटिंग के प्रमुख हैं।

तब भी, अतिरिक्त मॉडल कॉल, हैंडऑफ़, लेटेंसी और विफलता के बिंदुओं के मुकाबले फ़ायदों का आकलन करें।

AI एजेंट ऑर्केस्ट्रेशन आर्किटेक्चर और उनके ट्रेड-ऑफ़

एजेंट के समन्वय को संरचित करने के तीन आम तरीके हैं — केंद्रीकृत, विकेंद्रीकृत और पदानुक्रमित ऑर्केस्ट्रेशन। सही आर्किटेक्चर चुनना एक ही सवाल पर निर्भर करता है: काम को कौन नियंत्रित करता है, और एजेंट आपस में कैसे समन्वय करते हैं?

केंद्रीकृत ऑर्केस्ट्रेशन

केंद्रीकृत ऑर्केस्ट्रेशन में, एक ऑर्केस्ट्रेटर प्रक्रिया को मैनेज करता है। यह कार्य को हिस्सों में बाँटता है, विशेषज्ञ एजेंट को काम सौंपता है, उनकी प्रगति ट्रैक करता है और उनके नतीजों को एक साथ जोड़ता है।

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

विकेंद्रीकृत ऑर्केस्ट्रेशन

विकेंद्रीकृत ऑर्केस्ट्रेशन में, एजेंट हर निर्णय के लिए किसी एक मैनेजर पर निर्भर रहने के बजाय ज़्यादा सीधे तौर पर समन्वय करते हैं। वे संदेशों का आदान-प्रदान कर सकते हैं, साझा स्टेट पढ़ सकते हैं और स्वतंत्र रूप से अपने अगले चरण तय कर सकते हैं।

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

पदानुक्रमित ऑर्केस्ट्रेशन

पदानुक्रमित ऑर्केस्ट्रेशन मैनेजर वाले तरीके को कई स्तरों तक विस्तारित करता है। शीर्ष-स्तरीय ऑर्केस्ट्रेटर ज़िम्मेदारी अधीनस्थ ऑर्केस्ट्रेटर को सौंपता है, जो विशेषज्ञ एजेंट के अपने-अपने समूहों का समन्वय करते हैं।

सेल्स, फ़ाइनेंस और लीगल टीमों से जुड़े किसी एंटरप्राइज़ वर्कफ़्लो के बारे में सोचें। एक शीर्ष-स्तरीय ऑर्केस्ट्रेटर हर कार्यधारा को किसी डोमेन-विशिष्ट कोऑर्डिनेटर को सौंप सकता है। फिर वे कोऑर्डिनेटर अपने विशेषज्ञ एजेंटों को मैनेज करेंगे और समेकित नतीजों की रिपोर्ट देंगे।

यह संरचना तब मदद कर सकती है जब वर्कफ़्लो इतने व्यापक हों कि एक ऑर्केस्ट्रेटर उन्हें प्रभावी ढंग से मैनेज न कर सके।

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

इन आर्किटेक्चर की तुलना:

मानदंड

केंद्रीकृत

विकेंद्रीकृत

पदानुक्रमित

एक्ज़ीक्यूशन का स्वामित्व

एक ऑर्केस्ट्रेटर काम सौंपने को नियंत्रित करता है

एजेंट साथी एजेंट या साझा स्टेट के ज़रिए समन्वय करते हैं

ज़िम्मेदारी ऑर्केस्ट्रेशन के अलग-अलग स्तरों में बँटी होती है

स्टेट की संगति

एक नियंत्रण बिंदु के ज़रिए समन्वय करना आसान

स्पष्ट सिंक्रनाइज़ेशन और टकराव से निपटने की ज़रूरत होती है

शाखाओं के भीतर और उनके बीच समन्वय की ज़रूरत होती है

विफलता का अलगाव

केंद्रीय कंट्रोलर एक अहम निर्भरता बन सकता है

अलग-अलग एजेंट स्वतंत्र रूप से विफल हो सकते हैं, लेकिन साझा इन्फ़्रास्ट्रक्चर अहम बना रहता है

अगर रिकवरी को ध्यान में रखकर डिज़ाइन किया गया हो, तो विफलताएँ शाखाओं के भीतर ही सीमित रह सकती हैं

नीति प्रवर्तन

सामान्य नियंत्रण केंद्रीय रूप से लागू किए जा सकते हैं

नीतियों को सभी प्रतिभागियों में एक समान रूप से लागू किया जाना चाहिए

नियंत्रण वैश्विक और डोमेन स्तर पर लागू किए जा सकते हैं

परिचालन जटिलता

आम तौर पर कम

समन्वय की अधिक जटिलता

कई ऑर्केस्ट्रेशन परतों के कारण अधिक जटिलता

क्रमिक, समानांतर और हैंडऑफ़-आधारित निष्पादन

एक और अंतर समझना ज़रूरी है। आर्किटेक्चर यह तय करता है कि एजेंटों का समन्वय कौन करता है। निष्पादन पैटर्न यह तय करता है कि उनके कार्य कैसे आगे बढ़ते हैं।

ये तीन निष्पादन पैटर्न हैं:

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

ये पैटर्न परस्पर अनन्य नहीं हैं, और ये ऑर्केस्ट्रेशन आर्किटेक्चर से एक-से-एक मेल नहीं खाते। लक्ष्य ऐसी सबसे सरल संरचना चुनना है जो आपके वर्कफ़्लो की निर्भरताओं, समन्वय आवश्यकताओं और स्वीकार्य परिचालन ओवरहेड के अनुकूल हो।

AI एजेंट ऑर्केस्ट्रेशन की आम विफलताएँ

ऑर्केस्ट्रेशन में कुछ भी गलत हो सकता है, साधारण चूक से लेकर जटिल रुकावटों तक। कभी-कभी कोई एजेंट अपना काम सही ढंग से करता हुआ भी दिख सकता है, जबकि पूरा वर्कफ़्लो विफल हो जाता है। विशेषज्ञों के अनुभवों के आधार पर, हमने कुछ ऐसी आम गलतियाँ संकलित की हैं जिनके कारण ऑर्केस्ट्रेटेड वर्कफ़्लो अविश्वसनीय हो जाते हैं — इन पर नज़र रखें:

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

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

प्रोडक्शन में विश्वसनीयता के लिए AI एजेंट ऑर्केस्ट्रेशन की 7 सर्वोत्तम प्रथाएँ

1. स्पष्ट कार्य अनुबंध, स्वीकृति मानदंड और रुकने की शर्तें परिभाषित करें

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

उदाहरण के लिए, रुक-रुककर विफल होने वाले किसी इंटीग्रेशन टेस्ट को ठीक करने के लिए ज़िम्मेदार एजेंट का अनुबंध आप इस तरह परिभाषित कर सकते हैं:

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

लेकिन एक और महत्वपूर्ण पहलू है: एजेंट को कब रुकना चाहिए?

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

अब फिर से हमारे CI उदाहरण पर आते हैं। आप रुकने की ये शर्तें परिभाषित कर सकते हैं:

  • सफलता: सुधार लगातार 10 टेस्ट रन और संबंधित रिग्रेशन सुइट में पास होता है।
  • इटरेशन सीमा: एजेंट अधिकतम दो संभावित सुधार आज़मा सकता है।
  • निष्पादन बजट: एजेंट को 60 मिनट के बाद रुकना होगा, भले ही समस्या अनसुलझी रहे।
  • डेलिगेशन सीमा: एजेंट एक विशेषज्ञ एजेंट को काम सौंप सकता है, लेकिन उसके आगे किसी सबएजेंट को काम नहीं सौंपा जाएगा।
  • आंशिक पूर्णता: यदि दोनों प्रयास विफल हो जाते हैं या समय सीमा समाप्त हो जाती है, तो एजेंट अपने निष्कर्ष, आज़माए गए बदलाव और टेस्ट परिणाम लौटाता है।
  • अवरुद्ध निष्पादन: यदि टेस्ट एनवायरनमेंट उपलब्ध नहीं है, तो एजेंट सफलता का दावा करने के बजाय रुक जाता है और रुकावट की रिपोर्ट करता है।

2. ऑर्केस्ट्रेटर को हल्का रखें और संरचित हैंडऑफ़ लागू करें

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

इसलिए ऑर्केस्ट्रेटर को अपना काम करने दें और ठोस आर्टिफ़ैक्ट का संदर्भ देकर हैंडऑफ़ लागू करें: मूल कार्य, संबंधित इनपुट, आउटपुट आर्टिफ़ैक्ट, निष्पादन की स्थिति और कोई भी अनसुलझी समस्या।

इस उदाहरण पर विचार करें: status: completed एजेंट को सौंपे गए काम को दर्शाता है, पूरे वर्कफ़्लो को नहीं। चूँकि टेस्ट अभी भी pending हैं, इसलिए ऑर्केस्ट्रेटर को अंतिम परिणाम अनुमोदित नहीं करना चाहिए।

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

3. वर्कफ़्लो स्टेट को स्थायी रूप से सहेजें और कॉन्टेक्स्ट के बढ़ने को नियंत्रित करें

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

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

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

4. विफलताओं को ध्यान में रखकर रीट्राई और रिकवर किए जा सकने वाले टूल निष्पादन को डिज़ाइन करें

मान लीजिए आपका 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)

कोड नोट: यह उदाहरण मानकर चलता है कि CI API अनुरोध ID के आधार पर रन खोजने का समर्थन करता है। request_id केवल तभी डुप्लिकेट रोकता है जब प्रदाता स्पष्ट रूप से आइडेम्पोटेंसी की गारंटी देता हो। bounded_retry() केवल उदाहरण के लिए दिया गया स्यूडोकोड है। प्रोडक्शन में, रीट्राई को प्रति-ऑपरेशन रीट्राई बजट (अधिकतम प्रयास या बीता हुआ समय) और पूरे वर्कफ़्लो की डेडलाइन, दोनों से सीमित किया जाना चाहिए।

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

5. स्पष्ट संसाधन बजट के साथ काम को रूट और समानांतर करें

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

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

उदाहरण के लिए, Perplexity Computer का Effort Mode आपको मैन्युअल रूप से मॉडल चुने बिना यह तय करने देता है कि किसी कार्य पर कितना प्रयास लगाया जाए। Light, Standard, High या Ultra चुनें, और Perplexity अपने-आप ऑर्केस्ट्रेटिंग मॉडल और उसका रीज़निंग स्तर चुन लेता है। इसके बाद वह ऑर्केस्ट्रेटर उप-कार्यों को सहायक एजेंटों को सौंपता है, जो अलग-अलग प्रदाताओं के मॉडल का उपयोग कर सकते हैं।

Perplexity गुणवत्ता और लागत के आधार पर मॉडल कॉन्फ़िगरेशन का मूल्यांकन करता है, और ऐसे कम खर्चीले विकल्पों को प्राथमिकता देता है जो तुलनीय परिणाम देते हैं। यदि आप मॉडल और रीज़निंग स्तर खुद चुनना पसंद करते हैं, तो आप Custom नियंत्रणों का भी उपयोग कर सकते हैं।

समानांतरता के लिए, सीमा आपके इंफ्रास्ट्रक्चर और बाहरी निर्भरताओं के आधार पर तय होनी चाहिए। साझा API की अनुरोध और टोकन रेट लिमिट की पुष्टि करें, फिर बढ़ती कॉन्करेंसी के साथ अपने वर्कफ़्लो का लोड टेस्ट करें। देखें कि थ्रूपुट बेहतर होता है या अनुरोध कतार में लगने, धीमे होने या 429 त्रुटियाँ लौटाने लगते हैं।

संसाधनों की खपत को पूर्वानुमेय बनाए रखने के लिए, संसाधन सीमाएँ और शेड्यूलिंग नियंत्रण लागू करें:

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

6. अनुमोदन लागू करें और एजेंट निष्पादन को आइसोलेट करें

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

“मुझे अत्यधिक जटिल मल्टी-एजेंट सिस्टम पर संदेह है, खासकर जब एजेंट एक-दूसरे के काम की समीक्षा और अनुमोदन कर रहे हों। ऐसा हो सकता है कि कई एजेंट पूरे भरोसे के साथ एक ही गलती को आगे बढ़ाते रहें, और कोई भी उसे वास्तव में पकड़ न पाए,” Spilker चेतावनी देते हैं।

जिन कार्रवाइयों के लिए मानवीय अनुमोदन आवश्यक है, उनके लिए निष्पादन रोकें और ठीक वही प्रस्तावित ऑपरेशन सहेजें:

  • उसके पैरामीटर
  • उसका लक्ष्य संसाधन
  • उसका कमिट या स्टेट संस्करण
  • समीक्षक का निर्णय

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

इसलिए यदि अनुमोदन अस्वीकार हो जाता है या उसकी अवधि समाप्त हो जाती है, तो अनुरोध बंद हो जाता है। यदि निष्पादन से पहले लक्ष्य कमिट, पैरामीटर या अनुमतियाँ बदल जाती हैं, तो अनुमोदन को अमान्य करें और नए अनुमोदन का अनुरोध करें।

Spilker पूरी तरह स्वायत्त, एंड-टू-एंड एजेंटों को लक्ष्य मानने के विचार का भी समर्थन नहीं करते। “मेरे लिए बेहतर तरीका यह है कि स्पष्ट ज़िम्मेदारियों, परिभाषित अनुमतियों और सही बिंदुओं पर मानवीय समीक्षा वाले कुछ केंद्रित एजेंट बनाए जाएँ। इससे आपको पूरा नियंत्रण छोड़े बिना भी दक्षता मिलती है,” वे निष्कर्ष के तौर पर कहते हैं।

7. आउटपुट को स्वतंत्र रूप से सत्यापित करें और रिकवरी व्यवहार का परीक्षण करें

क्या कभी किसी एजेंट ने 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 सेवा की जाँच नहीं करते और यह नहीं पाते कि एक के बजाय दो टेस्ट रन बन गए हैं।

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

जो विफलताएँ आपको मिलें, उन्हें अपने रिग्रेशन टेस्ट में जोड़ें ताकि भविष्य के बदलाव उन्हें दोबारा न ला सकें।

अंततः, सफलता का अर्थ है कि वर्कफ़्लो ने अपनी आवश्यक जाँचें पास कर लीं और उसके बाहरी परिणामों का सत्यापन हो गया।

AI एजेंट ऑर्केस्ट्रेशन से जुड़े अक्सर पूछे जाने वाले प्रश्न

अलग-थलग काम करने वाले AI एजेंट एंटरप्राइज़ स्तर पर क्यों विफल हो जाते हैं?

अलग-थलग काम करने वाले एजेंट अपने-अपने टास्क सही ढंग से पूरे कर सकते हैं, लेकिन साथ मिलकर असंगत परिणाम दे सकते हैं। कल्पना कीजिए कि एक सेल्स एजेंट 10:00 बजे ग्राहक की शर्तें प्राप्त करता है, एक प्राइसिंग एजेंट 10:05 बजे अपडेट की गई कीमतों के आधार पर कोटेशन तैयार करता है, और एक लीगल एजेंट उस अनुबंध की जाँच करता है जो 10:07 बजे बदल गया था। हर एजेंट व्यवसाय के एक अलग स्नैपशॉट के साथ काम करता है, इसलिए उनके आउटपुट एक-दूसरे के विपरीत हो सकते हैं।

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

AI एजेंटों में अंतहीन रीट्राई लूप को कैसे रोकें?

कई स्तरों पर सीमाएँ तय करें: टूल कॉल के अधिकतम रीट्राई, एजेंट के अधिकतम इटरेशन, डेलिगेशन की गहराई, और वर्कफ़्लो की कुल समय-सीमा। रीट्राई करने से पहले विफलताओं को वर्गीकृत करें। अस्थायी 429 रिस्पॉन्स के लिए, यदि Retry-After दिया गया हो तो उसका पालन करें। अन्यथा, जिटर के साथ सीमित एक्सपोनेंशियल बैकऑफ़ का उपयोग करें।

वैलिडेशन या अनुमति संबंधी त्रुटियों के बाद बिना बदलाव वाले अनुरोधों को दोबारा भेजना बंद करें। अगर कोई डाउनस्ट्रीम सेवा बार-बार विफल होती है, तो सर्किट ब्रेकर एजेंटों को अतिरिक्त लोड पैदा करने से रोक सकता है।

क्रैश के बाद AI एजेंट वर्कफ़्लो को फिर से कैसे शुरू करें?

रिकवरी का तरीका आपके रनटाइम पर निर्भर करता है। LangGraph में, PostgresSaver जैसा पर्सिस्टेंट चेकपॉइंटर ग्राफ़ की स्थिति को एक thread_id के तहत संग्रहीत करता है, जिससे निष्पादन सहेजी गई स्थिति से आगे जारी रह सकता है। Temporal में, कोई दूसरा वर्कर किसी वर्कफ़्लो के इवेंट इतिहास को रीप्ले करके उसे फिर से बना सकता है। रीप्ले के दौरान, यह पहले से दर्ज एक्टिविटी परिणामों का दोबारा उपयोग करता है।

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

AI एजेंट ऑर्केस्ट्रेशन की विश्वसनीयता का परीक्षण कैसे करें?

एक जैसे प्रतिनिधि टास्क कई बार चलाएँ और pass@k (क्या k प्रयासों में से कम से कम एक सफल होता है) और pass^k (क्या सभी k प्रयास सफल होते हैं) के बीच अंतर करें

किसी एक समग्र सफलता दर पर निर्भर रहने के बजाय, टास्क श्रेणी और वर्कफ़्लो संस्करण के अनुसार परिणामों को मापें। पहले प्रयास में सफलता, बार-बार चलाने पर निरंतरता, p95 लेटेंसी, प्रति पूर्ण टास्क लागत, और मानवीय हस्तक्षेप की ज़रूरत वाले मामलों के अनुपात को ट्रैक करें। सफलता दरों के लिए सैंपल साइज़ और अनिश्चितता अंतराल रिपोर्ट करें।