استكشاف تصميم Super-agent: نحو نظام وكلاء أكثر استقلالية

1. Super-agent

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

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

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

مدّ وكيل محلي أحادي الجلسة بـCLI أو MCP أو موصلات خارجية يجعله يستقبل الرسائل الخارجية، لكنه يبقى مقيدًا بحجب التزامن في الجلسة الواحدة، واختلاط سياق المهام المتعددة، وتوقف كل شيء عند انقطاع الجهاز — مع صيانة يدورية ضخمة.

لكسر هذه القيود يجب فك ارتباط الوكيل بالجلسة اليدوية الواحدة، ليجعل كيانًا متصلًا يحفظ السياق عبر الجلسات ويدفع عدة مهام معقدة بالتوازي دون تداخل. نسمي هذا الشكل — ومعماريته — Super-agent.

ففي النسخة الداخلية العاملة على DeepSeek Harness تتقدم مهمة تطوير واحدة باستمرار بين المحادثات وGitHub؛ وتراقب النسخة أيضًا ملاحظات المجموعات العامة فتحدد السبب الجذري دون أن يُشَار إليها وتقدم طلب سحب للإصلاح.

وبالتحديد، يتمتع Super-agent بأربع خصائص أساسية:

• متصل: يتفاعل المستخدم معه مباشرة في واجهاته المألوفة — محادثات المراسلة وتعليقات GitHub — ويشعر أن ثمة وكيلًا واحدًا حاضرًا دائمًا، بلا حاجة لسؤال «هل كانت المعلومة Y في سياق الجلسة X؟». يمكنه اقتراح الخطة A في المحادثة ثم التحول إلى B في تعليق على طلب السحب فيفهم ويعدّل الاتجاه.
• كفؤ: تفاعل سريع الاستجابة مع إنجاز عدة مهام معقدة بالتوازي وبجودة عالية؛ يستقبل التعليمة التالية دون انتظار اكتمال السابقة.
• استباقي: لا ينتظر التعليمات واحدة واحدة؛ يراقب أحداث البيئة باستمرار ويدفع ما يستحق الدفع، ويبقى صامتًا حين لا يلزم التدخل.
• دائم: متصل دومًا، مرتبط ببيئات العمل الحقيقية، ويستعيد نفسه تلقائيًا عند الخلل في التشغيل الطويل.

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

وللتطبيق صور متعددة، لكن خمسة وحدات تشكل الهيكل الأساس: بنية الطبقتين (القسم 2) تجمع الترابط والكفاءة؛ نظام الأحداث (القسم 3) يحقق الاستباقية؛ التفاعل الموجه للإنسان (القسم 4) يجعل الواجهة نفسها متصلة وكفؤة؛ وفصل الحساب والحالة والبيئة (القسم 5) مع Watchdog (القسم 6) يحقق الدوام عبر الأجهزة والشفاء الذاتي.

2. بنية الطبقتين

لتحقيق الترابط عبر القنوات وتزامن المهام معًا، تواجه تنظيمية الجلسات مقايضة جوهرية بين الترابط والإنتاجية.

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

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

للموازنة نقسم «حفظ الترابط الشامل» و«التنفيذ المتزامن العالي» إلى طبقتين: طبقة Router مقيمة (2.1) تستقبل كل تفاعل الإنسان والتنسيق الشامل، وطبقة Worker معزولة السياق (2.2) تنفذ المهام تزامنيًا.

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

«الطبقتان» تقسيم منطقي للمسؤوليات؛ وكل طبقة لا تُحصر في جلسة واحدة ولها بنيتها الداخلية. نعرض الطبقتين تاليًا.

2.1 طبقة Router

الـRouter طبقة توجيه شاملة مقيمة تستقبل كل تفاعل الإنسان من كل المداخل. تتجمع فيها كل معلومات وقرارات ما بين المهام؛ فهي نقطة التسلسل والتنسيق والذاكرة الشاملة. ولكي لا تصبح عنق زجاجة، لا تنفذ مهام بل تكتفي بالتفاعل والإرسال؛ وقد لا تحمل أداة Bash أصلًا.

مُرسِل مركزي فوق منفذين متعددين يشبه ظاهريًا Agent Team المألوف، لكن التركيز مختلف. الـAgent Team يفكك خطوات مهمة معقدة واحدة؛ والخطوات الفرعية متشابكة عادة، فيضطر القائد إلى فهم دقيق للمهمة وتخطيط فرعي وتنسيق عالي التردد — حمل استدلالي ثقيل. أما في Super-agent فيتولى الـRouter الربط والإرسال الرفيع المستوى بين المهام فقط دون نزول إلى تفكيك المهمة الواحدة. وبالعكس، لو قيدنا بالبرومبت جلسة Agent Team الرئيسية ألا تنفذ بنفسها بل تواجه الخارج وترسل المهام للأعضاء، لصارت هي أيضًا هذه البنية. وعمليًا كثيرًا ما تكون مهام الـRouter أقل تعقيدًا مما يُظن، ونموذج أخف يوازن بين السرعة والجودة.

وداخليًا لا يُحصر الـRouter في جلسة واحدة، وقد لا تستدعي أجزاء من منطقه نموذجًا أصلًا. اخترنا أبسط نواة — جلسة LLM مقيمة واحدة — فوجدناها أقل عرضة للاختناق مما تبدو، لأن الأحداث الواردة أثناء جولة استدلال (الـTriggerات في القسم 3) تتراكم وتعالج دفعة في الجولة التالية مكوّنة التجميع (Batching) وكلفته الإضافية صغيرة:

• حين يهدأ التدفق تدخل الـTriggerات واحدة واحدة وتظل الاستجابة منخفضة الكمون.
• وحين تتدفق الأحداث وتزدحم الطابور، تندمج المتراكمات تلقائيًا وتُحقن معًا في النداء التالي. خطوات الـRouter عادة مدخل طويل ومخرج قصير؛ ودمج المتراكم في نداء واحد يوازي حساب الـprefill، فنمو زمن النداء أبطأ كثيرًا من نمو الدفعة. وفي نطاق معين كل زاد المتراكم انخفض زمن الاستدلال لكل قرار — والسقف هو طول السياق وعدد الـTriggerات التي يعالجها النموذج بدقة في الجولة.

يعرض القسم 7.2 هذا التجميع كميًا. ومع الاشتراك والتمرير المباشر وسلسلة الاستدعاء (3.2 و3.3) تكفي جلسة Router مقيمة واحدة عند مقياس فريقنا الحالي.

وعند التوسع أكثر يمكن جعل داخل الـRouter بنية تصفية متعددة الطبقات أو تقسيمًا أفقيًا (Sharding) إلى جلسات. حينها يصبح تصميم الـRouter الداخلي نفسه مقايضة ترابط/إنتاجية: تشذيب أدق يرفع التزامن ويخفض استمرارية الذاكرة بين الشظايا. وقبل حل مسألة الذاكرة الشاملة تظل هذه المقايضة قائمة.

2.2 طبقة Worker

طبقة الـWorker جلسات التنفيذ: عزل متبادل للسياق، أدوات كاملة، وتركيز على مهمة واحدة في سياق مستقل. ولأن جلسات الـWorker تقرر النتيجة وجودة الكود مباشرة، توضع فيها عادة أقوى النماذج.

لا يتفاعل الـWorker مع البشر مباشرة، ولا يُخرج استدلاله واستدعاءاته إلى القنوات الخارجية؛ بل يرفع حالته إلى الـRouter الذي يرد على المستخدم موحدًا — فيتحقق التزامن وجودة التسليم دون فوضى الردود المتعددة.

في تعدد المهام يتقدم العاملون باستقلال ولا يحتاجون عادة إلى تواصل مباشر فيما بينهم. التعارض يقع غالبًا في بيئات مشتركة كطلب السحب نفسه؛ وما دام الطرفان مشتركين في الـThread نفسه وصلاهما الإشعار ذاته (3.2) فقد يحلان التعارض بأنفسهما، والتنسيق النادر بين المهام يمر عبر الـRouter.

وكالـRouter، قد لا تنحصر جلسة الـWorker في واحدة: يمكنها إنشاء Subagent داخل مهمة معقدة أو أن تكون هي نفسها Agent Team، بشفافية أمام الـRouter. يناسب ذلك تعاون الشيفرة — استنساخات ومراجعات وميزات تتقدم متوازية دون تراص — والمساعد الشخصي أيضًا: نافذة محادثة واحدة تحفظ ترابط الواجهة، بينما توزَّع المواضيع في الأسفل على وكلاء يقرّون الردود بالتوازي.

3. نظام الأحداث

الاستباقية تبدأ بتغيير ما يقود النظام. المدخل الرئيسي لم يعد برومبتات يكتبها الإنسان في الجلسة بل أحداث شبه مهيكلة من البيئة. رسائل المجموعات وتنبيهات البريد والتقويم وتعليقات المراجعة ونتائج CI كلها Trigger. بمراقبة الـTriggerات والاستجابة لها لا يعود الوكيل ينفذ مرة واحدة لكل أمر كما في النموذج الأحادي.

وعلى مسار الحدث من وروده إلى معالجته أربعة أسئلة متدرجة: ترشيح الضجيج بسياسة ثنائية تجمع البرنامج والنموذج (3.1)؛ وتمرير الأحداث إلى العاملين بالاشتراك والتمرير المباشر (3.2)؛ وحقن السياق واستدعاؤه بكثافة عبر Inline & Spill وسلسلة الاستدعاء (3.3)؛ والتحرك المبكر بالتنفيذ التخميني (3.4).

3.1 ترشيح الأحداث

بعد الربط بمجموعات ومنصات حقيقية يتسم التدفق بـ«ضجيج عالٍ ومعدل إطلاق منخفض»: معظم الرسائل اليومية لا تحتاج تدخل الوكيل. والحكم على كل حدث بنموذج كبير من الصفر لا يطاق كمونًا وكلفة. وباستعارة Fast Path / Slow Path من النظم، يُعد استدلال النموذج مسارًا بطيئًا مرنًا مكلفًا، وتثبيت الأحكام الواضحة المستقرة عالية التردد في كود حتمي يشكل مسارًا سريعًا رخيصًا.

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

• سياسة البرنامج (Fast Path): فحوص قبول حتمية في الكود على المصدر ونطاق المجموعة وقوائم السماح — لكل مصدر مثلًا «استجب للطلبات الصريحة فقط» أو «اعتبره مرشحًا» أو «تجاهل» — فتُقصى معظم الرسائل غير ذات الصلة قبل النموذج.
• السياسة الدلالية (Slow Path): ما يجتاز يذهب إلى الـLLM ليقرر الحاجة إلى الفعل وفق سياسات مكتوبة بالبرومبت والسياق. وهي أيضًا نقطة الامتداد باللغة الطبيعية: تفعيل سياسة أو إضافتها تعديل برومبت فحسب.

3.2 توجيه الأحداث

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

في سير العمل الفعلي تشكل الأحداث المتتابعة تحت طلب سحب واحد أو موضوع محادثة واحد أو سلسلة بريد واحدة تدفقًا — Thread. فإذا أنشأ الـRouter جلسة عاملاً للحدث الأولي لـThread اشترك العامل فيه مباشرة، فينقسم التوجيه إلى مسارين:

• مشترك (Fast Path): أحداث الـThread التالية تمر مباشرة إلى العامل المشترك دون وساطة الـRouter. وإذا جاوز حدثٌ نطاق المهمة جاز للعامل إلغاء الاشتراك أو إعادته إلى الـRouter.
• غير مشترك (Slow Path): يظل الـRouter يرصد كل شيء للإلمام الشامل لكنه لا يحكم ويوزع إلا الأحداث غير المشترك فيها.

والاشتراك بين الـThread والعامل متعدد إلى متعدد: عامل يشترك في عدة Threads ذات صلة، وThread يشترك فيه عدة عاملين. فإذا تقاطع عاملون في بيئة واحدة وصلتهم أحداث الـThread الجديدة جميعًا فيعرف كل واحد عمل الآخر ويحل التعارض بلا رسائل ثنائية. وفي المخرجات يرفع العاملون الخلاصات إلى الـRouter الذي يرد موحدًا ويحدّث الذاكرة الشاملة.

3.3 تنظيم السياق

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

فلتُدر النافذة المحدودة كذاكرة. وبمفاهيم تحسين المصرفات والنظم يكفي عمليتان: Inline يضع في النافذة ما سيُحتاج قريبًا صوناً لجولات الأدوات؛ وSpill يُبقي خارجها المعلومة الكاملة الزائدة عن الميزانية أو قليلة الاستخدام ولا يترك داخلًا سوى مرجع أو ملخص يُقرأ عند الحاجة.

وبمبدأ الموقعية (Locality) الكلاسيكي:

1. من الأقل بدايةً: معرّف الكائن وملخص مضمونه فقط.
2. Inline بالموقعية: معرفات الكائنات الوثيقة الصلة أولًا، ثم المضامين المتجاورة زمانًا ومكانًا — أول 50 حرفًا، والرسائل المجاورة والمردود عليها، والتعليقات المجاورة في نقاش المراجعة.
3. Spill فوق السقف: حد صغير للطويل الذي لا يُلغى كله؛ الفائض يخرج من النافذة مع مقبض استكمال يقرؤه النموذج بأداة عند اللزوم.

ومع مرور أحداث كثيرة مباشرة إلى العاملين وتراكم تاريخ المهام في التشغيل الطويل، لا يستطيع الـRouter وضع كل التاريخ في نافذته، لكن عليه استرجاع السياق إذا ذكر المستخدم مهمة قديمة عبر قناة أخرى. وتطبيق Inline & Spill باتساق على كائنات النظام يعطي آلية استرجاع متعدد القفزات عند الحاجة — سلسلة الاستدعاء (Chain of Recall) — تخفف ضياع المعلومات البعيدة لدى الـRouter.

وتحديدًا: تُمنح الـTriggerات والـThreads وجلسات العاملين معرفات فريدة، ويُحقن معرف الكائنات وثيقة الصلة، فيتكون في القاع رسم مراجع. ولأن كل كائن يُستدعى بأداة يخضع هو أيضًا لـInline & Spill، يتضمن مخرجه ملخص ومعرف القفزة التالية؛ فيمكن للنموذج من حدث راهن أن يتبع المراجع قفزة قفزة: يقرأ الـThread من رسالة، ويتتبع منه إلى جلسة عامل مرتبطة، ومنها إلى Thread مراجعة آخر.

3.4 التحرك المبكر

باستعارة التنفيذ التخميني من النظم، يمكن للوكيل أن يجرّب في الخلفية قبل أن يُعرف هل تُعتمد النتيجة، مقابل حساب خلفي إضافي يقلل انتظار الإنسان وتدخله. ما فيه خير يُسلَّم وما لا خير فيه يُهمَل.

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

4. التفاعل الموجه للإنسان

تضمن بناء الطبقتين الترابط على مستوى السياق؛ ولبقائه ترابطًا وكفاءة في التجربة الحية مسألتان: إزالة حجب العمليات الطويلة أمام الحوار عبر حلقة ReAct غير المتزامنة (4.1)، ومواءمة المخرجات لعرض كل قناة وعادات أهلها (4.2).

4.1 تفاعل مزدوج كامل

في حلقة ReAct الكلاسيكية يحجب استدعاء run() المتزامن الحلقة حتى عودة النتيجة، ولا تستجيب الجلسة لأي مدخل جديد في الأثناء. وإزالة الحجب تعني الانتقال من نصف مزدوج إلى مزدوج كامل.

لذا حُوّلت الأوامر والمهام الفرعية الطويلة إلى start() وstop() غير المتزامنين مكوّنةً حلقة ReAct غير المتزامنة. يعيد start() فورًا «بدأ» ولا تنتظر الحلقة؛ وعند اكتمال الأداة خلفيًا يُلقى الناتج في الجلسة رسالةً جديدة؛ ويمكن للنموذج استدعاء stop() لإنهاء أمر طال أمده.

بهذا ينفصل الحوار الأمامي عن التنفيذ الخلفي: يجيب الوكيل والمهام الطويلة تدور. والمدخل الجديد يعالج عقب خطوة الاستدلال الجارية لا خلف أداة منتظرة. الآلية منفذة في DeepSeek Harness ولم تُفعَّل افتراضيًا بعد.

4.2 تفاعل متعدد القنوات

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

البنية الطبقية تحل بعض ذلك: الاستدلال المطول والاستدعاءات تظل داخل جلسات العاملين، والـRouter وحده يواجه الخارج. وفوق ذلك يتصل النظام ببيئات العمل الفعلية ويضبط برومبت المعايير لكل قناة:

• قنوات المراسلة الفورية: تواصل خفيف منخفض الإزعاج — كزميل بشري يخطر عند القرار أو التسليم فقط، يسأل مباشرة ويجيب بإيجاز. قاعدة صارمة بسيطة أثبتت جدواها: رد واحد لا يتجاوز 100 كلمة.
• GitHub والبريد والمستندات (قنوات غير متزامنة): تسليم غير متزامن مهيكل عالي الكثافة — طلبات سحر مكتوبة وفق معايير المشروع بخلفية المشكلة ووصف التعديل ونتائج التحقق؛ وللمساعد الشخصي مسودات بريد ومستندات مهيكلة.

5. فصل الحساب والحالة والبيئة

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

5.1 فصل الحساب والحالة

يمكن جعل حساب الحلقة عديم الحالة؛ والواجب حفظه هو الحالة الجلسية. الفصل الأول: الحساب في حاويات سحابية مرنة عديمة الحالة، والجلسات والمهام في قاعدة بيانات. تتوسع الحاويات وتُعاد وتُستبدل، والتخزين الدائم يضمن الاستمرارية — فيتحرر الوكيل من دورة حياة جهاز محلي واحد.

5.2 فصل الحساب وبيئة التنفيذ

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

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

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

وهذا يوافق «فصل الدماغ عن اليدين» عند Anthropic: harness بلا حالة، وسجلات الجلسة خارجه، والبيئات تُلحق عبر واجهة موحدة. والفرق في المشهد: ذاك المقال يصف خدمة مُدارة وصناديق رمل عند الطلب وموارد داخل VPC العملاء؛ وهنا أول ما يُلحَق هو الأجهزة الشخصية اليومية ربما متقطعة الاتصال، بتعديلاتها غير المرفوعة واعتماداتها المحلية. لذا يدعم التصميم BYOM (Bring Your Own Machine) — إلحاق حاسوبك اليومي — إلى جانب الأجهزة المُدارة والحساب عند الطلب.

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

6. Watchdog

إلى جانب الفصل يحتاج الدوام تعافيًا ذاتيًا من الخلل. النظم الموزعة دائمة التشغيل يصعب أن تكفل موثوقيتها منطقُها الداخلي وحده؛ يلزم مسار تحكم خارجي مستقل — Control Loop.

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

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

7. تجارب أولية

لتقييم التصميم الأساسي للجدولة والتوجيه أجري طبقتان من التجارب: مقارنة شاملة بين البنية الطبقية بالاشتراك المباشر وصيغ الجلسة الواحدة (7.1)، ثم اختبار ضغط منفصل لتجميع الـRouter (7.2). الأحمال تخليقية والبيئات مبسطة، والنتائج مرجع أولي.

7.1 تجربة الحذف

دفعت تدفقات محادثات وCI GitHub أربع صيغ: نحو 300 رسالة في التجربة، منها نحو 20 طلب عمل، والبقية دردشة ومتابعة وإيقاف وCI. وأُبدل عمل البرمجة بأداة تستهلك الوقت فقط، فقياس التجربة للجدولة والتنسيق لا لتنفيذ المهمة الواحدة. خمس مرات لكل صيغة.

الأربع: Super-agent؛ وSuper-agent بلا تمرير مباشر؛ وجلسة واحدة + أداة subagent ببرومبتين. البرومبت المحايد: "Use a subagent for a piece of work when appropriate..."؛ والمفضِّل للتفويض: "Every message of the chat reaches you, so work you run yourself keeps stopping for new messages. Prefer handing each piece of work to a subagent of its own, and do only small things yourself..."

في زمن الإنجاز بلغ وسيط Super-agent و95 منه 12.4 و15.7 دقيقة متفوقًا بوضوح على الجلسة الواحدة بأداة subagent. فالجلسة الواحدة شديدة الحساسية للبرومبت: كثيرًا ما اختارت الجلسة الرئيسية التنفيذ بنفسها فطال الزمن واضطرب. وبالبرومبت المحايد لم تستدعِ الأداة ولا مرة في خمس جولات؛ جرى العمل كله في الجلسة الرئيسية يُقطَع بالرسائل حتى بلغ الـ95 29.5 دقيقة؛ وبالتفويض فوضت في 4 من 5 — أسرع لكنها تظل دون Super-agent — وفي الخامسة رأت العمل «صغيرًا» فأنجزته بنفسها مكوّنة الذيل البنفسجي الطويل. فبدل ترك فصل العمل للبرومبت وحدس النموذج تحسم البنية الطبقية الأمر بنيويًا: الـRouter لا ينفذ، والعامل لا يستقبل إلا رسائل Thread مشتركه.

وعلى الكلفة: صيانة جلسات متعددة تجعل رموز قراءة الذاكرة للتجربة الواحدة أعلى من الجلسة الواحدة — رموز أكثر مقابل زمن أقرب وأثبت. وداخل Super-agent، إزالة التمرير المباشر أبقت الزمن شبه ثابت لكنها رفعت قرارات الـRouter نحو 30% ورموز قراءة الذاكرة من 23.23 مليون إلى 31.77 مليونًا (+37%). فتحت هذا الحمل لا يرفع التمرير جودة ولا سرعة، لكنه يوفر على الـRouter رموزًا واستدلالًا معتبرًا.

7.2 تجميع الـRouter

لاختبار سقف جلسة الـRouter المقيمة أجري اختبار ضغط منفصل: نموذج حقيقي للـRouter ووهمي للعاملين، مع رفع معدل ورود الـTriggerات الواجب حسمها من نحو 1 إلى نحو 40 في الدقيقة، ورصد متوسط الدفعة وزمن النداء وزمن الاستدلال لكل قرار.

فمن نحو 1 إلى نحو 40 في الدقيقة ارتفع متوسط الدفعة من 1.0 إلى 2.8 بينما لم يتجاوز زمن النداء 2.5 ثانية إلى 3.9 — نمو أبطأ من الدفعة — فهبط زمن الاستدلال لكل قرار من 6.4 ثانية إلى 1.6. فعند تدفق الأحداث يرفع الـRouter إنتاجيته الفعالة بدمج المتراكم تلقائيًا. وهذا يفسر أن إزالة التمرير في 7.1، رغم رفعها ذروة حمل الـRouter، لم تلامس سقفه — فلا داعي عند مقياسنا الحالي لتقسيم مبكر يضحي باستمرارية السياق الشامل.

8. مسائل مفتوحة

ألفت الأقسام 2–6 الهيكل الأساس، وأثبت القسم 7 الجدولة والتوجيه تحت الحمل المتزامن. ويظل النظام قليل التعقيد بفضل تبسيطات هندسية ومشهدية مقصودة. وعند تجاوزها تبقى مسائل: توسيع الطبقتين (8.1)؛ التعاون بعد الجلسات (8.2)؛ حدود السياق وA2A (8.3)؛ والأمن والخصوصية (8.4).

8.1 توسيع الطبقتين

تركيبة «Router مقيم + اشتراك مباشر + بلا تواصل بين العاملين» غطت بأقل كلفة معظم المهام اليومية. وعند تجاوز الحمل لا جواب قاطعًا للبنية الداخلية: متى التقسيم الأفقي وبأي حبيبية؛ ومتى تواصل مباشر بين العاملين وبأي طبولوجيا. والتصميم المشترك للنظام والنموذج اتجاه يستحق: تدريب خاص لتمييز أحداث الـRouter وإرسالها الدفعي واستدعاء سياقها قد يرفع الإنتاجية وجودة القرار.

والـRouter المقيم مع سلسلة الاستدعاء يحلان استرجاع القريب أساسًا. وعلى مدى شهور وأكثر تصبح الذاكرة البعيدة عنق الزجاجة للتوسع.

8.2 التعاون بعد الجلسات

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

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

8.3 حدود السياق وA2A

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

وبوجود نسخ معزولة داخل المنظمة أو بين المنظمات — مساعدو الأفراد وSuper-agent الفريق — يصبح التعاون عبر الحدود تواصل وكلاء (A2A، بلا بروتوكول بعينه). وتحقيق A2A آمن موثوق بين أطراف لا تشترك سياقًا وتمثل حدود صلاحيات مختلفة ما يزال بحثًا.

8.4 الأمن والخصوصية

نظام الأحداث يوسع ما يقود الوكيل ويوسع معه التعرض لمدخلات غير موثوقة. وبلا حلول جيدة للأمن والخصوصية لا يعمل Super-agent إلا في نطاق ضيق موثوق.

فقسم 5 — حلقة في السحابة وdaemons خفيفة على الأجهزة — يفترض ثقة متبادلة بين الطرفين. لكن حلقة تلاحق أحداثًا خارجية موصولة بأجهزة تحمل شيفرة خاصة وبيانات حساسة واعتمادات محلية تدخل مخاطر حقيقية: اختراق خدمة أو حقن برومبت للحلقة يهدد بالسيطرة على كل الأجهزة الموصولة.

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

9. خاتمة

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

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

في هذا الشكل لا يعود الوكيل نافذة تنتظر الأوامر بل متعاونًا مستقلًا مقيمًا في البيئة الرقمية: للأفراد مساعدًا عبر الأجهزة، وللفرق مشاركًا في سير التطوير يتسلم المهام ويدفعها. ومع تطور القدرة والمعمارية معًا قد يصير هذا النمط الأكثر استقلالية هو معيار التعاون بين الإنسان والآلة.

كما في الأصل: أجزاء من هذا التصميم منفذة في dsh-superagent-prototype؛ وال-plugin نموذج أولي للتحقق من المسار وليس منتجًا رسميًا. المؤلف والشكر: النص ثمرة ممارسة فريق DeepSeek Harness؛ أنجز Yujia Qiao التنفيذ والكتابة، وشارك في المراجعة والنقاش Huanqi Cao وZui Chen وXieting Chu وTianyi Cui وShiyuan Feng وYudong Han وKexin Liu وShichun Liu وGesi Luo وYifan Shi وTongrui Xiong وHanxiang Xu وC.C. Yu وZiya Zhang وF. Zhou.

المصادر

• DeepSeek 产品部 (WeChat الرسمي) — النص الأصلي الصيني، 1 نوفمبر 2026
• deepseek-ai/dsh-superagent-prototype — النموذج الأولي برخصة MIT (README وdocs 000–008)
• مراجع داخلية: الترجمة الإنجليزية الكاملة · النص الصيني الأصل · تغطية dsh-superagent