# لماذا يقول وكيل ذكاء اصطناعي «تم» بينما العمل لم يكتمل
> التحايل على المكافأة، ومعايير الإنجاز، والقبول المستقل، وموجّهان جاهزان للاستخدام للتحقق من النتيجة الفعلية.
Source: https://ailoot.ai/blog/ar/ai-agent-says-done/
Canonical: https://ailoot.ai/blog/ar/ai-agent-says-done/
Language: ar
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-202
Revision: sha256-b5281e8b2236ea70af93977ffc42d07bf18e1d9d1c4adebb40b9f0f012d66e5d
تشرح [وثائق Ailoot](https://ailoot.ai/docs/) كيفية ربط النماذج والعمل مع واجهة API.
## كيف خرج نموذج من OpenAI من بيئة الاختبار المعزولة واخترق Hugging Face؟
الخلاصة
أخضعت OpenAI نماذجها لاختبار للأمن السيبراني في بيئة مغلقة. لم تحل النماذج المهام، بل عثرت على ثغرة في البرنامج الوحيد الذي كان بإمكان البيئة من خلاله الاتصال بالعالم الخارجي، ووصلت إلى الإنترنت المفتوح، واخترقت خوادم Hugging Face الإنتاجية، وحاولت الحصول منها على الإجابات الجاهزة للاختبار. وأعلنت الشركتان عن ذلك في يوليو 2026.
أولًا، الوقائع؛ ثم لماذا يهمك هذا الأمر.
قاست OpenAI ما تستطيع نماذجها فعله في الأمن السيبراني الهجومي. واستخدمت اختبار ExploitGym، الذي يتضمن 898 مهمة تتطلب تحويل ثغرة معروفة إلى استغلال يعمل، أي برنامج جاهز يستخدم تلك الثغرة. ولمعرفة الحد الأقصى الحقيقي لقدراتها، عطّلت مرشحات الأمان المدمجة التي تمنع النموذج عادةً من القيام بأمور كهذه. وعزلت البيئة بالكامل، مع الإبقاء على منفذ واحد للخروج: برنامج وسيط داخلي يُستخدم لتثبيت الحزم.
أثناء العمل في بيئة الاختبار المعزولة لدينا، أمضت النماذج جزءًا كبيرًا من مواردها الحاسوبية في البحث عن طريقة للوصول إلى الإنترنت المفتوح لحل المهمة. وللحصول على هذا الوصول، عثرت النماذج على ثغرة من فئة zero-day في وكيل التخزين المؤقت لسجل الحزم واستغلتها.
— OpenAI, https://openai.com/index/hugging-face-model-evaluation-security-incident/
ثغرة zero-day هي ثغرة لا يعرف بها أحد بعد، بمن في ذلك الشخص الذي كتب البرنامج. وقد عثرت النماذج على واحدة في منفذ الخروج الوحيد نفسه.
بعد ذلك، رفعت صلاحياتها، وانتقلت عبر الشبكة الداخلية إلى جهاز يتصل بالإنترنت، ثم خمّنت أن إجابات ExploitGym قد تكون على Hugging Face. لم يخبرها أحد عن Hugging Face؛ بل استنتجت ذلك بنفسها.
كان التخمين خاطئًا. لا يوجد ExploitGym على Hugging Face إطلاقًا. لكن ذلك لا يقلل من حقيقة الاختراق.
اكتشفت Hugging Face التسلل بنفسها ونشرت بيانًا عنه في 16 يوليو، من دون أن تعرف آنذاك من اخترقها.
كان هذا الحادث مختلفًا عن أي شيء واجهناه من قبل في جانب مهم واحد: فقد تحكم نظام مستقل من وكلاء الذكاء الاصطناعي بالهجوم من بدايته إلى نهايته، كما اكتشفناه وحللناه في المقام الأول باستخدام ذكائنا الاصطناعي.
— Hugging Face, https://huggingface.co/blog/security-incident-july-2026
وثمة تفصيل آخر في ذلك البيان يكشف الكثير عن الوضع الراهن. عندما حاول مهندسو Hugging Face إدخال سجل الهجوم إلى نماذج رائدة عبر الواجهات التجارية المعتادة، حظرت مرشحات الأمان الطلبات؛ فهي لا تميز بين من يحقق في اختراق ومن ينفذه. وفي النهاية، أُجري التحليل على نموذج مفتوح باستخدام أجهزتهم الخاصة.
أقرت OpenAI بالأمر في 21 يوليو، بعد خمسة أيام من بيان Hugging Face. وكان قد مضى آنذاك نحو عشرة أيام على التسلل نفسه.
وهكذا ختمت OpenAI تحليلها.
تشير جميع البيانات إلى أن النماذج ركزت بشدة على إيجاد حل لـ ExploitGym، واتخذت تدابير قصوى لتحقيق هدف اختبار محدود إلى حد بعيد.
— OpenAI, https://openai.com/index/hugging-face-model-evaluation-security-incident/
انشغل النموذج بالهدف الضيق للاختبار، ولجأ إلى أقصى التدابير لتحقيقه. والتعبيران `hyper-focused` و`fairly narrow testing objective` من صياغة OpenAI نفسها، وهما يشيران إلى نماذجها.
هذا هو الجسر بين مختبر شخص آخر وحاسوبك المحمول.
## لماذا لا يُعد هذا «هلوسة»؟
الخلاصة
الهلوسة هي أن يختلق النموذج شيئًا غير موجود. أما هنا فالأمر مختلف: لم يختلق الوكيل شيئًا، بل استوفى بصدق واكتمال المقياس الذي أُعطي له معيارًا للإنجاز. تحقق المقياس، لكن المهمة لم تُحل. تختلف الأسباب، وكذلك الحلول، لذا يجدر التمييز بينهما قبل البدء في إصلاح الأمور.
كثيرًا ما أرى في المحادثات عبارات مثل «ها هو يهلوس مجددًا»، أو «السياق صار مثقلًا»، أو «كان ينبغي أن نضع خطة». وأحيانًا يكون هذا بالضبط ما حدث. لكن عندما يكتب وكيل ذكاء اصطناعي «تم، تحققت، كل شيء يعمل» بينما لم يكتمل العمل، فعادةً لا تكون كمية السياق ذات صلة.
لم يختلق شيئًا. لقد فعل بالضبط ما قسته.
نضع ثلاثة إخفاقات مختلفة تحت الكلمة الشائعة الجامعة «الهلوسات». إليك أوجه اختلافها:
| ما الذي حدث | كيف يبدو | كيفية إصلاحه |
|----|----|----|
| **الاختلاق** | يشير إلى دالة غير موجودة؛ يخترع مكتبة؛ يصف ملفًا غير موجود | السياق: بنية المشروع، `CLAUDE.md`، خطة، وضجيج أقل في نافذة السياق |
| **التملق** | يجيب «نعم، بالطبع» على كل اقتراح، ويوافق على تغيير خاطئ، ولا يعترض | طريقة صياغة الطلب منذ البداية: امنع الافتراضات، واطلب الاعتراض |
| **التلاعب بالمقياس** | عمل بصدق، وتحقق بصدق، وأبلغ بصدق، لكنه أخفق تمامًا في تحقيق الهدف | طريقة تعريف معيار الإنجاز: ما الذي تقيسه تحديدًا على أنه «تم» |
يُعالج الأول بالسياق، وهو الحالة الأشهر. والثاني ظاهرة مستقلة تناولها تحليل [موافقة Claude على كل شيء](https://ailoot.ai/blog/ar/claude-code-sycophancy-prompts/): يضحي النموذج بالدقة كي يوافق بسرعة. ويحدث كلاهما **قبل** العمل، في مرحلة الإدخال.
أما الصف الثالث في الجدول فهو موضوع هذا المقال. لم يتملق الوكيل ولم يختلق. بل عمل وتحقق وأبلغ بالحقيقة. غير أن هذه الحقيقة تصف المقياس ولا تقول شيئًا عن المهمة.
للإخفاق الثالث اسم.
## ما المقصود بالتحايل على المكافأة ببساطة؟
الخلاصة
يحدث التحايل على المكافأة عندما يجد النموذج ثغرة ويحصل على درجة عالية باتباع حرفية المهمة من دون تحقيق غايتها. وفي البرمجة، يعني ذلك تعديل الاختبار، أو استبدال دالة التحقق، أو البحث عن إجابة جاهزة. وقد وثّقت Anthropic وOpenAI وDeepMind هذه الظاهرة.
تقدم Anthropic التعريف بنفسها.
نطلق على الخداع الذي ينتج عنه هذا الانحراف اسم «التحايل على المكافأة»: إذ يخدع الذكاء الاصطناعي عملية تدريبه ليحصل على درجة عالية رغم أن المهمة لم تُنجز فعليًا. وبعبارة أخرى، وجد النموذج ثغرة عبر التحايل على المهمة، وهي طريقة للحصول على المكافأة باتباع حرفية المهمة لا روحها.
— Anthropic, https://www.anthropic.com/research/emergent-misalignment-reward-hacking
الفكرة أقدم من الشبكات العصبية. وتسميها ورقة من DeepMind «التلاعب بالمواصفات»، وتشرحها من خلال أسطورة.
لعل القراء يتذكرون أسطورة الملك ميداس ولمسته الذهبية: طلب الملك أن يتحول كل ما يلمسه إلى ذهب، ثم اكتشف سريعًا أن الطعام والشراب اللذين في يديه يتحولان أيضًا إلى معدن.
— DeepMind، https://deepmind.google/discover/blog/specification-gaming-the-flip-side-of-ai-ingenuity/
حصل ميداس على ما طلبه بالضبط. وكانت المشكلة في صياغة الطلب.
وفي البرمجة، يتخذ الأمر أشكالًا ملموسة. إليك مثالًا نموذجيًا من Anthropic أيضًا:
إحدى هذه الاستراتيجيات هي استدعاء sys.exit(0) للخروج من بيئة الاختبار برمز إرجاع يساوي صفرًا؛ فيبدو الأمر كما لو أن جميع عمليات التحقق نجحت. وفي البرمجة، يعادل ذلك كتابة «ممتاز» في أعلى ورقتك بدلًا من تعلم المادة وكتابة الورقة جيدًا.
— Anthropic, https://www.anthropic.com/research/emergent-misalignment-reward-hacking
وهذا ليس ظرفًا مختبريًا غريبًا. فقد حللت Cursor عددًا قدره 731 من المسارات في معيار شائع.
في SWE-bench Pro، وجدنا أن Opus 4.8 Max استرجع إصلاحًا جاهزًا بدلًا من اشتقاق حل مستقل في 63% من الحلول الناجحة. وفي 57% من المسارات، عثر النموذج على إصلاح سبق أن قبله شخص آخر ونشره للعامة، ثم أعاد إنتاجه شبه حرفيًا. وفي 9% أخرى، فتش في سجل المستودع المرفق عن التزام مستقبلي يتضمن الإصلاح، واسترجعه منه.
— Cursor, https://cursor.com/blog/reward-hacking-coding-benchmarks
ست مهام من كل عشر مهام «محلولة» هي إجابات عُثر عليها. وهذا بالضبط سبب تغيير القطاع لطريقة قياس الأداء: لدينا تحليل [لمعيار يقيس الجاهزية للإنتاج](https://ailoot.ai/blog/ar/frontiercode-benchmark-mergeable-ai-code/)، حيث لم يعد اجتياز عمليات التحقق المعيار الأساسي.
## كيف يبدو هذا في منتج عادي؟
الخلاصة
أربع قصص استُوفي فيها المقياس بصدق لكن النتيجة لم تتحقق: فحص لا يشمل جزءًا من النظام؛ أو مهمة قُسمت بين أشخاص ينفذون العمل لكنها فشلت عند نقطة التقاء الأجزاء؛ أو مراجع نظر في الاتجاه الخاطئ؛ أو مقياس يكافئ التشابه.
من السهل اعتبار الأمثلة المختبرية حالات غريبة. لذا إليك أربع قصص من الممارسة العملية. جرى تغيير العملاء والقطاعات، لكن الآليات بقيت كما هي.
### أربعة فحوص ناجحة ومكوّن خدمة متوقف
تعمل وكالة عقارات على بناء خدمة: موقع إلكتروني بقوائم العقارات، بالإضافة إلى معالج خلفي منفصل يصدّر القوائم إلى المنصات ليلًا. ينجز الوكيل المهمة ويبلغ بأن فحص الأنواع اجتاز، وفحص أسلوب الشيفرة اجتاز، والبناء ناجح، والصفحات تستجيب، وقد فُحصت بصريًا.
كل عبارة صحيحة. ولا علاقة لأي منها بالمعالج الليلي: فهو يعمل كعملية منفصلة ولا يدخل في بناء الموقع أصلًا. ينجح النشر ويعمل الموقع تمامًا، لكن تصدير القوائم يتوقف، ولا يبلغ العملاء بذلك إلا في اليوم التالي.
قبل أن أقول «تم»، أسأل الآن سؤالًا واحدًا: ما جزء العمل الذي يعمل خارج نطاق الفحص الذي أجريته؟ إذا وُجد شيء كهذا، شغّله منفصلًا وأدرج ناتج الأمر في التقرير. كلمة «تم التحقق» لا تحسم الأمر.
### علامة النجاح الخاطئة تظهر عند نقطة التقاء الأجزاء
يقسّم متجر إلكتروني مهمة كبيرة بين عدة وكلاء في الوقت نفسه: أحدهم يتولى الواجهة الخلفية، والثاني الصفحات، والثالث بطاقات المنتجات. يعمل كل منهم بجد، وتجتاز فحوصهم جميعًا.
وبعد أسبوع، يتضح أن زر «كان هذا التقييم مفيدًا» لا يعمل في أي مكان. كُتبت الواجهة الخلفية بالكامل، وفحوصها ناجحة، واتُّبعت قواعد إعادة الحساب. لكن لا توجد أي صفحة تعرض الزر: كان الزر ضمن نطاق وكيل، والصفحات ضمن نطاق آخر، ولم يفكر أحد في وضعه على الشاشة. وكان العداد سيظل عند الصفر إلى الأبد.
«كُتبت الشيفرة وغُطّيت بالفحوص» و«تعمل الميزة» ادعاءان مختلفان. أتحقق من الادعاء الثاني بسؤال واحد لكل ميزة جديدة: **من يستدعيها؟** وأتأكد من ذلك بالبحث في المشروع، لأن تقرير الوكيل ليس مصدرًا موثوقًا هنا.
### لا يرى المراجع إلا الاتجاه الذي طُلب منه فحصه
تضيف خدمة ما مستويات للولاء: كلما زاد ما تدفعه، ارتفعت رتبتك وخصوماتك. وقبل النشر، تُرسل الشيفرة للمراجعة مع التعليمات التالية: «حاول رفع رتبتك بنفسك». يؤدي المراجع عمله بصدق ويبلغ بأنه «لا توجد مشكلات جوهرية»؛ إذ لا يمكن فعلًا رفع الرتبة بهذه الطريقة.
وفي جولة ثانية، يُطرح سؤال مختلف: «ماذا يحدث للرتبة عندما تُسترد الأموال؟» يُكتشف الخلل في عشر دقائق. فقد حُسبت النقاط من سجل المعاملات، ولا يعرف السجل شيئًا عن المبالغ المستردة. اشترِ شيئًا، واكسب نقاطًا، ثم استرد أموالك، واحتفظ بالرتبة والخصم إلى الأبد.
لم يتهاون المراجع الأول. بل **لم يكن بإمكانه بنيويًا** أن يرى الخلل: فقد أُعطي اتجاه «إدخال، ترقية»، بينما كان الخلل في اتجاه «عكس الإدخال، الاحتفاظ بالترقية». عندما تكون الأموال أو صلاحيات الوصول أو الرتب التي يمكن شراؤها على المحك، أجري جولتين، وأعدد صراحةً في الثانية الاتجاهات العكسية: استرداد الأموال، الحظر، إلغاء الوصول، انتهاء الصلاحية، حذف مصدر البيانات.
### المقياس يكافئ التشابه
تقرر خدمة توصيل قياس ما إذا كانت اقتراحات الذكاء الاصطناعي للمشغلين قد تحسنت. فتأخذ مئتي طلب دعم قديم، وتعالجها بالإصدار الجديد، وتقيس مدى تشابه المسودة مع الرد الذي كتبه مشغّل بشري بالفعل. وتُظهر نتائج القياس زيادة واضحة.
لا تعني هذه الزيادة شيئًا، لسببين. يُجمّع سياق المسودة «اعتبارًا من اليوم»، ويشمل كامل المراسلات، بما فيها رد المشغّل نفسه الذي ستُقارن به لاحقًا. فالنموذج لا يكتب ردًا، بل يعيد صياغة الإجابة المرجعية التي عُرضت عليه. فضلًا عن ذلك، يكافئ المقياس نفسه تطابق الكلمات والطول: فتحصل مسودة تذكر تاريخًا **خاطئًا**، مستخدمةً الكلمات نفسها التي استخدمها المشغّل للتاريخ الصحيح، على درجة عالية.
إلى جوار أي مقياس من نوع «التشابه يعني الجودة»، أضع الآن بوابات ميكانيكية صارمة لا يستطيع الأسلوب خداعها: الأرقام والتواريخ المختلقة، وكلمات التوقف، والوعود باتخاذ إجراء. وأي تراجع في نتائج البوابات يلغي أي تحسن في المقياس.
## لماذا لا يثبت قول الوكيل «تحققت» شيئًا؟
الخلاصة
لأن المراجع والشخص الذي يخضع للمراجعة هما الشخص نفسه. فالوكيل نفسه، عندما يُسأل السؤال نفسه عن المشروع نفسه، يقول «كل شيء على ما يرام»، بينما يجد نموذج آخر عشرات المشكلات في المدخلات نفسها. وتشرح Anthropic الآلية مباشرةً في وثائق Claude Code: من دون فحص قابل للتنفيذ، لا يملك الوكيل سوى إشارة واحدة، وهي الشكل الذي يبدو عليه العمل.
خذ أي مشروع لديك واسأل الوكيل: «تحقق من الأمان». كثيرًا ما تكون الإجابة «كل شيء على ما يرام، لا توجد مشكلات جوهرية».
والآن اسأل نموذجًا آخر السؤال نفسه عن المشروع نفسه. سيجد الكثير، لا سيما إذا كان المشروع كبيرًا. وقبل النشر، يفحص الكاتب المشروع باستخدام ثلاثة نماذج مختلفة، ويجد كل واحد منها شيئًا مختلفًا.
المدخلات نفسها، والسؤال نفسه، وحكمان متناقضان. ليس أحد النموذجين أسوأ من الآخر. لكن «كل شيء على ما يرام» نص مولّد، في الطبقة نفسها تمامًا التي تنتمي إليها أي إجابة أخرى. لا يملك الوكيل وسيلة لتمييز «نظرت ولم أجد مشكلة» من «نظرت في المكان الخطأ».
تصف Anthropic هذه الآلية في وثائق Claude Code.
يتوقف Claude عندما يبدو العمل منتهيًا. ومن دون فحص يستطيع تشغيله، تكون إشارة «يبدو منتهيًا» هي الوحيدة المتاحة، وتصبح أنت حلقة التحقق: كل خطأ ينتظر حتى تلاحظه.
— وثائق Claude Code الرسمية، https://code.claude.com/docs/en/best-practices
تأمل الجملة ببطء. إلى أن تعطي الوكيل فحصًا يستطيع **تشغيله**، لن تكون لديه سوى إشارة واحدة: كيف يبدو العمل. وفي هذا الإعداد، تكون أنت حلقة التحقق، لكنك آخر من يعلم بالأخطاء.
وهناك طبقة أعمق. عندما حاولت OpenAI الضغط على نموذج بمراقبة استدلاله ومعاقبته على «الأفكار السيئة»، لم تكن النتيجة كما توقعت.
يظل الوكيل المدرّب تحت الضغط على سلسلة تفكيره يتعلم التحايل على المكافأة؛ لكن خداعه يصبح الآن غير مرئي للمراقب، لأنه تعلم إخفاء نيته داخل استدلاله.
— OpenAI, https://openai.com/index/chain-of-thought-monitoring/
تؤدي معاقبة النية المعلنة إلى اختفاء التصريح، لكن النية نفسها تبقى. لذا لن أراهن على أن الوكيل سيخبرك بصدق كيف غش.
ويتجه مطورو الأدوات أنفسهم في الاتجاه ذاته. ففي إصدار Claude Code 2.1.215، توقفت المهارتان `/verify` و`/code-review` عن العمل بمبادرة من النموذج نفسه.
```
2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them
```
لم تشرح Anthropic السبب. لكن المبدأ واضح: لا يعيّن الشخص الخاضع للمراجعة مراجعته بنفسه.
## لماذا لا تُبقي قاعدة في ملف المشروع الوكيل ملتزمًا؟
الخلاصة
لأن القاعدة المكتوبة في ملف نصي تظل نصًا في السياق، تمامًا مثل آلاف الأسطر الأخرى. عندما يواجه الأداة أمرين: «حقق الهدف» و«قيد نصي في الطريق»، تختار الهدف. وحدها الحواجز الميكانيكية التي لا يمكن تجاوزها تصمد: صلاحيات القراءة، ومنع الحذف، وحدود الإنفاق التي يفرضها المزوّد.
كتبت في ملف قواعد المشروع: لا تنفذ commit إلا إذا طُلب منك ذلك مباشرة؛ ولا تنشر في بيئة الإنتاج إلا إذا قلت ذلك صراحةً؛ ولا تصل إلى بيانات الإنتاج إلا في وضع القراءة فقط.
وفقًا لخبرة الكاتب، يمضي الوكيل في النشر من تلقاء نفسه في نحو مرة واحدة من كل عشر مرات. لا يفعل ذلك عن خبث، ولا لأنه لم يقرأ القاعدة. لقد قرأها. لكن كان أمامه هدف، وكانت القاعدة نصًا، شأنها شأن بقية السياق.
وهذا بالضبط ما حدث في مختبر OpenAI، لكن على نطاق أوسع. كانت النماذج في بيئة مغلقة لها منفذ خروج واحد، وأمضت جزءًا كبيرًا من مواردها الحاسوبية في البحث عن مخرج. وبقيت مهام الاختبار بلا حل.
موقفي هنا بسيط: الوكيل ليس خطرًا ولا خبيثًا. إنه عادي، لكنه أحمق يملك صلاحيات. لذا عليك تقييد صلاحياته، لا إعادة صياغة طلباتك.
ما الذي يصمد فعلًا؟ وصول مقيد بصرامة للقراءة فقط إلى بيانات الإنتاج. منع حذف المجلدات بأكملها. منع الأوامر التي تعيد كتابة سجل التغييرات من دون طريقة لاستعادته. تعيين حد للإنفاق لدى المزوّد. ويمكن تلخيص الفرق بعبارة واحدة: «لا يستطيع فعل ذلك فعليًا» أقوى من «طلبت منه ألا يفعل ذلك». تُشرح الإعدادات المحددة على نحو مستقل في المقال عن [الفرامل الميكانيكية بدلًا من الطلبات في التعليمات](https://ailoot.ai/blog/ar/claude-code-safe-overnight-setup/).
ومع ذلك، حافظ على هدوئك. حتى بيئة الاختبار المعزولة ليست حدًا مطلقًا، والمزوّد يصرح بذلك بوضوح.
تقلل بيئة الاختبار المعزولة المخاطر، لكنها لا توفر حدًا كاملًا للعزل. اقرأ القيود أدناه قبل الاعتماد عليها بوصفها آلية أمان قوية.
— Claude Code Docs, https://code.claude.com/docs/en/sandboxing
وفوق ذلك، يتضمن Claude Code مخرجًا طارئًا مدمجًا يستطيع النموذج نفسه استخدامه. عندما يفشل أمر بسبب قيود بيئة الاختبار، يحلل Claude الإخفاق وقد يعيد تنفيذ الأمر نفسه مع معامل يعطل العزل. ويمكن إغلاق هذا المسار بإعداد صريح للوضع الصارم؛ أما افتراضيًا، فالحل البديل متاح وموثق.
لا يعمل القيد إلا بقدر ما تشدده. ولكل حاجز كلفة على السرعة؛ يجدر حسابها بصدق مسبقًا، لأن اكتشافها بعد أسبوع سيكلف أكثر.
## كيف تضع معيار إنجاز لا يمكن التلاعب به؟
الخلاصة
المعيار الجيد ينتج النتيجة نفسها آليًا، ولا يمكن استيفاؤه بالنص. أما المعيار السيئ فيطلب من الوكيل تقييم عمله بنفسه. واختبار الصياغة بسيط: هل يستطيع الوكيل استيفاء هذا المعيار من دون أن يفعل شيئًا؟ تشرح Anthropic أربعة مستويات من الصرامة يمكنك التدرج فيها كلما ارتفعت كلفة الخطأ.
تحدد صياغة المعيار كل ما يأتي بعدها. اختبرها بهذا السؤال: **هل يستطيع الوكيل استيفاء هذا المعيار من دون أن يفعل شيئًا؟**
- «تحقق من أن كل شيء يعمل» — يستطيع ذلك. يكفي أن يكتب «تحققت، إنه يعمل».
- «شغّل عملية البناء وأرني الناتج» — أصبح الأمر أصعب؛ إذ سيتعين عليه الحصول على الناتج من مكان ما.
- «شغّل التطبيق، واضغط زر الدفع، وأرني ما ظهر على الشاشة» — يكاد يستحيل استيفاء ذلك بالنص وحده.
الفرق بين الطلب الأول والثالث هو الفرق بين التقرير والدليل.
تصف وثائق Claude Code أربعة مستويات من الصرامة، وهي درجات مفيدة تصعدها كلما ارتفعت كلفة الخطأ:
1. **في رسالة واحدة.** اطلب من الوكيل تشغيل الفحص وتكراره حتى ينجح هنا مباشرةً. هذا هو الخيار الأقل كلفة، ويناسب الأمور الصغيرة.
2. **طوال الجلسة.** اجعل الفحص شرطًا لتحقيق الهدف: يفحصه مقيّم مستقل بعد كل جولة، ويعمل الوكيل حتى يتحقق الشرط. تُغطى التفاصيل التقنية في الدليل عن [وضع معيار الإنجاز مسبقًا](https://ailoot.ai/blog/ar/goal-mode-claude-code-codex/).
3. **حاجز ميكانيكي.** يعمل نص برمجي عندما يحاول الوكيل إنهاء جولة، ويمنعه من إنهائها إلى أن يجتاز الفحص. وهناك تفصيل ينبغي ذكره بصراحة: بعد ثماني مرات متتالية من المنع، يتجاوز Claude Code الحاجز وينهي الجولة على أي حال. لا توجد حواجز منيعة تمامًا في النظام.
4. **رأي ثانٍ.** مراجع مستقل بسياق جديد، ومهمته دحض النتيجة.
يختلف البند الرابع لأنه الوحيد الذي لا يتعلق بالأدوات.
## من ينبغي له قبول عمل الوكيل؟
الخلاصة
أي شخص، باستثناء صاحب العمل نفسه. وتنطبق القاعدة على البشر والوكلاء على حد سواء: سيكون صاحب العمل آخر من يرى ثغرة في عمله، لأنه ينظر إليه بالمنطق نفسه الذي استخدمه لإنشائه. وصياغة المهمة التي تُعطى للمراجع أهم من النموذج الذي يستخدمه.
عندما أشغّل الوكلاء في حلقة لإنجاز مهمة كبيرة، يكون الإعداد كالتالي: تكتب مجموعة، وتقبل العمل مجموعة أخرى جديدة لم تشارك في كتابته.
كلمة «جديدة» هي المفتاح. والمقصود بها سياق نظيف لم يشهد كيفية اتخاذ القرارات خلال العمل. ولا يكفي تغيير الموجّه في الجلسة نفسها. فقد استثمر الشخص الذي كتب الشيفرة اهتمامه بالفعل في إقناع نفسه بأنها صحيحة، وسيواصل البحث عما يؤكد ذلك. وليس دحض العمل من مصلحته.
صياغة المهمة التي تُعطى للمراجع أهم من النموذج الذي يستخدمه. قارن بين التالي:
- «راجع هذا العمل» — سيجد المراجع ما يسهل العثور عليه، ثم يكتب «جيد عمومًا».
- «حاول إثبات أن هذا العمل لم يُنجز» — سيبدأ المراجع بالبحث عن الثغرات، لأن ذلك هو هدفه.
تنجح الصياغة الثانية للسبب نفسه الذي أفشل ExploitGym: يلتزم الوكيل بالهدف الذي يُعطى له. امنحه هدف البحث عن ثغرة، وسيبحث عنها.
إليك النص كاملًا، جاهزًا للنسخ كما هو:
الموجّه: مهمة المراجع — دحض النتيجة
```
أنت تراجع عمل شخص آخر. لم تكتبه بنفسك، ولا يتعين عليك الدفاع عنه.
هدفك هو إثبات أن النتيجة المعلنة لم تتحقق. اعثر على ثلاث طرق على الأقل ربما لم تتحقق بها النتيجة رغم نجاح جميع الفحوص.
تحقق بالترتيب التالي:
ما العمل الذي يجري خارج نطاق الفحوص — العمليات الخلفية، والنصوص البرمجية المنفصلة، والمهام المجدولة، ومعالجات قوائم الانتظار.
من يستدعي كل دالة جديدة. اعثر على موضع الاستدعاء بالبحث في المشروع، واذكر الملف والسطر.
المسارات العكسية: استرداد الأموال، والحظر، وإلغاء الوصول، وانتهاء الصلاحية، وحذف مصدر البيانات.
القيم داخل النتيجة، وليس مجرد وجودها.
إذا لم يكشف البحث النزيه أي ثغرات، فقل ذلك، لكن أدرج بدقة ما تحققت منه وكيف فعلت ذلك.
```
يشرح المقال عن [تحقق الوكيل من نفسه في حلقة](https://ailoot.ai/blog/ar/claude-code-loop-engineering/) كيف تعمل الحلقة التي يتحقق فيها الوكيل من نفسه بين التكرارات، وأين تفشل عادةً.
## ما الذي يتغير عندما تعيد صياغة المعيار؟
الخلاصة
يتغير نوع العيوب التي تظهر أصلًا. فعبارة «أجرِ مراجعة للشيفرة» تجعل الوكيل يستدل من داخل الشيفرة، بينما عبارة «تتبّع رحلة العميل من الزيارة الأولى حتى استرداد الأموال» تُظهر أمورًا لا تستطيع مراجعة الشيفرة رؤيتها من حيث المبدأ، لأن كل عيب من تلك العيوب صحيح داخل الشيفرة.
هذا أرخص تحسين أعرفه، ولا يكاد أحد يطبقه.
اطلب من الوكيل مراجعة الشيفرة، وسيفكر بمصطلحات الشيفرة: البنية، ومعالجة الأخطاء، وإعادة المحاولة، والمناطق المعرضة للخطر. وهذا مفيد.
اطلب منه تتبّع رحلة العميل، من الزيارة الأولى للموقع إلى محاولة استرداد الأموال، وستظهر أنواع مختلفة من العيوب. خطأ يعرض للمستخدم شيئًا لا ينبغي له رؤيته. رسالة بريد إلكتروني لا يتطابق نصها مع ما حدث فعلًا. خطوة يستحيل منطقيًا إكمالها إن لم يكن المستخدم قد وصل إليها عبر السيناريو المثالي.
لن تكشف مراجعة الشيفرة أيًا من هذه العيوب، لأنها كلها صحيحة داخل الشيفرة.
وهذا يقود إلى قاعدة أتمسك بها: **إذا لم يعثر الفحص على شيء، فغيّر الصياغة أولًا.** غالبًا ما لا يكون النموذج هو المشكلة. فالعمل نفسه، إذا طُرحت عنه ثلاثة أسئلة بصيغ مختلفة، ينتج ثلاث قوائم مختلفة من النتائج. وقد جُمعت مجموعة عملية من الأسئلة لغير المبرمجين على نحو مستقل: [سبعة فحوص للشيفرة من دون مهارات برمجية](https://ailoot.ai/blog/ar/check-ai-generated-code/).
## موجّه جاهز لقبول عمل الوكيل
الخلاصة
ينقل الموجّه أدناه القبول من «هل أنجزته؟» إلى «أرني». فهو يمنع استخدام كلمة «تحققت» من دون إخراج الأمر، ويطلب التصريح بوضوح بكل ما لم يُفحص، وينتهي بسؤال عما يعمل خارج نطاق الفحص. ألصقه في نهاية المهمة، بعد أن يذكر الوكيل أنه جاهز.
الموجّه: قبول عمل الوكيل
```
لا تجب بكلمتي «تم» أو «تحققت». أحتاج إلى دليل.
لكل بند من بنود العمل، أعطني بالضبط ما يلي:
ما الأمر الذي شغّلته للتأكد من أن البند يعمل؟ أدرج الأمر نفسه وناتجه كاملًا، من دون اختصار.
إذا لم تشغّل الأمر، فقل: «لم يُشغّل». لا تستبدل ذلك بعبارة «تم التحقق بصريًا» أو «المنطق صحيح».
ما العمل الذي يجري خارج النطاق الذي يغطيه فحصك؟ العمليات الخلفية، والنصوص البرمجية المنفصلة، والمهام المجدولة، ومعالجات قوائم الانتظار — أي شيء يبدأ بطريقة مختلفة عن التطبيق الرئيسي. ولكل جزء كهذا: هل شغّلته منفصلًا، وما الناتج الذي صدر عنه؟
من يستدعي كل دالة جديدة أضفتها؟ اعثر على موضع الاستدعاء بالبحث في المشروع، واذكر الملف والسطر. وإذا لم يكن لها استدعاء، فقل ذلك مباشرةً.
ثم أضف قسمًا منفصلًا: ثلاث طرق ربما لم تتحقق بها النتيجة المعلنة رغم نجاح جميع فحوصك. ابحث بجدية.
وفي النهاية، سطر واحد: ما الذي ينبغي أن أفحصه بعيني لأن الفحص الآلي لن يكتشفه؟
```
يبدو البند الرابع بسيطًا، لكنه يلتقط فئة كاملة من المشكلات. في مهمة كبيرة وزعتها على وكلاء بحسب المجالات، كان تقرير «تم» الخاطئ الوحيد من بين مئة تقرير عند نقطة التقاء مجالين: كُتبت الشيفرة، واجتازت الفحوص، لكن أحدًا لم يفكر في إظهارها على الشاشة.
## أربع طرق لخداع نفسك بفحص
الخلاصة
لا تفشل الفحوص فقط عندما تكون غائبة. بل غالبًا ما تكون موجودة وتبدو مقنعة، لكنها لا تضمن شيئًا. يصف الكاتب أربع طرق لخداع النفس: عدم انتظار جميع المراجعين، والثقة بالملخص، وعدم النظر بعينيك، والتحقق من الوجود بدلًا من القيمة. وكل واحدة من هذه الطرق الأربع كلفت الكاتب وقتًا.
1. **لم أنتظر جميع المراجعين.** أطلقت ثلاثة فحوص متوازية، وعاد اثنان منها بالنجاح، فنشرت. وصل الثالث بعد أربع دقائق ومعه ستة انتهاكات. إصلاح شيء بعد النشر يكلف أكثر من الانتظار دقيقتين.
2. **وثقت بملخص «عولج N من N».** عند توزيع المهام على نطاق واسع، تفشل بعض الوكلاء بصمت: يبلغون عن النجاح، لكن الملف يظل بلا تغيير. والآن أتحقق آليًا بعد أي كتابة يجريها وكيل من أن التغييرات موجودة فعلًا على القرص.
3. **لم أنظر بعيني.** قد تنجح الفحوص الآلية مع نتيجة لا تصلح للاستخدام إطلاقًا. الصور صحيحة تقنيًا، والحجم صحيح، ورمز الاستجابة صحيح. لكنها في الواقع إطارات ثابتة مولدة آليًا وُضعت بدلًا من أغلفة مصورة. ولن يكتشف أي فحص آلي ذلك.
4. **تحققت من الوجود بدلًا من القيمة.** بحث الفحص عن النص المطلوب في النتيجة؛ وكان النص موجودًا، لكن البيانات بداخله خاطئة: التاريخ متأخر بيوم. نجح الفحص وكان التقرير كذبًا. والآن أتحقق من القيمة المتوقعة كاملة، لأن وجود الكلمة الصحيحة وحده لا يضمن شيئًا.
تشترك الحالات الأربع في الآتي: كان هناك فحص، وبدا مقنعًا، لكنه تحقق من الشيء الخطأ. إنها الآلية نفسها التي ظهرت مع النماذج واختبارها، لكن من دون أي ابتكار.
## من أين تبدأ اليوم؟
الخلاصة
خذ آخر مهمة أنهاها وكيل بكلمة «تم»، وافحصها بالموجّه الخاص بالقبول في هذا المقال. ثم ضع لنفسك قاعدة واحدة: لا يُعتد بكلمة «تحققت» من دون إخراج الأمر بوصفها إغلاقًا للمهمة. وفي المهمة التالية، افصل بين من يكتب ومن يقبل العمل.
ثلاث خطوات تستغرق عشرين دقيقة.
1. **خذ آخر «تم».** مرره عبر موجّه القبول في القسم الذي يتناول الأدلة. الهدف بسيط: اكتشف كم بندًا أُغلق بالكلمات، وكم بندًا أُغلق بإخراج الأمر.
2. **ضع لنفسك قاعدة واحدة.** لا يُعتد بكلمة «تحققت» من دون إخراج الأمر المرفق بوصفها إغلاقًا للمهمة. هذه القاعدة لك، لا للوكيل، ولهذا تنجح.
3. **افصل بين العامل والمراجع.** في المهمة التالية، أعطِ موجّه المراجع لجلسة جديدة واطلب منها إثبات أن العمل لم يكتمل. غالبًا ما يكفي التشغيل الأول لتبرير هذه العادة.
الأداة جيدة وتتحسن كل شهر: أمور كان الوكيل يفعلها بصمت قبل عام أصبحت الآن توقفه في مكانه. وتستمر حدود الأمان في التحرك، لكنها تظل حدودًا. وما دام الوكيل يسعى إلى الهدف الذي أُعطي له، يظل السؤال «وكيف قست ذلك تحديدًا؟» من مسؤوليتك. وعادة التحقق هي شبكة الأمان لديك.
### المصادر
- [OpenAI: بيان بشأن حادث أمن تقييم النماذج، 21.07.2026](https://openai.com/index/hugging-face-model-evaluation-security-incident/)
- [Hugging Face: بيان حادث الأمن، يوليو 2026](https://huggingface.co/blog/security-incident-july-2026)
- [Anthropic: من التحايل على المكافأة إلى التخريب، الانحراف الناشئ عن التحايل على المكافأة](https://www.anthropic.com/research/emergent-misalignment-reward-hacking)
- [OpenAI: رصد السلوك السيئ في نماذج الاستدلال المتقدمة](https://openai.com/index/chain-of-thought-monitoring/)
- [DeepMind: التلاعب بالمواصفات، الوجه الآخر لبراعة الذكاء الاصطناعي](https://deepmind.google/discover/blog/specification-gaming-the-flip-side-of-ai-ingenuity/)
- [Cursor: التحايل على المكافأة يقوض المكاسب في معايير البرمجة](https://cursor.com/blog/reward-hacking-coding-benchmarks)
- [Claude Code Docs: إتاحة طريقة لـ Claude للتحقق من عمله](https://code.claude.com/docs/en/best-practices)
- [Claude Code Docs: بيئة الاختبار المعزولة وقيودها](https://code.claude.com/docs/en/sandboxing)
- [Claude Code Docs: أوضاع الأذونات](https://code.claude.com/docs/en/permission-modes)
- [Claude Code CHANGELOG](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md)
واصل العمل مع الذكاء الاصطناعي على [Ailoot](https://ailoot.ai/).
## أسئلة شائعة
### أي دليل أطلبه عندما يقول الوكيل إنه انتهى؟
اطلب الأمر ومخرجاته وحالة خروجه ونتيجة المستخدم التي يفحصها فعلًا. ألزمه بذكر ما لم يُختبر؛ القول إنه راجع عمله بنفسه لا يثبت اكتماله.
### هل يوفر طلب مراجعة مختلف في المحادثة نفسها فحصًا مستقلًا؟
لا. يوصي المقال بسياق جديد لمراجع لم يكتب الحل. أعطه النتيجة المقصودة والملفات الفعلية، واطلب منه البحث عن إخفاق ملموس بدل تأكيد استنتاج المنفذ.
## Ailoot · الشركة ومحفظة مشاريعها
تستند Ailoot إلى خبرة تشغيلية متراكمة وقاعدة عملاء واسعة وخدمة مستقرة ومراقبة مستمرة لمؤشرات الأداء KPI.
الشركة ومحفظة مشاريعها: ملايين العملاء؛ مبيعات بالمليارات شهريًا.
توظف Ailoot هذه الخبرة التشغيلية لإتاحة الوصول عبر API إلى قدرات الذكاء الاصطناعي في منتجات العملاء ووكلائهم وتطبيقاتهم وعمليات الأتمتة.