وكيل ذكاء اصطناعي لإصلاح الأخطاء البرمجية: كيف تبني وكيلًا يعيد إنتاج الخلل أولًا

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

قدّم فريق DeepSeek Harness هذه الفكرة أمام جمهور كبير في 1 نوفمبر 2026، في مقال حول تصميم الوكيل الفائق. يحوّل هذا الدليل الفكرة إلى خط معالجة (pipeline) يمكنك بناؤه هذا الأسبوع، مع كتابة خطوة إعادة الإنتاج على شكل اختبار API ينشئه الوكيل ويشغّله من الطرفية (terminal).

لماذا يفشل الأمر «أيها الوكيل، أصلح هذا» دون إعادة إنتاج

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

بدون خطوة إعادة إنتاج، تحدث ثلاث مشكلات:

• يخمّن الوكيل السبب. يختار السطر الأكثر ترجيحًا من رسالة الخطأ ويعدّله.
• لا يوجد تعريف لـ «تم الإصلاح». الدليل الوحيد هو ملخص الوكيل نفسه.
• تتسلل حالات التراجع. تعديلٌ على أداة تحقّق مشتركة قد يصلح نقطة نهاية واحدة ويعطّل أربعًا أخرى.

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

من أين جاءت فكرة «إعادة الإنتاج والإصلاح بصمت»

في مقال «Exploring Super-agent Design»، يصف فريق DeepSeek Harness سياسة من مجموعة مستخدميهم: عندما يبلّغ أحدهم عن خطأ، يحاول وكيلٌ إعادة إنتاج الخلف (في الخلفية). لا يتكلم إلا بمعالجة مُثبتة وبسيطة. وإلا فلا يقول شيئًا.

يُسمّي المقال هذا التنفيذ التخميني (speculative execution) ويرافقه بمكوّنين ستستخدمهما هنا. العمّال (Workers) يحصل كل منهم على جلسة معزولة واحدة لكل مهمة، بكامل الأدوات وأقوى نموذج، ويقدّم تقاريره إلى موجِّه (router) بدلًا من التحدث مع البشر. أما المراقب (watchdog) فهو جلسة منفصلة تتحقق مما إذا كان كل عامل يتقدم فعلًا أم ينحرف عن المسار.

تنبيه واحد: يصف المقال معماريةً، وليس ميزات فعّالة في DeepSeek Harness. بعض أجزائه موجودة في إضافة نموذجية باسم dsh-superagent-prototype، وهي كما يقول المؤلفون ليست منتجًا رسميًا من DeepSeek. للتعمق في نموذج الموجِّه والعامل، راجع كيفية بناء وكيل فائق.

خط معالجة الوكيل المصلّح للأخطاء بخمس خطوات

يُشغّل الوكيل ذاتي الإصلاح الحلقة نفسها في كل مرة، مع بوّابتين:

1. الاستقبال: جمع التقرير، والطلب الفاشل، والاستجابة التي تلقّاها.
2. إعادة الإنتاج: كتابة اختبار يفشل للسبب المُبلَّغ عنه. لا اختبار فاشل، لا إصلاح.
3. الإصلاح: تعديل الكود على فرع أو شجرة عمل (worktree) معزولة.
4. إعادة التشغيل: يجب أن ينجح الاختبار الجديد، وكذلك المجموعة الحالية.
5. التسليم: فتح طلب دمج (pull request) مع الأدلة، أو البقاء صامتًا.

الخطوة 1: استقبال تقرير الخطأ

لا يستطيع وكيلك إعادة إنتاج عبارة غامضة مثل «السلة معطلة مرة أخرى». امنح الاستقبال شكلًا ثابتًا:

إذا كانت الحقول ناقصة، يسأل الوكيل مرة واحدة أو يسحب الطلب من السجلات. الأجسام الخطأ الملتزمة بـ تفاصيل المشكلة في RFC 9457 مفيدة، لأن نوع الخطأ يصل في شكل يمكن التنبؤ به.

الخطوة 2: إعادة إنتاج الخطأ كاختبار API فاشل

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

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

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

اكتب إعادة الإنتاج كاختبار API لا كاختبار وحدة (unit test): فالوكيل يضرب الواجهة نفسها التي ضربها المستخدم، فلا يمكنه إعادة إنتاج خطأ مختلف عن قصد أو سهوًا.

الخطوة 3: إصلاح الكود في فرع معزول

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

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

الخطوة 4: إعادة تشغيل إعادة الإنتاج والمجموعة الكاملة

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

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

الخطوة 5: تسليم الإصلاح المؤكد البسيط فقط

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

ضوابط الحماية لوكيل ذكاء اصطناعي ذاتي الإصلاح

اضبط هذه الأسوار قبل أول تشغيل دون إشراف:

بيانات الاعتماد هي الأهم: إعادة الإنتاج تضرب واجهة API فعلًا، فاستخدم بيئة staging أو بيانات محلية مهيأة مسبقًا.

دع وكيلك البرمجي يبني إعادة الإنتاج باستخدام Apidog CLI

الخطوة 2 هي قلب خط المعالجة، وهي ما بُني من أجله Apidog CLI. يكتب وكيلك البرمجي (Claude Code أو Codex أو Cursor أو OpenCode) حالة الاختبار بصيغة JSON، وينشئها في مشروعك على Apidog ويشغّلها من الطرفية. أنت تكتب مُوجِّهًا (prompt) واحدًا فقط.

أعدّ الأدوات مرة واحدة:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

ثم سلّم وكيلك تقرير الخطأ مع هذا المُوجِّه:

Here is a bug report for POST /orders in Apidog project <projectId>.
Turn it into an Apidog test case that fails today: assert status 201
and that $.id exists. Run it against staging and confirm it fails for
the reported reason. If it does, fix the handler on a new worktree
branch until the same test passes, run the endpoint's other cases, and
open a PR with both JSON reports. If it doesn't reproduce, stop and log why.

لا يبني الوكيل حِمل الطلب من ذاكرته. بل يقرأ المخطط (schema)، ويجد تصنيفًا مناسبًا، ويتحقق من ملفه، وعندها فقط ينشئ الحالة:

apidog cli-schema get test-case-create
apidog test-case category --project <projectId>
apidog cli-schema validate test-case-create --file repro-orders.json
apidog test-case create --project <projectId> --file repro-orders.json

الملف الذي يكتبه يبدو هكذا (المعرّفات تأتي من مشروعك):

{
  "name": "Repro: POST /orders with null coupon returns 500",
  "apiDetailId": 123456,
  "categoryId": 1,
  "method": "post",
  "path": "/orders",
  "parameters": {},
  "commonParameters": {},
  "requestBody": {
    "type": "application/json",
    "data": "{\"items\":[{\"sku\":\"A-100\",\"qty\":1}],\"coupon\":null}"
  },
  "postProcessors": [
    { "type": "assertion", "defaultEnable": true, "enable": true,
      "data": { "name": "status is 201", "subject": "httpCode", "comparison": "equal", "path": "", "value": "201" } },
    { "type": "assertion", "defaultEnable": true, "enable": true,
      "data": { "name": "order id exists", "subject": "responseJson", "comparison": "exists", "path": "$.id" } }
  ]
}

الآن التشغيل الأحمر الذي يُثبت وجود الخطأ:

apidog run --test-case <caseId> --project <projectId> -e <stagingEnvId> -r cli,json --out-file repro-before

يُظهر مُبلِّغ الواجهة النصية فشل تأكيد الحالة مع رمز 500، ويهبط ملف repro-before.json في مجلد apidog-reports/. بعد الإصلاح، يشغّل الوكيل الأمر نفسه تمامًا مع --out-file repro-after وينجح التأكيدان معًا. هذان الملفان هما الدليل في طلب الدمج. وفي الخطوة 4، يشغّل كل الحالات على نقطة النهاية حتى لا يكسر الإصلاح جارًا مجاورًا بصمت:

apidog test-case run --project <projectId> --endpoint <endpointId> -e <stagingEnvId> -r cli,json

أضف --upload-report لعرض التشغيل في تطبيق Apidog. بعد الدمج، تبقى حالة إعادة الإنتاج في مشروعك كاختبار تراجع، والأمر نفسه apidog run مع -r junit يندمج مباشرة في CI، كما هو موضح في تشغيل Apidog CLI في خط CI/CD. لمزيد من الإعدادات، راجع سير عمل الوكيل مع Apidog CLI وApidog CLI في Claude Code. تغطي النسخة المجانية من Apidog حتى 4 مستخدمين، فيمكنك تجربة الحلقة كاملة دون خطة مدفوعة.

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

هل يستطيع وكيل ذكاء اصطناعي فعلًا إصلاح الأخطاء دون إنسان؟

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

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

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

كيف أمنع الوكيل من تعديل الاختبار لينجح؟

احفظ نسخة أو بصمة (hash) من حالة الاختبار لحظة فشلها الأول، وقارن قبل قبول الإصلاح. وأبقِ ملف الاختبار خارج المسارات التي يجوز للعامل تعديلها.

هل أحتاج DeepSeek Harness لبناء هذا؟

لا. يصف المقال تصميمًا، وإضافته النموذجية ليست منتجًا رسميًا من DeepSeek. أي وكيل برمجي يشغّل أوامر الطرفية يفي بالغرض، بما في ذلك Claude Code في GitHub Actions. وإن أردت تجربته هناك، راجع ما هو DeepSeek Harness.