ابنِ تطبيقات على NVIDIA BlueField بشكل أسرع باستخدام مهارات وكيل NVIDIA DOCA

ابنِ تطبيقات على NVIDIA BlueField بشكل أسرع باستخدام NVIDIA DOCA Agent Skills

البناء على DPU ليس مثل البناء على CPU المضيف، والفرق يظهر مبكرًا. عادةً ما ينقسم تطبيق DOCA عبر نطاقي تنفيذ: مستوى تحكم من جهة المضيف يقوم بالتهيئة والإشراف، ومنطق من جهة DPU يعمل على أنوية Arm في BlueField ويلمس مسار البيانات الشبكي. جعل وكيل برمجي بالذكاء الاصطناعي يساعد في هذا الانقسام أصعب من توجيهه إلى قاعدة شيفرة أحادية العملية، لأن الوكيل يجب أن يحتفظ في ذهنه في الوقت نفسه بسياق الجهاز، وأعراف SDK، وحلقة البناء والنشر.

تتناول تدوينة مدونة مطوري NVIDIA بعنوان Build Applications on NVIDIA BlueField Faster with NVIDIA DOCA Agent Skills (المنشورة في 1 أكتوبر 2026) هذا الاحتكاك مباشرةً. يعمل هذا المقال انطلاقًا من هذا المصدر الأساسي الوحيد. وحيث أصف آليات سير عمل لا توضحها التدوينة نفسها، أُصنّفها على أنها تفسير أو ممارسة DOCA قياسية، وليس على أنها ادعاءات من NVIDIA.

ما الذي يثبته المصدر

الحقائق المُتحقَّق منها محدودة، ويستحق ذكرها بوضوح قبل بناء أي شيء فوقها:

• نشرت NVIDIA تدوينة على مدونة المطورين بعنوان "Build Applications on NVIDIA BlueField Faster with NVIDIA DOCA Agent Skills."
• التدوينة متاحة على مدونة NVIDIA Developer.
• الموضوع هو تسريع تطوير التطبيقات على NVIDIA BlueField باستخدام NVIDIA DOCA Agent Skills.

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

لماذا يقاوم تطوير BlueField الأتمتة الساذجة

فيما يلي تفسير، وليس ادعاءً من المصدر.

يبلاء وكيل برمجي عام بلاءً حسنًا مع مكتبة مستقلة ذات API معروف جيدًا. لكن العمل على BlueField يكسر ثلاثة من الافتراضات التي تجعل ذلك ممكنًا.

أولًا، نطاقان وميزة واحدة. نادرًا ما تكون ميزة تفريغ التدفق (flow-offload) مكتملة على جانب واحد. يجب أن يكتشف شيء ما على المضيف الجهاز، ويفتح سياق DOCA، ويدفع التهيئة. ويجب أن يتفاعل شيء ما على DPU مع تلك التهيئة في مسار البيانات. الوكيل الذي يولّد نصف المضيف فقط ينتج شيفرة تُترجم ولا تفعل شيئًا مفيدًا.

ثانيًا، قدرة العتاد حقيقة وقت تشغيل. يعتمد توفر تفريغ معيّن، أو وضع تشفير، أو عنصر أولي في قائمة الانتظار على جيل BlueField المحدد، والبرنامج الثابت (firmware)، وإصدار DOCA المثبت. الشيفرة التي تفترض وجود قدرة ستفشل في وقت التشغيل وليس في وقت الترجمة، وهذا بالضبط نمط الفشل الذي يكون الوكيل أضعف ما يكون في تشخيصه دون تغذية راجعة.

ثالثًا، حلقة البناء ليست `make && ./run`. عادةً ما تُجمّع تبادليًا (cross-compile) أو تبني على DPU، ثم تنشر الملف الثنائي إلى جانب Arm، ثم تراقب السلوك على نظام ثانٍ. كل قفزة إضافية هي موضع يمكن فيه لافتراضات الوكيل حول نظام الملفات، أو سلسلة الأدوات، أو معمارية الهدف أن تنحرف بصمت عن الواقع.

تكتسب Agent Skills أهميتها تحديدًا لأنها تهاجم مشكلة السياق هذه بدلًا من مشكلة توليد الشيفرة. القيمة ليست في نموذج أذكى؛ بل في نموذج أضيق وأكثر تأصيلًا.

ما الذي تغيّره "Agent Skills" عمليًا

هذا القسم تفسير، مصوغ كنموذج عمل وليس وصفًا لتنفيذ NVIDIA.

النموذج الذهني المفيد هو أن المهارة وحدة مُحزَّمة من إجراءات المجال: متى تُستخدم، وما الشروط المسبقة التي يجب فحصها، وما الأوامر أو واجهات API التي يُفضّل استخدامها، وكيف تبدو بصمات الفشل، وكيف يتم التحقق من النجاح. إنها أقرب إلى دليل تشغيل (runbook) يسلّمه مهندس خبير إلى زميل جديد منها إلى مقتطف توجيه (prompt snippet).

وعند تطبيق ذلك على BlueField، يعني أن المهارة يمكنها ترميز أجزاء سير العمل التي لا يستطيع النموذج استنتاجها من الشيفرة وحدها:

• تسلسل الاكتشاف — كيفية تأكيد وجود DPU، والأدوات التي تُبلّغ عن القدرة، وكيف يبدو المخرَج "المتوقع".
• انقسام النطاق — أي أجزاء الميزة تنتمي إلى المضيف وأيها تنتمي إلى DPU.
• عقد التحقق — كيف يبدو اختبار ناجح لهذه الفئة من التفريغ، وكيف يبدو بدلًا من ذلك سوء تهيئة صامت.
• ثوابت البيئة — افتراضات نظام التشغيل والنواة وإصدار DOCA التي يُعرف أن الإجراء يعمل في ظلها.

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

المتطلبات

المتطلبات أدناه عامة لبيئة تطوير DOCA. الإصدارات الدقيقة تأتي من وثائق DOCA من NVIDIA والتدوينة، وهما المرجعان الموثوقان لإصدارك.

• نظام مضيف عليه DPU من NVIDIA BlueField مثبّت ومرئي على ناقل PCIe.
• توزيعة Linux مدعومة على المضيف، ونواة تطابق ما يتطلبه إصدار DOCA لديك.
• الوصول إلى حزمة برمجيات DOCA، مثبّتة إما من مستودع حزم NVIDIA أو من مُثبّت DOCA ذي الصلة، وفقًا لتعليمات التثبيت الرسمية من NVIDIA.
• سلسلة أدوات: مترجم C/C++، وcmake، وpkg-config، وgit.
• Python 3 مع venv إذا كنت تنوي برمجة حلقة جهة المضيف أو تشغيل منصة وكيل محليًا.
• وصول شبكي لتثبيت الحزم، وأذونات مناسبة — معظم خطوات الاكتشاف والتثبيت أدناه تحتاج إلى sudo.

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

التثبيت خطوة بخطوة

التسلسل أدناه يقوم عمدًا على الاكتشاف أولًا. كل خطوة تسأل النظام عما لديه قبل ادعاء أي شيء بشأنه.

1. تأكيد وجود جهاز BlueField

اسرد أجهزة NVIDIA/Mellanox PCIe على المضيف.

lspci -nn | grep -i mellanox

أنت تبحث عن مدخل متحكم شبكة. يُعرّف DPU من BlueField نفسه كجهاز PCIe له نظامه الفرعي Arm الخاص، لذا سيختلف تخطيط الوظائف الدقيق عن بطاقة شبكة عادية. إذا لم يظهر شيء، توقف هنا — لن يساعد أي قدر من تثبيت SDK، وسيعمل الوكيل ضد جهاز وهمي.

2. تسجيل بيئة المضيف

التقط نظام التشغيل والنواة كي تُثبّت تعريفات مهاراتك على تركيبة معروفة الجودة.

cat /etc/os-release
uname -srm

احتفظ بهذا المخرَج. عندما ينتج الوكيل شيفرة تفشل على جهازك فقط، هذا أول شيء تقارنه.

3. التحقق مما إذا كان DOCA مثبّتًا بالفعل

استعلم من قاعدة بيانات الحزم بدلًا من افتراض نظام نظيف.

dpkg -l | grep -i doca || echo "no doca packages found via dpkg"

ثم ابحث عن دليل تثبيت، دون تخمين المسار الدقيق الذي يستخدمه إصدارك.

find / -maxdepth 4 -type d -name 'doca*' 2>/dev/null

4. اكتشاف الحزم التي يعرضها مستودعك

هذه هي الخطوة التي تحل محل أسماء الحزم المُخمَّنة.

apt-cache search --names-only '^doca' | sort

اقرأ القائمة. تخبرك مكونات DOCA التي يحملها مستودعك المُهيأ، وبشكل غير مباشر، خط الإصدار الذي أنت عليه. تحقق منها مقابل دليل تثبيت DOCA الرسمي من NVIDIA قبل المتابعة.

5. تثبيت مكونات DOCA التي تحتاجها

حدّث الفهرس، ثم ثبّت المكونات المحددة في الخطوة السابقة. العنصر النائب أدناه مقصود — استبدله بالاسم الحقيقي من مخرَج apt-cache search الخاص بك.

sudo apt-get update
sudo apt-get install -y <doca-package-from-step-4>

6. تثبيت سلسلة أدوات البناء

المترجم وCMake مطلوبان لأي تطبيق DOCA ستكتبه أنت أو الوكيل.

sudo apt-get install -y build-essential cmake git pkg-config

7. تحديد موقع أدوات استعلام DOCA والملفات الثنائية النموذجية

بدلًا من افتراض اسم أداة، اسأل الحزمة المثبّتة عما وضعته على القرص.

dpkg -L <doca-package-from-step-4> | grep -E '/(bin|sbin)/'

هكذا تجد أداة استعلام الإصدار والتطبيقات النموذجية لإصدارك. التطبيقات النموذجية هي أفضل مادة تأصيلية يمكنك تسليمها لوكيل، لأنها مضمونة الترجمة مقابل ترويساتك المثبّتة.

8. إنشاء هيكل مشروع

أنشئ تخطيطًا متوقعًا كي يكون لدى الوكيل مكان مستقر للكتابة والقراءة.

mkdir -p ~/bf-doca-lab/{src,skills,scripts,build}
cd ~/bf-doca-lab
git init

9. تجهيز بيئة Python للبرمجة النصية من جهة المضيف

إذا كنت تخطط لبرمجة الاكتشاف أو النشر أو استدعاء الوكيل، فاعزل التبعيات.

cd ~/bf-doca-lab
python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip

أمثلة الاستخدام

الأمثلة أدناه أنماط، وليست مواصفة لأي صيغة توفرها NVIDIA. تعامل معها كهياكل قابلة للتكيّف.

مثال 1: ترميز مهارة كإجراء مُتحقَّق منه

مهارة بهذا الشكل العام تمنح الوكيل شروطًا مسبقة وعقد تحقق، وليس مجرد تعليمات. احفظها تحت skills/.

# skill: dpu-device-preflight

## الشروط المسبقة
- لدى المضيف DPU من BlueField مرئي على PCIe
- حزم DOCA مثبّتة وأدوات الاستعلام موجودة في PATH

## الخطوات
1. تأكيد تعداد DPU على ناقل PCIe.
2. تسجيل إصدار DOCA لهذه البيئة.
3. تأكيد أن أداة الاستعلام تُبلّغ عن القدرة المطلوبة.
4. إذا كانت القدرة غائبة، توقف وأبلغ عنها. لا تولّد شيفرة.

## التحقق
- كل خطوة تنتج مخرَجًا ملاحظًا، وليس افتراضًا.
- غياب قدرة هو نتيجة صالحة وقابلة للإبلاغ.

عبارة "توقف وأبلغ" تهم أكثر مما تبدو. إنها تحوّل فئة من التهيؤ — اختراع تفريغ لا يدعمه العتاد — إلى فشل نظيف.

مثال 2: حلقة بناء واختبار حتمية

أعطِ الوكيل أمرًا واحدًا إما ينجح أو يفشل، حتى لا يستطيع أن يتخلص بالسرد من بناء معطوب.

#!/usr/bin/env bash
set -euo pipefail

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j"$(nproc)"
ctest --test-dir build --output-on-failure

لأن set -euo pipefail فعّال، أي مرحلة فاشلة تُجهض السكربت. يرى الوكيل رمز خروج غير صفري وذيل السجل، وليس نجاحًا غامضًا.

مثال 3: منسّق من جهة المضيف يسجّل الحالة الملاحظة

هذا القالب يشغّل أمرًا خارجيًا، ويلتقط مخرَجه، ويسجّل الأمر والنتيجة معًا. كيّف قائمة الأوامر وفق الأدوات التي وجدتها في الخطوة 7 من التثبيت.

import logging
import subprocess

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(message)s",
)

def observe(cmd: list[str]) -> str:
    """Run a read-only discovery command and return its stdout."""
    logging.info("running: %s", " ".join(cmd))
    result = subprocess.run(
        cmd,
        capture_output=True,
        text=True,
        check=False,
    )
    if result.returncode != 0:
        logging.warning("command exited %d: %s", result.returncode, result.stderr.strip())
    return result.stdout

if __name__ == "__main__":
    for probe in (
        ["lspci", "-nn"],
        ["uname", "-srm"],
    ):
        output = observe(probe)
        print(output)

قيد القراءة فقط مقصود. أوامر الاكتشاف آمنة للتشغيل دون إشراف؛ أما أوامر التهيئة فليست كذلك، وينبغي للمهارة أن تفصل بين الطورين صراحةً.

مثال 4: نمط توجيه يُبقي الوكيل مُؤصَّلًا

عند استدعاء الوكيل، وفّر ملف المهارة، ولقطة البيئة من الخطوة 2، والمخرَج الخام للفشل. نمط مختصر:

السياق:
- ملف المهارة: skills/dpu-device-preflight.md
- البيئة: <الصق مخرَج /etc/os-release و uname>
- إصدار DOCA المثبت: <الصق مخرَج الإصدار>

المهمة:
شخّص سبب فشل البناء في scripts/build-and-test.sh.
اقترح رقعة للمكوّن من جهة المضيف فقط.
لا تُدخل استدعاءات API غير موجودة في الترويسات المثبتة.

المخرَج المطلوب:
1. السبب الجذري، مع سطر السجل الذي يدعمه.
2. فرق موحّد (unified diff).
3. الأمر الدقيق للتحقق من الإصلاح.

السطر الأخير هو المهم. طلب أمر تحقق يُغلق الحلقة ويجعل ادعاء الوكيل قابلًا للاختبار.

حدود مفتوحة وما يجب التحقق منه بنفسك

ثلاثة أشياء تظل غير مؤكدة حقًا، وادعاء غير ذلك سيكون مضللًا.

تفاصيل مهارات NVIDIA. التدوينة هي المصدر الموثوق لوجود المهارات، والصيغة التي تستخدمها، والإصدارات التي تستهدفها. هذا المقال لا يعيد إنتاج تلك القائمة.

انحراف الإصدارات. تتغير أسماء حزم DOCA ومواقع الأدوات بين الإصدارات. صُمم تسلسل التثبيت القائم على الاكتشاف أولًا أعلاه للنجاة من ذلك الانحراف، لكنه لا يمكن أن يحل محل قراءة ملاحظات الإصدار.

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

الخاتمة

الشيء المثير في DOCA Agent Skills ليس أن وكيلًا يكتب شيفرة DOCA. بل أن عنق الزجاجة في تطوير DPU كان دائمًا السياق — قدرة الجهاز، وانقسام المضيف/DPU، وحلقة بناء تمتد عبر نظامين. تُحزّم المهارات ذلك السياق كي يكون الوكيل مفيدًا داخله بدلًا من أن يكون معقولًا خارجه.

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