يحتوي DeepSeek Harness على 4 أوضاع: القياسي، والبرمجة، والمختصر، ووضع المبدعين — شرح مفصّل

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

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

إذا كنت تقارن DeepSeek ببيئة وكيل أخرى دائمة، فإن دليلنا حول إضافات Hermes لوكلاء DeepSeek يوضح المبدأ نفسه من اتجاه آخر: إذ يمكن لتغيير طبقة الوكيل أن يضيف الرؤية والذاكرة والوصول إلى البيانات الخاصة وإمكانات أخرى، من دون استبدال النموذج الأساسي.

لماذا يحتاج DeepSeek Harness إلى أربعة أوضاع مختلفة؟

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

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

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

١. الوضع القياسي — بيئة وكيل DeepSeek الكاملة الافتراضية

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

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

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

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

٢. وضع البرمجة — دع DeepSeek يحوّل تنسيق الأدوات إلى برنامج

وضع Code هو الأسهل فهمًا على نحو خاطئ بين الأوضاع الأربعة. فهو لا يعني «الوضع القياسي، لكن لمهام البرمجة فقط». ووفقًا لتعريف DeepSeek الحالي، يحتفظ وضع Code بجميع إمكانات الوضع القياسي. أما التغيير فيكمن في طريقة عرض الأدوات على النموذج: إذ يمكن لـ DeepSeek استخدام SDK وضع Code لدمج عمليات متعددة داخل برنامج TypeScript يُنشئه النموذج.

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

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

البحث في الملفات
→ تصفية المسارات المطابقة
→ التكرار عبر النتائج
→ قراءة الملفات المحددة
→ معالجة البيانات المُعادة
→ تشغيل عمليات متابعة

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

3. الوضع الأدنى — أزل Harness وشاهد المزيد مما يستطيع النموذج

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

سبب هذا التقييد هو التقييم. فقد استخدمت DeepSeek نفسها الوضع الأدنى لـ DeepSeek Harness في معايير Code Agent العامة المبلّغ عنها مع V4-Flash. ويوضح هذا الاستخدام الغرض بشكل أكبر: إذ صُمم الوضع الأدنى لتقليل البنية المحيطة بالوكيل عندما يرغب الباحثون في الحصول على رؤية أضيق لما يمكن للنموذج إنجازه باستخدام مجموعة صغيرة ومضبوطة من الأدوات.

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

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

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

4. وضع المنشئ — استخدم DeepSeek Harness لتغيير Harness

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

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

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

فحص بيئة التشغيل الحالية
→ إضافة المكونات الإضافية أو اختبارها
→ مراقبة الخدمات والاعتماديات
→ ضبط التكوين
→ حفظ إعداد مسبق مخصص
→ شغّل تلك البيئة مجددًا

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

القياسي مقابل البرمجة مقابل الأدنى مقابل المنشئ: ما الذي يتغيّر فعليًا؟

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

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

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

أي وضع من أوضاع DeepSeek Harness ينبغي لك استخدامه فعليًا؟

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

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

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

استخدم وضع المنشئ عندما تريد تغيير ماهية بيئة الوكيل. فهو مخصص لتجارب الإضافات، والإعدادات المسبقة المتخصصة، والمطورين الذين يتعاملون مع DeepSeek Harness بوصفه بنيةً تحتية لإنشاء وكيل جديد، لا مجرد تشغيل الوكيل الافتراضي.

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

الوضع التخطيطي ليس وضع تشغيل خامسًا في DeepSeek Harness

هناك ميزة أخرى في DSH تجعل المصطلحات مربكة: الوضع التخطيطي. قد يبدو أنه ينتمي إلى جانب الأوضاع Standard وCode وMinimal وCreator، لكن البنية الحالية في DeepSeek تتعامل معه بشكل مختلف. فالأوضاع الأربعة المذكورة أعلاه إعدادات مسبقة أو تركيبات لوقت التشغيل. أما الوضع التخطيطي فهو حالة تخطيط اختيارية لكل وكيل، تغيّر التوجيهات المقدمة إلى النموذج.

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

وهذا يمنح المفهومين مهمتين مختلفتين. تجيب أوضاع Standard وCode وMinimal وCreator عن أسئلة تتعلق بـ تركيب بيئة التشغيل: ما القدرات المتاحة وكيف يعمل الوكيل. أما وضع Plan فيجيب عن سؤال سلوكي: هل ينبغي أن يبقى الوكيل في حالة تعاون موجهة نحو التخطيط قبل متابعة التنفيذ؟

Standard / Code / Minimal / Creator
= تركيب بيئة التشغيل

وضع Plan
= حالة التخطيط والتوجيه

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

تكشف الأوضاع الأربعة ما الذي يبنيه DeepSeek Harness فعليًا

أكثر ما يثير الاهتمام في DSH ليس أنه يمنح المستخدمين أربعة أزرار للاختيار من بينها. فالأوضاع تكشف أربع طبقات مختلفة من هندسة الوكلاء. يركز الوضع Standard على التنفيذ. ويركز Code على التنسيق. ويركز Minimal على التقييم. ويركز Creator على التركيب. وتوضح هذه الأوضاع مجتمعة أن DeepSeek يتعامل مع الحزام باعتباره جزءًا فاعلًا من سلوك الوكيل، لا مجرد حلقة وصل غير مرئية حول النموذج.

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

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

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