تصحيح أخطاء وكيل الذكاء الاصطناعي: لوحة التحكم الخاصة بك تعرف التكلفة وليس السبب.

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

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

الخطأ الذي لا يمكنك إعادة إنتاجه

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

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

لا يهم أي نموذج اختاره الموجّه للتشغيل (GLM 5.3 Flash أو أي شيء آخر): بمجرد خروج العملية، يختفي الاستدلال معها. الأدلة كانت موجودة فقط أثناء التشغيل: المطالبات، استدعاءات الأدوات، المخرجات، الفروقات. إذا لم يسجّلها شيء، فإن "لماذا غيّر ذلك الملف" ليس لها إجابة. لديها نظريات.

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

ماذا يقيس لوحة المعلومات، وما الذي يتخطاه؟

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

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

تصف لوحةُ المعلوماتٍ التشغيلةَ من الخارج: أنها حدثت، وماذا كانت تَزِن، وماذا كلّفت. لا يمكنها أن تُسلّمك التشغيلةَ نفسَها؛ فـ«لماذا» ليست خاصيةً من خصائص الوصف، بل خاصيةً من خصائص التسلسل.

• كم كانت تكلفة التشغيل؟ — لوحة معلومات التكلفة {{1}}تجيب عن ذلك{{/1}} مقابل التتبع المسجَّل {{2}}يجيب عن ذلك{{/2}}

• لماذا غيّر الوكيل ذلك الملف؟ — لوحة التكاليف: لا إجابة مقابل التتبع المسجّل. التعديل، بالتسلسل، مع الفرق.

• أيّ فحص فشل في تشغيلٍ أخضر؟ — لوحة التكاليف: لا إجابة مقابل التتبّع المسجّل: الفحص، مع رمز خروجه

• هل يمكنني إعادة إنتاج الفشل نفسه بالضبط؟ — لوحة التكلفة: لا، بينما الأثر المسجَّل: نعم، دون اتصال، وبدون أي تكلفة.

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

قراءة تشغيل واحد كخط زمني

مع التسجيل، يتوقف تصحيح الأخطاء عن كونه علم آثار ويصبح قراءة. علم الآثار هو ما تفعله دون تسجيل: git reflog، إدخالات stash، سجل الأوامر، وتذكُّرك الخاص لما طلبتَه في وقتٍ سابق من ذلك اليوم. القراءة هي ما تفعله مع تسجيل: افتح الخط الزمني ومرِّر.

يعرض الخط الزمني العملية بالترتيب الذي حدثت به: المطالبة التي بدأتها، وكل استدعاء أداة، وكل تعديل ملف مع الفرق (diff)، وكل فحص، وكل رمز خروج. تُلتقط لقطة نظام الملفات مرة واحدة لكل جولة وليس لكل استدعاء أداة، وهذا كافٍ لرؤية حالة المستودع في كل خطوة من المحادثة دون الغرق في الضوضاء الناتجة عن كل استدعاء. وما يجعل هذا تصحيحًا للأخطاء لا مجرد تصفح هو التجاور: فالتعديل والفحص الذي كشف الخطأ يتجاوران بالترتيب دون أي شيء بينهما للتكهن. «لماذا» هي في معظمها خاصية من خصائص التجاور.

مثال ملموس مقروء من إصلاحٍ مُسجَّل: 14 حدثًا، من بينها تغيير الملف المعروض بالشكل +1 -3 وفحصٌ فاشل برمز الخروج 1. التعديل، ثم الفحص الذي فشل بسببه، متجاوران في السجل. هذا هو الفرق برمّته بين إعادة بناء تشغيلٍ من شظايا وقراءة تشغيلٍ واحد. وله أهمية قصوى لدى وكلاء البرمجة عبر الطرفية، الذين مساحة عملهم طرفيةٌ تنغلق لحظة اكتمال المهمة؛ فالخط الزمني هو سجلّ التمرير الذي يبقى.

مسجَّل أو مستنتَج: ما تعرفه بيانات التتبع مقابل ما توصّلت إليه

الخط الزمني يخبرك بما حدث بالترتيب. الرسم البياني السببي يخبرك بما أدى إلى ماذا، والفجوة بين هذين هي المكان الذي يجب فيه كسب الثقة.

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

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

إعادة إنتاجه بقدر ما تشاء مجانًا

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

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

الأداة أيضًا ليست صندوقًا أسود.OrcaReplayهي مفتوحة المصدر بموجب رخصة Apache-2.0، وتنسيق التتبُّع مرخّص بموجب CC BY 4.0، لذا يمكن لأي شخص إعادة تنفيذها؛ فتسجيلاتك ليست رهينةً لتنسيقٍ مملوك، ولا تسجيلاتنا كذلك. وهي مُختبَرة فعلًا وليست مجرد عرضٍ توضيحي: 1393 اختبارًا على Node 20 وNode 22. يمكنك قراءة المصدر والتحقق من التنسيق وتشغيل مجموعة الاختبارات بنفسك قبل أن تثق بها في تشغيلات فريقك.

الخلاصة

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

الطريقة بأكملها تتكون من أربع خطوات:

• سجّل الأشواط.

• اقرأ الخط الزمني.

• تحقق من حواف الرسم البياني.

أعد تشغيل ما يخيفك مجانًا بقدر ما تشاء.

ملاحظة حول المصادر: كل رقم في هذه المقالة مُبلغ عنه من البائع، من منتجنا الخاص ومن مستودع OrcaReplay ووثائقه: سلوك رمز الخروج لتشغيل ما، والإصلاح المسجَّل المكوَّن من 14 حدثًا مع فارقه +1 -3 وفحص رمز الخروج 1، وتسمية الحواف في رسم أوركا البياني، وإيقاع اللقطات مرة واحدة لكل دورة، وإعادة التشغيل دون اتصال مع حجب الشبكة، ومجموعة الاختبارات المكوَّنة من 1393 اختبارًا على Node 20 وNode 22. لا تُستشهد بأي قياسات من جهات خارجية في أي مكان في هذه المقالة. مجموعة الاختبارات المكوَّنة من 1393 اختبارًا هي الادعاء الوحيد الذي يمكنك التحقق منه بنفسك، عبر استنساخ المستودع وتشغيله. جميع البنود تم التحقق منها آخر مرة في 2026-09-04.