كيف تجعل وكيل الذكاء الاصطناعي موثوقًا: خطة من ثماني خطوات من القياس إلى العمل المستقل

لماذا يبقى الوكيل غير موثوق حتى مع نموذج قوي

موثوقية الوكيل خاصية للنظام كله، وليست للنموذج وحده. المهمة الطويلة تتكون من عشرات الخطوات، والأخطاء تتراكم: إذا كانت دقة كل خطوة 95%، فإن نحو 60% فقط من التشغيلات تنجح في عشر خطوات دون خطأ (0.95^10 ≈ 0.60)، وأقل من 10% في خمسين خطوة. لا يمكنك رفع دقة النموذج مباشرة، لكن يمكنك التقاط الخطأ في الخطوة التي وقع فيها، وجعل تكلفته منخفضة. وهذا ما يفعله الهارنس: التعليمات والأدوات والبيئة والحالة والتغذية الراجعة، كلها مبنية حول النموذج.

تنتقل الخطة التالية من «التقدير بالإحساس» إلى موثوقية قابلة للقياس، ثم إلى العمل المستقل. الخطوات مرتبة حسب أثرها، وكل خطوة تبني على ما قبلها.

الخطوة 1: توقف عن التقييم بالإحساس

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

| التاريخ | المهمة           | ما الذي حدث                     | النظام الفرعي  |
|---------|------------------|---------------------------------|----------------|
| 10/10   | خصم السلة        | «اكتمل»، لكن e2e لم يُشغَّل     | التغذية الراجعة |
| 10/10   | webhook الدفع    | لم يستطع تشغيل قاعدة البيانات   | البيئة         |
| 11/11   | refactor للـ API | كرّر حلًا سبق رفضه              | الحالة         |

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

الخطوة 2: أدخل مؤشرين: MTBF وMTTR

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

السعي وراء وكيل لا يخطئ أبدًا سباق بلا نهاية. أما تقليل MTTR فيمكن أن يتم غالبًا خلال يوم واحد، لذلك ابدأ بالرقم الثاني.

الخطوة 3: اجعل الخطأ رخيصًا

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

• التزامات صغيرة ونظيفة——يمكن التراجع عن أي تعديل بأمر واحد.
• العزل——يعمل الوكيل في فرع منفصل أو نسخة عمل مستقلة، مثل git worktree، وفي صندوق رمل بلا وصول إلى الإنتاج.
• سكربت إعادة ضبط البيئة——تعود قاعدة البيانات والتبعيات والخدمات إلى حالتها الأولى بأمر واحد.

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # إعادة إنشاء قاعدة البيانات، وتطبيق الترحيلات، وتحميل البيانات الثابتة

قِس بالساعة المدة اللازمة للعودة الكاملة إلى حالة صالحة للعمل. هذا هو MTTR الخاص بك. وحدّد أيضًا نطاق الضرر: حد أقصى لحجم الفرق (diff) في المهمة الواحدة، ومنع تعديل الملفات خارج نطاقها.

الخطوة 4: أغلق حلقة التغذية الراجعة

بدون فحوصات يكون الوكيل قاضيَ نفسه الوحيد، ويعتقد بصدق أن العمل قد اكتمل. امنحه أوامر يتحقق بها من نفسه، واجعلها إلزامية.

• الفشل السريع (fail-fast):يتوقف الفحص عند أول خطأ برسالة واضحة، بدل أن يطبع مئة سطر من الضوضاء.
• فحوصات سريعة بعد كل تعديل:المدقق وفحص الأنواع عبر خطاف الوكيل.
• التكرار:فحص ثانٍ مستقل للخاصية نفسها، مثل سيناريو E2E فوق اختبارات الوحدة. فاختبارات الوحدة الناجحة لا تثبت أن الميزة تعمل عند المستخدم.

اكتب معيار «الاكتمال» كشرط قابل للتحقق: «سيناريو E2E لإتمام الطلب بكوبون يمر بنجاح»، لا «تم تنفيذ الخصم».

الخطوة 5: انقل الذاكرة إلى الملفات

الوكيل لا يتذكر الجلسة السابقة. كل ما يلزم لمواصلة العمل يجب أن يوجد في المستودع: الهدف، والمنجَز وكيفية التحقق منه، والقرارات مع أسبابها، والطرق المسدودة، والخطوة التالية. والعلامة الجيدة أن تبدأ جلسة جديدة، تتلقى المستودع وكلمة «تابع» فقط، ثم تبدأ عملًا مفيدًا على الفور.

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

الخطوة 6: مهمة واحدة في كل مرة

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

• حافظ على WIP=1: ميزة واحدة حتى نتيجة موثّقة.
• قطّع المهام إلى أجزاء صغيرة: قدرة واحدة يمكن التحقق منها للمستخدم، في 1 إلى 3 ملفات، وتحقق يستغرق أقل من دقيقة.
• أنشئ BACKLOG.md كمنفذ لما يُلاحَظ «على الهامش»: إذا لاحظ الوكيل خللًا مجاورًا، فليُسجَّل في سطر واحد في قائمة المهام، لا يُصلَح من تلقاء نفسه.

الخطوة 7: افصل المنفِّذ عن المُدقِّق

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

الخطوة 8: أطلق الوكيل في حلقة مستقلة

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

الهدف:   اجتياز سيناريو e2e للدفع بكوبون
التحقق:  make lint && make test && make e2e
التوقف:  بلوغ الهدف أو 15 محاولة أو ساعتان ← استدعاء إنسان

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

قواعد الاستقلالية الآمنة

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

أخطاء شائعة على هذا الطريق

البدء بإعادة كتابة التعليمات

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

إصلاح كل شيء دفعة واحدة

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

الخلط بين «الاختبارات خضراء» و«الميزة تعمل»

قد يكتب الوكيل اختبارًا يتحقق من تنفيذه هو، لا من المتطلب، فيبقى هذا الاختبار أخضر دائمًا. الحماية هي التحقق على مستوى المستخدم (سيناريو E2E)، يُكتب قبل التنفيذ أو يكتبه مُدقِّق مستقل، مع قاعدة تقول إن الوكيل لا يعدّل الاختبار ليمر.

تعطيل الفحوصات من أجل السرعة

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

جعل تحليل الاستئصال (ablation) الخطوة الأولى

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

سلّم النضج

الخلاصة

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