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)।
विवरण में Summary, Testing, और How to review नाम के तीन सेक्शन होते हैं, जिन्हें
वास्तविक कमिट्स और टेस्ट रन्स के आधार पर लिखा जाता है। Architect रिव्यूअर्स का सुझाव दे सकता है
(suggest_merge_proposal_reviewers), लेकिन उन्हें आप चुनते हैं।
वैलिडेशन बातचीत के अंदर होता है, आपसे कुछ पब्लिश या रिव्यू करने के लिए कहने से पहले। जब प्रस्ताव किसी रिव्यूअर तक पहुंचता है, तो बदलाव के लिए प्रेरित करने वाले टेस्ट्स पहले ही एजेंट से जुड़े होते हैं और ब्रांच पर चल चुके होते हैं। रिव्यूअर को क्या दिखता है, इसके लिए प्रस्ताव और वैलिडेशन देखें।
बदलाव से पहले और बाद का टेस्ट रन एक अच्छा तरीका है, लेकिन Architect इसे हर बदलाव पर अपने-आप नहीं चलाता। यह सुनिश्चित करने के लिए कि यह ऐसा करे, सीधे कहें, जैसे “मुझे नए टेस्ट्स main पर फेल होते और ब्रांच पर पास होते दिखाएं।”
स्लैश कमांड्स
मौजूदा पेज पर उपलब्ध कमांड्स देखने के लिए कंपोज़र में / टाइप करें।
ज़्यादातर कमांड्स केवल तब लागू होती हैं जब आप किसी एजेंट के अंदर हों। /clear और /feedback Architect टैब के होम पेज पर उपलब्ध नहीं हैं।
चैट में डैशबोर्ड्स
Architect डेटा के साथ किसी सवाल का जवाब देने के लिए बातचीत में डैशबोर्ड बना सकता है, जैसे “इस सप्ताह के एस्केलेशंस को कारण के अनुसार बांटें और ट्रेंड दिखाएं।” /dashboard इस्तेमाल करें या सीधे इसके लिए कहें।
Architect अपने टूल्स से डेटा इकट्ठा करता है, उसे कोड से आकार देता है और Spotlight जैसे ही मेट्रिक टाइल्स, चार्ट्स, लिस्ट्स और टेक्स्ट कार्ड्स से बना डैशबोर्ड रेंडर करता है। डैशबोर्ड में शामिल हो सकते हैं:
- हेडलाइन वैल्यू, बदलाव और स्पार्कलाइन वाली मेट्रिक टाइल्स।
- चार्ट्स: टॉप-N ब्रेकडाउन के लिए एरिया, लाइन, बार, स्टैक्ड एरिया, डोनट और रैंक्ड बार लिस्ट्स।
- स्टेटस लेबल्स, तारीखों और अलग-अलग बातचीत जैसे ElevenAgents के पेजों के लिंक वाली लिस्ट्स।
- निष्कर्षों और सुझावों के लिए टेक्स्ट कार्ड्स।
फ़ुल-स्क्रीन Architect टैब में, डैशबोर्ड बातचीत में इनलाइन रेंडर होते हैं। साइडबार में, वे चैट के बगल में एक पैनल में खुलते हैं।
डैशबोर्ड डेटा केवल उस ब्राउज़र टैब की मेमोरी में रखा जाता है जहां इसे बनाया गया था और इसे चैट के साथ कभी सेव नहीं किया जाता। पेज रीलोड करने, दूसरे टैब में चैट खोलने या कई बड़े डैशबोर्ड बनाने के बाद, पुराने डैशबोर्ड में डेटा के बजाय एक मैसेज दिखता है। Architect से इसे फिर बनाने के लिए कहें। डैशबोर्ड रीड-ओनली स्नैपशॉट्स हैं। इनमें फ़िल्टर्स नहीं होते और ये लाइव अपडेट नहीं होते।
कोड चलाना
Architect अपने टूल्स के डेटा को गिनने, ग्रुप करने और तुलना करने के लिए छोटे Python प्रोग्राम चला सकता है, जैसे कुछ सौ बातचीत में सप्ताह के अनुसार रिज़ॉल्यूशन रेट्स निकालना। कोड केवल Python स्टैंडर्ड लाइब्रेरी के साथ आपके ब्राउज़र के सैंडबॉक्स में चलता है। इसे नेटवर्क एक्सेस, आपके ElevenLabs अकाउंट का एक्सेस नहीं मिलता और इसकी समय सीमा 20 सेकंड है। कोड एक्ज़ीक्यूशन धीरे-धीरे रोल आउट हो रहा है और शायद हर वर्कस्पेस में उपलब्ध न हो।
बड़े रिस्पॉन्स
जब कोई टूल बातचीत में फिट होने से अधिक डेटा लौटाता है, जैसे बातचीत की लंबी लिस्ट, तो Architect पूरा रिस्पॉन्स आपके ब्राउज़र टैब की मेमोरी में रखता है और सारांश के साथ काम करता है। जरूरत पड़ने पर यह बाकी डेटा खोज और पढ़ सकता है। टूल कॉल पर एक नोटिस दिखाता है कि ऐसा कब हुआ। ये रिस्पॉन्स कभी सेव या अपलोड नहीं किए जाते।