ہر ایجنٹ سسٹم کو ایک ہی مشکل توازن (trade-off) کا سامنا کرنا پڑتا ہے۔ آپ ایک ایسا گہرا اور منظم نالج بیس چاہتے ہیں جو کوڈ ریویو اور گٹ ہسٹری (git history) میں برقرار رہے۔ لیکن آپ کو یہ بھی ضرورت ہے کہ رن ٹائم (runtime) تیز رفتار ہو اور توجہ مرکوز رکھے۔ یہ دونوں ضروریات ایک دوسرے کے خلاف کام کرتی ہیں۔ آپ جتنی زیادہ ہدایات محفوظ کریں گے، ان سب کو پرامپٹ (prompt) میں ڈال کر بہترین نتائج کی امید کرنا اتنا ہی پرکشش ہوتا جائے گا۔ لیکن وہ امید مہنگی پڑتی ہے۔
Agent Project Context کے ایکو سسٹم میں، یہ تناؤ دو تہوں (layers) میں واضح طور پر تقسیم ہو جاتا ہے۔ APC پائیداری (durability) کو سنبھالتا ہے۔ APX رفتار کو سنبھالتا ہے۔ یہ سمجھنا کہ وہ ایک دوسرے کے ساتھ کیسے کام کرتے ہیں—اور کیوں APX ہر اسکل (skill) کی تعریف کو پہلے سے لوڈ (preload) کرنے سے انکار کرتا ہے—آپ کو پرامپٹ انجینئرنگ کے بارے میں ان تمام معلومات سے زیادہ بتا سکتا ہے جو زیادہ تر آپٹیمائزیشن گائیڈز میں ملتی ہیں۔
آرکائیو اور انجن
APC کا کام مستقل مزاجی (permanence) ہے۔ یہ دوبارہ استعمال کے قابل اسکل فائلز کو .apc/skills/ کے تحت سادہ مارک ڈاؤن (Markdown) دستاویزات کے طور پر محفوظ کرتا ہے۔ چونکہ یہ فائلیں آپ کی ریپوزٹری (repository) کے اندر ہوتی ہیں، اس لیے وہ ورژن کنٹرول (version control) کے ساتھ ساتھ چلتی ہیں۔ آپ ایسی پل ریکوسٹ (pull request) کھول سکتے ہیں جو ڈیپلائمنٹ کے طریقہ کار کو تبدیل کر دے۔ آپ چھ ہفتے پہلے کی سیکیورٹی پالیسی کے رول بیک (rollback) کا فرق (diff) دیکھ سکتے ہیں۔ آپ بالکل آڈٹ کر سکتے ہیں کہ ایجنٹ کو کیا جاننا چاہیے تھا اور کب۔ جب کوئی غلط ڈیپلائمنٹ لائیو ہو جائے یا کوئی کمپلائنس آڈیٹر سوالات پوچھنا شروع کر دے، تو یہ ریویو ایبلٹی (reviewability) بہت اہمیت رکھتی ہے۔
دوسری طرف، APX لمحے میں جیتا ہے۔ یہ آپ اور ماڈل کے درمیان ہونے والی اصل گفتگو کو مینیج کرتا ہے۔ اس کا مقصد علم کو آرکائیو کرنا نہیں بلکہ اسے درست طریقے سے استعمال کرنا ہے۔ جب APX اسکلز کو مستقل بوجھ کے طور پر لیتا ہے، تو پورا سسٹم سست ہو جاتا ہے۔ کانٹیکسٹ ونڈو (context window) بھر جاتی ہے۔ ٹوکن کی لاگت بڑھ جاتی ہے۔ اس سے بھی بدتر یہ کہ ماڈل کی توجہ ان ہدایات پر بکھر جاتی ہے جن کا موجودہ درخواست سے کوئی تعلق نہیں ہوتا۔
یہی وجہ ہے کہ اسکل باڈیز (skill bodies) ضرورت پڑنے پر لوڈ ہوتی ہیں۔
ایک ضرورت سے زیادہ بھرے ہوئے پرامپٹ کی اصل قیمت
زیادہ تر ٹیمیں سمجھتی ہیں کہ ٹوکنز کی قیمت ہوتی ہے۔ لیکن بہت کم ٹیمیں اس بات کو سمجھتی ہیں کہ غیر متعلقہ ٹوکنز کی قیمت درستگی (accuracy) کی صورت میں چکانی پڑتی ہے۔
جب APX ہر مرحلے (turn) میں ہر دستیاب اسکل کو شامل کرتا ہے، تو پرامپٹ شور (noisy) سے بھر جاتا ہے۔ ماڈل کو ڈیپلائمنٹ رن بک (runbook)، سیکیورٹی گائیڈ، API اسٹائل ریفرنس، ٹیسٹنگ چیک لسٹ، اور آن بورڈنگ FAQ سب ایک ساتھ مل جاتے ہیں۔ ایک بڑے کانٹیکسٹ ونڈو کے باوجود، جب ماڈل کو سگنل تلاش کرنے کے لیے پہلے شور سے چھان بین کرنی پڑتی ہے، تو اس کے استدلال (reasoning) کا معیار گر جاتا ہے۔ وہ لوکل ٹیسٹ سیٹ اپ کے بارے میں سوال کا جواب دیتے ہوئے پروڈکشن ڈیپلائمنٹ کے لیے بنائی گئی سیکیورٹی ضرورت پر توجہ دے سکتا ہے۔ وہ ایک سادہ بگ فکس (bug fix) میں ریلیز چیک لسٹ کے مراحل کو غلط طور پر شامل (hallucinate) کر سکتا ہے۔ غیر متعلقہ متن کا ہر اضافی پیراگراف ایک توجہ بھٹکانے والا عنصر ہے۔
حساب کتاب سادہ ہے۔ زیادہ تر مراحل میں زیادہ تر اسکلز کی ضرورت نہیں ہوتی۔ اگر آپ ایرر لاگ (error log) کے لیے فوری حل مانگ رہے ہیں، تو آپ کو ڈیپلائمنٹ رن بک یا سیکیورٹی ہارڈننگ گائیڈ کی مکمل تحریر کی ضرورت نہیں ہے۔ آپ کو ضرورت ہے کہ ماڈل ایرر کو دیکھے، آپ کے پروجیکٹ کے طریقہ کار (conventions) کو سمجھے، اور صحیح فائل کو ایڈٹ کرے۔ غیر متعلقہ اسکل باڈیز کو لوڈ کرنا ماڈل کی اس کام میں مدد نہیں کرتا۔ بلکہ یہ ماڈل کو آپ کے اصل مسئلے پر کام شروع کرنے سے پہلے ہی غیر ضروری ڈیٹا کو فلٹر کرنے پر مجبور کرتا ہے۔
آن ڈیمانڈ لوڈنگ کیسے کام کرتی ہے
یہ طریقہ کار سادہ مگر سوچ سمجھ کر بنایا گیا ہے۔ APC اصل حقیقت (ground truth) کو برقرار رکھتا ہے۔ آپ کی اسکل تعریفیں وہیں رہتی ہیں جہاں انہیں ہونا چاہیے: .apc/skills/<name>.md میں۔
APX ان فائلوں کو ایکٹو میموری (active memory) میں کاپی نہیں کرتا۔ اس کے بجائے، یہ اسکل ناموں کی ایک مختصر رجسٹری تیار کرتا ہے۔ ماڈل اس فہرست کو دیکھتا ہے اور سمجھ جاتا ہے کہ ایک کیٹلاگ موجود ہے۔ اگر اسے یہ دیکھنے یا تصدیق کرنے کی ضرورت ہو کہ کون سی صلاحیتیں دستیاب ہیں، تو وہ list_skills کال کر سکتا ہے۔ یہ اسے حجم (volume) بڑھائے بغیر معلومات فراہم کرتا ہے۔
جب کام کے لیے واقعی اسکل فائل میں موجود درست سنٹیکس (syntax)، تفصیلی مراحل، یا مخصوص پابندیوں کی ضرورت ہوتی ہے، تو ماڈل load_skill کو کال کرتا ہے۔ اس وقت، اور صرف اسی وقت، APX، APC سے مکمل مارک ڈاؤن باڈی حاصل کرتا ہے اور اسے کانٹیکسٹ میں شامل کر دیتا ہے۔ ہدایت فوراً دستیاب ہوتی ہے، اسے اس کے مطلوبہ مقصد کے لیے ایک بار استعمال کیا جاتا ہے، اور سسٹم اسے اضافی بوجھ کے طور پر اٹھانے سے بچ جاتا ہے۔
ایک لائبریری کو امپورٹ کرنے اور اپنی مین فائل میں ہر فنکشن کی تعریف پیسٹ کرنے کے درمیان فرق کے بارے میں سوچیں۔ ایک طریقہ آپ کے کوڈ بیس کو قابلِ استعمال (navigable) رکھتا ہے۔ دوسرا ایک ایسا انتشار پیدا کرتا ہے جو صرف اتفاقاً کمپائل ہو جاتا ہے۔
جب اسکلز کا ٹکراؤ ہو تو کون جیتتا ہے
جب APX اسکلز لوڈ کرتا ہے، تو وہ ترجیحات کا ایک واضح نظم و ضبط بھی نافذ کرتا ہے۔ ہر ماحول ایک جیسا نہیں ہوتا، اور عمومی مشورے کو کبھی بھی مقامی معلومات (local knowledge) پر فوقیت نہیں دینی چاہیے۔
پروجیکٹ اسکلز (Project skills) کو اولین ترجیح حاصل ہے۔ یہ فائلیں آپ کی موجودہ ریپوزٹری میں .apc/skills/ کے تحت موجود ہوتی ہیں۔ یہ آپ کی ٹیم کے مخصوص طریقہ کار (conventions)، آپ کے کسٹم ریپرز (custom wrappers)، آپ کے پرانے نام رکھنے کے معیار (legacy naming standards)، اور آپ کے مخصوص ٹول چین (toolchain) کو محفوظ کرتی ہیں۔ اگر آپ کا پروجیکٹ ڈیٹا بیس مائیگریشن (database migrations) کو سنبھالنے کا اپنا طریقہ طے کرتا ہے، تو وہی طریقہ کار مانا جائے گا۔
اس کے بعد گلوبل اسکلز (Global skills) آتی ہیں۔ یہ تنظیم بھر کے ایسے پیٹرنز (patterns) پر مشتمل ہوتی ہیں جو اس وقت لاگو ہوتے ہیں جب پروجیکٹ خود کوئی وضاحت نہ کرے۔ یہ ایک اسٹینڈرڈ لائبریری کے طور پر کام کرتی ہیں۔
بلٹ ان رن ٹائم اسکلز (Built-in runtime skills) سب سے آخر میں بطور متبادل (fallback) ہوتی ہیں۔ یہ ان عمومی صلاحیتوں کو سنبھالتی ہیں جنہیں ہر ایجنٹ کو سمجھنا چاہیے لیکن کسی مخصوص پروجیکٹ نے انہیں دوبارہ سے بیان کرنے کی ضرورت محسوس نہیں کی۔
اس درجہ بندی والے طریقہ کار کا مطلب یہ ہے کہ آپ کی ریپوزٹری اپنے طرزِ عمل پر مکمل کنٹرول رکھتی ہے۔ کوئی گلوبل یا بلٹ ان اسکل غلطی سے اس ورک فلو (workflow) پر قبضہ نہیں کر سکتی جسے آپ کی ٹیم نے جان بوجھ کر اپنی ضرورت کے مطابق ڈھالا ہو۔
عملی طور پر یہ کیسا نظر آتا ہے
ایک عام مینٹیننس ٹاسک کا تصور کریں۔ ایک ساتھی چیٹ میں ایرر لاگ (error log) پیسٹ کرتا ہے۔ ٹریس بیک (traceback) ایک یوٹیلٹی ماڈیول میں ایک سنگل 'null reference' کی طرف اشارہ کرتا ہے۔ اس کا حل غالباً ڈیفنسو کوڈنگ (defensive coding) کی دو لائنیں ہیں۔
آن ڈیمانڈ لوڈنگ (on-demand loading) کے بغیر کسی سسٹم میں، APX سیاق و سباق (context) کو ان تمام اسکلز سے بھر دے گا جنہیں وہ جانتا ہے۔ اب ماڈل کے پاس ان دو لائنوں پر کام کرنے سے پہلے چالیس صفحات کا متن ہوتا ہے جس پر اسے غور کرنا پڑتا ہے۔ وہ ریلیز چیک لسٹ (release checklist) دیکھتا ہے اور سوچتا ہے کہ کیا اسے ورژن بڑھانا چاہیے؟ وہ سیکیورٹی گائیڈ دیکھتا ہے اور اس فنکشن پر ان پٹ ویلیڈیشن (input validation) کے بارے میں سوچنے لگتا ہے جسے صرف ایک 'null check' کی ضرورت ہے۔ وہ ڈیپلائمنٹ رن بک (deployment runbook) دیکھتا ہے اور اسٹیجنگ انوائرمنٹس (staging environments) کے بارے میں سوچنا شروع کر دیتا ہے۔ ماڈل کا دھیان بھٹک جاتا ہے۔ جواب دینے میں زیادہ وقت لگتا ہے۔ ٹوکن میٹر (token meter) تیزی سے گھومنے لگتا ہے۔
APX کے آن ڈیمانڈ ڈیزائن کے ساتھ، ماڈل صرف نام دیکھتا ہے۔ وہ جانتا ہے کہ [release-checklist], [security-guide], [deployment-runbook], اور [error-handling] موجود ہیں۔ وہ پہلے تینوں کو نظر انداز کر دیتا ہے۔ اگر آپ کے پروجیکٹ کے 'null safety' کے طریقہ کار مخصوص ہیں، تو وہ شاید [error-handling] کو لوڈ کر لے۔ وہ بگ (bug) کو ٹھیک کر دیتا ہے۔ غیر متعلقہ اسکلز کبھی بھی کانٹیکسٹ ونڈو (context window) میں شامل ہی نہیں ہوئیں۔ ماڈل پر توجہ برقرار رہی کیونکہ پرامپٹ (prompt) صاف ستھرا رہا۔
یہی منطق اس وقت بھی لاگو ہوتی ہے جب کام واقعی پیچیدہ ہو۔ اگر آپ بعد میں ایجنٹ سے پروڈکشن ڈیپلائمنٹ (production deployment) تیار کرنے کو کہتے ہیں، تو وہ ڈیپلائمنٹ رن بک لوڈ کر سکتا ہے، سیکیورٹی گائیڈ سے مشورہ کر سکتا ہے، اور ریلیز چیک لسٹ پر بالکل اسی وقت عمل کر سکتا ہے جب وہ اقدامات متعلقہ ہو جائیں۔ علم ہمیشہ وہیں موجود تھا۔ وہ صرف صحیح لمحے کا انتظار کر رہا تھا۔
آرکیٹیکچر کے طور پر پرامپٹ ڈسپلن
APC اور APX کے درمیان علیحدگی محض ایک تکنیکی تفصیل نہیں ہے۔ یہ پرامپٹ ڈسپلن کا ایک فلسفہ ہے۔ APC علم کو ہمیشہ کے لیے محفوظ رکھتا ہے، جس سے اسے نظرثانی کے قابل، ورژن کے مطابق، اور محفوظ بنایا جاتا ہے۔ APX فیصلہ کرتا ہے کہ اس علم کا کتنا حصہ اس وقت ایکٹو کانٹیکسٹ (active context) میں جگہ کا مستحق ہے۔
اسکلز کا ایک بھرپور کیٹلاگ ایک اثاثہ ہے۔ ایک ضرورت سے زیادہ بھرا ہوا (bloated) پرامپٹ ایک بوجھ ہے۔ مقصد یہ ہے کہ آپ کے کانٹیکسٹ کو ہمیشہ ایکٹو رکھے بغیر اسے پورٹیبل (portable) رکھا جائے۔ آپ کی ریپوزٹری میں وہ ہر ہدایت ہونی چاہیے جو آپ کی ٹیم نے کبھی لکھی ہو، لیکن ایجنٹ کو صرف وہی پڑھنی چاہیے جو فوری کام میں مددگار ہو۔
اگر آپ کا سسٹم ماڈل کو ہر بار تمام اسکلز کے مکمل متن کو ساتھ لے جانے پر مجبور کرتا ہے، تو آپ ایک ذہین اسسٹنٹ نہیں بنا رہے ہیں۔ آپ ایک ایسا لائبریرین بنا رہے ہیں جو ہر سوال کے لیے پورے آرکائیو کو گھسیٹ کر لاتا ہے۔ سب کچھ محفوظ کریں۔ صرف وہی لوڈ کریں جو اہم ہے۔ اسی طرح آپ ایجنٹس کو تیز، کانٹیکسٹ کو صاف، اور استدلال (reasoning) کو تیز تر رکھ سکتے ہیں۔