ElevenAgents Architect कैसे काम करता है
बातचीत शुरू होने पर ElevenAgents Architect क्या जानता है, वह कैसे जांच करता है और किसी सवाल को सत्यापित बदलाव में कैसे बदलता है।
ओवरव्यू
ElevenAgents Architect की बातचीत एक रीयल-टाइम ElevenAgents बातचीत के रूप में चलती है, उसी इंजन पर जो आपके बनाए एजेंट्स को चलाता है। Architect के टूल्स आपके साइन-इन सेशन में आपके ब्राउज़र पर चलते हैं। हर टूल वही ElevenAgents APIs कॉल करता है जो डैशबोर्ड इस्तेमाल करता है, इसलिए हर रीड और राइट की जांच आपकी अपनी अनुमतियों के आधार पर होती है। अनुमतियां, अप्रूवल और ड्राफ़्ट देखें।
ElevenAgents Architect डिफ़ॉल्ट रूप से क्या जानता है
हर बातचीत की शुरुआत में, Architect को ये चीज़ें मिलती हैं:
- आपका अकाउंट और वर्कस्पेस: आपका प्लान, वर्कस्पेस और उपयोग।
- आप कहां हैं: पेज और, जब आप किसी एजेंट के अंदर हों, वह एजेंट और आपके खुले हुए ब्रांच की जानकारी। साइडबार में Architect को पेज का एक स्नैपशॉट भी मिलता है, और पेज बदलने पर हर संदेश से पहले अपडेट मिलता है।
- एजेंट का सारांश: जब आप किसी एजेंट के अंदर होते हैं, तो ElevenLabs इसे बनाता है। इसमें एजेंट का नाम और ओनर, उसके ब्रांच और उनका ट्रैफ़िक स्प्लिट, पिछले 7 दिनों का कॉल वॉल्यूम, ड्राफ़्ट स्थिति, कनेक्टेड एजेंट्स, प्रोसीजर्स, टेस्ट कॉन्फ़िगर किए गए हैं या नहीं, और आप किन ब्रांच को एडिट कर सकते हैं, शामिल होते हैं।
- एजेंट कॉन्टेक्स्ट: एजेंट का
agents.mdदस्तावेज़, जिसे एजेंट बनाने वाले सभी लोगों के साथ शेयर किया जाता है। Architect को कस्टमाइज़ करना देखें। - आपकी प्राथमिकताएं: आपका निजी
user.mdदस्तावेज़, जो आपके बनाए हर एजेंट पर लागू होता है। - एंट्री पॉइंट से मिली जानकारी: उदाहरण के लिए, फेल हुए टेस्ट, Spotlight की खोज या ट्रायेज टिकट। बातचीत शुरू करना देखें।
- इस चैट के पहले के संदेश।
Architect शुरुआत में एजेंट का पूरा कॉन्फ़िगरेशन, उसके ट्रांसक्रिप्ट्स, टेस्ट नतीजे, Spotlight डेटा या आपकी दूसरी Architect चैट्स नहीं देखता। काम के लिए ज़रूरत पड़ने पर वह टूल्स से इन्हें पढ़ता है। इससे हर बातचीत केंद्रित रहती है और Architect हमेशा पुराने कॉपी के बजाय मौजूदा डेटा के साथ काम करता है।
जांच और सीधे निर्देश
Architect दो तरह के अनुरोधों को अलग तरीके से संभालता है।
सीधे निर्देश बदलाव का नाम बताते हैं, जैसे “प्रतियोगियों की कीमतों पर चर्चा रोकने वाली गार्डरेल जोड़ें” या “पहला संदेश छोटा करें।” Architect संबंधित कॉन्फ़िगरेशन पढ़ता है, बदलाव करता है और बताता है कि उसने क्या स्टेज किया है। डिफ़ॉल्ट अप्रूवल मोड में, एजेंट कॉन्फ़िगरेशन में बदलाव बिना पूछे ड्राफ़्ट में स्टेज कर दिए जाते हैं। लाइव ट्रैफ़िक या साझा संसाधनों को प्रभावित करने वाली कार्रवाइयां आपके अप्रूवल का इंतज़ार करती हैं।
जांच किसी सुधार का नाम लिए बिना सवाल पूछती हैं, जैसे “रिफ़ंड कॉल एस्केलेट क्यों हो रही हैं?” या “मैं रिफ़ंड रिज़ॉल्यूशन कैसे सुधारूं?” Architect कुछ बदलने से पहले रिसर्च करता है:
- वह जांच के लिए एक टू-डू लिस्ट लिखता है, जो आइटम पूरे होने के साथ कंपोज़र के ऊपर दिखती रहती है।
- अलग-अलग ट्रांसक्रिप्ट पढ़ने से पहले, वह कम खर्चीले संकेतों से शुरुआत करता है, जैसे बातचीत की संख्या, टॉपिक्स और मूल्यांकन नतीजे।
- वह बातचीत का समानांतर रूप से विश्लेषण करता है और अपनी खोज को मूल कारण के अनुसार समूहित करता है।
- उसका तर्क दिखाई देता है। तर्क का हर चरण Thought for Ns में सिमट जाता है और उसे एक्सपैंड किया जा सकता है।
- वह बताता है कि उसे क्या मिला, जिसमें यह भी शामिल होता है कि उसने वास्तव में कितनी बातचीत पढ़ीं। वह किसी सैंपल को संपूर्ण नहीं बताता।
प्लान मोड
बड़े बदलावों के लिए, कंपोज़र को Plan पर स्विच करें (मोड बदलने के लिए Shift+Tab दबाएं)। Plan मोड में, Architect रीड-ओनली टूल्स से रिसर्च करता है, एक प्लान लिखता है जिसे आप बनते हुए देख सकते हैं, और फिर आपसे Approve plan या Reject करने को कहता है। आपके अप्रूवल तक वह कोई बदलाव नहीं करता। अगर आप नोट के साथ प्लान अस्वीकार करते हैं, तो Architect उसमें सुधार करता है और फिर से पूछता है।
फ़ुल-स्क्रीन Architect टैब में, प्लान कंपोज़र के ऊपर एक पैनल में दिखता है। साइडबार में, यह चैट में एक कार्ड के रूप में दिखता है।
उदाहरण: रिफ़ंड रिज़ॉल्यूशन में सुधार
यह उदाहरण एक बातचीत में व्यापक सवाल से लेकर रिव्यू के लिए तैयार बदलाव तक की प्रक्रिया दिखाता है। टूल के नाम इसलिए दिखाए गए हैं ताकि आप हर चरण को बातचीत में दिखने वाली चीज़ों से मिला सकें। Architect अपने चरण खुद चुनता है, इसलिए असली बातचीत का क्रम और विवरण अलग हो सकता है।
एजेंट के Architect टैब से भेजा गया अनुरोध:
मैं रिफ़ंड रिज़ॉल्यूशन कैसे सुधारूं?
जांच की योजना बनाएं
Architect एक टू-डू लिस्ट लिखता है (write_todos): समस्या को मापना, फेल हुई रिफ़ंड
बातचीत ढूंढना, मूल कारणों की पहचान करना, सुधार सुझाना और उसका टेस्ट करना।
समस्या को मापें
Architect एजेंट के टॉपिक्स (get_agent_topics, get_topics_summary) पढ़ता है ताकि रिफ़ंड
टॉपिक और उसकी सफलता दर पता चल सके, फिर मूल्यांकन में फेल हुई हाल की रिफ़ंड बातचीत की गिनती करता है और उन्हें सूचीबद्ध करता है
(count_conversations, list_conversations)।
बातचीत पढ़ें
Architect रिफ़ंड अनुरोधों के लिए ट्रांसक्रिप्ट खोजता है (search_conversation_messages,
semantic_search_conversations), फिर फेल हुई बातचीत के एक बैच का समानांतर रूप से विश्लेषण करता है
(analyze_conversation_subagent)। हर विश्लेषण बताता है कि यूज़र क्या चाहता था, एजेंट
कहां गलत हुआ और यह किस टर्न में हुआ।
मूल कारण ढूंढें
Architect मौजूदा कॉन्फ़िगरेशन से फेलियर की तुलना करता है (get_agent_config,
list_procedures, get_procedure)। वह ऐसी खोज रिपोर्ट करता है: “40 फेल हुई रिफ़ंड
कॉल्स में से 31 में, एजेंट ने ऑर्डर नंबर पूछने से पहले lookup_order कॉल किया, उसे त्रुटि मिली और
उसने एस्केलेट कर दिया।”
ब्रांच पर बदलाव करें
Architect एक ब्रांच बनाता है (create_branch) ताकि बदलाव लाइव एजेंट से अलग रहे। फिर वह
रिफ़ंड प्रोसीजर को एडिट करता है (update_procedure) ताकि लुकअप से पहले ऑर्डर नंबर पूछा जाए।
बदलाव उस ब्रांच पर आपके ड्राफ़्ट में स्टेज होता है। लाइव कॉलर्स के लिए कुछ भी नहीं बदला है।
बदलाव के लिए टेस्ट लिखें
Architect ऐसे टेस्ट लिखता है जो फेलियर को कैप्चर करें: ऑर्डर नंबर दिए बिना रिफ़ंड मांगने वाले कॉलर का सिमुलेशन
(create_simulation_test), यह जांचने वाला टूल-कॉल टेस्ट कि
lookup_order को पहले कॉल नहीं किया जाता (create_tool_test), और असली फेल हुई बातचीत में से एक से जनरेट किया गया टेस्ट
(generate_test_from_conversation)। Architect सिमुलेशन में साइड इफेक्ट वाले टूल्स को मॉक करता है, ताकि कोई असली रिफ़ंड जारी न हो।
पहले और बाद में टेस्ट चलाएं
Architect बदलाव के बिना एजेंट पर टेस्ट चलाता है (मूल
ब्रांच पर run_tests, या include_draft: false के साथ run_agent_tests), फिर बदलाव वाले ड्राफ़्ट पर
(run_agent_tests) और नतीजे पढ़ता है (get_test_suite_summary,
get_test_suite_failures)। अपेक्षित नतीजा यह है कि नए टेस्ट बदलाव के बिना फेल हों
और उसके साथ पास हों। अगर टेस्ट फिर भी फेल होते हैं, तो Architect फेलियर पढ़ता है, बदलाव को एडजस्ट करता है और
उन्हें फिर से चलाता है।
बदलाव पेश करें
Architect मूल कारण, बदलाव और टेस्ट नतीजों का सारांश देता है और पब्लिश
डायलॉग खोलता है (request_draft_publish)। आप डिफ़ देखते हैं और Publish चुनते हैं, जो
बदलाव को ब्रांच पर नए वर्शन के रूप में कमिट करता है। Architect आपकी ओर से पब्लिश नहीं कर सकता।
प्रस्ताव खोलें
Architect ब्रांच की हिस्ट्री और मर्ज प्रीव्यू पढ़ता है (get_branch_history,
merge_branch_preview) और main में एक मर्ज प्रस्ताव खोलता है (create_merge_proposal)।
विवरण में सारांश, टेस्टिंग, और कैसे रिव्यू करें के तीन सेक्शन होते हैं, जिन्हें
असली कमिट्स और टेस्ट रन से लिखा जाता है। Architect रिव्यूअर्स सुझा सकता है
(suggest_merge_proposal_reviewers), लेकिन आप उन्हें चुनते हैं।
वैलिडेशन बातचीत के अंदर होता है, आपको कुछ पब्लिश या रिव्यू करने के लिए कहने से पहले। जब प्रस्ताव किसी रिव्यूअर तक पहुंचता है, तो बदलाव को प्रेरित करने वाले टेस्ट पहले से एजेंट से जुड़े होते हैं और ब्रांच पर चल चुके होते हैं। रिव्यूअर को क्या दिखता है, इसके लिए प्रस्ताव और वैलिडेशन देखें।
बदलाव से पहले और बाद में टेस्ट चलाना अच्छा अभ्यास है, लेकिन Architect इसे हर बदलाव पर अपने-आप नहीं चलाता। यह सुनिश्चित करने के लिए कि वह ऐसा करे, सीधे कहें, जैसे “मुझे नए टेस्ट main पर फेल होते और ब्रांच पर पास होते दिखाएं।”
स्लैश कमांड्स
मौजूदा पेज पर उपलब्ध कमांड्स देखने के लिए कंपोज़र में / टाइप करें।
ज़्यादातर कमांड केवल एजेंट के अंदर होने पर लागू होते हैं। /clear और /feedback Architect टैब के होम पेज पर उपलब्ध नहीं हैं।
चैट में डैशबोर्ड्स
Architect किसी सवाल का जवाब डेटा के साथ देने के लिए बातचीत में डैशबोर्ड बना सकता है, जैसे “इस हफ़्ते के एस्केलेशन को कारण के अनुसार बांटें और ट्रेंड दिखाएं।” /dashboard इस्तेमाल करें या सीधे डैशबोर्ड मांगें।
Architect अपने टूल्स से डेटा इकट्ठा करता है, उसे कोड से आकार देता है और Spotlight के समान मेट्रिक टाइल्स, चार्ट्स, लिस्ट्स और टेक्स्ट कार्ड्स से बना डैशबोर्ड रेंडर करता है। डैशबोर्ड में ये शामिल हो सकते हैं:
- हेडलाइन वैल्यू, बदलाव और स्पार्कलाइन वाले मेट्रिक टाइल्स।
- चार्ट्स: एरिया, लाइन, बार, स्टैक्ड एरिया, डोनट और टॉप-N ब्रेकडाउन के लिए रैंक्ड बार लिस्ट्स।
- स्टेटस लेबल्स, तारीखों और अलग-अलग बातचीत जैसे ElevenAgents के पेजों के लिंक वाली लिस्ट्स।
- निष्कर्षों और सुझावों के लिए टेक्स्ट कार्ड्स।
फ़ुल-स्क्रीन Architect टैब में, डैशबोर्ड बातचीत में इनलाइन रेंडर होते हैं। साइडबार में, वे चैट के पास एक पैनल में खुलते हैं।
डैशबोर्ड डेटा केवल उसी ब्राउज़र टैब की मेमोरी में रखा जाता है जहां इसे बनाया गया था और चैट के साथ कभी सेव नहीं होता। पेज रीलोड करने, चैट को दूसरे टैब में खोलने या कई बड़े डैशबोर्ड बनाने के बाद, किसी पुराने डैशबोर्ड में डेटा के बजाय संदेश दिखता है। Architect से इसे फिर से बनाने के लिए कहें। डैशबोर्ड रीड-ओनली स्नैपशॉट होते हैं। इनमें फ़िल्टर नहीं होते और ये लाइव अपडेट नहीं होते।
कोड चलाना
Architect अपने टूल्स के डेटा को गिनने, समूहित करने और तुलना करने के लिए छोटे Python प्रोग्राम चला सकता है, उदाहरण के लिए कुछ सौ बातचीत में हफ़्ते के हिसाब से रिज़ॉल्यूशन रेट निकालने के लिए। कोड केवल Python स्टैंडर्ड लाइब्रेरी के साथ आपके ब्राउज़र के सैंडबॉक्स में चलता है। इसे नेटवर्क एक्सेस, आपके ElevenLabs अकाउंट का एक्सेस नहीं मिलता और इसकी समय सीमा 20 सेकंड है। कोड एक्ज़ीक्यूशन धीरे-धीरे रोल आउट किया जा रहा है और हर वर्कस्पेस में उपलब्ध नहीं हो सकता।
बड़े रिस्पॉन्स
जब कोई टूल बातचीत में समाने से ज़्यादा डेटा लौटाता है, जैसे बातचीत की लंबी सूची, Architect पूरा रिस्पॉन्स आपके ब्राउज़र टैब की मेमोरी में रखता है और सारांश के साथ काम करता है। ज़रूरत पड़ने पर वह बाकी डेटा खोज और पढ़ सकता है। ऐसा होने पर टूल कॉल पर एक नोटिस दिखता है। ये रिस्पॉन्स कभी सेव या अपलोड नहीं किए जाते।