बोला गया सारांश — साथ पढ़ने के लिए प्ले दबाएँ: बोली जा रही पंक्ति ऊपर रहती है।
अब जब आप जानते हैं कि सबएजेंट कैसे बनाते हैं, तो आइए उन पैटर्न को देखें जो उन्हें वास्तव में प्रभावी बनाते हैं। एक खराब तरीके से कॉन्फ़िगर किया गया सबएजेंट भटकेगा, बहुत लंबे समय तक चलेगा, या ऐसा आउटपुट देगा जिसे मुख्य एजेंट उपयोग नहीं कर सकता। समाधान चार चीजों पर आते हैं: अच्छे विवरण लिखना, आउटपुट प्रारूप परिभाषित करना, बाधाओं की रिपोर्ट करना, और टूल एक्सेस को सीमित करना।
सबएजेंट कॉन्फ़िग डेटा का उपयोग कैसे होता है
जब आप मुख्य context window एजेंट को एक संदेश भेजते हैं, तो हर उपलब्ध सबएजेंट का नाम और विवरण सिस्टम प्रॉम्प्ट में शामिल होता है। यह है कि मुख्य एजेंट कैसे तय करता है कि कौन सा सबएजेंट लॉन्च करना है और कब। यदि आप यह बेहतर नियंत्रण चाहते हैं कि सबएजेंट कब स्वचालित रूप से ट्रिगर होता है, तो नाम और विवरण वह है जिसे आपको समायोजित करना चाहिए।
विवरण की एक दूसरी भूमिका भी है। जब मुख्य एजेंट एक सबएजेंट लॉन्च करता है, तो यह कार्य को शुरू करने के लिए एक इनपुट प्रॉम्प्ट लिखता है। यह उस प्रॉम्प्ट को लिखने के लिए मार्गदर्शन के रूप में विवरण का उपयोग करता है। तो विवरण केवल यह नियंत्रित नहीं करता कि कब एक सबएजेंट चलता है -- यह आकार देता है सबएजेंट को क्या बताया जाता है।
विवरण लिखना जो इनपुट प्रॉम्प्ट को आकार देता है
एक कोड समीक्षा सबएजेंट पर विचार करें। एक सामान्य विवरण के साथ, मुख्य एजेंट "वर्तमान परिवर्तन खोजने के लिए get diff का उपयोग करें" जैसा एक इनपुट प्रॉम्प्ट लिख सकता है। यह अस्पष्ट है। सबएजेंट को यह पता लगाना होगा कि कौन सी फाइलें अपने आप महत्वपूर्ण हैं।
यदि आप विवरण को "आपको एजेंट को सटीक रूप से बताना चाहिए कि आप इसे कौन सी फाइलों की समीक्षा करना चाहते हैं" जैसी कुछ चीज़ शामिल करने के लिए अपडेट करते हैं, तो मुख्य एजेंट अब एक बहुत अधिक विशिष्ट इनपुट प्रॉम्प्ट लिखेगा जो समीक्षा करने के लिए वास्तविक फाइलों को सूचीबद्ध करता है।
यह समान तकनीक विभिन्न प्रकार के सबएजेंट में काम करती है। उदाहरण के लिए, एक वेब सर्च सबएजेंट के विवरण में "स्रोत लौटाएं जिन्हें उद्धृत किया जा सकता है" जोड़ने से मुख्य एजेंट कार्य को सौंपते समय उस निर्देश को शामिल करेगा।
आउटपुट प्रारूप परिभाषित करना
आप एक सबएजेंट में जो सबसे महत्वपूर्ण सुधार कर सकते हैं वह है इसके सिस्टम प्रॉम्प्ट में एक आउटपुट प्रारूप परिभाषित करना। यह दो काम करता है:
- यह प्राकृतिक रोकने के बिंदु बनाता है -- सबएजेंट जानता है कि यह हो गया है जब इसने प्रारूप के प्रत्येक अनुभाग को भर दिया है।
- यह सबएजेंट को बहुत लंबे समय तक चलने से रोकता है। परिभाषित आउटपुट के बिना, सबएजेंट यह तय करने के लिए संघर्ष करते हैं कि पर्याप्त शोध कब किया गया है और आवश्यकता से अधिक समय तक चलते हैं।
यहाँ एक कोड समीक्षा सबएजेंट के लिए एक संरचित आउटपुट प्रारूप का उदाहरण है:
अपनी समीक्षा एक संरचित प्रारूप में प्रदान करें:
- सारांश: आपने जो समीक्षा की उसका संक्षिप्त अवलोकन और समग्र मूल्यांकन
- महत्वपूर्ण समस्याएं: कोई भी सुरक्षा कमजोरियां, डेटा अखंडता जोखिम,
या तर्क त्रुटियां जिन्हें तुरंत ठीक किया जाना चाहिए
- प्रमुख समस्याएं: गुणवत्ता की समस्याएं, आर्किटेक्चर असंरेखण, या
महत्वपूर्ण प्रदर्शन संबंधी चिंताएं
- मामूली समस्याएं: शैली असंगतियां, दस्तावेज़ीकरण अंतराल, या
मामूली अनुकूलन
- सिफारिशें: सुधार के सुझाव, रीफैक्टरिंग
अवसर, या लागू करने के लिए सर्वोत्तम प्रथाएं
- अनुमोदन स्थिति: स्पष्ट कथन कि क्या कोड विलय/तैनाती के लिए तैयार है
या परिवर्तन की आवश्यकता है
यह प्रारूप सबएजेंट को काम करने के लिए एक स्पष्ट चेकलिस्ट देता है। एक बार जब हर अनुभाग भर जाता है, तो सबएजेंट जानता है कि यह रुक सकता है।
बाधाओं की रिपोर्ट करना
जब एक सबएजेंट अपने काम के दौरान एक समाधान की खोज करता है -- जैसे एक निर्भरता समस्या को हल करना या यह पता लगाना कि एक निश्चित कमांड को विशेष flags की आवश्यकता है -- वे विवरण उस सारांश में दिखाई देने चाहिए जो यह लौटाता है। यदि वे नहीं करते हैं, तो मुख्य thread को समान समाधानों को फिर से खोजना होगा, जो समय और tokens बर्बाद करता है।
आप जिन चीजों को सामने लाना चाहते हैं उनमें शामिल हैं:
- सेटअप समस्याएं या environment विशेषताएं
- कार्य के दौरान खोजे गए समाधान
- कमांड जिन्हें विशेष flags या कॉन्फ़िगरेशन की आवश्यकता थी
- निर्भरताएं या imports जिन्होंने समस्याएं पैदा कीं
यह जानकारी प्राप्त करने का तरीका आउटपुट प्रारूप में इसके लिए स्पष्ट रूप से पूछना है। अपने आउटपुट टेम्पलेट में एक "Obstacles Encountered" अनुभाग जोड़ने से यह जानकारी विश्वसनीय रूप से सामने आती है।
- Obstacles Encountered: समीक्षा प्रक्रिया के दौरान सामने आई किसी भी बाधा की रिपोर्ट करें।
यह हो सकता है: सेटअप समस्याएं, खोजे गए समाधान या environment विशेषताएं। कमांड की रिपोर्ट करें जिन्हें विशेष flag या कॉन्फ़िगरेशन की आवश्यकता थी। निर्भरताओं या imports की रिपोर्ट करें जिन्होंने समस्याएं पैदा कीं।
टूल एक्सेस को सीमित करना
हर सबएजेंट को हर टूल तक पहुंच की आवश्यकता नहीं है। इस बारे में सोचें कि एक सबएजेंट को वास्तव में क्या करना है, और केवल उस काम के लिए आवश्यक टूल दें। यह दो काम करता है: यह अनपेक्षित दुष्प्रभावों को रोकता है, और जब आपके पास कई सबएजेंट हों तो प्रत्येक सबएजेंट की भूमिका को स्पष्ट करता है।
सामान्य सबएजेंट प्रकारों के लिए टूल एक्सेस के बारे में कैसे सोचें:
- Research / read-only सबएजेंट \-- केवल Glob, Grep, और Read की आवश्यकता है। फाइलों को गलती से संशोधित नहीं कर सकता।
- Code reviewer \-- git diff चलाने और देखने के लिए Bash एक्सेस की आवश्यकता है कि क्या बदला गया, लेकिन फिर भी Edit या Write की आवश्यकता नहीं है।
- Styling / code modification एजेंट \-- यह वह जगह है जहां आप Edit और Write एक्सेस देते हैं, क्योंकि सबएजेंट का काम वास्तव में आपके कोड को बदलना है।
सब कुछ एक साथ रखना
प्रभावी सबएजेंट चार विशेषताएं साझा करते हैं:
- विशिष्ट विवरण \-- विवरण नियंत्रित करता है कि सबएजेंट कब लॉन्च होता है और यह कौन से निर्देश प्राप्त करता है। दोनों को स्टीयर करने के लिए इसे लिखें।
- संरचित आउटपुट \-- सिस्टम प्रॉम्प्ट में एक आउटपुट प्रारूप परिभाषित करें ताकि सबएजेंट जानता है कि यह कब हो गया है और मुख्य thread उपयोग कर सकने वाली जानकारी लौटाता है।
- बाधा रिपोर्टिंग \-- आउटपुट प्रारूप में समाधान, विशेषताओं, और समस्याओं के लिए एक अनुभाग शामिल करें ताकि मुख्य thread को उन्हें फिर से खोजना न पड़े।
- सीमित टूल एक्सेस \-- सबएजेंट को केवल वह टूल दें जिसकी उसे वास्तव में आवश्यकता है। research के लिए read-only, reviewers के लिए bash, कोड बदलने वाले एजेंट के लिए edit/write।
इनमें से प्रत्येक पैटर्न अपने आप में सरल है, लेकिन एक साथ वे एक सबएजेंट को कुछ ऐसी चीज़ से बदल देते हैं जो अस्पष्ट रूप से मदद करने की कोशिश करती है एक केंद्रित, अनुमानित कार्यकर्ता में जो समय पर समाप्त होता है और स्पष्ट रूप से वापस रिपोर्ट करता है।