قابلية رصد وكلاء البرمجة: الحالة والسجلات وإشارات الفشل المهمة

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

هذه الفجوة هي ما يُفترض أن تسدّه قابلية مراقبة وكلاء البرمجة. فقابلية المراقبة، المستعارة من هندسة الأنظمة، هي القدرة على فهم ما يفعله عملية قيد التشغيل من خلال الإشارات التي تصدرها، دون الاتصال بها مباشرةً (لدى OpenTelemetry مقدمة جيدة عن هذا). وبالنسبة لوكلاء البرمجة، المعيار هو: أن تكون قادرًا على الإجابة عن سؤال «ما الذي يفعله كل وكيل، وما الذي فشل، وما الذي يحتاج إلى تدخّل بشري» من خلال عرض مشترك، لا من خلال متابعة جلسة واحدة. ومعظم الإعدادات لا تستطيع ذلك. لديها حالة في مكان ما وسجل في مكان آخر، وتسمّي ذلك قابلية مراقبة. لكنه ليس كذلك.

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

الحالة والسجلات وإشارات الفشل ثلاثة أشياء مختلفة

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

الحالة هي الملخّص العام لتشغيل ما. قيد التشغيل، في انتظار إدخال، منتهٍ، أو فاشل. إنها حقل واحد، رخيص القراءة، وتخبرك أين وصل التشغيل، لا ما الذي فعله. الحالة ليست قابلية مراقبة؛ إنها أصغر حقيقة عن التشغيل.

السجلات هي أثر التنفيذ الخام. كل استدعاء أداة، وكل تعديل ملف، وكل استجابة من النموذج، بالترتيب. تخبرك السجلات بما حدث بعد أن تعرف بالفعل أن شيئًا ما قد فشل. وهي لا غنى عنها في تحليل ما بعد الحادث، لكنها بلا جدوى كإشارة حيّة، لأن لا أحد يراقب خمسة سجلات تتحرك في آنٍ واحد. السجل ليس إشارة حتى يستخرج منه شيء ما معنى.

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

الفخ هو التوقف عند أول طبقتين. فالحالة مع السجلات تبدو وكأنها قابلية مراقبة، لأن لديك حالة وسجلًا. لكن السؤال الوحيد القابل للتوسّع، «أيّ من وكلائي يحتاجني؟»، يعيش بالكامل في الطبقة الثالثة.

إشارات الفشل التي تهمّ فعلًا

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

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

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

كم تحتاج من قابلية المراقبة، حسب حجم الفريق

لا تحتاج الإشارات الست كلها من اليوم الأول. فالكمّ الصحيح من أدوات القياس يتناسب مع عدد الوكلاء الذين يعملون وعدد الأشخاص الذين يحتاجون إلى رؤيتهم.

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

حيث تكفي السجلات الخام وبيئة تشغيل واحدة

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

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

قابلية المراقبة عندما تعود النتائج إلى المهمة

تغيّر طبقة المهام وحدة قابلية المراقبة من «عملية في لوحة» إلى «مهمة بحالة». هذا هو التحوّل الذي بُنيت Sharkly حوله، وهو ينطبق على الإشارات الثلاث في آنٍ واحد.

يرتبط كل تشغيل وكيل بمهمة. وتعود الحالة والتقدّم والعوائق والنتائج إلى الخط الزمني لتلك المهمة بدلًا من أن تعيش في سجل لا يراه أحد غيرك. وتظهر إشارات الفشل في مكان واحد: التشغيلات التي تحتاج إلى تدخّل بشري تهبط في صندوق الوارد، فيتوقف السؤال عن كونه «هل انتهى أي شيء؟» ويصبح «هذا ما يحتاج إلى قراري». يبحث الوكلاء وينفّذون ويختبرون ويقدّمون تقاريرهم؛ ويحدّد البشر الاتجاه ويمنحون الصلاحية ويقبلون النتيجة. تتوقف الأتمتة حيث يُشترَط حكم الفريق.

الحدّ الفاصل مهم، لأنه من السهل أن تفترض خطأً. لا تشغّل Sharkly الوكيل ولا تكتب الكود. فلا تزال Claude Code وCodex وبيئات التشغيل الأخرى التي تستخدمها بالفعل هي من ينفّذ. تضيف Sharkly طبقة المهمة المشتركة والحاسوب والسياق والمراجعة حولها، بحيث تبقى السياق والتقدّم والعوائق والنتائج والمراجعة البشرية ظاهرة من الطلب حتى الإصدار. وللصورة الأكمل لما ينبغي أن تعرضه تلك اللوحة المشتركة، انظر ما تحتاجه لوحة تحكم وكيل البرمجة بالذكاء الاصطناعي فعلًا، ولزاوية المراقبة الحيّة، انظر كيفية مراقبة وكلاء البرمجة الذين يعملون بالتوازي.

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

الأسئلة الشائعة

هل قابلية مراقبة وكيل البرمجة هي نفسها التسجيل؟ لا. التسجيل يخزّن ما حدث. أما قابلية المراقبة فهي القدرة على الإجابة عن سؤال ما الذي يفعله كل وكيل، وما الذي فشل، وما الذي يحتاجك، دون قراءة تلك السجلات واحدة تلو الأخرى. فالسجلات مدخل واحد إلى قابلية المراقبة، لا كلّها.

ما أهم إشارة فشل واحدة يجب قياسها أولًا؟ التوقّف الصامت. فالوكيل الذي يقرأ «قيد التشغيل» بينما ينتظر إلى الأبد موجهًا لم تره قط هو أكثر الطرق شيوعًا لموت العمل المتوازي بهدوء. اجعل التشغيلات المحجوبة ترفع راية قبل أن تسعى وراء أي شيء أكثر تعقيدًا.

هل يمكنني الحصول على ذلك من المخرجات المدمجة لوكيل البرمجة لديّ؟ لوكيل واحد، نعم. أثر الجلسة من بيئة التشغيل نفسها كافٍ. لكن المخرجات المدمجة لا تملك عرضًا عابرًا للوكلاء، لذا لا تستطيع إخبارك أيّ من خمسة تشغيلات يحتاجك، وهو بالضبط السؤال الذي يظهر بمجرد أن تتجاوز وكيلًا واحدًا.