DeepSeek Harness هو حلقة عمل. يقرأ الوكيل مساحة عملك، ويحرر الملفات، ويشغل الأوامر عبر أداة bash الخاصة به، ويقرر ما يجب فعله بعد ذلك بناءً على المخرجات. فلماذا لا تكون اختبارات API الخاصة بك ضمن هذه الحلقة؟ إنها موجودة في Apidog خلف واجهة المستخدم الرسومية وتعمل عندما يتذكر شخص ما النقر. الوكيل لا يلمسها أبدًا.
الإصلاح هو كتلة إعداد واحدة. Apidog CLI هي حزمة npm، apidog-cli، تشغل سيناريوهات الاختبار التي أنشأتها في Apidog مباشرةً من محطة طرفية. بمجرد تثبيت CLI ومعرفة DeepSeek Harness بوجودها، يقوم الوكيل بتشغيل سيناريو Apidog بنفس الطريقة التي يشغل بها اختبارات الوحدات الخاصة بك: يشغل الأمر، ويقرأ رمز الخروج، ويصلح الكود إذا كان أحمر.
هناك أيضًا وسيطة رمز مميز للقيام بذلك. الوكيل الذي يؤكد أن API الخاص بك لا يزال يعمل عن طريق إعادة قراءة رمز المعالج والتفكير في أشكال الاستجابة يستهلك السياق في كل مرور. الوكيل الذي يشغل أمرًا واحدًا يحصل على الحقيقة الأساسية في بضعة أسطر. يضغط CLI "هل API صحيح؟" في رمز خروج، ويستخدم الوكيل سياقه على الإصلاح بدلاً من ذلك.
يغطي هذا الدليل الجزء الخاص بـ DeepSeek Harness الذي يتجاهله دليل التثبيت العام: أي ملف تعليمات يقرأه DeepSeek Harness فعليًا، وكيف تنفذ أداة bash الخاصة به apidog run، وكيف تحافظ على صدق الحلقة. إذا لم تقم بتثبيت CLI بعد، فافعل ذلك أولاً. كيفية تثبيت Apidog CLI باستخدام وكيل ترميز AI يشرح تثبيت npm، والمصادقة، والتشغيل الأول. يفترض هذا المقال أن apidog --version يطبع رقمًا وأن جهازك مصادق عليه.
ما هو DeepSeek Harness الذي يدور الحديث عنه
DeepSeek Harness، dsh على سطر الأوامر، هو نظام الوكيل مفتوح المصدر الذي أصدرته DeepSeek في 13 أغسطس 2026، جنبًا إلى جنب مع V4-Pro على API. إنه مرخص بترخيص MIT، ويوجد على github.com/deepseek-ai/deepseek-harness، وقد تجاوز 169 ألف نجمة اعتبارًا من 20 أغسطس. يمكنك تشغيله باستخدام npx @deepseek-ai/dsh web، والذي يقدم واجهة مستخدم ويب محلية على http://127.0.0.1:3080. هناك تختار مساحة عمل، وهي دليل المشروع الذي أطلقته منه، ويعمل الوكيل بداخله: يقرأ ويحرر الملفات، ويشغل الأوامر، ويطلب الإذن قبل العمليات التي تتطلب موافقة بموجب سياسة الأذونات النشطة.
شيئان يشكلان كل ما يلي. أولاً، DeepSeek Harness هو معاينة للمطورين. يحذر ملف README، بأحرف كبيرة، من أنه ستكون هناك تغييرات تكسر التوافق، لذا تعامل مع أسماء الملفات ومفاتيح الإعدادات هنا على أنها دقيقة لأواخر أغسطس 2026 وأعد التحقق منها مقابل وثائق المستودع إذا لم يتم تحميل شيء ما. ثانيًا، كل شيء في dsh هو مكون إضافي (plugin)، مبني على بنية Cordis، مما يجعل السؤال العملي أدناه قابلاً للإجابة: أي مكون إضافي يقرأ قواعد مشروعك، وماذا يبحث عنه؟ للحصول على جولة أوسع، انظر ما هو DeepSeek Harness؛ لمعرفة كيفية مقارنته بالمنافس الحالي، انظر DeepSeek Harness مقابل Claude Code.
الخطوة 1: ضع CLI في AGENTS.md
يقرأ DeepSeek Harness تعليمات مساحة العمل من خلال مكونه الإضافي @deepseek-ai/dsh-agent-instructions، والإعدادات الافتراضية ودية إذا كنت قد استخدمت وكلاء آخرين. وفقًا لمصدر المكون الإضافي وكتالوج الإعدادات، ينتقل المُحَمِّل للأعلى من دليل العمل الحالي للجلسة إلى جذر مشروعك (المعلم بـ .git) ويقوم بتحميل AGENTS.md، ويعود إلى CLAUDE.md، في كل دليل على طول الطريق. يتم تحميل التراكبات المحلية المسماة AGENTS.local.md أو CLAUDE.local.md بعد الملفات الأساسية، ويتم تطبيق AGENTS.md ثابت وعالمي للمستخدم في $DSH_HOME (الإعداد الافتراضي هو ~/.dsh) عبر المشاريع. يتم تجاهل الملفات التي تزيد عن 1 ميجابايت، وهو حجم لن يقترب منه ملف القواعد الخاص بك أبدًا.
الخلاصة العملية: إذا كان مستودعك يحتوي بالفعل على AGENTS.md لـ Codex أو CLAUDE.md لـ Claude Code، فإن DeepSeek Harness يلتقطه بدون أي إعداد إضافي. أضف كتلة Apidog قصيرة إليه:
## API testing with the Apidog CLI
- To test the API, run the Apidog scenario. Do not click through the GUI.
- Command: apidog run -t <scenario_id> -e <env_id> -r cli
- Exit code 0 means every assertion passed. Non-zero means a failure; read the report and fix the code.
- The machine is already authenticated. Never add an --access-token flag and never put a token in this file.
هذا هو السبب في أن ملف القواعد يتفوق على الدردشة. معرف السيناريو الذي يتم إدخاله في مُنشئ الجلسة يختفي عند انتهاء الجلسة. يتم تحميل المعرف المكتوب في AGENTS.md في كل جلسة جديدة، لكل زميل فريق، على كل جهاز يستنسخ المستودع. إذا كنت تعمل عبر عدة مشاريع، فإن ملف ~/.dsh/AGENTS.md العالمي للمستخدم يحمل العادة ("تحقق دائمًا من تغييرات API باستخدام أمر تشغيل apidog الخاص بالمشروع") بينما يحمل ملف كل مستودع المعرفات الحقيقية.
الخطوة 2: احصل على الأمر من Apidog
لست مضطرًا لتخمين معرفات السيناريو والبيئة. افتح سيناريو الاختبار في Apidog، انتقل إلى علامة التبويب CI/CD الخاصة به، وانسخ الأمر المُنشأ. يبدو كالتالي:
apidog run -t 123456 -e 789012 -r cli
العلامة -t هي معرف سيناريو الاختبار، و -e هي معرف البيئة، و -r cli يختار المُبلغ الذي يطبع النتائج مباشرةً، وهو بالضبط ما يحتاجه الوكيل للقراءة. الصق المعرفات الحقيقية في كتلة AGENTS.md الخاصة بك حتى يشغل الوكيل الأمر الذي أنشأه Apidog، وليس تخمينًا.
الخطوة 3: اجعل الوكيل يشغل الاختبار
ابدأ جلسة في واجهة الويب dsh مع تحديد مساحة عملك. قام مُحَمِّل التعليمات بالفعل بتغذية AGENTS.md الخاص بك في سياق الوكيل، لذلك يعرف أن CLI موجود. قم بإجراء تغيير يمس API الخاص بك، أو فقط اسأل:
Run the Apidog test scenario and tell me the exit code.
يقوم الوكيل بتنفيذه عبر أداة bash الخاصة به، ومعرفة كيف تتصرف هذه الأداة يوفر عليك جلسة تصحيح أخطاء لاحقًا. وفقًا لـ كتالوج الأدوات، تشغل أداة bash الافتراضية كل أمر في شيل جديد: لا توجد دليل عمل، أو متغيرات، أو دوال تستمر بين الاستدعاءات، وتعمل الأوامر من مساحة عمل الجلسة ما لم يتم تمرير workdir. هذا جيد لـ apidog run، وهو أمر واحد مكتفٍ ذاتيًا، لكن الوكيل لا يمكنه الانتقال إلى دليل فرعي أولاً وتشغيل الاختبار كخطوة ثانية. إذا كان سيناريوك يجب أن يعمل من دليل فرعي، ضع الاستدعاء الكامل في سطر واحد في ملف القواعد الخاص بك.
سلوكان آخران يستحقان المعرفة. تظهر رموز الخروج غير الصفرية كـ [exit code: N] صريحة، لذلك تظل إشارة النجاح/الفشل قائمة حتى عندما يتم اقتطاع المخرجات الطويلة إلى ذيلها. وقد تعمل الأوامر تحت بيئة ساندبوكس للملفات: يتم الإبلاغ عن عملية محظورة كرفض سياسة، وليس فشل أمر. نادرًا ما يؤدي تشغيل اختبار للقراءة فقط إلى هذا، لكن مُبلغ HTML الذي يكتب إلى ./apidog-reports يمكن أن يفعل ذلك، اعتمادًا على السياسة النشطة.
ما إذا كان التشغيل يتطلب نقرتك أولاً يعتمد على نفس سياسة الأذونات. تطلب واجهة الويب الإذن قبل العمليات التي تتطلب موافقة بموجبها، وفقًا لـ دليل المستخدم. عندما تطلب الموافقة على apidog run، وافق عليها: سيناريو اختبار مقابل بيئة تجريبية هو بالضبط نوع الأمر الآمن والقراءة بشكل أساسي الذي يهدف تدفق الموافقة إلى تمريره.
الخطوة 4: اقرأ التقرير
عندما يفشل تشغيل، يكون التقرير هو الإجابة. مع -r cli، يحصل الوكيل على تفصيل قابل للقراءة مباشرةً: كل طلب، كل تأكيد، وأي منها فشل مع القيمة المتوقعة مقابل القيمة الفعلية. يسمي التأكيد الفاشل الحقل الدقيق أو رمز الحالة، وهو عادةً ما يكفي للوكيل لتحديد الإصلاح دون أن تحتاج إلى الترجمة.
للحصول على تقرير يمكنك فتحه في متصفح أو تسليمه لزميل فريق، أضف مُبلغ HTML:
apidog run -t 123456 -e 789012 -r cli,html
يكتب مُبلغ html ملفًا مكتفيًا ذاتيًا إلى ./apidog-reports. احتفظ بـ cli في القائمة حتى يستمر الوكيل في الحصول على المخرجات المباشرة التي يقرأها لتحديد خطوته التالية.
الحلقة، من البداية إلى النهاية
إليك ما يوفره لك هذا الإعداد. لنفترض أن الوكيل يقوم بتحرير معالج تسجيل خروج. بدون CLI، تنتهي حلقته عند "الكود يبدو صحيحًا". مع الكتلة في AGENTS.md، تمتد الحلقة: يقوم بتحرير المعالج، ويشغل apidog run -t 123456 -e 789012 -r cli، ويقرأ النتيجة. إذا كانت خضراء (ناجحة)، ينتقل. إذا كانت حمراء (فاشلة)، يرى [exit code: 1]، ويقرأ أي تأكيد فشل (رمز 500 حيث كان متوقعًا 200، حقل total مفقود، رمز عملة خاطئ)، ويصلح المعالج، ويعيد التشغيل. يصبح فحص عقد API جزءًا من نفس دورة التعديل والاختبار والإصلاح التي يشغل الوكيل اختبارات الوحدات الخاصة بك من خلالها بالفعل.
لاحظ ما لم يفعله الوكيل: لم يعد قراءة كل ملف مسار ليتأكد من أن API يعمل. السيناريو بالفعل يرمز السلوك المتوقع، والذي تم بناؤه بصريًا في Apidog بواسطة من يملك API. يفوض الوكيل التحقق إلى أداة حتمية ويصرف توكناته حيث يلزم الحكم. هذا التقسيم للعمل هو النمط بأكمله: يكتب dsh الكود، ويتحقق CLI من طبقة API، وتقوم أنت بإنشاء السيناريوهات في Apidog دون كتابة أي كود اختبار على الإطلاق.
تحقق من أن dsh قد نفذه بالفعل
يبلغ الوكلاء عن نجاح لم يكسبوه، ونظام معاينة للمطورين ليس المكان الذي نأخذ فيه الكلام على محمل الثقة. ثلاث فحوصات، بالترتيب الذي تلتقط به المشاكل.
أولاً، تأكد من تشغيل الأمر. تعرض واجهة الويب dsh استدعاءات أداة الوكيل ومخرجاتها في الجلسة. ابحث عن استدعاء bash الحرفي apidog run ... ونتيجته. إذا قال الوكيل إنه أجرى الاختبارات ولكن لم يظهر مثل هذا الاستدعاء، فقد لخص شيئًا لم يفعله أبدًا. اطلب منه التشغيل مرة أخرى وإظهار المخرجات الخام.
ثانياً، تأكد من رمز الخروج. اسأل مباشرةً: "ما هو رمز الخروج لأمر apidog run هذا؟" يقدم نظام DeepSeek Harness للوكيل علامة [exit code: N] صريحة عند الفشل، لذلك لا يوجد غموض للاختباء وراءه. عندما يقول ملخص الوكيل "نجحت الاختبارات" ولكن العلامة قالت غير صفرية، فإن العلامة هي الصحيحة.
ثالثاً، تأكد من استخدامه للسيناريو الحقيقي. عادةً ما يعني فشل "لم يتم العثور على السيناريو" أن الوكيل اخترع أو تذكر معرفًا خاطئًا. أعد التحقق من قيم -t و -e مقابل كتلة AGENTS.md الخاصة بك والأمر في علامة التبويب CI/CD في Apidog. المعرفات في ملف القواعد هي الحقيقة؛ أي شيء آخر كتبه الوكيل هو تخمين.
اختياري: أضف خادم Apidog MCP للوصول إلى المواصفات
تشغيل السيناريوهات يغطي التحقق. إذا كنت تريد أيضًا أن يقرأ الوكيل مواصفات API الخاصة بك أثناء كتابة الكود، فهذه مهمة لـ MCP، وهنا تهم الصورة الصادقة: اعتبارًا من أواخر أغسطس 2026، لا يتم توثيق دعم MCP في ملف README الأساسي لـ DeepSeek Harness أو دليل المستخدم. ما هو موجود هو مكون إضافي مجتمعي، hyqhyq3/dsh-mcp-manager، تم اكتشافه من خلال موضوع GitHub dsh-plugin مثل بقية النظام البيئي. يضيف صفحة MCP ضمن الإعدادات، ويدعم خوادم HTTP البعيدة و stdio المحلية، ويسجل الأدوات كـ mcp__<name>__*، ويقرأ تعريفات الخادم لكل مشروع من <workspace>/.dsh/dshmm/mcp.json.
من خلاله يمكنك ربط خادم Apidog MCP، الذي يكشف مواصفات API الخاصة بك عبر MCP حتى يتمكن الوكيل من التحقق من المخطط الفعلي لنقطة نهاية قبل كتابة المعالج، بدلاً من بعد فشل السيناريو. مكون إضافي مجتمعي بالإضافة إلى مضيف معاينة للمطورين يعني أن هذا الاقتران يمكن أن يتعطل عند تحديث أي من الجانبين، لذا تعامل معه كطبقة إضافية. مسار CLI أعلاه هو المسار الأساسي: لا يحتاج إلى شيء سوى شيل.
محاذير المعاينة، وإلى أين يتجه هذا
DeepSeek Harness يتحرك بسرعة ويحذرك من أنه سيكسر الأشياء. الاحتمالات الأكثر ترجيحًا للتغيير هي تلك المذكورة هنا: مرشحات ملف المكون الإضافي للتعليمات، تقارير بيئة ساندبوكس لأداة bash، وأي شيء يمس المكون الإضافي المجتمعي MCP. ومع ذلك، فإن النمط قابل للنقل. ملف قواعد يقول "تحقق من API بهذا الأمر الواحد" بالإضافة إلى CLI الذي يعيد رمز خروج نظيف يعمل في dsh اليوم لنفس السبب الذي يعمل به في Claude Code وكل نظام DeepSeek Harness آخر في هذه السلسلة: الوكلاء جيدون في قراءة مخرجات الأوامر وسيئون في الثقة بهم بدونها.
إذن: قم بتنزيل Apidog، وقم ببناء سيناريو اختبار واحد بصريًا، وانسخ أمر apidog run الخاص به من علامة التبويب CI/CD، وأسقط الكتلة في AGENTS.md الذي يحتويه مستودعك بالفعل. في المرة القادمة التي يلمس فيها DeepSeek Harness كود API الخاص بك، سيتحقق من عمله الخاص قبل إخبارك بأنه انتهى.
الأسئلة الشائعة
هل يقرأ DeepSeek Harness ملف AGENTS.md بشكل أصلي؟ نعم. يقوم المكون الإضافي @deepseek-ai/dsh-agent-instructions بتحميل AGENTS.md (أو CLAUDE.md كخيار احتياطي) من جذر مشروعك والأدلة الموجودة فوق دليل عمل جلستك، بالإضافة إلى تراكبات AGENTS.local.md/CLAUDE.local.md وملف AGENTS.md عالمي للمستخدم في ~/.dsh. إذا كنت تحتفظ بالفعل بملف AGENTS.md لوكلاء آخرين، فإن dsh يلتقطه دون تغيير.
هل أحتاج إلى خطة DeepSeek مدفوعة لاستخدام Apidog CLI في dsh؟ لا. نظام DeepSeek Harness هو مشروع مفتوح المصدر مرخص بترخيص MIT، وأنت تحضر نموذجك الخاص: يغطي مزودو الكتالوج Anthropic وOpenAI وBedrock وVertex وAzure، وتعمل البوابات المخصصة من خلال settings.yaml، كما هو موضح في كيفية تشغيل أي نموذج في DeepSeek Harness. Apidog CLI نفسه عبارة عن حزمة npm مجانية؛ يحتاج إلى سيناريو اختبار Apidog ومصادقة، وليس نموذجًا محددًا.
لماذا ينسى أمر الوكيل الثاني الدليل الذي غيره الأول؟ حسب التصميم. تشغل أداة bash الافتراضية لـ dsh كل استدعاء في شيل جديد، لذا فإن cd لا تستمر بين الأوامر. مرر معلمة workdir للأداة أو، الأبسط، احتفظ باستدعاء apidog run الكامل في سطر واحد في ملف القواعد الخاص بك حتى لا يكون هناك شيء لنسيانه.
هل يمكن لـ dsh تشغيل السيناريو دون سؤالي في كل مرة؟ يعتمد ذلك على سياسة الأذونات النشطة. تطلب واجهة الويب الإذن قبل العمليات التي تتطلب موافقة بموجبها؛ دليل المستخدم لا يعدد مستويات السياسة، لذا تحقق من الإعدادات في بنائك لترى ما يسمح به نشرك. عندما يطلب الموافقة، فإن الموافقة على apidog run مقابل بيئة تجريبية هي نعم آمنة.