IT之家، أعلن اليوم 31 أكتوبر أن الفريق الرسمي لـ DeepSeek Harness نشر مقالًا بعنوان “استكشاف تصميم Super-agent: نحو نظام أجهزة ذات استقلالية أكبر”، ويوضح المقال أساليب التصميم الهيكلي لـ Super-agent الموجهة للممارسات الهندسية.
مع تقلّ الحاجة إلى تدخل الإنسان كلما كان النموذج الكبير يقوم بمهمة واحدة، فإن العوامل التي تحد من الإنتاجية تتحول تدريجيًا إلى انتباه الإنسان. يحتاج نظام الوكيل إلى التحول من أداة لإصدار الأوامر بشكل سلبي إلى شريك مستقل يعمل على الإنترنت المستمر ويمكنه معالجة عدة مهام في نفس الوقت.
قالت شركة DeepSeek إن تصميم الوكالات الرئيسية الحالية لا يزال يعتمد على الجلسة الواحدة كوحدة أساسية، حيث تكون الجلسات المختلفة مستقلة عن بعضها البعض. عندما يقوم المستخدم بأداء عدة مهام بشكل متوازي، يجب عليه التبديل يدويًا والحفاظ على سياق كل جلسة على حدة.
وفقًا لملاحظات فريق DeepSeek، يمكن للشخص عادةً متابعة من 3 إلى 5 جلسات نشطة في نفس الوقت. حتى عند استخدام CLI أو MCP أو المزيد من مكوّنات الاتصال الخارجية لتوسيع الوكيل المحلي، قد تواجه مشاكل مثل الانسداد في التزامن بين جلسة واحدة، الفوضى في سياق المهام المتعددة، وتوقف المهام بعد انقطاع الجهاز المحلي.
يطلقون على هذا الشكل الجديد للعميل وهيكل النظام هذا اسم “Super-agent”， ويصنفون أربع خصائص أساسية: الاستمرارية، الكفاءة العالية، النشاط، والاستدامة.
أولاً، الاتصال المستمر يعني أن المستخدم يمكنه التفاعل مع العميل نفسه عبر قنوات مختلفة مثل المراسلات الفورية وتعليقات GitHub؛ الكفاءة العالية تعني القدرة على معالجة مهام معقدة متعددة بشكل متوازي؛ النشاط يعني أن النظام يمكنه مراقبة الأحداث البيئية باستمرار وتقدم الأمور التي تستحق المعالجة بنفسه؛ والاستمرارية تتطلب أن يكون العميل على اتصال دائم، ويمكنه التعافي من الحالات الشاذة أثناء التشغيل على المدى الطويل.
تتكون البنية الكاملة التي طرحتها DeepSeek من خمسة أجزاء: البنية المزدوجة، الدفع بالأحداث، التفاعل الموجه للإنسان، الفصل بين الحسابات والحالة البيئية، وWatchdog.
في هذا النظام، يتم تقسيم البنية المزدوجة إلى طبقتين: طبقة الراوتر وطبقة العامل. يتولى الراوتر استقبال التفاعلات البشرية، الحفاظ على السياق العالمي، وتوزيع المهام، بينما يقوم العامل بتنفيذ الأعمال الفردية بشكل متزامن في جلسات منفصلة عن بعضها. لا يرد العامل مباشرة على المستخدمين، بل يبلغ الراوتر بالحالة والنتائج، الذي بدوره يتولى الاتصال الخارجي بشكل موحد.
في آلية تشغيل الأحداث، تُعرف المعلومات الخارجية مثل رسائل الدردشة الجماعية، الرسائل الإلكترونية، تنبيهات الجدول الزمني، تعليقات مراجعة الكود، ونتائج تشغيل CI كـ "Trigger". يقوم النظام أولاً بتصفية الأحداث وفقًا لقواعد البرنامج، ثم يترك الأمر للنموذج الكبير لتحديد ما إذا كان هناك حاجة لاتخاذ إجراء. بالنسبة لسلسلة الأحداث التي تم تخصيص المهام لها، يمكن للWorker الاشتراك في السوفتشريت المقابل، ويتم إرسال الأحداث المتعلقة لاحقًا مباشرةً إلى Worker دون الحاجة إلى مرور كل شيء عبر Router، مما يقلل من حمل التوجيه.
قدم فريق DeepSeek أيضًا آليات Inline & Spill وChain of Recall. يضع الآلية الأولى المعلومات التي قد تُستخدم قريبًا مباشرة في نافذة السياق الخاصة بالنموذج، بينما يتم الاحتفاظ بالمحتوى الذي يتجاوز الميزانية أو يُستخدم بشكل نادر خارج النافذة، ليتم قراءته من قبل النموذج حسب الحاجة؛ أما الآلية الثانية، فهي تتيح للنموذج استعادة معلومات المهام التاريخية تدريجيًا عبر روابط بين كائنات مثل Trigger وThread وWorker Session.
لتقليل وقت الانتظار للبشر، أدخلت Super-agent آلية تنفيذ مضاربة يمكنها البدء في العمل مسبقًا بناءً على إشارات البيئة. على سبيل المثال، بعد استلام دعوة الاجتماع، يتم أولاً فحص التداخلات في الجدول الزمني، جمع المعلومات الأساسية، وإعداد مسودة الرد؛ وفي سياق التعاون البحثي والتطويري، يمكن محاولة إعادة إنتاج المشكلة وتحديد حلول الإصلاح أثناء مناقشة الموضوعات في الدردشة الجماعية، ولا يتم تسليم النتائج للمستخدم إلا بعد تأكيد المشكلة وإيجاد طريقة إصلاح بسيطة.
في مجال التفاعل بين الإنسان والآلة، يقترح المقال دورة ReAct غير المتزامنة، حيث يتم تحويل استدعاء الأدوات المُستهلكة للوقت إلى start() وstop() غير المتزامنة. بعد بدء العميل لمهمة خلفية، يمكنه العودة إلى الحالة Started دون الحاجة إلى الانتظار حتى اكتمال المهمة، ويتم إدخال نتائج الخلفية كحدث جديد في الجلسة.
بهذه الطريقة، يمكن لحوار الواجهة الأمامية الاستمرار في استقبال رسائل المستخدم الجديدة. ومع ذلك، أوضح فريق DS بشكل خاص أن آلية المهمة غير المتزامنة قد تم تحقيقها في DeepSeek Harness، لكنها لم تُفعَل بشكل افتراضي بعد.
لتشغيلها على المدى الطويل عبر الإنترنت، يقوم DeepSeek بفصل حسابات دورة العملية والحالة الدورية وبيئة التنفيذ: يتم وضع الحسابات والحالة المستمرة على السحابة، بينما يمكن الاحتفاظ ببيئة التنفيذ على الجهاز المحلي للمستخدم، مع توزيع دائرة خفيفة مسؤولة عن تنفيذ الأوامر وعرض النتائج. يدعم هذا التصميم BYOM (جلب جهازك الخاص)، أي توصيل أجهزة التطوير أو أجهزة الكمبيوتر الشخصية التي يستخدمها المستخدم يوميًا مع العميل السحابي، كما يدعم الاتصال بأجهزة مدارة على السحابة أو بيئة حوسبة يتم إنشاؤها حسب الحاجة.
بالإضافة إلى ذلك، يقوم النظام بإنشاء جلسة Watchdog مستقلة خارج البنية الأساسية، لتكوين دائرة تحكم خارجية. لا يقتصر Watchdog على مراقبة مشاكل البنية التحتية مثل أخطاء واجهات الاتصال وفشل استعادة الحالة، بل يقوم أيضًا بتقييم نجاح العمال في إحراز تقدم فعلي وتحقق اتجاه تنفيذهم من أهدافهم، ويتدخل في الإصلاح عند اكتشاف أي خطأ.
قام فريق DeepSeek أيضًا بإجراء تجارب أولية، مقارنة بين Super-agent وSuper-agent الذي حُذفت منه آلية التوجيه المباشر للأحداث، بالإضافة إلى خطة الدخول الفردي لجلسة واحدة مع Subagent تحت تكوينين مختلفين للتعليمات.
تحتوي التجربة على حوالي 300 رسالة في كل مرة، من بينها حوالي 20 رسالة هي طلبات عمل. تم تكرار كل خطة 5 مرات. أظهرت النتائج أن وقت إكمال مهمة Super-agent عند p50 وp95 كان 12.4 دقيقة و15.7 دقيقة على التوالي؛ أما عند الإشارة المحايدة، فإن وقت p95 لخطة سجلات جلسة واحدة كان 29.5 دقيقة.
أشار فريق DeepSeek إلى أن هذه التجارب تستند إلى حملات مركبة وبيئة مبسطة، وتقوم بشكل رئيسي بتقييم قدرة النظام على التنظيم والتعاون، ولا تقيس القدرة الفعلية على تنفيذ المهام الفردية.
في اختبار ضغط الطبقة Router، عندما تزيد سرعة وصول تنبيهات من حوالي 1 تنبيه في الدقيقة إلى حوالي 40 تنبيهًا، يزداد الحجم المتوسط للدفعة الواحدة من 1.0 إلى 2.8، ويزداد وقت استهلاك الطلب الفردي من 2.5 ثانية إلى 3.9 ثانية، بينما ينخفض الوقت المستغرق في التفكير لكل قرار من 6.4 ثانية إلى 1.6 ثانية. ويعتقد الفريق أنه عند حدوث تقلبات مفاجئة في الأحداث، يمكن لRouter أن تحسن معدل الاستهلاك الفعال عن طريق دمج الأحداث المتراكمة.
تشير الورقة البحثية أيضًا إلى أن هناك مشاكل لا تزال تحتاج إلى حل في هذا التصميم الهيكلي، بما في ذلك كيفية توسع طبقة الروتر مع حجم المهام، والذاكرة الطويلة المدى عبر الأشهر أو فترات أطول، وطريقة التعاون بين الإنسان والآلات بعد خروجها من جلسة، والاتصال A2A بين مثيلات الوكيل المختلفة، بالإضافة إلى الحماية الأمنية والخصوصية. وخاصة عند انضمام وكيل السحابة إلى الأجهزة المحلية، فإن إدخال كلمات التوجيه، وتسريب بيانات الهوية على الجانب الطرفي، ومخاطر الصلاحيات عبر الأجهزة المختلفة كلها تحتاج إلى حلول أكثر.
قال فريق DeepSeek إن المثال الداخلي لـ Super-agent الذي تم بناؤه باستخدام DeepSeek Harness يعمل بشكل مستمر، ويشارك في تكرار وحل المشاكل، ومراجعة الكود، بالإضافة إلى تطوير DeepSeek Harness نفسه.
بالإضافة إلى ذلك، قدموا في المقال تنفيذ نموذج أولي يُسمى dsh-superagent-prototype، لكنهم أوضحوا بشكل صريح أن هذا الإضافة تُستخدم للتحقق من المسار التقني، وليست منتجًا رسميًا لشركة DeepSeek.
المصدر:
مخزن GitHub لـ dsh-superagent: https://github.com/deepseek-ai/dsh-superagent-prototype