MWS تخفّض زمن بدء وكيل الذكاء الاصطناعي من 37.6 إلى 16.8 ثانية: تشريح الـharness

بينما يضبط بعض المطورين harness محليًا على حواسيبهم المحمولة، ينقله آخرون إلى بيئة الإنتاج لخدمة آلاف المستخدمين. حضر أحد كتّاب Habr لقاء MWS «Russkoe tekhno 2» ودوّن ما يحدث عندما يلزم توسيع نطاق المنظومة المحيطة بالنموذج. فيما يلي أهم ما ورد، مع تنبيه: الأرقام مأخوذة عن المتحدثين ولا يمكن التحقق منها من مصدر مستقل.

الـharness هو تقريبًا كل شيء عدا النموذج

نموذج اللغة الخام صندوق أسود: يتلقى نصًا ويُخرج نصًا. ليست لديه ذاكرة ولا حساب دقيق ولا فحص ذاتي. وبحسب المتحدثين، الوكيل يساوي نموذجًا زائد harness. والـharness هو التعليمات والسياق والذاكرة والأدوات وحلقة الإجراءات والفحوصات والقيود والتنسيق (orchestration).

كيف يظهر هذا الفرق عمليًا؟ كلّف أحد المعماريين في MWS نموذج Opus بمراجعة شيفرة شخص آخر فحصل على ثلاث ملاحظات صغيرة. أما المهمة نفسها على DeepSeek مع harness فأعطت نحو 50 ملاحظة، منها 25 تستحق الانتباه. أي أن نموذجًا «متوسطًا» في منظومة جيدة تفوّق على نموذج قوي في منظومة عادية.

بعض الدروس من المداخلة:

• السياق هو الأهم. يعيد النموذج قراءة المحادثة كلها من جديد، وكلما طالت ساءت الإجابات. الحل: ضغط التاريخ، أو تحميل المطلوب عبر وكلاء فرعيين، أو نقل البيانات إلى ملفات.
• كثرة الأدوات لا تعني الأفضل. عند Vercel كان الوكيل ذو الأدوات الـ17 يخطئ في مهمة من كل خمس. وبعد تقليصها إلى أربع أدوات ضرورية نجحت المهام بنسبة 100%.
• الأخطاء تتراكم. بدقة 99% للخطوة الواحدة، تمر سلسلة من 10 خطوات بلا أخطاء في 90% من الحالات، وسلسلة من 50 خطوة في 60% فقط. لذلك تلزم اختبارات بعد كل تعديل ومواصفات مخصصة للمهمة، مثلًا في OpenSpec.

اتجاه 2026 هو harness يصحّح نفسه. يقرأ «الضابط» سجلات الجلسات ويجد الأعطال المتكررة ويضيف قواعد. في مثال MWS كان الوكيل يسلّم عمله دون اختبارات في ثلاث جلسات من ست. أضاف الضابط hook بعنوان «لا تسليم بلا اختبارات»، وفي اليوم التالي مرّت الجلسات الست كلها مع اختبارات.

أين تذهب الـ37.6 ثانية

مشروع «الموظف الرقمي» هو وكيل كونسيرج شخصي في Telegram وMax يضم أكثر من 30 مهارة. وخلف الكواليس لكل مستخدم pod خاص به في Kubernetes مع OpenClaw أو Hermes. كان انتظار أول رد يستغرق في المتوسط 37.6 ثانية، بينما يستغرق رد النموذج نفسه 2.3–4.5 ثانية.

ذهب الوقت في البنية التحتية:

• 4 ث: المشغّل (operator) ينشر manifest الوكيل في Kubernetes؛
• 10 ث: ربط القرص بالعقدة (node)؛
• 5 ث: تحميل (mount) القرص في الـpod؛
• 5 ث: تهيئة الحاويات؛
• 9.5 ث: تحميل Gateway الخاص بالوكيل؛
• 3.1 ث: فحص الجاهزية؛
• 1 ث: تسليم الملفات.

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

جاءت سلسلة التحسينات كالتالي:

1. نقل رفع الـpod وتسليم المفاتيح إلى الخانات: ناقص 4 ث، يتبقى 33.6.
2. الانتقال من الأقراص الكتلية إلى التخزين المشترك CephFS: ناقص 15 ث، يتبقى 18.6.
3. تسخين الحاويات ووحدات الوكيل: مكسب 1.8 ث فقط، لأنه أضيف تثبيت الخانة وإيقاظ الوكيل.

النتيجة: 16.8 ثانية. الهدف هو 6–8 ثوانٍ، لكن بلوغه يتطلب الخوض في شيفرة الوكيل وربما عمل fork لها.

ثمن السرعة

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

قُسّمت ملفات workspace الخاصة بالوكيل إلى خمس مناطق: managed (بحسب السجل)، وprotected (ملفات التعريف، يُمنع لمسها)، وruntime، وuser-owned، وseed (تُسلَّم مرة واحدة). والقاعدة بسيطة: يجوز تحديث ما يخصك وحذفه فقط.

وهناك ألم آخر: متى يُنوَّم الوكيل. حاليًا بحسب الزمن: بعد 30–35 دقيقة من آخر نشاط للمستخدم، أو بعد 5 دقائق إذا كان Cron هو من رفع الخانة. ولا يمكن التمييز بين «غادر» و«يفكر في الرد» دون الوصول إلى runtime. ويختبر الفريق فرضية نموذج سريع يقرر خلال 0.5 ثانية.

ما الذي نستفيده من هذا

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

حدود المادة: ينقطع النص عند مداخلة حول تطبيق الذكاء الاصطناعي في المؤسسات وتقييم الأثر التجاري، لذلك لا يمكن هنا قول شيء عن قياس العائد على الاستثمار. وبعض الطروحات (مثل ما يخص Google Research Harness 2) وردت دون مصادر، وينبغي التعامل معها كتصريحات للمتحدثين.