تحليل تصميم DeepSeek Harness

أُطلق DeepSeek Harness (اسم الأمر dsh، والمستودع deepseek-ai/deepseek-harness) في أغسطس 2026 بصفته إصدار Developer Preview، وقد قدّم له التعريف الرسمي المباشر الآتي: Agent = Model + Environment + Tools + State—أي النموذج، والبيئة، والأدوات، والحالة.

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

نحلله في هذه المقالة مع التركيز على ثلاثة أمور: النواة القائمة على الإضافات، وفاصل القدرات (capability seam)، ومسار الأحداث، فضلًا عن أقوى قيد هندسي فيه: «كل ما يراه النموذج يجب تسجيله».

التعريف في جملة واحدة

يتكون الـ coding agent التقليدي من «LLM + حلقة agent ثابتة + مجموعة أدوات ثابتة». أما DeepSeek Harness فيتكون من «نموذج + نواة إضافات (Cordis)»؛ ولا تتولى النواة سوى تحميل الإضافات وإزالتها وإدارة تبعياتها وآلية أحداثها، ولا تمتلك أي قدرة خاصة بالـ agent—وتقول وثيقة البنية حرفيًا: «لا توجد نواة ذات امتيازات تحتاج إلى ترقيع»، و«يمكنك توسيع dsh بتركيب إضافة إلى جوار الإضافات الأخرى» بدل تعديل النواة. وهذا يعني أن حلقة الـ agent نفسها ليست مقدسة ولا عصية على التغيير—يمكنك استخدام نموذج DeepSeek، وربط الوكلاء الفرعيين في Claude Code، وإضافة صندوق رمل بعيد، وكتابة ذاكرة مخصصة، واستبدال الحلقة وواجهة المستخدم، ثم تجميع ذلك كله في agent جديد تمامًا.

هذا هو التطبيق الأكثر شمولًا لعبارة الدورة «كل ما يقع خارج أوزان النموذج هو harness»: ما دام harness مستقلًا، فلنجعله نظام تشغيل مستقلًا.

جوهر البنية 1: فاصل القدرات (Capability Seam)

يستخدم DeepSeek Harness مفهوم Service للتعبير عن «القدرة»، ويقسّم كل قدرة تقريبًا إلى ثلاث طبقات:

Service Definition
        ↓
Service Provider
        ↓
Consumer

لنأخذ نظام الملفات مثالًا: يندرج تحت FS Service عدد من Provider مثل Local FS وE2B FS وRemote FS، وتُعرَض جميعها للأعلى بصورة موحّدة على هيئة file tools. وتتبع Shell وSubprocess وSandbox وWeb وLLM وSubAgent البنية نفسها. وهذه البنية الثلاثية ليست خلاصة من عندنا—بل تذكر وثيقة البنية · Capability seams حرفيًا: فاصل القدرة هو قدرة قابلة للاستبدال ذات ثلاثة أدوار: Service Definition يعلن الواجهة، وService Provider ينفذها، وConsumer يستخدمها، وغالبًا ما يكون الأخير أداة ظاهرة للنموذج.

يحل ذلك مشكلة مزمنة في هندسة harness: هل ينبغي أن يعتمد الـ agent على «أداة محددة»، أم على «واجهة قدرة»؟ يختار DeepSeek Harness الثانية. وبمصطلحات الدورة، يعني هذا توحيد «النظام الفرعي للأدوات» في واجهة: عند استبدال Provider لا يتغير شكل الأدوات المعروضة للنموذج، مع أن البيئة تتغير بالكامل.

جوهر البنية 2: مسار الأحداث (Event Pipeline)

لا يعمل DeepSeek Harness داخليًا وفق دورة بسيطة من «LLM ← أداة ← LLM»، بل وفق مسار أحداث تكون كل مرحلة فيه نقطة حدث يمكن لإضافة برمجية الاستماع إليها:

turn/start → claim input → assemble（system prompt / context / tools）
  → agent/pre-step → step/start → LLM request（agent/request）→ llm/stream
  → assistant/message → tool/call
  → tools/pre-execute（permission / guard / policy / hook）
  → tools/execute → tools/post-execute → tool/result → step/end → next turn

(المسار أعلاه إعادة صياغة لقسم وثيقة البنية · Turn flow: تمثل turn/* وstep/* وuser/message وassistant/* وtool/* أحداث جلسة دائمة، بينما تمثل agent/pre-step وagent/request وllm/stream وtools/* نقاط توسعة يمكن للإضافات الاستماع إليها.)

أكبر مزايا هذا التصميم هي أن عددًا كبيرًا من الوظائف لا يتطلب تعديل حلقة الـ agent أصلًا. هل تريد فحصًا أمنيًا قبل تنفيذ الأداة؟ استمع إلى tools/pre-execute. هل تريد إضافة ذاكرة؟ احقنها عند agent/pre-step. هل تريد تسجيل السلوك؟ اشترك في أحداث الجلسة. هل تريد تعديل طلب النموذج؟ اربطه بـ agent/request. هل تريد تقرير مواصلة الاستدلال؟ استمع إلى agent/turn-stopping.

مقارنة بالمحاضرة الحادية عشرة، «جعل عملية تشغيل الـ agent قابلة للرصد»، يذهب DeepSeek Harness أبعد: فهو لا «يضيف السجلات» فحسب، بل يحوّل كل خطوة في الحلقة إلى نقطة حدث، فتُعلّق قابلية الرصد والأذونات والذاكرة والسياسات كلها على الحلقة بصفتها مستمِعات، بدل أن تُرسّخ داخلها.

جوهر البنية 3: Session Event Log وقاعدة «كل ما يراه النموذج يجب تسجيله»

يتضمن DeepSeek Harness‏ Session Event Log للإلحاق فقط، ويفرض قيدًا هندسيًا شديد القوة. تقول وثيقة البنية · Session log حرفيًا:

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

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

بعبارة أخرى، ليست قابلية الرصد سجلًا يضاف بعد وقوع الحدث، بل قيدًا أوليًا في harness: كل ما يدخل سياق النموذج ينبغي افتراضيًا أن يترك سجلًا. وهذا ينسجم مباشرة مع عبارة المحاضرة الختامية «قابلية الرصد تنتمي إلى داخل harness»، ويحوّل تصميم التخزين append-only إلى مبدأ—فالسجل لا يقبل إلا الإلحاق ولا يُعاد فوقه، ويمكن إعادة تشغيل حالة الجلسة.

المواءمة مع إطار الدورة

النظام الفرعي	تطبيق DeepSeek Harness	التقييم
التعليمات	قائمة على الإضافات؛ تُحقن القواعد/المهارات في صورة إضافات	حرية فائقة، لكن من دون عرف مضمّن شبيه بـ CLAUDE.md
الأدوات	فاصل قدرات Service Definition → Provider → Consumer	أقصى درجات توحيد النظام الفرعي للأدوات
البيئة	يمكن استبدال Provider لكل من صندوق الرمل/FS/Shell (بما في ذلك E2B البعيد)	بيئة قابلة للتوصيل بالكامل
الحالة	Session Event Log للإلحاق فقط + كل ما يراه النموذج يجب تسجيله	قابلية الرصد قيد أولي
التغذية الراجعة	permission / guard / policy / hook على tools/pre-execute	آليات التغذية الراجعة قائمة على الأحداث

الفرق الجوهري بين DeepSeek Harness والمنتجات الثلاثة الأخرى هو أن Pi وClaude Code وCodex تحسّن harness داخل «agent محدد»، بينما يعرّف DeepSeek Harness‏ harness بوصفه نظام تشغيل مستقلًا عن النموذج، ولا يكون الـ agent نفسه سوى تطبيق قابل للاستبدال على هذا النظام. والثمن واضح أيضًا—فالحرية الكبيرة تعني تكلفة إعداد مرتفعة، وهذا هو الوجه الآخر الملازم لفكرة «harness بوصفه نظام تشغيل» (كما أن مرحلة معاينة المطورين موجهة إلى «التجربة المبكرة، مع استمرار تطور الآليات»).

تصميمات جديرة بالاقتباس

1. تحويل كل خطوة في الحلقة إلى نقطة حدث: تُعلّق الأذونات والذاكرة والسياسات والسجلات على الحلقة بوصفها مستمِعات، بدل أن تُرسّخ داخلها.
2. توحيد فاصل القدرات: الاعتماد على «واجهة قدرة» بدل «أداة محددة»، بحيث يمكن استبدال البيئة ككتلة كاملة من دون التأثير في واجهة الأدوات التي يراها النموذج.
3. كل ما يراه النموذج يجب تسجيله: تسجيل كل ما يستطيع النموذج رؤيته، وتحويل قابلية الرصد من «ميزة إضافية» إلى «قيد أولي».
4. سجل جلسة append-only: حالة قابلة لإعادة التشغيل، وتسليم موثوق؛ وهذا ضمان هندسي لقاعدة «ترك حالة نظيفة في نهاية كل جلسة».

المصادر المرجعية (النص الأصلي / الشيفرة المصدرية)

يمكن تتبع كل ادعاء إلى النص الأصلي أو الشيفرة المصدرية أدناه، تجنبًا للنقل اعتمادًا على الانطباع:

• موقع DeepSeek Harness الرسمي: تعريف المنتج «Agent = Model + Environment + Tools + State»، وتصنيفه Developer Preview، والأمر dsh.
  https://deepseek.com/harness
• مستودع deepseek-ai/deepseek-harness (الأمر dsh، وترخيص MIT):
  https://github.com/deepseek-ai/deepseek-harness
• وثيقة البنية architecture.md: المصدر الأهم لهذه المقالة—«كل جزء من المنتج إضافة برمجية»، و«لا توجد نواة ذات امتيازات تحتاج إلى ترقيع»، ومسار أحداث Turn flow، والأدوار الثلاثة لفواصل القدرات، وقاعدة «كل ما يراه النموذج يجب تسجيله» وثابت وقت التشغيل، وSession Event Log للإلحاق فقط، وفواصل قدرات مثل fs/tools/telemetry، وأنظمة ctx.* الفرعية.
  https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/architecture.md
• الوثائق الفرعية المساندة لوثيقة البنية: مقدمة إلى نواة Cordis (تسهم الإضافات بخدمات، وأحداث محددة الأنواع، وتأثيرات قابلة للعكس)، وتفاصيل فواصل القدرات، والنظام الفرعي للجلسة.
  https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/cordis-primer.md ｜ https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/capability-seams.md ｜ https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/subsystems/session.md

المحاضرات ذات الصلة: المحاضرة الحادية عشرة · جعل عملية تشغيل الـ agent قابلة للرصد ｜ المحاضرة الثانية عشرة · إجراء تسليم جيد قبل نهاية كل جلسة ｜ المحاضرة الثانية · ما هو Harness بالضبط؟