Zero में A2A: एजेंट, चैट और कार्य हस्तांतरण

Zero में A2A क्या है?

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

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

Zero में A2A के काम करने के तीन तरीके

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

इन पैटर्न के पीछे तीन उत्पाद ऑब्जेक्ट हैं:

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

जरूरी बात सरल है: नया चाइल्ड चैट कंट्रोल चैट का पूरा इतिहास अपने आप नहीं पाता। उसके पहले संदेश में काम पूरा करने के लिए जरूरी सारी जानकारी होनी चाहिए।

A2A, कई चैट, सबएजेंट, वर्कफ़्लो और ऑटोमेशन

ये शब्द अलग-अलग समस्याएँ हल करते हैं। उतना ही छोटा सेटअप चुनें जितना जरूरी सीमा बनाने के लिए चाहिए।

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

एक आसान नियम: तरीका वही हो तो काम को अलग चैट में बाँटें। तरीका या एक्सेस बदलता हो तो विशेषज्ञ एजेंट बनाएँ। प्रक्रिया हर बार एक जैसी दोहरानी हो तो वर्कफ़्लो इस्तेमाल करें।

1. एक एजेंट कई अलग चैट खोलता है

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

इसके बजाय हर यात्रा के लिए अलग चैट इस्तेमाल करें।

एक साझा ब्रीफ़, चार अलग जाँच और फिर एक अंतिम रिपोर्ट।

हमने 25 अगस्त 2026 को staging उत्पाद में यही सेटअप बनाया। उसी Zero एजेंट ने ऑनबोर्डिंग, बिलिंग, टीममेट अनुमतियों और मोबाइल व लोकैल टेस्टिंग के लिए चार वास्तविक चैट खोले।

हर यात्रा का अपना चैट है, इसलिए प्रमाण देखना आसान रहता है।

यह प्रॉम्प्ट आज़माएँ:

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

यह पैटर्न इन कामों में भी उपयोगी है:

• हर ब्राउज़र या डिवाइस आकार के लिए एक चैट
• हर लोकैल या अकाउंट भूमिका के लिए एक चैट
• हर pull request या feature flag के लिए एक चैट
• हर समीक्षक के लिए एक चैट, ताकि निष्कर्ष अंत तक अलग रहें
• ग्राहक इंटरव्यू के हर बैच या रिसर्च स्रोतों के हर समूह के लिए एक चैट
• हर मॉडल के लिए एक चैट, ताकि आउटपुट की निष्पक्ष तुलना हो सके

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

2. @ से किसी दूसरे चैट को काम में शामिल करें

कई बार उपयोगी काम पहले से किसी चैट में मौजूद होता है। रिसर्च चैट में ग्राहकों के कथन हैं। QA चैट में स्क्रीनशॉट हैं। दूसरी समीक्षा किसी अलग निष्कर्ष पर पहुँची है। आपको यह सब कॉपी-पेस्ट करने की जरूरत नहीं है।

इनपुट बॉक्स पर क्लिक करके @ लिखें। Zero आपके मौजूदा चैट की सूची खोल देगा।

सूची छोटी करने के लिए शीर्षक लिखना शुरू करें, फिर जरूरी चैट चुनें।

चुना गया चैट क्लिक किए जा सकने वाले नारंगी चिप के रूप में दिखता है।

चिप ठीक उसी ऑनबोर्डिंग चैट को संदर्भित करता है। जवाब वर्तमान चैट में लिखा जाएगा।

फिर एक क्रिया जोड़ें। Zero को साफ बताएँ कि उस चैट के साथ क्या करना है:

• “@Onboarding QA की तुलना इस बिलिंग समीक्षा से करें।”
• “@Customer research batch 2 से आगे बढ़ें और सुझाव यहाँ लिखें।”
• “@Security review के सबसे अधिक जोखिम वाले निष्कर्ष को चुनौती दें।”
• “@Mobile walkthrough के स्क्रीनशॉट से बग रिपोर्ट बनाएँ।”
• “@Launch research के सभी अनसुलझे सवाल निकालें।”

@ लिखें, चैट चुनें और बताएँ कि Zero को उसके साथ क्या करना है।

मेंशन अस्पष्ट टेक्स्ट लेबल नहीं, चुने हुए चैट का पता है। यह पूरी बातचीत को इनपुट बॉक्स में चिपकाए बिना Zero को सही चैट दिखाता है। संदेश पढ़ने में आसान रहता है, लेकिन निर्देश में साफ क्रिया फिर भी जरूरी है। “इसे इस्तेमाल करें” अस्पष्ट है। “असफल चरणों की तुलना करें और साझा ब्लॉकरों को प्राथमिकता दें” स्पष्ट है।

3. काम के अलग हिस्से विशेषज्ञ एजेंटों या सबएजेंटों को सौंपें

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

उत्पाद लॉन्च इसका अच्छा उदाहरण है। Research Scout प्रमाण सत्यापित कर सकता है। Browser QA जारी किए गए उत्पाद की जाँच कर सकता है। Launch Writer पेज का ड्राफ्ट लिख सकता है। दावों की समीक्षा पूरी होने के बाद Publishing Operator CMS ड्राफ्ट बना सकता है।

staging वर्कस्पेस में एक मुख्य एजेंट और चार नाम वाले विशेषज्ञ एजेंट हैं। हर एजेंट स्पष्ट सीमा वाला काम लेने के लिए तैयार है।

नतीजे की जिम्मेदारी कोऑर्डिनेटर की है। विशेषज्ञ प्रमाण और आर्टिफैक्ट लौटाते हैं, फिर एक मालिक अंतिम परिणाम लिखता है।

यह एक व्यावहारिक लॉन्च ब्रीफ़ है:

Feature X का लॉन्च पैकेज तैयार करें। Research Scout से ग्राहक प्रमाण और प्रतिस्पर्धियों के दावों की जाँच कराएँ। Browser QA से staging में हर उत्पाद दावे को दोहराने और स्क्रीनशॉट जोड़ने को कहें। Launch Writer प्रमाण मिलने के बाद ही पेज का ड्राफ्ट लिखे। Publishing Operator CMS ड्राफ्ट बना सकता है, लेकिन उसे प्रकाशित नहीं करना है। गायब प्रमाण और विरोधी दावों की रिपोर्ट इसी चैट में करें।

मूल्य वास्तविक सीमाओं से आता है। रिसर्च एजेंट केवल पढ़ने की अनुमति पर रह सकता है। प्रकाशन एजेंट को प्रकाशित करने की अनुमति दिए बिना ड्राफ्ट एक्सेस दिया जा सकता है। QA एजेंट हर बार तय ब्राउज़र चेकलिस्ट पर चल सकता है। Zero के अनुमति नियंत्रण इन सीमाओं को छोटा और स्पष्ट रखने में मदद करते हैं।

सिर्फ साइडबार भरने के लिए विशेषज्ञ एजेंट न बनाएँ। एजेंट तभी बनाएँ जब भूमिका काम करने का तरीका बदलती हो।

4. स्वतंत्र समीक्षकों को अलग राय देने दें, फिर एक निर्णायक एजेंट का उपयोग करें

दो समीक्षाएँ तभी उपयोगी हैं जब दूसरा समीक्षक पहले की नकल न करे। अलग चैट खोलें, दोनों समीक्षकों को वही प्रमाण दें और उनकी पहली रिपोर्ट अलग रखें।

फिर निर्णय के लिए एक नया चैट शुरू करें और एक ही प्रॉम्प्ट में दोनों रिपोर्ट मेंशन करें।

एक प्रॉम्प्ट दो वास्तविक QA चैट को संदर्भित कर सकता है और Zero से साझा ब्लॉकर खोजने को कह सकता है।

उदाहरण:

@Onboarding QA और @Billing QA की तुलना करें। दोनों चैट को मिले ब्लॉकर, केवल एक चैट को मिली समस्याएँ और अभी गायब प्रमाण सूचीबद्ध करें। फिर तय करें कि रिलीज़ करनी चाहिए या नहीं। हर ब्लॉकर के समर्थन में स्क्रीनशॉट या चरण उद्धृत करें।

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

5. काम एक एजेंट से अगले एजेंट को सौंपें

कुछ काम एक साथ नहीं चलने चाहिए। रिसर्च ड्राफ्ट से पहले पूरी होनी चाहिए। ड्राफ्ट QA से पहले पूरा होना चाहिए। QA प्रकाशन से पहले पूरी होनी चाहिए।

हर हैंडऑफ को छोटी डिलीवरी नोट की तरह लिखें:

1. काम पाने वाले एजेंट या चैट का नाम लिखें।
2. आर्टिफैक्ट संलग्न करें या उसका संदर्भ दें।
3. स्वीकृति के मापदंड साफ करें।
4. बताएँ कि काम पाने वाला नतीजा कहाँ वापस रिपोर्ट करेगा।

“लेखक को बता दो कि क्या मिला” को सत्यापित करना मुश्किल है। यह निर्देश बेहतर है:

मंजूर किया गया रिसर्च सारांश Launch Writer को भेजें। ड्राफ्ट में केवल सत्यापित दावों का इस्तेमाल हो, मंजूर शब्दावली बनी रहे, और जहाँ प्रमाण गायब हो वहाँ [EVIDENCE NEEDED] लिखें। ड्राफ्ट का लिंक और अनसुलझे सवाल इस चैट में लौटाएँ।

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

Zero में AI एजेंट संदर्भ कैसे साझा करते हैं?

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

यह तरीका मल्टी-एजेंट काम की दो सामान्य समस्याओं से बचाता है। पहला, गैर-जरूरी इतिहास कार्यकर्ता के संदर्भ को नहीं भरता। दूसरा, कोऑर्डिनेटर साफ देख सकता है कि कौन सा स्रोत या चैट किसी दावे का समर्थन करता है।

संदर्भ साझा करने के ये चार तरीके इस्तेमाल करें:

1. अपने आप में पूरा ब्रीफ़: ऐसे नए चाइल्ड चैट के लिए सबसे अच्छा जो साफ शुरुआत करे।
2. @ चैट मेंशन: जब कोई मौजूदा बातचीत स्रोत हो।
3. आर्टिफैक्ट लिंक: दस्तावेज़, स्क्रीनशॉट, डेटासेट और कोड बदलावों के लिए।
4. संरचित जवाब: जब कई कार्यकर्ताओं को एक ही प्रारूप में रिपोर्ट करना हो।

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

A2A और मल्टी-एजेंट वर्कफ़्लो के और उदाहरण

परिदृश्य	काम कैसे बाँटें	क्या वापस आएगा
रिलीज़ walkthrough	वही एजेंट, हर उपयोगकर्ता यात्रा के लिए एक चैट	स्क्रीनशॉट, पास/फेल जाँच और साझा ब्लॉकर
लोकलाइज़ेशन QA	वही एजेंट, हर लोकैल के लिए एक चैट	टूटी स्ट्रिंग, लेआउट समस्या और लोकैल-विशिष्ट स्क्रीनशॉट
ब्राउज़र और डिवाइस टेस्टिंग	वही एजेंट, हर ब्राउज़र या viewport के लिए एक चैट	प्रमाण के साथ तुलना योग्य compatibility matrix
Pull request समीक्षा	वही एजेंट, हर PR या समीक्षा कोण के लिए एक चैट	बग, जोखिम नोट और लाइन-स्तरीय सुझाव
ग्राहक रिसर्च	वही एजेंट, हर इंटरव्यू बैच के लिए एक चैट	कथन, पैटर्न, आपत्तियाँ और स्रोत लिंक
घटना प्रतिक्रिया	कोऑर्डिनेटर के साथ app, API, deploy और ग्राहक-प्रभाव एजेंट	सहमतियों और मतभेदों वाली एक समयरेखा
कंटेंट प्रोडक्शन	रिसर्च, लेखन, डिज़ाइन, QA और प्रकाशन एजेंट	समीक्षा किया हुआ ड्राफ्ट और नियंत्रित प्रकाशन हैंडऑफ
ग्राहक सहायता ट्रायेज	कोऑर्डिनेटर के साथ अकाउंट, उत्पाद, बिलिंग और उत्तर एजेंट	मूल कारण, प्राथमिकता, मालिक और जवाब का ड्राफ्ट
डेटा विश्लेषण QA	विश्लेषक एजेंट और स्वतंत्र समीक्षक	जाँचे गए joins, denominators, time zones और assumptions
मॉडल तुलना	एक ही ब्रीफ़ और अलग मॉडल वाले साफ चैट	accuracy, cost, latency और format score

सही विभाजन उपयोगी सीमा बनाता है। वह संदर्भ अलग कर सकता है, अनुमति बचा सकता है, समीक्षाएँ स्वतंत्र रख सकता है या तैयार काम को एक साथ चलने दे सकता है।

एक चैट, कई चैट या कई एजेंट कब इस्तेमाल करें?

जब हर अगला कदम तुरंत पिछले जवाब पर निर्भर हो, तब एक चैट इस्तेमाल करें। क्रमिक debugging session इसका अच्छा उदाहरण है।

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

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

जब प्रक्रिया दोहराई जा सकनी चाहिए, तब वर्कफ़्लो इस्तेमाल करें। ऑटोमेशन तभी जोड़ें जब प्रक्रिया को समय-सारिणी या घटना ट्रिगर भी चाहिए। Zero इन दोनों घटकों को अलग समझाता है: वर्कफ़्लो तरीका तय करते हैं, जबकि ऑटोमेशन तय करते हैं कि वह कब चलेगा।

A2A सुरक्षा और अनुमति की सीमाएँ

मल्टी-एजेंट काम तब सुरक्षित होता है जब एक्सेस दिए गए काम के अनुसार हो। हर विशेषज्ञ को केवल उसके हिस्से के लिए जरूरी कनेक्टर और अनुमतियाँ दें। रिसर्च एजेंट को सामान्यतः प्रकाशित करने की अनुमति नहीं चाहिए। QA एजेंट को staging लॉगिन चाहिए हो सकता है, लेकिन production billing controls नहीं। प्रकाशन एजेंट को ड्राफ्ट एक्सेस मिल सकता है, जबकि अंतिम रिलीज़ के लिए व्यक्ति की मंजूरी जरूरी रहे।

बाहरी बदलावों का एक नामित मालिक रखें। कई एजेंट repository, CRM या CMS पढ़ सकते हैं, लेकिन अंतिम ticket बनाना, record अपडेट करना, ग्राहक को जवाब भेजना या पेज प्रकाशित करना एक एजेंट की जिम्मेदारी होनी चाहिए। इससे डुप्लिकेट बदलाव नहीं होते और audit trail साफ रहता है।

अधिक जोखिम वाले काम में ब्रीफ़ के भीतर रुकने की शर्त लिखें: “केवल ड्राफ्ट”, “मत भेजें”, “प्रमाण टकराएँ तो escalation करें” या “production बदलने से पहले मंजूरी माँगें।” A2A काम सौंपना आसान बनाता है, लेकिन साफ जवाबदेही की जरूरत खत्म नहीं करता।

A2A काम व्यवस्थित रखने के चार नियम

1. हर पहला संदेश अपने आप में पूरा रखें

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

2. सभी कार्यकर्ताओं से एक ही प्रारूप में जवाब माँगें

अगर चार QA चैट चार अलग प्रारूप लौटाएँ, तो कोऑर्डिनेटर का समय टेक्स्ट साफ करने में जाएगा। हर कार्यकर्ता से एक ही फ़ील्ड माँगें: environment, steps, evidence, status और next action।

3. साझा बाहरी बदलावों का एक ही मालिक रखें

दो सही एजेंट भी एक ही चीज़ दो बार लिखकर गड़बड़ कर सकते हैं। अंतिम बाहरी कार्रवाई करने वाले एजेंट का नाम पहले तय करें।

4. केवल वही काम बाँटें जिसे बाँटने से फायदा हो

आठ चैट बनाने का मतलब यह नहीं कि आठ रन एक साथ चलेंगे। वर्कस्पेस की concurrency सीमा फिर भी लागू होती है, और निर्भर काम को अपने इनपुट का इंतजार करना चाहिए। जब हर अगला कदम पिछले जवाब पर निर्भर हो, तो काम को एक ही चैट में रखें।

क्या Zero A2A, Google के Agent2Agent प्रोटोकॉल जैसा है?

यहाँ प्रोटोकॉल के बराबर होने का दावा नहीं किया गया है। यह गाइड Zero के भीतर एजेंट और चैट के बीच उत्पाद-स्तरीय तालमेल समझाती है: काम को कैसे बाँटा, संदर्भित, जाँचा और इंटरफ़ेस से आगे सौंपा जाता है।

Google का Agent2Agent ओपन प्रोटोकॉल दूरस्थ एजेंट सिस्टम के बीच संचार का तकनीकी मानक है। इसमें capability discovery, task management, messages और artifacts शामिल हैं। “A2A” के खोज परिणाम अक्सर इसी प्रोटोकॉल पर केंद्रित होते हैं, इसलिए फर्क महत्वपूर्ण है: Zero A2A वह व्यावहारिक उत्पाद वर्कफ़्लो है जिसे यह लेख समझाता है।

अक्सर पूछे जाने वाले प्रश्न

क्या चैट और एजेंट एक ही हैं?

नहीं। एजेंट दोबारा इस्तेमाल किया जा सकने वाला कार्यकर्ता कॉन्फ़िगरेशन है। चैट उस एजेंट के साथ अलग बातचीत है। एक एजेंट के कई चैट हो सकते हैं।

क्या चाइल्ड चैट कंट्रोल चैट का संदर्भ साझा करते हैं?

नहीं। हर चाइल्ड चैट को पूरा ब्रीफ़ देकर शुरू करें। कार्यकर्ता नतीजे लौटा सकते हैं या सीमित आर्टिफैक्ट दूसरे चैट को दे सकते हैं, लेकिन साझा इतिहास मानकर नहीं चलना चाहिए।

किसी चैट को @ करने पर क्या होता है?

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

Zero में सबएजेंट क्या है?

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

क्या कई चैट समानांतर चल सकते हैं?

हाँ, जब वर्कस्पेस में concurrency उपलब्ध हो और काम स्वतंत्र हों। सीमा पूरी होने पर अतिरिक्त काम कतार में जा सकते हैं। निर्भर काम क्रम से चलना चाहिए।

अलग एजेंट कब इस्तेमाल करने चाहिए?

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

पहले staging walkthrough आज़माएँ

Zero में नया चैट खोलें और एक वास्तविक रिलीज़ जाँच को चार अलग चैट में बाँटें। हर चैट से स्क्रीनशॉट और एक जैसा पास/फेल प्रारूप माँगें। यह काम करने लगे तो एक शाखा को विशेषज्ञ एजेंट दें या निर्णायक प्रॉम्प्ट में दो पूरे हो चुके चैट मेंशन करें।

और उदाहरणों के लिए सटीक प्रॉम्प्ट और टूल वाले 20 AI एजेंट उपयोग के मामले देखें।