الانتقال إلى المحتوى الرئيسي

تكلفة القياس عن بُعد متغيّر تصميمي للوكيل، لا فاتورة بنية تحتية

تضاعف أحمال عمل الوكيل إنفاق المراقبة لأن كل خطوة تصدر تتبعات وسجلات ومقاييس. الحل هو سياسة أخذ عينات واحتفاظ مصممة جنبًا إلى جنب مع الوكيل.

صورة ماكرو للوحة دائرة تُظهر التتبعات ونقاط اللحام والمكونات السطحية بتفاصيل حادة

منحنى التكلفة الذي لا يحسبه أحد قبل الإطلاق

تصدر الخدمة التقليدية القياس عن بُعد بما يتناسب تقريبًا مع الطلبات التي تخدمها. أما الوكيل فليس كذلك. يتفرّع طلب مستخدم واحد إلى خطوة تخطيط، وتسلسل من استدعاءات الأدوات، ومرحلة تحقق، وإعادة محاولة أو اثنتين، وتوليف نهائي. كل مرحلة من هذه المراحل هي span؛ وكل span يحمل سمات وأحداثًا وغالبًا حمولة بيانات. هذا التضاعف بنيوي وليس عارضًا.

بدأت التقارير القطاعية بتسمية هذا النمط. فالتغطية الإعلامية لإرشادات المراقبة من Splunk، والتعليقات الأوسع في Network World، ومواد Cisco حول القياس عن بُعد، تصف جميعها الشكل نفسه: أحمال العمل المدفوعة بالوكلاء وبـ LLM ترفع حجم المراقبة بوتيرة أسرع من معدل الطلبات الأساسي، ويبقى كثير من الإنفاق الناتج خفيًا لأنه يتراكم في التخزين والاستيعاب وتراخيص المقاعد بدلًا من أن يظهر في بند واحد مرئي. راجع التغطية المتعلقة بـ Splunk، ونقاش Network World، وكتابات Cisco حول المراقبة للاتجاه العام.

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

لقطة قريبة لمبدّل ألياف ضوئية مع كابلات موصولة، من الأسفل

ما تصدره الوكلاء ولا تصدره الخدمات

القياس عن بُعد التقليدي للطلبات صغير ومنظم: مسار، ورمز حالة، ومدة. أما قياس الوكيل فضخم ودلالي. تهيمن أربع فئات على الحجم.

حمولات الـ prompt والإكمال. يمكن لكل استدعاء نموذج أن يحمل سياق الإدخال الكامل والمخرجات المولّدة الكاملة. هذه هي السجلات الأكثر فائدة لتصحيح الأخطاء والأكثر تكلفة في التخزين، لأنها تتدرج مع عدد الـ token لا مع عدد الطلبات.

وسائط الأدوات ونتائجها. span استدعاء الأداة رخيص؛ أما سماته فليست كذلك. يمكن أن تكون الوسائط كائنات منظمة كبيرة، ويمكن أن تكون النتائج مستندات كاملة. وعندما تُستدعى أداة في حلقة، يُصدر الشكل نفسه مرارًا.

خطوات الاستدلال الوسيطة. تُصدر تتبعات التخطيط ومحتوى المسودة ومراحل النقد الذاتي لكل خطوة. وهي قيّمة حقًا عندما ينحرف المسار، وشبه عديمة القيمة عندما يسير على ما يرام.

تضخيم إعادة المحاولة. عاصفة إعادة المحاولة هي أسوأ حالة لنسبة التكلفة إلى المعلومات: تُتتبع العملية المنطقية نفسها مرات عديدة، وكل محاولة تضيف spans وأحداثًا وسمات أخطاء. يرتفع عدد الـ span بينما تقترب المعلومات الحدية من الصفر، لأن الحقيقة المثيرة للاهتمام هي وقوع حلقة إعادة محاولة، لا محتويات المحاولة الرابعة عشرة.

هناك أيضًا طبقة بيانات وصفية — أعداد الـ token، ومعرّفات النموذج، وزمن استدعاء، وأعلام إصابة الـ cache — رخيصة لكل سجل ومفيدة إجمالًا. لكنها بالدقة الكاملة عبر كل span تصبح بندًا تخزينيًا كبيرًا بحد ذاته.

سياسة أخذ عينات مرتبطة بنقاط القرار

التجريد المفيد ليس الخدمة ولا نوع الـ span. إنه القرار. كل خطوة وكيل إما تقرأ حالة، أو تغيّر حالة، أو تقرر ما تفعله بعد ذلك. يجب أن يتبع أخذ العينات هذا التصنيف.

  • احتفظ بالتتبعات الكاملة لاستدعاءات الأدوات التي تغيّر الحالة. الكتابات والحذف والمدفوعات والرسائل الصادرة وتغييرات الملفات. هذه هي الاستدعاءات التي ستحتاج فيها مراجعة الحادث إلى الوسائط الدقيقة والنتيجة الدقيقة، والتي يكون لسجل التدقيق فيها قيمة تتجاوز تصحيح الأخطاء.
  • خذ عينات من القراءات بقوة. يمكن أخذ عينات من الاسترجاع والبحث واستدعاءات API للقراءة فقط بمعدل منخفض عبر أخذ عينات قائم على الرأس عند جذر التتبع، أو أخذ عينات قائم على الذيل مرتبط بحالة الخطأ. المعلومات المفقودة صغيرة لأن القراءات قابلة لإعادة الإنتاج.
  • احتفظ بملخصات منظمة على مستوى المسار. لكل مسار مكتمل، خزّن سجلًا مضغوطًا: الخطة، والقائمة المرتبة لأسماء الأدوات، والنتيجة، وإجماليات الـ token، وتفصيل زمن الاستجابة. هذا يحفظ شكل ما حدث دون الحمولات.
  • احتفظ بالحمولات الخام عند الفشل فقط. عندما ينتهي مسار بخطأ، أو بتفعيل guardrail، أو بفشل ظاهر للمستخدم، رقِّ التتبع الكامل إلى تخزين دائم. هذه قاعدة قائمة على الذيل وهي الإعداد الأعلى أثرًا في السياسة.
  • حدّد الاحتفاظ حسب فئة القرار، لا حسب الخدمة. قد يستدعي استدعاء يغيّر الحالة نافذة طويلة؛ وقد يستدعي span قراءة ساعات. التعبير عن الاحتفاظ كخاصية لفئة القرار يجعل السياسة واضحة وقابلة للمراجعة عندما يتغير سلوك الوكيل.

آلية ملموسة: أضف إلى كل span وقت الإصدار سمة فئة قرار — read، mutate، decide — يضبطها غلاف الأداة لا المستدعي. ثم يوجّه المجمّع بناءً على تلك السمة. تذهب spans التغيير إلى تخزين كامل الدقة بنافذة طويلة؛ وتذهب spans القراءة إلى تيار مُعاين بنافذة قصيرة؛ وتحتفظ spans القرار بالسمات وتُسقط الحمولات. وتُعالَج ترقية الفشل بواسطة معالج الذيل في المجمّع، الذي يخزّن التتبع مؤقتًا لفترة وجيزة ثم يمرّر الكل عندما يحمل span الجذر حالة خطأ. لا يتغير كود الوكيل؛ تعيش السياسة في الغلاف وإعدادات المجمّع، وكلاهما مُصدَّر بإصدارات مع الوكيل.

المقايضة، مصاغة بصدق

يقلل أخذ العينات الأدلة المتاحة لمراجعة الحوادث. هذه هي التكلفة، وهي حقيقية. القراءة التي استُبعدت بأخذ العينات لا يمكن إعادة بنائها بعد وقوعها، وقد لا يكون الفشل الذي يتبين أنه مهم هو الفشل الذي ضُبطت له قاعدة الذيل.

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

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

تكلفة القياس عن بُعد خاصية من خصائص تصميم الوكيل. تعامل معها على هذا الأساس.

لقطة قريبة للوحة دائرة إلكترونية تُظهر الشرائح وأنماط التتبع المعقدة

مشاركةXLinkedInرابط دائم5 دقيقة قراءة

قراءات ذات صلة

الأسئلة التي يجيب عنها هذا

Why do agent workloads cost more to observe than ordinary services?

Each user request fans out into planning, tool calls, validation and retries, and each of those stages emits its own spans, events and payloads. Volume scales with steps rather than with requests, and prompt and completion payloads scale with token count rather than request count.

What is decision-class sampling?

It is a policy that classifies every span as a read, a mutation or a decision, annotates it at emission time, and routes it accordingly: full fidelity and long retention for mutations, aggressive sampling for reads, attributes without payloads for decisions.

Why must the policy be set before the agent ships?

Retrofitting sampling destroys the baseline. Traces collected before the change are not comparable with those collected after, so the first post-change incident is diagnosed against a different evidence set than earlier ones.

How are raw payloads kept without storing everything?

A tail-based rule buffers each trace briefly and promotes the full payload to durable storage only when the trajectory fails, trips a guardrail or ends in an error. Completed trajectories keep a compact structured summary instead.