دوز مباشرة للمحتوى الرئيسي
دروس فالذكاء الاصطناعي

إعداد واستعمال dsh-superagent لمهام البرمجة الاستباقية فـ GitHub

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

إعداد واستعمال dsh-superagent لمهام البرمجة الاستباقية فـ GitHub

شنو هو dsh-superagent؟

dsh-superagent هو وكيل برمجي استباقي مصمم باش يخدم مع مستودع واحد فـ GitHub. كيتوزع كحزمة على DeepSeek Harness وكيستمع للطلبات اللي جاية من GitHub، ومن Feishu اختيارياً.

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

dsh-superagent نموذج أولي بحثي للرجوع إليه، وماشي منتوج رسمي ديال DeepSeek ولا نظام واجد للإنتاج.

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

المبدأ الأساسي فالتصميم

الهدف ديال المشروع هو ياخذ أقل قدر ممكن من الانتباه البشري، مع تقديم أكبر قيمة ممكنة. وحيت الوكيل ديال الفريق كامل يقدر حتى هو يستهلك انتباه الفريق، dsh-superagent كيتبع جوج قيود مهمين:

  • كيخدم غير ملي شي واحد كيطلب منو يخدم، ولا ملي شي قاعدة محددة من طرف الفريق كتسمح بهاد الإجراء.
  • كيهضر غير ملي خاص شي واحد يدير إجراء، ولا يقدر يستافد من نتيجة كملات.

قبل ما تنشر الوكيل، قرا وثيقة الفلسفة. كاتشرح هاد المبدأ التشغيلي والمسؤوليات ديال الشخص اللي كيسير النظام.

الخصائص الرئيسية

  • التركيز على مستودع واحد: كل عملية نشر كتخدم مع مستودع واحد فـ GitHub.
  • التكامل مع GitHub: الوكيل كيسمع للطلبات المصرح بها والجاية من GitHub.
  • التكامل الاختياري مع Feishu: الفرق تقدر تستعمل حتى Feishu كمصدر للطلبات.
  • تتبع عناصر الخدمة: كل طلب مقبول كيولي عنصر خدمة.
  • تنفيذ معزول: كل مهمة كاتخدم فجلسة ودليل خاصين بالوكيل.
  • أجوبة واعية بالمحادثة: النتائج كترجع للمحادثة اللي جا منها الطلب.
  • لوحة الانتباه البشري: لوحة ويب كاتحدد الخدمة اللي محتاجة تدخل شي شخص.
  • سلوك محكوم بالقواعد: الوكيل كيتصرف غير استجابة لطلب ولا لقاعدة صريحة ديال الفريق.

قبل ما تثبت

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

الإعداد فيه بزاف ديال المراحل، وداكشي علاش المشروع كيوصي تكملو بشكل تشاركي مع وكيل برمجي، عوض التخمين اليدوي للإعدادات المطلوبة.

التثبيت والإعداد الموجهان

الخطوة 1: حلّ المستودع باستعمال الوكيل البرمجي ديالك

خلي المستودع اللي درتي ليه clone ولا checkout متاح للوكيل البرمجي ديالك. ومن بعد عطيو تعليمة الإعداد اللي كيوصي بها المشروع:

قرا SETUP.md فهاد المستودع وجهز معايا dsh-superagent.

خاص الوكيل البرمجي يتبع SETUP.md باعتبارها المصدر المعتمد.

الخطوة 2: جاوب على أسئلة الإعداد

مسار الإعداد مصمم باش يطرح سؤال قصير واحد فكل مرة. عطيو المعلومات المطلوبة على المستودع ديالك، والتكاملات، والبيئة ديالك. ما تفوتش مراحل المراجعة غير حيث العملية كيساعد فيها وكيل.

الخطوة 3: راجع الخطة الكاملة

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

الخطوة 4: خلي الوكيل يثبت المشروع ويضبطو

من بعد ما توافق على الخطة، الوكيل البرمجي كيثبت النظام وكيضبطو حسب SETUP.md. وحيت ملف README كيحيل تفاصيل مسطرة الإعداد على هاد الملف، تبع التعليمات الحالية ديالو عوض الاعتماد على أوامر ما موثّقاش.

الخطوة 5: تحقق من المشروع

للتحقق فمرحلة التطوير، شغل:

pnpm check

هاد الأمر كيشغل فحص الأنواع، والاختبارات، والبناء. التشغيل الناجح كيعطي فحصاً موحداً للأنواع ديال المشروع، ومجموعة الاختبارات، وعملية البناء.

فهم التوثيق قبل تشغيل الوكيل

التوثيق المرقم مترتب بشكل تراكمي عن قصد. قراه بالترتيب، حيث كل وثيقة كتفترض غير المواد اللي تقدمات قبل منها:

  1. 000 الفلسفة: فهم المبدأ التشغيلي اللي كيقلّل من استهلاك الانتباه، والمسؤوليات ديال المشغّل.
  2. 001 نموذج المجال: تعلّم المفاهيم الأساسية ديال المشروع وكيفاش كترتبط ببعضياتها.
  3. 002 التفويض: حدّد شكون مسموح ليه يطلب من الوكيل ينجز الخدمة.
  4. 003 التنفيذ: فهم كيفاش كتتنفّذ المهام المقبولة.
  5. 004 التعليمات: راجع التعليمات اللي كتوّجه سلوك الوكيل.
  6. 005 اللوحة: تعلّم كيفاش كتعرّض لوحة الويب العناصر اللي كتحتاج انتباه بشري.
  7. 006 النشر: تبّع إرشادات الإعداد اليدوي، والتهيئة، والترقية، وحلّ المشاكل.
  8. 007 المعمارية: درس البنية التقنية ديال النظام.
  9. 008 دليل الوصفات: تعلّم كيفاش تزيد Source.

الاستعمال الأساسي

إرسال طلب مُفوَّض

من بعد الإعداد، يقدر مستخدم مسموح ليه يطلب من الوكيل ينجز خدمة فالمستودع عبر GitHub أو عبر Feishu إلا كانت هاد الاندماج الاختياري مفعّلة. خاص الطلب العادي يوضّح التغيير المطلوب فالمستودع وأي معايير قبول مرتبطة به.

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

خلّي الوكيل ينشئ وينفّذ عنصر الخدمة

ملي كيتقبل الطلب، كيفتح dsh-superagent عنصر خدمة وكيخدم على المهمة فجلسة الوكيل والدليل ديالو. هاد النموذج ديال التنفيذ كيخلي السياق العملي ديال المهمة منفصل.

تلقّى النتيجة فالسياق ديالها

كيردّ الوكيل فالمحادثة الأصلية بلا ما يفرض على المستخدمين يقلبو على النتائج فقناة أخرى. وعلى حساب الخدمة اللي تدارَت، يقدر الرد يتضمّن طلب دمج.

استعمل اللوحة للمتابعة البشرية

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

التفويض والتشغيل الآمن

التفويض أساسي فهاد التصميم. الوكيل الاستباقي اللي يقدر يتصرّف فمستودع ديال الفريق ما خاصوش يقبل طلبات عشوائية. استعمل وثائق التفويض باش تحدّد شكون يقدر يبدا الخدمة وفاش تقدر تبدا.

  • قيّد مقدّمي الطلبات: سمح غير للأشخاص أو الأنظمة المقصودة ينشئو طلبات قابلة للتنفيذ.
  • راجع قواعد الفريق: تأكّد بلي الإجراءات الآلية كتوقع غير وفق القواعد اللي كتبها الفريق بوضوح.
  • حافظ على المراجعة البشرية: اعتبر التغييرات اللي كيولّدها الوكيل خدمة ممكن تحتاج التفقد والتكييف.
  • جرّب قبل الاستعمال الواسع: شغّل pnpm check من بعد تغييرات التطوير، وتحقّق من السلوك فبيئتك.

نصائح متقدمة

استعمل دليل النشر للعمليات اليدوية

إلا كنت محتاج تدير الإعداد يدوياً، تبدّل التهيئة، ترقي المشروع، ولا تحلّ مشكل فيه، راجع 006 النشر. كيوضّح README بلي هاد الوثيقة هي المصدر المفصّل لهاد الإجراءات التشغيلية.

راجع التعليمات ملي كتضبط السلوك

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

درس التنفيذ قبل ما تبدّل عزل المهام

كيعطي النظام لكل عنصر خدمة جلسة وكيل ودليل خاصّين به. قبل ما تبدّل هاد السلوك، راجع 003 التنفيذ و007 المعمارية باش تبقى التغييرات منسجمة مع نماذج التنفيذ والنظام ديال المشروع.

زيد Source بحذر

Source هو اندماج كيقدر النظام يستقبل من خلاله الخدمة. إلا بغيتي تزيد واحد آخر من غير مساري GitHub وFeishu الاختياريين الموفّرين، تبّع 008 دليل الوصفات. ما تتجاوزش نموذج التفويض ملي كتدخل قناة جديدة للطلبات.

حسّن من أجل الصمت المفيد

ملي كتكيّف النظام، قيّم قيمة كل إجراء وتكلفة الانتباه ديال الإشعارات ديالو. فضّل التواصل ملي خاص شخص يدير شي إجراء أو ملي كتكون نتيجة قابلة للاستعمال واجدة. هاد الشي كيخلّي الإضافات والقواعد التشغيلية منسجمة مع الفلسفة المركزية ديال المشروع.

مسار التطوير

من بعد ما تبدّل الكود، استعمل أمر التحقق المدمج ديال المشروع:

pnpm check

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

الخلاصة

كيقدّم dsh-superagent نموذج موجّه للبحث لتفويض الخدمة على مستودع GitHub واحد، مع تقليل المطالب على انتباه البشر. بدا بمسار SETUP.md الموجّه، قرا الوثائق المرقّمة بالترتيب، هيّأ التفويض بحذر، تحقّق من التغييرات باستعمال pnpm check، واستعمل اللوحة باش تركّز الجهد البشري فين كاين الاحتياج الحقيقي.