২,৪৬৫টি পাবলিকলি লিস্টেড AI-এজেন্ট "skills"-এর একটি সাম্প্রতিক অডিটে দেখা গেছে যে অর্ধেকেরও বেশি নির্ধারিত স্পেসিফিকেশন লঙ্ঘন করে, এবং ৭.৮ শতাংশ স্কিল এমনকি কোনো এজেন্ট দ্বারা নির্বাচিতও হতে পারে না কারণ সেগুলোতে প্রয়োজনীয় মেটাডেটা নেই। এই ত্রুটিগুলো এমন যেকোনো সিস্টেমের নির্ভরযোগ্যতাকে হুমকির মুখে ফেলছে যা স্বয়ংক্রিয়ভাবে এই স্কিলগুলো খুঁজে বের করে এবং লোড করে।
কেন এই অডিটটি গুরুত্বপূর্ণ
এজেন্ট-স্কিল রেজিস্ট্রি ডেভেলপারদের পুনরায় ব্যবহারযোগ্য সক্ষমতা (reusable capabilities) প্রকাশ করতে দেয়—এগুলো হলো কোড প্যাকেজ যা একটি স্বায়ত্তশাসিত এজেন্ট (autonomous agent) প্রয়োজনে ব্যবহার করতে পারে। একটি এজেন্ট রেজিস্ট্রি স্ক্যান করে, প্রতিটি স্কিলের YAML frontmatter (একটি ছোট স্ট্রাকচার্ড টেক্সট ব্লক যাতে অন্তত একটি নাম এবং একটি বিবরণ থাকতে হয়) পড়ে এবং সিদ্ধান্ত নেয় যে স্কিলটি তার লক্ষ্যের সাথে সামঞ্জস্যপূর্ণ কি না। যদি frontmatter অনুপস্থিত থাকে বা ভুলভাবে লেখা থাকে, তবে স্কিলটি এজেন্টের মেনু থেকে হারিয়ে যায়। এমন একটি বিশ্বে যেখানে স্বায়ত্তশাসিত এজেন্টরা মিটিং শিডিউল করা, সার্ভার ট্রাবলশুটিং করা এবং আরও অনেক কাজ করে, সেখানে একটি ত্রুটিপূর্ণ স্কিল পুরো কাজের ধারা (workflow) নষ্ট করে দিতে পারে।
সংখ্যাগুলো কী প্রকাশ করে
- ৫৭.৮% স্কিলের অন্তত একটি স্পেক ভায়োলেশন (spec violation) রয়েছে।
- ২৯.২% এমন নাম তালিকাভুক্ত করে যা রেজিস্ট্রি slug (URL আইডেন্টিফায়ার)-এর সাথে মেলে না।
- ১৮.১% ত্রুটিপূর্ণ প্যাকেজ পাথ বা ডেড লিঙ্ক ধারণ করে।
- ৭.৮% (১৯২টি স্কিল)-এ কোনো YAML frontmatter নেই, ফলে সেগুলো নামহীন এবং বিবরণহীন থেকে যায়।
- ৩.৮% এমন অ্যাবসোলিউট ফাইল পাথ (absolute file paths) ব্যবহার করে যা শুধুমাত্র লেখকের মেশিনে বিদ্যমান।
- ২.৪%
allowed-toolsফিল্ডটি ভুলভাবে ব্যবহার করে, যার ফলে এজেন্টগুলো এটি পড়তে পারে না। - ২.১% এনভায়রনমেন্ট ভেরিয়েবলের মাধ্যমে API key প্রকাশ করে, যা একটি নিরাপত্তা ঝুঁকি (security red flag)।
- ১.৩% ঘোষণা না করেই এক্সটার্নাল কমান্ড-লাইন টুল কল করে, যা পোর্টেবিলিটি নিয়ম লঙ্ঘন করে।
পোর্টেবিলিটি বা বহনযোগ্যতার সমস্যাটি সবচেয়ে বেশি দেখা যায়। /home/USER/.local/bin/tool-এর মতো একটি অ্যাবসোলিউট পাথ সেই ডেভেলপারের জন্য কাজ করবে যিনি স্কিলটি লিখেছেন, কিন্তু অন্য সকল ব্যবহারকারীর জন্য এটি ব্যর্থ হবে, যার ফলে রানটাইম এরর (runtime errors) তৈরি হবে যা স্ট্যাটিক চেক (static checks) কখনোই ধরতে পারে না।
আরও গভীরে: openclaw কেস
অডিটে openclaw রিপোজিটরিতে থাকা ৪৬টি স্কিলও পরীক্ষা করা হয়েছে। ফলস অ্যালার্ম (false alarms) কমাতে টেস্টিং স্ক্রিপ্টটি আরও উন্নত করার পর, রিভিউয়ার ৫৯টি প্রকৃত ত্রুটি খুঁজে পান—যা একটি অনুস্মারক যে অতিরিক্ত আক্রমণাত্মক লিন্টার (linters) উল্টো ফল দিতে পারে। যখন কোনো টুল অনেক বেশি ক্ষতিকারক নয় এমন সমস্যা চিহ্নিত করে, তখন ডেভেলপাররা সেটি ব্যবহার করা বন্ধ করে দেয় এবং প্রকৃত সমস্যাগুলো এড়িয়ে যায়।
openclaw-এর দুটি ত্রুটি এমন ফাইল নির্দেশ করেছিল যা রিপোজিটরিতে আর নেই। মেইনটেইনার একটি ফিক্স মার্জ করেছেন যা হারিয়ে যাওয়া রেফারেন্সগুলো পুনরুদ্ধার করে, যা দেখায় যে কীভাবে একটি মাত্র পুল রিকোয়েস্ট (pull request) একটি ত্রুটিপূর্ণ ডিপেন্ডেন্সি চেইন পরিষ্কার করতে পারে।
ডেভেলপারদের প্রতিক্রিয়া
অডিটর মূল স্কিল রিপোজিটরিতে ইস্যু (issues) ওপেন করেছেন। একটি রিপোর্ট প্রত্যাখ্যান করা হয়েছিল; মেইনটেইনার যুক্তি দিয়েছিলেন যে "ত্রুটিপূর্ণ" (broken) বিষয়টি স্ট্যাটিক ফাইল ইন্সপেকশনের পরিবর্তে প্রকৃত রানটাইম আচরণের ভিত্তিতে বিচার করা উচিত। অডিটর একমত হন যে ত্রুটিপূর্ণ হওয়ার একটি কঠোর সংজ্ঞা অবশ্যই স্কিলটি বাস্তবে কীভাবে কাজ করে তার সাথে সামঞ্জস্যপূর্ণ হতে হবে। আরেকটি ইস্যু গ্রহণ করা হয়েছে এবং সংশ্লিষ্ট ফিক্সটি এখন লাইভ।
কারা লাভবান হবে—বা ক্ষতিগ্রস্ত হবে
- এজেন্ট এবং এন্ড-ইউজাররা আরও মসৃণ এবং অনুমানযোগ্য আচরণ উপভোগ করে যখন রেজিস্ট্রি শুধুমাত্র নিয়ম মেনে চলা এবং পোর্টেবল স্কিল ধারণ করে।
- স্কিল লেখকরা আরও স্পষ্ট ভ্যালিডেশন রুলস পান যা প্রকাশের আগেই ভুলগুলো ধরে ফেলে, ফলে ইস্যু ট্রায়াজ (issue triage)-এর জন্য বারবার ছোটাছুটি করতে হয় না।
- রেজিস্ট্রি অপারেটরদের আরও কঠোর ভ্যালিডেশন পাইপলাইন তৈরি বা ইন্টিগ্রেট করতে হবে; তা না হলে ইকোসিস্টেমের বিশ্বাসযোগ্যতা হারানোর ঝুঁকি থাকে।
শিথিল ভ্যালিডেশন "quick-and-dirty" সাবমিশনকে উৎসাহিত করে যা প্রোডাকশনে এজেন্টদের অচল করে দিতে পারে, যার ফলে সম্ভাব্য বড় ধরনের ডাউনটাইম বা নিরাপত্তা ঝুঁকি তৈরি হতে পারে।
পাল্টা যুক্তি: সব ভায়োলেশন কি মারাত্মক?
কেউ কেউ যুক্তি দেন যে কিছু নির্দিষ্ট "ত্রুটি" ক্ষতিকারক নয়। একটি নাম অমিল হওয়া সেই এজেন্টের ক্ষেত্রে প্রভাব ফেলতে পারে না যা প্রদর্শিত নামের পরিবর্তে slug দিয়ে স্কিল নির্বাচন করে। লোকাল ডেভেলপমেন্টের জন্য এনভায়রনমেন্ট থেকে API key পড়া একটি ইচ্ছাকৃত ডিজাইন চয়েস হতে পারে। তবে অডিটের শতাংশগুলো স্পেক থেকে যেকোনো বিচ্যুতিকেই ভায়োলেশন হিসেবে গণ্য করে, যা কিছু সমস্যার বাস্তব প্রভাবকে বাড়িয়ে দেখাতে পারে।
পরবর্তীতে যা লক্ষ্য রাখতে হবে
- উন্নত লিন্টার (Enhanced linters) যা প্রকৃত পোর্টেবিলিটি বাগ এবং সাধারণ ছোটখাটো বিষয়গুলোকে আলাদা করতে পারে।
- রেজিস্ট্রি-সাইড ভ্যালিডেশন হুক (Registry-side validation hooks) যা প্রয়োজনীয় frontmatter নেই এমন বা অ্যাবসোলিউট পাথ আছে এমন সাবমিশন প্রত্যাখ্যান করে।
- কমিউনিটি-চালিত অডিট যা প্রোডাকশন এজেন্টে পৌঁছানোর আগেই লুকানো ত্রুটিগুলো সামনে আনে।
- সম্ভাব্য স্পেক রিভিশন যা
allowed-tools-এর মতো অস্পষ্ট ফিল্ডগুলোকে স্পষ্ট করবে এবং এনভায়রনমেন্ট ভেরিয়েবলের গ্রহণযোগ্য ব্যবহার সংজ্ঞায়িত করবে।
পরবর্তী প্রজন্মের টুলিং সম্ভবত এই চেকগুলোকে কন্টিনিউয়াস-ইন্টিগ্রেশন পাইপলাইনে (continuous-integration pipelines) অন্তর্ভুক্ত করবে, যা কমপ্লায়েন্স বা নিয়ম মেনে চলাকে একটি ম্যানুয়াল afterthought থেকে একটি স্বয়ংক্রিয় গেটে পরিণত করবে।
টেকঅ্যাওয়ে (Takeaway)
জনসমক্ষে তালিকাভুক্ত এআই-এজেন্ট স্কিলগুলোর একটি বড় অংশ মৌলিক কমপ্লায়েন্স চেকগুলোতে ব্যর্থ হচ্ছে, এবং একটি উল্লেখযোগ্য অংশ একেবারেই নির্বাচন করা সম্ভব হচ্ছে না। এই ফলাফলগুলো আরও কঠোর যাচাইকরণ, উন্নত লিন্টিং টুলস এবং এমন একটি কমিউনিটি সংস্কৃতির স্পষ্ট প্রয়োজনীয়তাকে নির্দেশ করে, যেখানে স্পেক অনুসরণ করাকে প্রকাশের একটি পূর্বশর্ত হিসেবে গণ্য করা হবে। যতক্ষণ না এই সুরক্ষা ব্যবস্থাগুলো কার্যকর করা হচ্ছে, ততক্ষণ এজেন্টগুলো ভঙ্গুর এবং নন-পোর্টেবল স্কিলগুলোর কারণে সমস্যার সম্মুখীন হতে থাকবে।