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

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

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

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

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

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

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

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

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

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

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

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

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

2. وضع التعليمات البرمجية — دع 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 لتنسيقها، ويتيح لك اكتشاف ما إذا كانت بيئة تشغيل أكثر تخصصًا ضرورية أصلًا. قد يؤدي البدء بالوضع المصغّر لمجرد أنه يبدو أخف إلى إزالة الإمكانات التي تجعل الوكيل مفيدًا تحديدًا.

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

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

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

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

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

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

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

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

قياسي / برمجة / أدنى / إنشاء
= تكوين بيئة التشغيل

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

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

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

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

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

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

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