प्रत्येक एजंट सिस्टमला एकाच प्रकारच्या कठीण तडजोडीचा सामना करावा लागतो. तुम्हाला एक सखोल आणि सुव्यवस्थित नॉलेज बेस हवा असतो जो

प्रत्येक एजंट सिस्टमला एकाच प्रकारच्या कठीण तडजोडीचा (trade-off) सामना करावा लागतो. तुम्हाला एक सखोल, सुव्यवस्थित ज्ञानकोश (knowledge base) हवा असतो जो कोड रिव्ह्यू आणि गिट हिस्ट्रीमध्ये टिकून राहील. पण तुम्हाला रनटाइम वेगाने चालण्यासाठी आणि लक्ष केंद्रित करण्यासाठी देखील आवश्यक असतो. या दोन गरजा एकमेकांच्या विरोधात काम करतात. तुम्ही जितक्या जास्त सूचना जतन कराल, तितकेच त्या सर्व प्रॉम्प्टमध्ये टाकून 'सर्व काही ठीक होईल' अशी आशा करणे मोहक वाटते. पण ती आशा महाग पडते.

Agent Project Context इकोसिस्टममध्ये, हा तणाव दोन थरांमध्ये स्पष्टपणे विभागला गेला आहे. APC टिकाऊपणा (durability) हाताळते. APX वेग (speed) हाताळते. ते एकमेकांशी कसे संवाद साधतात—आणि APX प्रत्येक स्किल डेफिनेशन प्रीलोड करण्यास नकार का देते—हे समजून घेतल्यास तुम्हाला प्रॉम्प्ट इंजिनिअरिंगबद्दल बहुतांश ऑप्टिमायझेशन गाईड्सपेक्षा अधिक माहिती मिळेल.

आर्काइव्ह आणि इंजिन

APC चे काम कायमस्वरूपी अस्तित्व टिकवून ठेवणे हे आहे. ते पुन्हा वापरण्यायोग्य स्किल फाइल्स .apc/skills/ अंतर्गत साध्या Markdown दस्तऐवजांच्या स्वरूपात साठवते. या फाइल्स तुमच्या रिपॉझिटरीमध्ये असल्याने, त्या व्हर्जन कंट्रोलसोबत राहतात. तुम्ही डिप्लॉयमेंट प्रक्रिया बदलणारी पुल रिक्वेस्ट (pull request) काढू शकता. तुम्ही सहा आठवड्यांपूर्वीचा सिक्युरिटी पॉलिसी रोलबॅक 'डिफ' (diff) करू शकता. एजंटला नेमके काय माहित असणे अपेक्षित होते आणि कधी, याचे तुम्ही ऑडिट करू शकता. जेव्हा एखादे चुकीचे डिप्लॉयमेंट लाईव्ह होते किंवा एखादा कंप्लायन्स ऑडिटर प्रश्न विचारू लागतो, तेव्हा ही रिव्ह्यूक्षमता महत्त्वाची ठरते.

दुसरीकडे, APX वर्तमानातील क्षणांवर काम करते. ते तुमच्या आणि मॉडेलमधील प्रत्यक्ष संवादाचे व्यवस्थापन करते. त्याचे ध्येय ज्ञान आर्काइव्ह करणे नसून त्याचा अचूक वापर करणे हे आहे. जेव्हा APX स्किल्सना कायमस्वरूपी ओझे म्हणून हाताळते, तेव्हा संपूर्ण सिस्टमचा वेग मंदावतो. कॉन्टेक्स्ट विंडो भरून जाते. टोकनचा खर्च वाढतो. त्याहून वाईट म्हणजे, मॉडेलचे लक्ष अशा सूचनांकडे विखुरते ज्याचा सध्याच्या विनंतीशी काहीही संबंध नसतो.

म्हणूनच skill bodies 'ऑन डिमांड' लोड केल्या जातात.

फुगलेल्या (Bloated) प्रॉम्प्टचा खरा खर्च

बहुतेक टीम्सना समजते की टोकन्ससाठी पैसे द्यावे लागतात. पण कमीच टीम्सना हे समजते की अनावश्यक टोकन्समुळे अचूकतेवर (accuracy) परिणाम होतो.

जेव्हा APX प्रत्येक टर्नमध्ये उपलब्ध असलेले प्रत्येक स्किल समाविष्ट करते, तेव्हा प्रॉम्प्ट गोंधळलेला (noisy) होतो. मॉडेलला डिप्लॉयमेंट रनबुक, सिक्युरिटी गाईड, API स्टाईल रेफरन्स, टेस्टिंग चेकलिस्ट आणि ऑनबोर्डिंग FAQ हे सर्व एकाच वेळी मिळते. मोठ्या कॉन्टेक्स्ट विंडो असूनही, जेव्हा मॉडेलला सिग्नल शोधण्यासाठी आधी गोंधळातून (noise) माहिती गाळून घ्यावी लागते, तेव्हा तर्क करण्याची गुणवत्ता (reasoning quality) कमी होते. स्थानिक टेस्ट सेटअपबद्दल प्रश्न विचारताना मॉडेल चुकून प्रोडक्शन डिप्लॉयमेंटसाठी असलेल्या सिक्युरिटी आवश्यकतेवर लक्ष केंद्रित करू शकते. एखाद्या साध्या बग फिक्समध्ये ते रिलीज चेकलिस्टमधील पायऱ्या हॅल्युसिनेट (hallucinate) करू शकते. असंबद्ध मजकुराचा प्रत्येक अतिरिक्त परिच्छेद हा एक संभाव्य अडथळा असतो.

याचे गणित अगदी सोपे आहे. बहुतेक टर्न्सना बहुतेक स्किल्सची गरज नसते. जर तुम्ही एरर लॉगमधील त्वरित सुधारासाठी विचारत असाल, तर तुम्हाला डिप्लॉयमेंट रनबुक किंवा सिक्युरिटी हार्डनिंग गाईडचा पूर्ण मजकूर नको असतो. तुम्हाला मॉडेलने एरर पाहावा, तुमच्या प्रोजेक्ट कन्व्हेंशन्स समजून घ्यावेत आणि योग्य फाईल एडिट करावी अशी अपेक्षा असते. असंबद्ध skill bodies लोड केल्याने मॉडेलला हे करण्यास मदत होत नाही. उलट, यामुळे मॉडेलला तुमच्या वास्तविक समस्येवर काम सुरू करण्यापूर्वीच निरुपयोगी डेटा फिल्टर करण्यास भाग पाडले जाते.

ऑन-डिमांड लोडिंग कसे कार्य करते

ही यंत्रणा साधी पण हेतुपुरस्सर आहे. APC मूळ सत्य माहिती (ground truth) जतन ठेवते. तुमच्या स्किल डेफिनिशन्स त्यांच्या योग्य ठिकाणी राहतात: .apc/skills/<name>.md मध्ये.

APX त्या फाइल्स ॲक्टिव्ह मेमरीमध्ये कॉपी (mirror) करत नाही. त्याऐवजी, ते स्किल नावांची एक संक्षिप्त रजिस्ट्री (compact registry) तयार करते. मॉडेलला ही यादी दिसते आणि त्याला समजते की एक कॅटलॉग अस्तित्वात आहे. जर त्याला उपलब्ध क्षमता शोधायच्या असतील किंवा खात्री करायची असेल, तर ते list_skills कॉल करू शकते. यामुळे मोठ्या डेटाशिवाय दृश्यमानता (visibility) मिळते.

जेव्हा कार्याला खरोखर अचूक सिंटॅक्स, तपशीलवार पायऱ्या किंवा स्किल फाईलमध्ये एनकोड केलेल्या विशिष्ट अटींची (constraints) आवश्यकता असते, तेव्हा मॉडेल load_skill कॉल करते. त्या वेळी, आणि केवळ त्याच वेळी, APX कडून APC मधून पूर्ण Markdown बॉडी मिळवली जाते आणि ती कॉन्टेक्स्टमध्ये समाविष्ट केली जाते. सूचना त्वरित (hot) उपलब्ध होते, तिचा वापर केवळ तिच्या अपेक्षित उद्देशासाठी एकदा केला जातो आणि सिस्टमला ती अनावश्यक ओझे म्हणून वाहून नेण्यापासून वाचवले जाते.

एका लायब्ररीला इम्पोर्ट करणे आणि प्रत्येक फंक्शन डेफिनेशन तुमच्या मुख्य फाईलमध्ये पेस्ट करणे यातील फरकाचा विचार करा. एक पद्धत तुमचा कोडबेस सुलभ (navigable) ठेवते. दुसरी पद्धत असा गोंधळ निर्माण करते जो केवळ योगायोगाने चालतो.

जेव्हा स्किल्समध्ये संघर्ष होतो तेव्हा कोण जिंकते

जेव्हा APX स्किल्स लोड करते, तेव्हा ते एक स्पष्ट प्राधान्य क्रम (priority order) देखील लागू करते. प्रत्येक वातावरण (environment) सारखे नसते आणि सामान्य सल्ला (generic advice) कधीही स्थानिक माहितीला (local knowledge) मागे टाकणारा नसावा.

प्रोजेक्ट स्किल्सना सर्वोच्च प्राधान्य दिले जाते. ही फाईल्स तुमच्या सध्याच्या रिपॉझिटरीमध्ये .apc/skills/ अंतर्गत असतात. त्या तुमच्या टीमच्या विशिष्ट पद्धती, तुमचे कस्टम रॅपर्स, तुमचे लेगसी नेमिंग स्टँडर्ड्स आणि तुमचे विशिष्ट टूलचैन कॅप्चर करतात. जर तुमच्या प्रोजेक्टने डेटाबेस मायग्रेशन्स हाताळण्याची स्वतःची पद्धत परिभाषित केली असेल, तर तीच पद्धत ग्राह्य धरली जाते.

त्यानंतर ग्लोबल स्किल्स येतात. जेव्हा प्रोजेक्ट स्वतः काही माहिती देत नाही, तेव्हा या स्किल्स संस्था-व्यापी पॅटर्न लागू करतात. त्या स्टँडर्ड लायब्ररीप्रमाणे काम करतात.

बिल्ट-इन रनटाइम स्किल्स सर्वात खाली फॉलबॅक म्हणून असतात. त्या अशा सामान्य क्षमता हाताळतात ज्या प्रत्येक एजंटला समजल्या पाहिजेत, परंतु कोणत्याही विशिष्ट प्रोजेक्टने त्या पुन्हा परिभाषित करण्याची गरज मानली नाही.

या स्तरित दृष्टिकोनाचा अर्थ असा आहे की तुमची रिपॉझिटरी स्वतःच्या वर्तनावर नियंत्रण ठेवते. एखादी ग्लोबल किंवा बिल्ट-इन स्किल चुकून अशा वर्कफ्लोमध्ये हस्तक्षेप करू शकत नाही जो तुमच्या टीमने हेतुपूर्वक कस्टमाइझ केला आहे.

प्रत्यक्ष वापरात हे कसे दिसते

एका सामान्य मेंटेनन्स टास्कची कल्पना करा. एखादा टीममेट चॅटमध्ये एरर लॉग पेस्ट करतो. ट्रेसबॅक एका युटिलिटी मॉड्यूलमधील सिंगल नल्ल रेफरन्सकडे निर्देश करतो. याचे निराकरण बहुधा दोन ओळींच्या डिफेन्सिव्ह कोडिंगने होऊ शकते.

ऑन-डिमांड लोडिंग नसलेल्या सिस्टममध्ये, APX त्याच्या माहित असलेल्या प्रत्येक स्किलने कॉन्टेक्स्ट भरून टाकेल. आता मॉडेलला त्या दोन ओळींवर काम करण्यापूर्वी चाळीस पानांचा मजकूर विचारात घ्यावा लागेल. ते रिलीज चेकलिस्ट पाहते आणि व्हर्जन वाढवायचे का याचा विचार करते. ते सिक्युरिटी गाईड पाहते आणि ज्या फंक्शनला फक्त नल्ल चेकची गरज आहे, त्यावर इनपुट व्हॅलिडेशन करण्याबाबत विचार करते. ते डिप्लॉयमेंट रनबुक पाहते आणि स्टेजिंग एन्व्हायरनमेंट्सबद्दल विचार करू लागते. मॉडेल भरकटते. प्रतिसाद मिळण्यास वेळ लागतो. टोकन मीटर वेगाने वाढतो.

APX च्या ऑन-डिमांड डिझाइनमुळे, मॉडेलला फक्त नावे दिसतात. त्याला माहित असते की [release-checklist], [security-guide], [deployment-runbook], आणि [error-handling] अस्तित्वात आहेत. ते पहिल्या तीन गोष्टींकडे दुर्लक्ष करते. जर तुमच्या प्रोजेक्टचे नल्ल सेफ्टीसाठीचे नियम विशिष्ट असतील, तर ते [error-handling] लोड करू शकते. ते बग फिक्स करते. असं संबंधित नसलेले स्किल्स कॉन्टेक्स्ट विंडोमध्ये कधीच आले नाहीत. प्रॉम्प्ट स्वच्छ राहिल्यामुळे मॉडेल लक्ष केंद्रित करू शकले.

जेव्हा कार्य खरोखर जटिल असते, तेव्हाही हेच तर्क लागू होते. जर तुम्ही नंतर एजंटला प्रोडक्शन डिप्लॉयमेंट तयार करण्यास सांगितले, तर ते डिप्लॉयमेंट रनबुक लोड करू शकते, सिक्युरिटी गाईडचा सल्ला घेऊ शकते आणि जेव्हा त्या पायऱ्या सुसंगत होतील तेव्हाच रिलीज चेकलिस्टचे पालन करू शकते. ज्ञान नेहमीच तिथे होते. ते फक्त योग्य क्षणाची वाट पाहत होते.

आर्किटेक्चर म्हणून प्रॉम्प्ट डिसिप्लिन

APC आणि APX मधील फरक केवळ एक इम्प्लिमेंटेशन डिटेल नाही. ते प्रॉम्प्ट डिसिप्लिनचे एक तत्त्वज्ञान आहे. APC ज्ञानाचे कायमस्वरूपी जतन करते, ज्यामुळे ते रिव्ह्यू करण्यायोग्य, व्हर्जन केलेले आणि सुरक्षित राहते. APX त्यापैकी किती ज्ञान सध्याच्या ॲक्टिव्ह कॉन्टेक्स्टमध्ये स्थान मिळवू शकते हे ठरवते.

एक समृद्ध स्किल कॅटलॉग ही एक मालमत्ता आहे. अनावश्यक माहिती असलेला (bloated) प्रॉम्प्ट हे एक ओझे आहे. तुमचे कॉन्टेक्स्ट नेहमी ॲक्टिव्ह न ठेवता ते पोर्टेबल ठेवणे हे ध्येय आहे. तुमच्या रिपॉझिटरीमध्ये तुमच्या टीमने लिहिलेली प्रत्येक सूचना असायला हवी, परंतु एजंटने फक्त त्या सूचना वाचल्या पाहिजेत ज्या तात्काळ कामात मदत करतात.

जर तुमची सिस्टम मॉडेलला प्रत्येक वेळी प्रत्येक स्किलचा संपूर्ण मजकूर सोबत नेण्यास भाग पाडत असेल, तर तुम्ही बुद्धिमान सहाय्यक तयार करत नाही आहात. तुम्ही असा ग्रंथपाल तयार करत आहात जो प्रत्येक संदर्भाच्या प्रश्नासाठी संपूर्ण आर्काइव्ह ओढून आणतो. सर्व काही साठवा. जे महत्त्वाचे आहे तेच लोड करा. अशा प्रकारे तुम्ही एजंट्सना वेगवान, कॉन्टेक्स्ट स्वच्छ आणि तर्कशक्ती तीक्ष्ण ठेवू शकता.