2,465 عوامی سطح پر فہرست شدہ AI-agent "skills" کے ایک تازہ آڈٹ سے معلوم ہوا ہے کہ نصف سے زیادہ اشاعت کردہ تفصیلات (specifications) کی خلاف ورزی کرتی ہیں، اور 7.8 فیصد کو تو ایجنٹ منتخب بھی نہیں کر سکتا کیونکہ ان میں مطلوبہ میٹا ڈیٹا (metadata) کی کمی ہے۔ یہ نقائص کسی بھی ایسے نظام کی بھروسہ مندی کے لیے خطرہ ہیں جو خودکار طریقے سے ان skills کو تلاش کرتا ہے اور لوڈ کرتا ہے۔
یہ آڈٹ کیوں اہم ہے
ایجنٹ-skill رجسٹرز ڈویلپرز کو دوبارہ استعمال کے قابل صلاحیتیں (reusable capabilities) شائع کرنے کی اجازت دیتے ہیں—یعنی کوڈ پیکجز جنہیں ایک خود مختار ایجنٹ ضرورت پڑنے پر استعمال کر سکتا ہے۔ ایک ایجنٹ رجسٹر کو اسکین کرتا ہے، ہر skill کے YAML frontmatter (ایک چھوٹا سا منظم متن کا بلاک جس میں کم از کم ایک نام اور تفصیل ہونی چاہیے) کو پڑھتا ہے، اور فیصلہ کرتا ہے کہ آیا skill اس کے اہداف کے مطابق ہے یا نہیں۔ اگر frontmatter موجود نہ ہو یا غلط طریقے سے لکھا گیا ہو، تو skill ایجنٹ کے مینو سے غائب ہو جاتی ہے۔ ایک ایسی دنیا میں جہاں خود مختار ایجنٹ میٹنگز شیڈول کرتے ہیں، سرورز کی خرابیوں کو دور کرتے ہیں، اور بہت کچھ کرتے ہیں، ایک خراب skill پورے ورک فلو کو تباہ کر دیتی ہے۔
اعداد و شمار کیا ظاہر کرتے ہیں
- 57.8% skills میں کم از کم ایک spec کی خلاف ورزی پائی گئی ہے۔
- 29.2% میں ایسا نام درج ہے جو registry slug (URL شناختی کوڈ) سے مطابقت نہیں رکھتا۔
- 18.1% میں خراب پیکج پاتھ یا ڈیڈ لنکس (dead links) شامل ہیں۔
- 7.8% (192 skills) میں کوئی YAML frontmatter ہی نہیں ہے، جس کی وجہ سے وہ بے نام اور بغیر تفصیل کے رہ جاتی ہیں۔
- 3.8% میں ایسے absolute file paths شامل ہیں جو صرف مصنف کے کمپیوٹر پر موجود ہیں۔
- 2.4%
allowed-toolsفیلڈ کا غلط استعمال کرتے ہیں، جس سے ایجنٹس کے لیے انہیں پڑھنا ناممکن ہو جاتا ہے۔ - 2.1% انوائرمنٹ ویری ایبلز (environment variables) کے ذریعے API keys ظاہر کرتے ہیں، جو کہ سیکیورٹی کے لحاظ سے ایک بڑا خطرہ ہے۔
- 1.3% بیرونی کمانڈ لائن ٹولز کو ظاہر کیے بغیر استعمال کرتے ہیں، جو پورٹیبلٹی کے اصول کی خلاف ورزی ہے۔
پورٹیبلٹی کا مسئلہ سب سے زیادہ سامنے آتا ہے۔ ایک absolute path جیسے کہ /home/USER/.local/bin/tool اس ڈویلپر کے لیے تو کام کرتا ہے جس نے skill لکھی ہے، لیکن دوسرے تمام صارفین کے لیے ناکام ہو جاتا ہے، جس سے runtime errors پیدا ہوتے ہیں جنہیں static checks کبھی نہیں پکڑ پاتے۔
گہرائی سے جائزہ: openclaw کا کیس
آڈٹ میں openclaw ریپوزٹری میں موجود 46 skills کا بھی جائزہ لیا گیا۔ غلط وارننگز کو روکنے کے لیے ٹیسٹنگ اسکرپٹ کو بہتر بنانے کے بعد، ریویو نے 59 حقیقی نقائص دریافت کیے—جو اس بات کی یاد دہانی ہے کہ حد سے زیادہ جارحانہ linters الٹا اثر بھی کر سکتے ہیں۔ جب کوئی ٹول بہت زیادہ بے ضرر مسائل کی نشاندہی کرتا ہے، تو ڈویلپرز اسے استعمال کرنا چھوڑ دیتے ہیں، اور اصل مسائل نظر انداز ہو جاتے ہیں۔
openclaw کے دو نقائص ایسے تھے جو ان فائلوں کی طرف اشارہ کر رہے تھے جو اب ریپوزٹری میں موجود نہیں تھیں۔ مینٹینر نے ایک ایسا فکس (fix) شامل کیا جس سے گمشدہ حوالے بحال ہو گئے، جو یہ ظاہر کرتا ہے کہ کس طرح ایک واحد pull request ایک خراب ڈیپینڈنسی چین (dependency chain) کو درست کر سکتی ہے۔
ڈویلپرز کے ردعمل
آڈیٹر نے اصل skill ریپوزٹریز پر issues کھولے۔ ایک رپورٹ مسترد کر دی گئی؛ مینٹینر کا استدلال تھا کہ "خراب" کا فیصلہ اصل runtime رویے سے ہونا چاہیے، نہ کہ static file inspection سے۔ آڈیٹر اس بات سے متفق ہوا کہ "خراب" ہونے کی ایک سخت تعریف ایسی ہونی چاہیے جو اس بات کے مطابق ہو کہ skill عملی طور پر کیسے کام کرتی ہے۔ ایک اور issue قبول کر لیا گیا، اور اس کا متعلقہ فکس اب لائیو ہے۔
کس کا فائدہ ہوگا—یا نقصان
- ایجنٹس اور اینڈ یوزرز کو اس وقت زیادہ ہموار اور قابل پیش گوئی رویہ ملتا ہے جب رجسٹر میں صرف تعمیل کرنے والی اور پورٹیبل skills موجود ہوں۔
- Skill مصنفین کو واضح تصدیقی اصول (validation rules) ملتے ہیں جو اشاعت سے پہلے غلطیوں کو پکڑ لیتے ہیں، جس سے issue triage کے لیے بار بار کی محنت کم ہو جاتی ہے۔
- Registry آپریٹرز کو سخت تر validation pipelines بنانی ہوں گی یا انہیں شامل کرنا ہوگا؛ ان کے بغیر، پورے ایکوسسٹم کے اعتماد کے ختم ہونے کا خطرہ ہے۔
کمزور validation "جلدی اور ناقص" (quick-and-dirty) سبمیشنز کی حوصلہ افزائی کرتی ہے جو پروڈکشن میں ایجنٹس کو خراب کر سکتی ہیں، جس سے مہنگا ڈاؤن ٹائم یا سیکیورٹی کے خطرات پیدا ہو سکتے ہیں۔
دوسرا پہلو: کیا تمام خلاف ورزیاں سنگین ہیں؟
کچھ لوگوں کا کہنا ہے کہ کچھ "غلطیاں" بے ضرر ہوتی ہیں۔ ایک نام کا ملا نہ ہونا اس ایجنٹ پر اثر انداز نہیں ہو سکتا جو skills کو دکھائے گئے نام کے بجائے slug کے ذریعے منتخب کرتا ہے۔ لوکل ڈویلپمنٹ کے لیے انوائرمنٹ سے API keys پڑھنا ایک دانستہ ڈیزائن انتخاب ہو سکتا ہے۔ تاہم، آڈٹ کے فیصد کسی بھی قسم کے انحراف کو خلاف ورزی کے طور پر دیکھتے ہیں، جو کچھ مسائل کے عملی اثر کو بڑھا چڑھا کر پیش کر سکتا ہے۔
آگے کیا نظر آئے گا
- بہتر linters جو حقیقی پورٹیبلٹی بگ اور معمولی خرابیوں کے درمیان فرق کر سکیں۔
- Registry-side validation hooks جو مطلوبہ frontmatter نہ ہونے والی یا absolute paths والی سبمیشنز کو مسترد کر دیں۔
- کمیونٹی کے ذریعے کیے جانے والے آڈٹ جو پروڈکشن ایجنٹس تک پہنچنے سے پہلے چھپے ہوئے نقائص کو سامنے لائیں۔
- ممکنہ spec میں تبدیلیاں جو
allowed-toolsجیسے مبہم فیلڈز کو واضح کریں اور انوائرمنٹ ویری ایبلز کے قابل قبول استعمال کی وضاحت کریں۔
ٹولنگ کی اگلی لہر ممکنہ طور پر ان چیکس کو continuous-integration pipelines میں شامل کر دے گی، جس سے تعمیل (compliance) کو ایک دستی کام کے بجائے ایک خودکار گیٹ (automatic gate) بنا دیا جائے گا۔
خلاصہ
عوامی سطح پر فہرست بند کردہ AI-agent مہارتوں کی اکثریت بنیادی تعمیل (compliance) کے چیک پاس کرنے میں ناکام رہتی ہے، اور ایک بڑا حصہ ایسا ہے جسے بالکل بھی منتخب نہیں کیا جا سکتا۔ یہ نتائج سخت ترین تصدیق (validation)، بہتر لنٹنگ ٹولز (linting tools)، اور ایک ایسی کمیونٹی کلچر کی واضح ضرورت کو اجاگر کرتے ہیں جو سپیک (spec) کی پاسداری کو اشاعت کے لیے ایک لازمی شرط کے طور پر سمجھے۔ جب تک یہ حفاظتی اقدامات وضع نہیں کر لیے جاتے، ایجنٹس کمزور اور غیر پورٹیبل (non-portable) مہارتوں کی وجہ سے ٹھوکریں کھاتے رہیں گے۔