مهارات الوكيل الموثَّقة من NVIDIA: كيف تُضفي ثقةً على سلسلة توريد المهارات بتوقيع OMS

نظرة عامة

باتت مهارات الوكيل مكوِّناً معيارياً في سرعة متصاعدة. يكفي أن تُدوِّن في ملف SKILL.md طريقة استخدام الأدوات والإجراءات المطلوبة، فيقرأ وكيل البرمجة تلك التعليمات وينفِّذ المهمة. المشكلة تبدأ بعد ذلك: لم تكن ثمة وسيلة واضحة للتحقق من هوية من صنع المهارة التي حصلت عليها من الإنترنت، أو من خلوِّها من شيفرة خطيرة، أو من أن أحداً لم يُعدِّلها بعد تنزيلها. والمهارات في نهاية المطاف تعليمات تمنح الوكيل صلاحيات وأفعالاً، فتشغيل مهارات مجهولة المصدر في بيئة الإنتاج ينطوي على مخاطر أكبر مما يبدو.

جاءت NVIDIA لتسدَّ هذه الثغرة بإطلاق مهارات الوكيل الموثَّقة (NVIDIA Verified Agent Skills). يرتكز الإطار على ركيزتين: إرفاق توقيع تشفيري بكل مهارة يُتيح التحقق من سلامتها ومصدرها حتى بعد التنزيل، وإخضاع كل مهارة قبل نشرها لفحص أمني وتوثيق بطاقة مهارة. فضلاً عن ذلك، تتَّبع هذه المهارات مواصفة agentskills.io المفتوحة، مما يعني أن ملف SKILL.md ذاته مُصمَّم للعمل عبر أدوات مختلفة كـ Claude Code وCodex وCursor.

تُشغِّل ThakiCloud منصة SaaS للذكاء الاصطناعي وتعلم الآلة قائمة على Kubernetes، وتُدير داخلياً مئات المهارات ومهام الوكيل الذاتية. لذلك فإن سؤال “كيف نثق بالمهارة؟” ليس لدينا تساؤلاً أكاديمياً، بل تحدياً تشغيلياً يومياً. في هذا المقال نستنسخ المستودع الذي أتاحته NVIDIA، ونتحقق من التوقيعات، ونُضيف سطراً واحداً لنرى ما إذا كان كشف التلاعب يعمل فعلاً، ثم نستخلص ما يُغيِّره هذا البناء لمن يُشغِّل منصة وكيل متعددة المستأجرين.

ما هذه التقنية

مهارات وكيل NVIDIA عبارة عن حزم تعليمات قابلة للنقل تُرشد الوكيل إلى الاستخدام الصحيح لمكتبات CUDA-X وخرائط Blueprint للذكاء الاصطناعي وأدوات المنصة. كلمة “موثَّقة (verified)” هنا ذات معنى محدد: مُدرَجة في الكتالوج، وخضعت لفحص أمني، ومُزوَّدة بتوقيع تشفيري، وموثَّقة ببطاقة مهارة. التمييز الجوهري عن السجلات التقليدية هو القدرة على التحقق من المخرج ذاته لا الاكتفاء بقرينة “نشره ناشر موثوق”.

تمر المهارة بثماني مراحل للتحقق: من المستودع المصدر إلى المراجعة والفحص والتقييم وإنشاء البطاقة والتوقيع والإدراج في الكتالوج والمزامنة. يتزامن هذا الخط يومياً، ولا تنتقل المهارة إلى المرحلة التالية إلا بعد اجتياز السابقة.

يستند هذا البناء إلى ثلاثة محاور.

المحور الأول: التوقيع. اعتمدت NVIDIA تنسيق OpenSSF Model Signing (OMS) لتوزيع ملف توقيع منفصل skill.oms.sig مع كل مهارة. يشمل هذا التوقيع جميع الملفات والمجلدات الفرعية داخل مجلد المهارة، أي أنه يضمن سلامة شجرة المجلد بأكملها لا ملفاً بعينه. OMS امتداد لحزم Sigstore يُتيح التحقق على مستوى المجلد.

المحور الثاني: الفحص الأمني. قبل النشر، تمر كل مهارة عبر SkillSpector الذي يتحقق من الاعتمادات الضعيفة والسكريبتات المريبة وأنماط الشيفرة الخطيرة والوصول إلى بيانات الاعتماد ومسارات تسريب البيانات، وهي مخاطر البرمجيات التقليدية. لكنه يتجاوز ذلك ليتناول مخاطر الوكيل الخاصة: التعليمات المخفية وحقن المطالبات وإساءة استخدام المشغِّلات والصلاحيات المفرطة وتلوُّث الأدوات والتناقض بين الغرض المُعلَن للمهارة والصلاحيات التي تطلبها والسلوكيات المُجمَّعة معها. قد تبدو المهارة بريئة على مستوى الملفات، لكنها قادرة على توجيه الوكيل نحو أفعال خطيرة، ولذلك يبقى فحص طبقة النية أمراً بالغ الأهمية. يستند نطاق فحص SkillSpector إلى دليل OWASP لمخاطر تطبيقات LLM ودليل مخاطر الذكاء الاصطناعي الوكيل.

المحور الثالث: بطاقة المهارة. يُرافق كل مهارة موثَّقة سجل ثقة قابل للقراءة آلياً يتضمن: ما تفعله المهارة، ومن أنشأها، وترخيصها، واعتمادياتها، والمخاطر التقنية المعروفة وحدودها وإجراءات التخفيف. يستطيع المطور بقراءة هذه البطاقة تحديد مدى توافقها مع الوكيل المستهدف وما يلزم التحقق منه قبل النشر.

التثبيت والتحقق

الأمر أوضح بالتطبيق المباشر، فجربناه بأنفسنا. ثبَّتنا أداة التحقق في البيئة الافتراضية المشتركة. التزاماً بقواعد وقت تشغيل Python في ThakiCloud، استخدمنا .venv الأصلي للمشروع دون إنشاء بيئة منفصلة.

# تثبيت أداة التحقق من OMS (حزمة model-signing)
VIRTUAL_ENV="$PWD/.venv" uv pip install model-signing
# الإصدار المُثبَّت: model-signing 1.1.1
# الاعتماديات المصاحبة: sigstore-models 0.0.6, sigstore-rekor-types 0.0.18, tuf 7.0.0

استنسخنا بعد ذلك الكتالوج العام. بدلاً من مهارة cuOpt التي استشهد بها مدوَّنة NVIDIA، اخترنا مهارة Dynamo للتحقق لارتباطها المباشر ببيئتنا.

# استنساخ سطحي للكتالوج العام (استغرق نحو 5.5 ثوانٍ)
git clone --depth 1 https://github.com/nvidia/skills
cd skills

# شهادة الجذر مُدرَجة في المستودع
ls nv-agent-root-cert.pem

# الانتقال إلى المهارة الموقَّعة
cd plugins/nvidia-skills/skills/dynamo-interconnect-check
ls
# BENCHMARK.md  evals  references  scripts  skill-card.md  SKILL.md  skill.oms.sig

صيغة أمر التحقق هي model_signing verify certificate. نُحدِّد فيه ملف التوقيع وسلسلة الشهادات والمسارات المُستثناة من التحقق (ملف التوقيع نفسه).

python -m model_signing verify certificate . \
  --signature skill.oms.sig \
  --certificate_chain /path/to/nv-agent-root-cert.pem \
  --ignore-paths skill.oms.sig

باستعراض المستودع بأكمله، وجدنا في مجلد skills/ مهاراتٍ يبلغ عددها 226، وملفات توقيع skill.oms.sig يبلغ عددها 237. شهادة الجذر مُضمَّنة في المستودع أيضاً، مما يعني إمكانية البدء في التحقق فوراً دون الحاجة إلى استلام مرساة الثقة عبر قناة منفصلة.

نتائج الاختبار العملي

أولاً: التحقق من توقيع سليم. عند تشغيل التحقق على مهارة dynamo-interconnect-check دون المساس بها، جاء النتيجة فورية:

Verification succeeded
verify_seconds=0.58

تحقَّقت سلامة شجرة المجلد بالكامل ومصدرها في 0.58 ثانية. سريع ومباشر.

الجوهر: كشف التلاعب. كي يكون للتوقيع معنى حقيقي، ينبغي أن يفشل التحقق عند أدنى تعديل على الملفات. أضفنا سطر تعليق واحداً إلى BENCHMARK.md داخل مجلد المهارة ثم أعدنا التحقق:

Verification failed with error: Signature mismatch:
['Hash mismatch for 'BENCHMARK.md':
  Expected Digest(algorithm='sha256', digest_value=b's\xa5\xf6i!...'),
  Actual   Digest(algorithm='sha256', digest_value=b'Uy\xb9\xf6#b...')']

فشل التحقق كما توقعنا، وليس بصورة مبهمة من قبيل “شيء ما أخطأ”، بل بتحديد دقيق لأي ملف وأي قيمة SHA-256 تختلف عن المتوقع. مجرد إضافة سطر واحد غيَّر هاش الملف كلياً وكشفه أداة التحقق. هذا هو الفارق بين قرينة “نشره ناشر موثوق” وبين ضمان “المخرج ذاته لم يُعبَث به”.

بطاقة المهارة. فتحنا skill-card.md الخاصة بـ dynamo-interconnect-check، فوجدنا فيها البيانات الوصفية للثقة الفعلية:

• الوصف: التحقق من استعداد ربط NIXL/UCX/NCCL في نشر Dynamo للخدمة الموزعة المعتمدة على RDMA/NVLink
• المالك: NVIDIA
• الترخيص: Apache-2.0
• حالة الاستخدام: للمطور الذي ينشر وصفة Dynamo الموزعة أو متعددة العقد قبل الوثوق بأرقام المعيار للتحقق من عمل طبقة نقل NIXL/UCX/NCCL
• المخاطر المعروفة وإجراءات التخفيف: قد يُضمِّن المقترح توجيهات خاطئة أو مضلِّلة في المهارة، لذا يجب مراجعتها وفحصها قبل النشر
• تنسيق الإخراج: JSON منظَّم يحتوي حكم ok/warn/fail/skipped لكل فحص

يمكن قراءة هذه البطاقة وحدها لتقييم ما إذا كانت المهارة مناسبة للبيئة التشغيلية. ملاحظة حول قيد عملي: الأمر المُستشهَد به في مدوَّنة NVIDIA يستخدم العلامة القديمة --ignore-unsigned-files، في حين تغيَّر اسم الخيار في model-signing 1.1.1 المُثبَّت فعلياً إلى --ignore-paths و--ignore_unsigned_files، مما تسبَّب في خطأ عند المحاولة الأولى. علامة واضحة على أن الأداة لا تزال في طور التطور السريع.

التطبيق والدلالات على منصة ThakiCloud K8s AI/ML SaaS

لهذا الموضوع صلة مباشرة بنا. تُشغِّل ThakiCloud المنصة باستخدام حزمة مهاراتها الخاصة، وفيها مهارات تحمل الاسم ذاته للمهارات التي وقَّعتها NVIDIA ووزَّعتها. dynamo-interconnect-check وdynamo-router-starter أدوات نستخدمها في التعامل مع حزمة الاستدلال الموزع. أن تأتي هذه المهارات الآن مرفقةً بتوقيعات تشفيرية يعني أنه يمكننا التحقق من مصدر المهارات الخارجية وسلامتها برمجياً ضمن خط الأنابيب التشغيلي.

من منظور تعدد المستأجرين تزداد الأهمية. تُشغِّل منصتنا وكلاء في بيئات عملاء متعددة. قبل نشر أي مهارة أنشأها عميل أو طرف ثالث في وقت تشغيل الوكيل على Kubernetes، يجب التحقق من عدم التلاعب بها بعد نشرها ومن الجهة المسؤولة عنها. يُتيح التحقق من توقيع OMS تحويل هذه البوابة من قاعدة نثرية إلى بوابة كود حتمية: إذا فشل التحقق أوقفنا النشر، وإذا نجح مضينا. وكما رأينا في الاختبار، التحقق يستغرق نحو 0.58 ثانية، مما يجعله عملياً جداً للدمج في مراحل CI أو admission دون تحميل إضافي يُذكر.

نُشغِّل بالفعل آليات حوكمة المهارات: بوابة استيراد المهارات وماسح أمان المهارات وحوكمة مهارات الثقة (TSG). خط أنابيب NVIDIA ذو الثماني مراحل يتداخل بصورة طبيعية مع هذا التدفق. الفارق أن NVIDIA أضافت طبقة أخيرة، “سلامة قابلة للتحقق حتى بعد التنزيل”، بتنسيق قياسي. من منظورنا، يمكن دراسة تطبيق توقيع OMS ذاته على مهاراتنا الداخلية لإغلاق سلسلة الثقة في كتالوجنا الداخلي.

في البيئات المحلية والبيئات الخاضعة للتنظيم تتضاعف هذه القيمة. في بيئات العملاء ذات الشبكات المعزولة أو المتطلبات الأمنية العالية، يُصبح إثبات “هذه المهارة هي فعلاً تلك التي أصدرتها NVIDIA ولم تتغير في طريقها إلينا” متطلباً تمتثيلياً بحد ذاته. إذا كانت الاستضافة الذاتية والتشغيل المحلي من نقاط القوة في المنصة، فإن قابلية التحقق من سلسلة توريد المهارات ليست شعاراً تسويقياً، بل متطلب تقني يُحدِّد ما إذا كان العميل يُجيز اعتماد المنتج.

القيود والاعتراضات

من الأمانة ألا نُبالغ في تقدير التوقيعات. ما يضمنه التوقيع التشفيري هو السلامة والمصدر، لا أن المهارة آمنة أو صحيحة. يمكن توقيع مهارة سيئة. التوقيع يقول فقط “هذا هو ما أصدره الناشر ولم يُعدَّل”، لا “اتباع تعليمات هذه المهارة آمن”. بل إن بطاقة مهارة dynamo-interconnect-check ذاتها نصَّت على “راجعها وافحصها قبل النشر”.

للفحص الأمني أيضاً حدوده. SkillSpector يعمل على جانب الناشر، أي أننا نثق بأن NVIDIA أجرت الفحص كما يجب دون أن نُعيد إنتاج نتائجه بأنفسنا. طبقة التقييم، دقة المشغِّل وإكمال المهمة وكفاءة الرمز المميز، لا تزال في مرحلة خارطة الطريق، مما يعني غياب مقاييس جودة معيارية حتى تُقاس وتعمل عبر أدوات مشتركة.

ثمة ملاحظة أيضاً على نضج الأدوات. تصف NVIDIA التوقيعات بأنها “تجريبية علناً”. كما رأينا، تغيَّر اسم الخيار فلم تعمل أمثلة المدوَّنة مباشرةً، ومنظومة أدوات التحقق لا تزال في مراحلها الأولى. ارتباط مرساة الثقة بشهادة جذر واحدة له وجهان: يُبسِّط التحقق لكنه يُركِّز الثقة في كيان واحد هو NVIDIA. إمكانية النقل عبر الأدوات “مُصمَّمة للعمل” لكنها غير مضمونة في كل أداة، لذا يستوجب الاعتماد تشغيل اختبار فعلي على الأداة المستهدفة.

ومع ذلك، الاتجاه واضح. ما دامت المهارات مكوِّنات تُحدِّد سلوك الوكيل، فإن متطلب التحقق من مصدر تلك المكوِّنات وسلامتها لن يزول. ما قدَّمته NVIDIA إجابة محددة وقابلة للإعادة على هذا المتطلب، وهي الإجابة الأولى من نوعها.

المصادر

• NVIDIA Technical Blog, NVIDIA-Verified Agent Skills Provide Capability Governance for AI Agents
• GitHub, NVIDIA/skills
• GitHub, NVIDIA/skillspector
• NVIDIA Skill Documentation, Verify Signed Agent Skills
• OpenSSF, Model Signing (OMS)
• الأرقام الواردة في النص (226 مهارة · 237 توقيعاً · تحقق 0.58 ثانية · كشف التلاعب) مقاسة من استنساخ المستودع مباشرةً بتاريخ 2026-06-25.