DeepSeek Harness: عندما يصبح كل شيء فعلاً إضافة

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

لهذا أجد Developer Preview من DeepSeek Harness مثيراً جداً. تلخص DeepSeek الفكرة في جملة واضحة: Everything is a plugin. ليست الأدوات الإضافية وحدها قابلة للاستبدال، بل النماذج والمهارات والجلسات وSandboxes والتخزين وحلقات الوكيل والجدولة وحتى واجهة المستخدم.

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

الوكيل أكبر من نموذجه

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

لذلك ليس Harness مجرد غلاف. إنه يحدد ما الذي يمكن أن تتحول إليه إجابة النموذج. هل يخرج الوكيل نصاً فقط أم يغير ملفاً؟ هل يرى المستودع كله أم مجلد عمل؟ هل يعمل الأمر على Host أم داخل Container أم في Remote Sandbox؟ هل يحتاج إلى موافقة بشرية؟ وهل تبقى الحالة بين الجلسات؟ هذه قرارات Runtime المحيط بالنموذج، لا خصائص النموذج نفسه.

من الإجابة إلى الفعل

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

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

البنية جزء من النتيجة

يجعل DeepSeek Harness هذه الطبقة مرئية. يقوم Cordis Kernel بتركيب Plugins وحل Dependencies وإزالة Components. تُعرض القدرات كخدمات. قد تنفذ إضافة Shell، وتجعلها أخرى Tool للنموذج، وتستهلكها ثالثة في Workflow. ويمكن تبديل التنفيذ عبر Configuration بلا إعادة بناء Harness كله.

تذهب DeepSeek أبعد من منصات تسمح ببعض الأدوات الإضافية فقط. اتصال النموذج وTool Registry وSession Log وAgent Loop نفسها Plugins. لا توجد نواة مميزة تحتاج إلى Patch لكل Extension، بل يُركب السلوك الجديد بجانب المكونات القائمة ويلغي تسجيلاته عند الإزالة.

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

لماذا تبدو فكرة «كل شيء إضافة» جذابة

تنقل الفكرة القوة من منتج نهائي إلى Runtime قابلة للتركيب. يمكن تبديل Model Provider دون بناء سير العمل من جديد، أو استبدال Local Shell بنسخة أكثر عزلاً، أو استخدام Storage ومنطق جلسات وواجهة مختلفة. وتوثق DeepSeek مزودين آخرين وCustom OpenAI-compatible Endpoints إلى جانب نموذجها.

تبديل النموذج دون البدء من الصفر

يصبح الوكيل بنية تحتية تناسب البيئة. قد يحتاج فريق تطوير صغير إلى الملفات وGit والاختبارات، بينما يريد فريق Security استعلامات شبكة وSandboxes معزولة وموافقات أشد وسجلات غير قابلة للتغيير. تستطيع شركة استخدام Model Gateway خاص، ويستطيع مختبر منزلي تشغيل Open-Weight Model محلي.

هذا مهم لأن النماذج تتغير بسرعة. يتفوق مزود اليوم في Coding وآخر غداً في السياق الطويل أو استخدام الأدوات. في منتج مغلق يعني تغيير النموذج غالباً تغيير المنصة وإعادة الجلسات والقواعد والصلاحيات والتكاملات. في Runtime معيارية يبقى النموذج مكوناً يمكن استبداله بمزود آخر أو Self-hosted Endpoint.

الأمر ليس بلا احتكاك. تختلف النماذج في Roles وReasoning وTool Calls والصور وسلوك الأخطاء، ويجب أن تعالج Adapters ذلك. لكن الوصلة الواضحة تمنع خصوصيات مزود واحد من الانتشار في المنتج كله.

بنية تحتية قابلة للاستبدال لا أزراراً إضافية

الفصل بين تعريف القدرة ومزودها ومستهلكها مهم. تصف Bash Interface ما تستطيع القدرة فعله، ويقرر Provider أين وكيف تعمل الأوامر، ثم تجعلها إضافة أخرى Tool يسمح للنموذج باستدعائها. عند هذه الوصلة يمكن إضافة Timeouts والعزل والموافقات والتسجيل دون إعادة كتابة كل Agent Loop.

تظهر القيمة حين تشترك قدرات في عالم تنفيذ واحد. إذا انتقل Filesystem والعمليات من بيئة محلية إلى Remote Sandbox، يمكن أن تنتقل Shell وTerminal وCode Navigation معها. تبقى القدرة متشابهة للمستخدم بينما يتغير إطار الأمان والتشغيل جذرياً. هذا أهم من مفتاح جديد في الواجهة.

توضح أوضاع التشغيل الهدف أيضاً. يقدم Standard Mode وكيل Coding كاملاً، وينسق Code Mode عدة Tool Calls عبر TypeScript مولد، ويختصر Minimal Mode البيئة إلى Shell وEditor للاختبارات، بينما يفحص Creator Mode الإضافات وPresets. لا تحتاج كل حالة إلى صندوق الأدوات الضخم نفسه.

وتحول Profiles وBundles ذلك من إضافات متناثرة إلى Runtime محددة للغرض: Profile خفيفة للتطوير المحلي، وأشد تقييداً للإنتاج، وForensic Profile تسجل أكثر. تأتي القدرات من المكونات نفسها لكن تركيبها وحدودها تناسب المخاطر.

أين تنشأ الإمكانات عملياً

البنية مثيرة، لكن قيمتها تظهر في الحالات العملية. ليس Plugin System غاية، بل يجب أن يكيف الوكيل مع المتطلبات الحقيقية سريعاً دون بناء منصة جديدة لكل استخدام.

من أداة شخصية إلى منصة شركة

يبدأ مطور واحد بـ Local Shell وFile Editor ونموذج. وعندما تصبح أداة فريق تظهر هويات مركزية وWorkspaces منفصلة وموافقات للأفعال الحرجة وModel Gateway وضبط تكاليف وجلسات دائمة وAudit Trail قابل للتصدير. في التطبيق الأحادي يقرر المصنع متى تأتي هذه الميزات.

في Runtime معيارية تستطيع الشركة إضافة الناقص أو استبدال Provider دون اختراع الوكيل من جديد. يمكن للواجهة والمنطق نفسيهما استخدام نماذج أخرى خلف Enterprise Gateway، وتشغيل الأوامر في Sandbox داخلية وحفظ الجلسات في Storage خاص. هذا هو الفرق بين Tool عملية وPlatform قابلة للتحكم.

مناطق ثقة مختلفة من المكونات نفسها

ليست كل مهمة بحاجة إلى الحقوق نفسها. وكيل تلخيص الوثائق لا يحتاج وصول الإنتاج. قد يحتاج وكيل Incident Response إلى Logs واستعلامات شبكة دون تعديل Configuration. وقد ينفذ وكيل Deployment التغييرات، لكن بموافقات أشد وTokens أقصر وتسجيل أوضح.

تعبر Services وProfiles المنفصلة عن ذلك تقنياً. لا يجب أن يفهم النموذج كل تفصيل أمني ويلتزم به طوعاً، فالبيئة تحدد القدرات الموجودة. والقدرة غير المركبة لا تظهر أصلاً Tool مباشرة للنموذج.

منظومة للمتخصصين

لا يستطيع مزود واحد بناء أفضل Sandbox وSession Store وكل نظام شركة وكل Model Adapter معاً. يسمح النموذج المفتوح لمزود Security بتقديم بيئة تنفيذ محصنة، ولمشروع Storage بتقديم جلسات قابلة للتدقيق، ولفريق داخلي بربط الهويات والموافقات بالمؤسسة.

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

قابلية التتبع ليست تفصيلاً ثانوياً

الفكرة القوية الثانية هي append-only Session Log. بحسب DeepSeek يُسجل كل ما يراه النموذج كحدث، بما في ذلك System Instructions وTool Calls ونتائجها وContext Injections وتخطيط الوكلاء الفرعيين. تعتمد المتابعة والتفرع والبحث والإعادة على Event Stream نفسها.

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

في التطبيقات التقليدية يمكن رد الخطأ إلى Input ومسار كود حتمي. أما الوكيل فقد يستنتج خطوات مختلفة من المهمة نفسها ويغير ترتيب الأدوات ويتفاعل مع نتائج غير متوقعة. بلا History كاملة لا يبقى سوى القول إن الوكيل قرر، وهذا لا يكفي لـ Debugging أو Security Incident.

جعل Event Stream مصدر الحقيقة يتيح تجارب قابلة للمقارنة. يمكن Fork للجلسة عند نقطة وتشغيلها بنموذج أو Prompt أو قدرات أخرى. هكذا نقيس أثر تغيير على حالة عمل حقيقية واحدة، لا من يكتب جواباً أجمل فقط.

قد تصبح هذه لاحقاً Change وIncident Log للوكلاء في الشركات: من أصدر المهمة؟ أي Policy كانت فعالة؟ ما البيانات التي رآها النموذج؟ أي فعل تمت الموافقة عليه وما النتيجة؟ ستصبح الأسئلة أساسية عندما يغير الوكلاء أنظمة حقيقية.

لكن السجل ليس Audit Trail كاملاً تلقائياً. يجب حل الاحتفاظ والحماية والسلامة والمحتوى الحساس والتصدير. وقد يصبح السجل نفسه خطراً إذا احتوى Prompts أو Source Code أو نتائج Tools أو Credentials. مع ذلك يعجبني القرار: يجب أن تأتي المعلومات المرئية للنموذج من Event Stream قابلة لإعادة البناء، لا من قناة جانبية مخفية.

المصادر المفتوحة تصبح سلاحاً استراتيجياً

يزيد مجيء المشروع من الصين الاهتمام. لا تنشر DeepSeek Model Weights فقط، بل تبني طبقات متعددة من Stack. يتوفر DeepSeek V4 بالأوزان والكود تحت MIT License، ويضيف Harness المرخص كذلك Runtime مفتوحة للعمل الوكيلي، وتحتها نموذج Cordis للإضافات والتركيب.

يناسب ذلك ما وصفته في الذكاء الاصطناعي والأمن والصراع على Stack الكامل. لا تستهلك الصين تطبيقات AI فقط، بل تبني شركاتها النماذج وبرامج Inference ومسارات Hardware ثم Agent Infrastructure. سرعة DeepSeek لا يفسرها التصور الغربي القديم لصناعة نسخ رخيصة.

Open Source ليس مثالياً فقط، بل Distribution وثقة عبر الفحص ومسرع Ecosystem. نشر Weights والكود والواجهات يدعو مطوري العالم لاكتشاف الأخطاء وبناء Integrations وتحويل التصميم إلى De-facto Standard. قد يكون Harness مفتوحاً أهم استراتيجياً من واجهة دردشة مغلقة لأنه يبقى مهماً حتى مع نماذج المنافسين.

تبني DeepSeek منصة تبقى فيها DeepSeek نفسها قابلة للاستبدال. يبدو ذلك متناقضاً: لماذا يسهل مزود نموذج الانتقال إلى منافس؟ لكن إذا بنى المطورون Agents وPlugins وقواعد Security وجلسات على Runtime هذه، يصبح Harness بنية مشتركة. قد تخسر DeepSeek بعض Model Calls لكنها تكسب تأثيراً على بنية المنظومة كلها.

يسرع الانفتاح التعلم أيضاً. يطور المصنع وحده تقريباً Core Architecture في المنتج المغلق، بينما يُستخدم المشروع المفتوح في بيئات لم يتوقعها فريقه، فتظهر Bug Reports وAdapters وBackends بديلة ومعرفة تشغيل. في مجال ناشئ قد تكون هذه الحلقة أهم من Release أول مثالي.

وهنا ذكاء Plugin Approach. لا تحتاج DeepSeek إلى بناء كل Storage وSandbox ونظام شركة، بل توفر البنية التي يضيف الآخرون قدراتهم إليها. وكل Integration جديدة تفيد النواة مع نمو المنظومة.

الصين لا تبني نموذجاً فقط، بل الطريق المحيط به

لا تقتصر الأهمية الجيوسياسية على Benchmarks. لا تتحقق السيادة التقنية بتدريب نموذج قوي وحده، بل تحتاج Hardware وبرامج Inference وأدوات تطوير وInterfaces وخبرة تشغيل ومطورين يبنون المنتجات. DeepSeek Harness جزء آخر من هذه السلسلة.

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

الفارق مع أفضل النماذج المغلقة يتقلص

اعتُبرت Open-Weight Models طويلاً بديلاً للمختبرات والحالات الخاصة، بينما بقيت القدرات الأقوى عند مزودين مغلقين. لم تعد الصورة ثابتة. لم تختف الفجوة في كل مجال، لكنها تنغلق أسرع من المتوقع.

تضع DeepSeek نماذج V4 في تقييماتها بجانب Closed Frontier Models الحالية. بحسب Benchmark يقترب V4 Pro أو يتعادل أو يتأخر بوضوح. لا توجد نتيجة واحدة في Software Engineering وTool Use والمعرفة وReasoning الصعب، لذلك لا ينبغي إعلان فائز من جدول واحد.

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

يتغير المعنى الاقتصادي أيضاً. قد يكون تفوق نموذج مغلق عشرة بالمئة حاسماً، لكن Open Model جيدة بما يكفي وتعمل على البنية الخاصة وداخل Security Zone قد تفوز في الحساب الكلي. التحكم وموقع البيانات والكلفة المتوقعة والتخصيص أجزاء من الأداء وإن غابت عن Benchmark.

ولا يجوز نسيان Hardware. فتح Weights لا يجعل نموذج 1.6 تريليون Parameter سهلاً في غرفة خوادم. DeepSeek V4 Pro نموذج Mixture-of-Experts ضخم، وتبقى الذاكرة وكلفة Inference والتشغيل صعبة حتى لو نشط جزء من المعلمات لكل Token. يزيل الانفتاح حاجز الوصول إلى الكود والأوزان لا الواقع الفيزيائي.

مع ذلك تغير الأوزان السوق. يستطيع الباحثون فحص النموذج، والمزودون تشغيله على بنيتهم، والمجتمعات تطوير Quantization وتحسين Runtime. وتحصل الشركات على بديل للاعتماد الكامل على API واحدة.

ينتقل التنافس. تبقى معرفة النموذج مهمة، لكن القيمة الدائمة توجد أيضاً في Data Pipelines وEvaluations وRuntime وSecurity وDistribution والدمج في العمليات. كلما سهل تبديل النماذج زادت قيمة المنصة التي تمنحها سياقاً وأدوات وحدوداً موثوقة.

الانفتاح لا يعني الثقة تلقائياً

من السذاجة مساواة «Open Source من الصين» بالسيادة. استخدام خدمة DeepSeek المستضافة يرسل البيانات إلى مزود خارجي. وحدهما Self-hosted Model Endpoint وHarness خاضعة للتحكم يغيران سيادة البيانات، ومع ذلك تبقى المنشأ وBuild Process وDependencies وUpdates جزءاً من Supply Chain.

تزيد Plugins المسؤولية. الإضافة ليست Theme بريئاً؛ يمكنها تسجيل Tools والوصول إلى Services وتنفيذ Code. تحذر وثائق DeepSeek من أن Build Scripts المسموح بها عند التثبيت من Git Repositories قد تعمل على Host خارج Agent Sandbox. وتوصي بمصادر موثوقة وتثبيت Dependencies على Commit محدد.

هذا هو التحذير الصحيح. تنشئ المنصة المفتوحة Supply Chain جديدة، وقد يصل كل Provider إلى Prompts وFiles وCredentials أو Tools تنفيذية. لا تحتاج إضافة مخترقة إلى Model Jailbreak إذا كانت جزءاً شرعياً من Runtime.

رؤية Source Code ميزة وليست Security Review. يجب أن يفحص شخص الكود ويعيد Builds ويثبت Versions ويراقب Updates. مع نمو المنظومة تصبح Provenance بأهمية Function تقريباً، وقد تكون إضافة مفيدة مجهولة المصدر أخطر من غياب الوظيفة.

في التشغيل الجدي سأستخدم عدداً قليلاً من Plugins المدققة، مع Versions مثبتة وصلاحيات مفصولة وSecrets خارج Configuration واتصالات صادرة مضبوطة. يجب أن تعزل Sandboxes فعلاً، وأن يُحمى Session Log ويُفحص للبيانات الحساسة. يجب ألا تتحول «كل شيء إضافة» إلى «كل إضافة تستطيع كل شيء».

تعتمد الإمكانات الطويلة أيضاً على Governance: Provenance مفهومة وArtifacts موقعة وBuilds قابلة للتكرار وDependencies واضحة وتقييد القدرات لكل Profile. إذا أخذت DeepSeek والمجتمع هذه الأسس المملة بجدية، يصبح الانفتاح تحكماً حقيقياً، وإلا صار الوعد Attack Surface هائلة.

ما أريد رؤيته من DeepSeek Harness

تسمي DeepSeek المشروع Developer Preview وتحذر من تغييرات غير متوافقة. هذا وقت مناسب للقراءة والتجربة ببيانات غير حرجة، لا للاعتماد عليه في Workflows إنتاج مركزية.

المهم هل تتحول البنية النظيفة إلى Ecosystem متينة. نحتاج Signed Releases وProvenance للإضافات وPermission Models واضحة وReproducible Builds وUpdate Process لا يطلب ثقة جديدة عند كل تغيير. كما يهم مدى توافق Plugins من مزودين مختلفين مع سرعة تطور المشروع.

وأريد معرفة هل تصمد قابلية الاستبدال يومياً. يبدو Model Adapter سهلاً على الورق، لكن النماذج تختلف في Tool Calls وReasoning وContext Formats والصور وFailure Modes. تقلل الواجهة المفتوحة هذه الفروق ولا تلغيها.

مع هذه التحفظات يبقى DeepSeek Harness أحد أكثر مشاريع AI إثارة هذا العام، لا لأنه يجب أن يكون أفضل Coding Agent الآن، بل لأن شركة صينية تفتح الطبقة فوق النموذج وتحولها إلى نظام تركيب. بينما يدمج غيرها الوكلاء في منصات مغلقة، تجعل DeepSeek نموذجها نفسه مجرد Plugin قابلة للاستبدال.

انطباعي والسرعة المذهلة

يكشف Developer Preview وحده إمكانات كبيرة. تجعل الواجهة مبدأ Plugins ملموساً، ويبين Trajectory View أن قابلية التتبع ليست إضافة لاحقة. المشروع شاب ومتغير، لكن بنيته المفتوحة تبدو أساساً قد ينمو عليه شيء كبير بسرعة.

يحدث في عالم AI الكثير حتى تبدو أسابيع قليلة قديمة. وهل هذا غريب حين تتوقع Alphabet وحدها نفقات رأسمالية بين 175 و185 مليار دولار لعام 2026، وMeta بين 115 و135 ملياراً، مدفوعة بقوة ببنية AI؟ تتدفق مئات المليارات فجأة إلى الفكرة والمنافسة والمستقبل نفسها.

لا يضمن المال منتجات جيدة، لكنه يفسر سرعة النماذج ومراكز البيانات ومنصات الوكلاء التي بدت مستحيلة قبل سنوات. تصبح النماذج قابلة للاستبدال، وتلحق Open Weights سريعاً، وينتقل التمايز الحاسم إلى Harness. تسرع DeepSeek في الثلاثة. وعلى من يبني AI Infrastructure أن يقرأ ذلك لا كقصة منافسة صينية فقط، بل كدعوة لإعادة تقييم اعتماده على Closed Stacks.

إلى اللقاء في المرة القادمة،
Joe