AgentCore يقيس أي وكيل عبر OpenTelemetry، بشرط أن تكتمل الآثار
وسّعت AWS في 26 أغسطس 2026 دعم Amazon Bedrock AgentCore Evaluations بحيث يمكن للخدمة تقييم وكيل بصرف النظر عن إطار بنائه، ما دامت آثاره تصل وفق اتفاقيات القياس التي تفهمها. ويوضح الإعلان التقني لـAWS أن الخدمة تعيد بناء الجلسة من بيانات OpenTelemetry أو OpenInference، ثم تطبق المقيمين أنفسهم على الأطر المختلفة.
لكن هذا الفصل عن إطار البناء لا يعني أن إرسال spans وحده يكفي. فقد عرضت قراءة تقنية مستقلة نُشرت في 27 أغسطس التغيير بوصفه عقداً قائماً على شكل القياسات، وذكرت LangGraph وLlamaIndex وOpenAI Agents SDK وGoogle ADK وClaude Agent SDK وStrands Agents؛ أما النتيجة القابلة للاستخدام فتظل مشروطة بوصول جلسة مترابطة وعمليات مصنفة ومحتوى يمكن للمقيم قراءته.
اسم الإطار لم يعد بوابة التوافق
تختار AgentCore طريقة تفسير كل span من قيمة scope.name. ووفق وثائق الدعم العام في AgentCore، يقبل المسار العام النطاقات التي تبدأ بـ opentelemetry.instrumentation.* لاتفاقية OpenTelemetry أو openinference.instrumentation.* لاتفاقية OpenInference. وإذا كان للإطار مسار موثق خاص، تستخدم الخدمة قواعد ذلك المسار بدلاً من القواعد العامة.
هذه البادئات ليست تفصيلاً شكلياً. نطاق مخصص مثل mycompany.agent.tracing لا يدخل تلقائياً في الدعم العام، حتى إذا احتوت spans على حقول تبدو مشابهة. وفي المقابل، لا تعامل الخدمة كل نطاق يطابق بادئة OpenTelemetry باعتباره نشاط وكيل: فهي تستبعد قياسات عملاء HTTP وأطر الويب وMCP وAWS SDK، بما فيها botocore ونطاقات bedrock-agentcore وbedrock-runtime، حتى لا تتحول عمليات النقل والبنية التحتية إلى استدعاءات وكيل أو نموذج أو أداة زائفة.
بعد قبول النطاق، تحتاج كل span يراد تقييمها إلى سمة تعريف معروفة. تستخدم اتفاقية OpenTelemetry القيمة gen_ai.operation.name، مع بدائل موثقة لبعض الآثار مثل traceloop.span.kind، بينما تعتمد OpenInference على openinference.span.kind. وبذلك تصنف الخدمة ثلاث عمليات أساسية: دورة الطلب والرد العليا، واستدعاء النموذج، وتنفيذ الأداة؛ أما span بلا سمة تعريف معروفة فتتخطاها الخدمة.
الجلسة والمحتوى هما الحد الأدنى القابل للتقييم
يعيد AgentCore تنظيم القياسات في ثلاث طبقات. تمثل الجلسة المحادثة الكاملة، ويمثل trace دورة واحدة من طلب المستخدم إلى رد الوكيل، بينما تصف spans الخطوات الداخلية، مثل استدعاء نموذج أو تنفيذ أداة. ويجمع النظام هذه العناصر بواسطة session.id؛ لذلك يجب أن تحمل الآثار المرتبطة بالمحادثة القيمة نفسها، وأن تطابق runtimeSessionId المستخدم عند تشغيل الوكيل في AgentCore Runtime.
يؤدي غياب هذا التطابق إلى وصول عمليات لا يمكن ضمها بثقة إلى جلسة واحدة. وقد تكون spans صحيحة من حيث التوقيت والأسماء، لكن المقيم الذي يعمل على مستوى الجلسة لن يرى تسلسلاً كاملاً. لهذا لا يثبت ظهور القياسات في CloudWatch وحده أن البيانات أصبحت جاهزة للتقييم.
تحتاج دورة الوكيل العليا إلى طلب المستخدم والرد النهائي، ويحتاج span الاستدلال إلى الرسائل المرسلة إلى النموذج ومخرجاته، فيما يحتاج span الأداة إلى اسم الأداة ومعاملاتها ونتيجتها. وقد يوجد المحتوى داخل سمات مثل gen_ai.input.messages وgen_ai.output.messages، أو داخل event records مرتبطة بالـspans. وفي OpenInference تستخدم رسائل النموذج سمات مفهرسة من عائلة llm.input_messages وllm.output_messages، بينما تظهر مدخلات الأداة ونتيجتها عادة في input.value وoutput.value.
- التجميع: session.id واحد يربط محادثة الوكيل وآثارها.
- التصنيف: سمة معروفة تحدد إن كانت العملية استدعاء وكيل أو نموذج أو أداة.
- المحتوى: طلب المستخدم والرد ورسائل الاستدلال في المواضع التي تستخرجها الخدمة.
- سياق الأدوات: الاسم والمعاملات والنتيجة، وتعريفات الأدوات عندما يحتاجها المقيم.
أعراض النقص تكشف الحقل المفقود
إذا لم تظهر عمليات قابلة للتقييم، فالنقطة الأولى هي scope.name ثم سمة التصنيف. نطاق غير معروف يمنع تشغيل المسار العام، وspan بلا gen_ai.operation.name أو بديله المعترف به تُتخطى حتى لو احتوت على أسماء وأزمنة. أما ظهور traces متفرقة من دون جلسة مكتملة فيشير غالباً إلى غياب session.id أو اختلافه عن معرف جلسة التشغيل.
إذا تعرفت الخدمة إلى الجلسة وأنواع العمليات، لكن تقييم جودة الرد بقي فارغاً أو أعاد خطأ، فالمشكلة الأقرب هي المحتوى. في إعداد القياس الموحد يبقى المحتوى مع spans داخل مجموعة السجل الخاصة بالوكيل. أما الإعدادات الأقدم ذات القياس المنقسم فقد تضع spans في aws/spans وتخزن الرسائل في event records منفصلة؛ اختيار مجموعة spans وحدها يسمح بالتصنيف، لكنه لا يمنح مقيمات مثل Correctness أو Helpfulness نص الطلب والرد اللازم للحكم.
مثال افتراضي: قد تحمل span قيمة chat وتُصنف بوصفها استدعاء نموذج، لكن غياب gen_ai.input.messages وgen_ai.output.messages وعدم وصول event record المقابل يترك للمقيم غلاف العملية من دون المحادثة. النتيجة هنا لا تثبت ضعف الوكيل؛ إنها تكشف أن مادة التقييم نفسها غير مكتملة.
ثمة عرض آخر سببه توقيت التصدير. تستخدم مكتبات OpenTelemetry معالجات مجمعة قد تُبقي spans أو event records في الذاكرة، بينما يمكن لبيئة AgentCore Runtime أن تُعلّق التنفيذ بعد إعادة الاستجابة. لذلك ينبغي تفريغ كل من tracer provider وlogger provider قبل نهاية معالج الاستدعاء؛ تفريغ الأول وحده قد يرسل بنية الأثر ويترك سجلات المحتوى في مخزن منفصل.
الدعم الواسع لا يساوي درجة مضمونة
التغيير المعلن هو توسيع طبقة التوافق، لا إطلاق خدمة AgentCore Evaluations للمرة الأولى. وتعمل البنية المشتركة مع التقييم عند الطلب والتقييم المتصل بحركة الإنتاج، لكن نوع البيانات المتاحة يظل مختلفاً: الاختبارات المضبوطة تستطيع إرفاق إجابات متوقعة ومسارات أدوات وعبارات تحقق، بينما لا تحمل حركة الإنتاج حقيقة مرجعية تلقائياً.
الخلاصة الفنية أن AgentCore أصبح أقل ارتباطاً باختيار SDK أو إطار الوكيل، لكنه أكثر صراحة في عقد البيانات الذي يسبق القياس. نطاق معترف به يفتح مسار القراءة، وسمة التصنيف تحدد دور كل span، وsession.id يبني المحادثة، ثم تمنح الرسائل وبيانات الأدوات المقيم المادة التي سيحكم عليها. إذا انكسر أحد هذه المستويات، فقد يظهر العطل كتقييم فارغ أو جلسة ناقصة أو عملية غير مصنفة، لا كخطأ واضح في منطق الوكيل.
المؤكد بعد تحديث 26 أغسطس 2026 هو دعم الأطر الستة المسماة والمسار العام للقياسات المتوافقة مع OpenTelemetry أو OpenInference. أما جودة النتائج عبر مكتبات instrumentation وإصداراتها المختلفة فتبقى رهناً باستمرارها في إصدار السمات والمحتوى بالمواضع المتوقعة، وباكتمال تصدير القياسات قبل انتهاء التشغيل.
اقرأ أيضًا:
اشترك في نشرتنا الإخبارية
احصل على أحدث أخبار الويب 3 والذكاء الاصطناعي والعملات المشفرة مباشرة في بريدك.