أضاف فريق Foundry في Microsoft خاصية التتبع (tracing) القائمة على OpenTelemetry إلى إطار عمل الوكلاء (agent framework) الخاص به، مما يمنح المطورين وسيلة لرؤية التنفيذ من البداية إلى النهاية عبر وكلاء متنوعين مدعومين بنماذج LLM.

لماذا تحتاج الأنظمة متعددة الوكلاء إلى ما هو أكثر من ملفات السجلات (log files)

تستخدم تمرينات الاستجابة للحوادث المدفوعة بالذكاء الاصطناعي النموذجية "وكيل قائد" (commander agent) يقوم بتنسيق عمل عدة وكلاء متخصصين: أحدهم يحلل السجلات، والآخر يكتشف الشذوذ في المقاييس، والثالث يطابق الأعراض مع أدلة التشغيل (runbooks)، ويقوم موجه (router) باختيار أفضل نموذج لغوي لكل مهمة فرعية. قد يستدعي كل متخصص نموذجاً مختلفاً - مثل إصدار "gpt-5-mini" - ويستخدم أدواته الخاصة. وعند حدوث خطأ ما، يضطر المهندسون إلى التحديق في سجلات معزولة تظهر ما فعله كل مكون، ولكن دون رؤية شاملة لكيفية ترابط هذه الأجزاء معاً.

بدون تتبع موحد (unified trace)، يختبئ السبب الجذري في عملية التسليم بين الوكلاء. فقد يرسل القائد طلباً يعالجه قارئ السجلات بشكل صحيح، ومع ذلك يسيء متخصص المقاييس تفسير البيانات ويقترح دليل تشغيل خاطئ. إن تصحيح أخطاء (debugging) تلك السلسلة يدوياً يستغرق وقتاً طويلاً ويفتح الباب للوقوع في الأخطاء.

كيف يقوم OpenTelemetry بربط سير العمل معاً

يحدد OpenTelemetry مفهومين أساسيين: traces و spans. الـ trace هو معرف فريد يتتبع الطلب من لحظة دخوله حتى الاستجابة النهائية. أما الـ span فيسجل عملية واحدة - مثل استدعاء نموذج لغوي أو تشغيل أداة - ضمن ذلك الـ trace.

عندما يتلقى الوكيل طلباً، فإنه يسحب Trace ID الوارد من البيانات الوصفية (metadata) للطلب وينشئ child span يرث نفس المعرف. يقوم الـ child span بتسجيل وقت البدء، والمدة، والسمات (مثل اسم النموذج، والأداة المستخدمة)، وأي أخطاء. وتتكرر هذه العملية مع كل وكيل لاحق (downstream agent)، مما يبني شجرة تعكس التدفق المنطقي للمهمة الإجمالية.

يدعم OpenTelemetry أيضاً Baggage، وهو ناقل خفيف لأزواج المفتاح والقيمة (key-value pairs) المخصصة. من خلال إرفاق "drill-id" أو أي سياق عمل آخر بالـ baggage في أعلى الـ trace، يرث كل span لاحق ذلك المعرف تلقائياً. ثم يقوم span processor بترقية الـ baggage إلى سمات (attributes) عادية، مما يسهل الاستعلام عن جميع الـ spans التابعة لتمرين حادث معين.

كيف تبدو واجهة التتبع الجديدة

مع تفعيل أدوات القياس (instrumentation)، يقوم Azure Monitor (أو أي backend متوافق مع OpenTelemetry) بعرض تسلسل هرمي مرئي:

  • اسم الوكيل / المعرف (Agent name / ID) – يوضح أي مكون قام بالعملية.
  • استخدام الأدوات (Tool usage) – يسجل أي خدمة خارجية أو دالة تم استدعاؤها.
  • إصدار النموذج (Model version) – يسجل نموذج LLM المستخدم بالضبط، وهو أمر مفيد لتتبع التراجعات (regressions) بعد ترقية النموذج.
  • استهلاك الرموز (Token consumption) – يرصد عدد الرموز (tokens) التي تم إرسالها واستلامها من النموذج، مما يساعد الفرق على إدارة التكلفة.
  • زمن الاستجابة / المدة (Latency / duration) – يسلط الضوء على أماكن ظهور الاختناقات، سواء في استنتاج النموذج (model inference) أو في عمليات الإدخال والإخراج للأدوات (tool I/O).

في مثال تمرين الحوادث، يقوم الـ root span الخاص بالقائد بإنشاء child spans لكل متخصص، ويقوم كل متخصص بإنشاء أطفال إضافيين لاستدعاءات النماذج الخاصة به. يؤدي النقر على أي عقدة (node) إلى كشف مجموعة السمات الكاملة، بحيث يرى المهندس تفاصيل كل عملية على الفور.

المخاطر والفوائد للعمليات المتمحورة حول الذكاء الاصطناعي

  • سرعة تحليل السبب الجذري – تتبع الفرق الفشل وصولاً إلى الـ span المحدد الذي تسبب في الخطأ، مما يقلل متوسط وقت الحل (MTTR).
  • وضوح التكلفة – تظهر أعداد الرموز (tokens) بجانب زمن الاستجابة، مما يسمح للقسم المالي برصد الاستخدام المفرط قبل تضخم فواتير السحابة.
  • ضبط الأداء – تشير الـ spans ذات زمن الاستجابة العالي عبر الوكلاء إلى الأماكن التي يمكن فيها للتخزين المؤقت (caching)، أو اختيار النموذج، أو إعادة تصميم الأدوات أن تزيد من معدل الإنتاجية (throughput).

ما الذي يجب مراقبته لاحقاً

يمكن للمشاريع المبنية على LangChain أو OpenAI SDK أو طبقات التنسيق (orchestration layers) الأخرى اعتماد نفس الاصطلاحات الدلالية (semantic conventions) للذكاء الاصطناعي التوليدي (GenAI)، مما يمهد الطريق لتتبع يتدفق عبر مزودي السحابة والبيئات المحلية (on-premise).

ما على المؤسسات سوى تفعيل OpenTelemetry SDK في وكلائها وإرسال البيانات إلى Azure Monitor أو إلى جامع بيانات (collector) مفتوح المصدر.

الخلاصة

يوفر OpenTelemetry لأنظمة الذكاء الاصطناعي متعددة الوكلاء "الغراء" المفقود الذي يحول تشتت السجلات إلى سرد متماسك. ومن خلال نشر Trace ID واحد عبر نماذج LLM متنوعة، والموجهات، واستدعاءات الأدوات، يمكن للمطورين تحديد أماكن الفشل، ومراقبة التكاليف، وتحسين الأداء دون الحاجة إلى إعادة اختراع بنية التتبع التحتية.