الوكيل الذكي المستقل (AI agent) نظام يعمل ضمن هدف محدد، ويستخدم أدوات، ويحتفظ بسياق المهمة، ويكرر الخطوات حتى ينجز العمل أو يتوقف. يختلف عن نموذج يجيب عن سؤال واحد لأنه ينفذ أفعالا داخل بيئة العمل ضمن صلاحيات يحددها الفريق، ويحتاج إلى نقاط توقف بشرية قبل القرارات الحساسة. أما مشروع dsh-superagent المنشور على GitHub ضمن منظمة deepseek-ai، فيصف نفسه بأنه نموذج بحثي للمرجعية، وليس منتجا رسميا من DeepSeek، وليس جاهزا للإنتاج.
يصل إلى فريق الدعم في شركة متوسطة الحجم طلب بسيط: تغيير صلاحيات موظف. قد يشرح لك نموذج لغوي الإجراء بوضوح، لكنه لن يفتح النظام ولن يكتب التغيير بنفسه. هنا يظهر الفرق بين الإجابة والتنفيذ.
يشرح هذا المقال ما هو الوكيل الذكي المستقل، وكيف تسير دورة عمله، وما الأدوات والصلاحيات التي يحتاجها، ومتى يتوقف عند نقطة بشرية. كما يعرض مشروع dsh-superagent المنشور ضمن منظمة deepseek-ai على GitHub، ويوضح حدوده التي يجب أن يعرفها فريق تقنية المعلومات قبل أي تجربة.
ما هو الوكيل الذكي المستقل، وكيف يختلف عن نموذج يجيب على الأسئلة فقط؟
يبدأ الفرق من طريقة العمل نفسها. نموذج اللغة الذي يجيب عن سؤال واحد يستقبل نصا ويعيد نصا، ثم تنتهي الجولة. أما الوكيل الذكي المستقل (AI agent) فيعمل ضمن هدف محدد، ويستخدم أدوات، ويحتفظ بسياق المهمة، ويكرر الخطوات حتى ينجز العمل أو يتوقف.
خذ مثالا توضيحيا لفريق دعم في شركة متوسطة الحجم في الرياض. يصله طلب بتغيير صلاحيات موظف. سؤال واحد إلى نموذج عام قد يعطي شرحا جيدا للإجراء، لكنه لا يفتح البلاغ، ولا يتحقق من الصلاحيات الحالية، ولا يبلغ صاحب الطلب بالنتيجة. الوكيل المصمم لهذه المهمة يقرأ البلاغ، ويجمع المعلومات من الأنظمة المسموح له بالوصول إليها، ويقترح الإجراء، ثم ينفذه أو يطلب موافقة المختص.
قبل تحويل أي مهمة إلى وكيل، ابدأ بتحديد نقطة الازدحام في العمل اليومي. الأتمتة المفيدة تبدأ من نقطة ازدحام واضحة تساعد على تحديد ما يستحق التجربة أولا.
الاستقلالية درجات وليست حالة ثنائية
لا يكون الوكيل مستقلا أو غير مستقل. الاستقلالية تتدرج حسب ما يُسمح له بفعله دون مراجعة بشرية. التقسيم التالي أداة للشرح، وليس معيارا رسميا معتمدا:
- المستوى الأول: وكيل يقترح فقط، والإنسان هو الذي ينفذ.
- المستوى الثاني: وكيل ينفذ إجراءات محددة ومكتوبة مسبقا، ويطلب موافقة لأي شيء خارجها.
- المستوى الثالث: وكيل يعمل على مهمة كاملة ضمن صلاحيات ضيقة، ويعرض النتيجة على إنسان قبل أن تصل إلى الأنظمة الحية أو إلى العملاء.
- المستوى الرابع: وكيل يتخذ قرارات واسعة دون مراجعة، وهذه أعلى درجات المخاطرة.
الفرق بين الوكيل وروبوت المحادثة في الاستخدام اليومي
روبوت المحادثة يجيب داخل جلسة يفتحها المستخدم، ثم ينتهي دوره عند الرد. أما الوكيل فيعمل على مهمة لها مدخلات ومخرجات ونقطة توقف واضحة.
مثال من مشروع برمجي: يصف المستودع المسمى dsh-superagent نموذجا يستمع إلى أحداث مستودع GitHub. وعندما يطلب شخص مسموح له عملا، يفتح بندا للعمل، ويعمل عليه في جلسته ومجلده الخاصين، ثم يرد في المحادثة الأصلية، مثل إنشاء طلب دمج. هذا عمل من عدة خطوات، وليس جوابا واحدا. ويذكر المستودع أيضا أن الوكيل يتصرف حين يُطلب منه ذلك، أو حين تسمح قاعدة كتبها الفريق، وهذه نقطة مهمة لفهم الحدود.
كيف يعمل الوكيل الذكي خطوة بخطوة من التخطيط حتى التحقق من النتيجة؟
لفهم الدورة خطوة بخطوة، ابدأ من الهدف. لنفترض مثالا توضيحيا: يطلب فريق تقنية معلومات في شركة توزيع بالرياض من الوكيل إصلاح خطأ في صفحة داخلية. بدون شرط اكتمال واضح، لن يعرف الوكيل متى يتوقف، ولن يعرف الفريق متى يقبل النتيجة.
لم تحدد المصادر التي راجعناها عددا ثابتا لمراحل هذه الدورة، لذلك نعرضها هنا ست خطوات للتوضيح فقط. كل خطوة تترك أثرا يمكن مراجعته لاحقا.
دورة العمل: الهدف، التخطيط، الأدوات، المراجعة
يبدأ الوكيل بتحديد الهدف وشروط اكتماله، مثل نجاح الاختبارات المرتبطة بالصفحة وعدم تغيير أي ملف خارج نطاقها. ثم يقسم المهمة إلى خطوات صغيرة، ويستدعي أداة مناسبة، ويقرأ نتيجتها. إذا فشلت الاختبارات، يذكر الوكيل سبب الفشل، لا أن يعلن الإنجاز.
التحقق من نتيجة الوكيل لا يعني الثقة المطلقة بالنموذج. يعني مقارنة النتيجة بمعايير واضحة: هل اجتازت الاختبارات؟ هل بقي التغيير ضمن النطاق؟ هل تطابق الطلب الأصلي؟ النموذج قد يخطئ بثقة، لذلك يجب أن يكون الفحص مستقلا عن رأيه، بأداة اختبار أو بمراجعة بشرية.
أين توضع نقطة التوقف البشرية في الدورة
نقطة التوقف البشرية لا تكون في نهاية الدورة فقط. قد تقع بعد التخطيط وقبل أي تغيير يمس بيئة الإنتاج، أو بعد المراجعة وقبل دمج النتيجة. تحديد هذه النقاط قرار حوكمة يتخذه الفريق.
في مستودع dsh-superagent، يعمل الوكيل في جلسة ومجلد خاص به، ويجيب في المحادثة الأصلية، مثلا بطلب سحب (pull request)، وتعرض لوحة ويب ما يحتاج إلى شخص. أي أن النتيجة تعود إلى من طلب العمل لمراجعتها قبل اعتمادها.
ويذكر ملف README أن المشروع نموذج أولي للبحث وليس برمجية جاهزة للإنتاج، وأن بعض التصاميم في المقال المرتبط به لم تُنفذ بعد. لذلك تحقق من كل مرحلة في الكود نفسه قبل الاعتماد عليها.
دورة عمل الوكيل الذكي من البداية إلى القرار
- الهدفما الذي يُعد نجاحا؟
- التخطيطتقسيم المهمة إلى خطوات
- استدعاء الأداةقراءة ملف أو تشغيل اختبار
- قراءة النتيجةتسجيل ما أعادته الأداة
- المراجعةمقارنة النتيجة بالمعايير
- القرارمتابعة، توقف، أو تسليم
خطوات الدورة بالترتيب
تحديد الهدف
صياغة الهدف وشروط اكتماله، مع تحديد النطاق المسموح به.
التخطيط
تقسيم المهمة إلى خطوات صغيرة مرتبة، حتى يسهل مراجعة كل خطوة.
استدعاء الأداة
تشغيل الأداة المناسبة، مثل قراءة ملف أو تنفيذ اختبار.
قراءة النتيجة
تسجيل ما أعادته الأداة، دون افتراض أنها صحيحة.
المراجعة والتحقق
مقارنة النتيجة بمعايير الاكتمال التي حُددت في البداية.
القرار
متابعة الخطوة التالية، أو التوقف عند خطأ، أو تسليم المهمة لشخص مسؤول.
ما الأدوات والذاكرة والصلاحيات التي يحتاجها الوكيل ليعمل بشكل مستقل؟
لا يعمل الوكيل الذكي المستقل بالنص وحده. ليُنجز مهمة، يحتاج إلى أدوات الوكيل الذكي التي تنفّذ الأفعال خارج نافذة المحادثة، وإلى ذاكرة تحفظ السياق، وإلى صلاحيات الوكلاء التي تحدد ما يُسمح له بالوصول إليه. هذه العناصر الثلاثة تحدد ما يستطيع الوكيل فعله فعلا.
الأدوات: ما الذي يستطيع الوكيل استدعاءه
الأداة وظيفة يستطيع الوكيل استدعاءها، مثل قراءة ملف، أو استعلام من قاعدة بيانات، أو فتح طلب في نظام تذاكر، أو إنشاء مسودة تغيير في مستودع برمجي. الأداة لا تقرر شيئا، بل تنفذ الطلب وتعيد النتيجة للوكيل.
عند تصميم أي أداة، حدد ثلاثة أمور: المدخلات المسموحة، والنتيجة التي تعيدها، والإجراء عند الفشل. أداة تعيد خطأ غامضا تربك الوكيل، وقد يكرر المحاولة دون نتيجة.
- أدوات القراءة: تقرأ ملفا أو تذكرة أو سجلا، ولا تغيّر شيئا.
- أدوات الكتابة المحدودة: تنشئ مسودة أو تعليقا، ويراجعها إنسان قبل الاعتماد.
- أدوات الكتابة المباشرة: تعدّل بيانات حية، وتحتاج أعلى درجات الحذر.
الذاكرة: ما الذي يُحفظ ولماذا يحتاج مراجعة
في ذاكرة الوكيل الذكي نفرّق بين أمرين. الأول السياق الحالي، أي ما يراه الوكيل في الجولة الجارية من تعليمات ورسائل ونتائج أدوات. الثاني السجل المحفوظ، أي ما يُكتب عن العمل بعد إنجازه ليراجعه الفريق.
السجل المحفوظ يساعد على المراجعة والتدقيق، لكنه قد يتضمن معلومات حساسة أو أخطاء تحتاج تصحيحا. لذلك اسأل من يطلع عليه، وكم مدة الاحتفاظ به.
لا تكفي المصادر المتاحة لنا لتحديد كيف يحفظ dsh-superagent السياق أو السجل، ولا مدة بقائهما. الوثيقتان 003 للتنفيذ و007 للبنية في المستودع هما المرجع، فراجعهما قبل الحكم على هذا الجانب.
الصلاحيات: القاعدة الأهم قبل أي تجربة
الصلاحية تحدد ما يُسمح للوكيل بالوصول إليه وتنفيذه. القاعدة العملية: امنح الحد الأدنى الذي تحتاجه المهمة، ولا تزد عليه.
يوضح المستودع هذا المبدأ. بحسب وصفه، يعمل الوكيل عندما يطلب ذلك شخص مسموح له، أو عندما تسمح قاعدة كتبها الفريق. ويعمل في جلسته ومجلده الخاصين، ثم يجيب في المحادثة الأصلية، كفتح طلب سحب. التفاصيل في الوثيقة 002 الخاصة بالتفويض.
هذا لا يعني أن النظام آمن تلقائيا. يصف المستودع نفسه بأنه نموذج بحثي يحتاج مراجعة قبل الاستخدام، والترخيص MIT يأتي بلا أي ضمان.
قبل ربط الوكيل بأنظمتك، راجع أولا كيف تتحدث أنظمتك مع بعضها دون تكرار العمل.
أين يتوقف الوكيل، وأين تحتاج المهمة إلى موافقة بشرية؟
الوكيل المستقل لا يعني أنه يتصرف دون حدود. الصورة الأوضح أنه يعمل ضمن ما هو مسموح له، ثم يتوقف عند نقطة يقرر فيها إنسان. نسمي هذه النقطة نقطة التوقف البشرية.
يصف مستودع dsh-superagent هذا المبدأ بوضوح. بحسب وصفه، يتحرك الوكيل عندما يُطلب منه ذلك أو عندما تسمح قاعدة كتبها الفريق، ويتكلم عندما يحتاج أحد إلى التصرف أو عندما تفيده النتيجة. كما تعرض لوحته على الويب ما يحتاج إلى شخص.
معيار الفصل الذي نقترحه بسيط. الإجراء القابل للتراجع بسهولة والمحدود الأثر يمكن أن يتم ضمن قواعد واضحة. أما الإجراءات التي تمس الأموال أو بيانات الموظفين أو صلاحيات الوصول، فتحتاج إلى موافقة بشرية على الوكيل قبل التنفيذ، حتى لو أعدّ الوكيل كل التحضير.
- أي تعديل على صلاحيات مستخدم أو مجموعة وصول.
- أي إجراء له أثر مالي، مثل صرف مبلغ أو تعديل فاتورة.
- الوصول إلى بيانات موظف أو تعديلها.
- أي رد يتضمن استثناء من السياسة المعتمدة.
سيناريو الدعم الفني: تغيير الصلاحيات
هذا سيناريو توضيحي، وليس وصفا لسلوك المستودع المنشور. يستقبل فريق دعم فني في شركة متوسطة طلبا من موظف في المبيعات لإعادة ضبط صلاحية الوصول إلى مجلد مشترك. يتولى الوكيل الذكي في الدعم الفني جمع معلومات الحساب، مثل الدور الحالي والمجموعات المرتبطة به وآخر تغيير مسجل، ثم يقترح أقل صلاحية تكفي، كقراءة فقط بدلا من التعديل.
لا ينفذ الوكيل التغيير بنفسه. يعرض الاقتراح على مسؤول الصلاحيات مع سببه والأثر المتوقع، ويبقى الطلب مفتوحا حتى تأتي الموافقة. هذه هي نقطة التوقف البشرية في أوضح صورها.
سيناريو الموارد البشرية: رد على استفسار إجازة
يسأل موظف عن رصيد إجازته وإجراءات الاستئذان. يصوغ الوكيل ردا مستندا إلى السياسة المكتوبة للشركة، ويذكر البند الذي بنى عليه الرد. إذا كانت الحالة قياسية، مثل إجازة سنوية ضمن شروط السياسة، يراجع موظف الرد سريعا ثم يُرسل.
إذا كانت الحالة استثنائية، مثل إجازة بدون راتب أو ظرف طارئ لا تغطيه السياسة، يحيل الوكيل المحادثة إلى موظف قبل أي إرسال. الوكيل لا يقرر الاستثناء، ولا يعد الموظف بشيء لم تعتمده الشركة.
مسار طلب الصلاحية
استلام الطلب
يفتح الوكيل بندا يربط الطلب بالمستخدم والمجلد.
جمع المعلومات
يقرأ حالة الحساب والمجموعات الحالية دون تعديل.
اقتراح الحل
يحدد أقل صلاحية تكفي، ويكتب سبب الاقتراح.
نقطة التوقف
يتوقف ويرفع الطلب إلى مسؤول الصلاحيات، ولا يغيّر شيئا قبل الموافقة.
التنفيذ والتحقق
بعد الموافقة ينفذ التغيير، ثم يتحقق من أن الصلاحية صارت كما اعتُمدت.
ما المقصود بمشروع DeepSeek superagent prototype، وما الذي يوضحه المستودع عن هدفه؟
المستودع المقصود هو deepseek-ai/dsh-superagent-prototype على GitHub، ويُشار إليه بالاسم DeepSeek superagent prototype. ينشره حساب deepseek-ai، وعنوانه الوصفي: Towards a More Autonomous Agent System.
يحمل المستودع اسم dsh-superagent-prototype على GitHub، بينما يحمل عنوان README اسم dsh-superagent. والأرجح أن الاسمين يشيران إلى المشروع نفسه، لكن تأكد من الاسم الذي تستخدمه في توثيقك وإعداداتك قبل أي نشر داخلي.
تصف الصفحة المشروع بأنه نموذج بحثي للمرجعية فقط، وليس منتجا رسميا من DeepSeek، وليس برمجيات جاهزة للإنتاج، وقد يحتوي على أخطاء. ويُنشر بترخيص MIT، ولغته الأساسية TypeScript.
بحسب README، هو وكيل برمجي موجّه لمستودع GitHub واحد، ويُعبأ حزمة لبيئة DeepSeek Harness. يستمع إلى GitHub، وإلى Feishu اختياريا. عندما يطلب شخص مصرّح له عملا، يفتح بند عمل، ويعمل فيه داخل جلسة ومجلد خاصين به، ثم يرد في المحادثة الأصلية، مثلا بطلب دمج. وتعرض لوحة ويب ما يحتاج إلى تدخل بشري.
الهدف الذي يوضحه README هو تقليل انتباه الفريق مع تحقيق أكبر قيمة ممكنة. لذلك يتصرف الوكيل عند الطلب أو وفق قاعدة كتبها الفريق، ولا يتكلم إلا حين يحتاج شخص إلى التصرف أو حين تكون النتيجة قابلة للاستخدام.
مثال توضيحي: في شركة لوجستية في جدة، يطلب مهندس مصرّح له من الوكيل تحديث مكتبة في مستودع واحد. يفتح الوكيل بند العمل، ويقدم طلب دمج في المحادثة نفسها، ويبقى قرار القبول لفريق المراجعة. هذا مثال للشرح فقط، وليس لعميل حقيقي.
ما الذي يثبته المستودع
المعلومات التالية واردة في صفحة المستودع وفي README، ويمكن التحقق منها مباشرة.
- المستودع منشور بترخيص MIT.
- يصف نفسه بأنه وكيل برمجي لمستودع واحد، مع لوحة ويب لمتابعة ما يحتاج إلى إنسان.
- يوثق مساره في تسع وثائق مرقمة من 000 إلى 008، يُقرأ كل منها بعد ما قبله.
- يشير README إلى أمر pnpm check الذي يشغل فحص الأنواع والاختبارات والبناء.
ما الذي لم نتحقق منه بعد ويجب اختباره داخل بيئة الشركة
لم نشغّل الكود ولم نراجعه في هذا المقال، والشرح مبني على README والبيانات المرفقة فقط. أما عدد النجوم والشوكات وقت جمع البيانات، فيدل على الاهتمام بالمشروع، ولا يثبت جودة الكود أو صلاحيته للإنتاج.
ينص README على أن النسخة المنشورة ليست مطابقة للنسخة الداخلية، ولا للتطبيق الموصوف في الورقة البحثية Exploring Super-agent Design: Towards a More Autonomous Agent System. وبعض التصاميم في الورقة اتجاهات مستقبلية غير منفذة في هذا النموذج.
ما الفرق بين الوكيل المستقل وأتمتة العمليات بقواعد ثابتة، ومتى يناسب كل منهما؟
تعتمد أتمتة العمليات التقليدية على قواعد مكتوبة مسبقا، من نوع: إذا حدث كذا، فنفذ كذا. يعرف النظام الحالة المتوقعة، وينفذ الخطوات نفسها بالترتيب نفسه في كل مرة.
أما الوكيل المستقل فيقبل طلبا مكتوبا بلغة عادية، ويفسره، ثم يختار الأدوات والخطوات بنفسه. بهذا يختلف عن روبوت المحادثة الذي يكتفي بالرد، لأنه ينفذ أفعالا داخل بيئة العمل ضمن صلاحيات محددة.
مثال توضيحي: شركة توزيع تريد رفض أي فاتورة مورد تتجاوز الحد المعتمد في العقد. هذه قاعدة واضحة، والأتمتة بالقواعد الثابتة مناسبة لها تماما. أما طلب مثل: راجع تقارير الأسبوع، وأخبرني لماذا تأخرت طلبات الفرع الشرقي، فلا توجد له خطوات محددة مسبقا. يحتاج إلى قراءة سياق وتقسيم العمل إلى مهام صغيرة، وهنا يفيد الوكيل.
من الناحية العملية، الأتمتة التقليدية أسهل في التدقيق والتشغيل المستمر، لأن كل خطوة مكتوبة ويمكن مراجعتها. وتتوقف عند الحالات التي لم تُكتب لها قاعدة، وهذا مفيد في الإجراءات الحساسة. أما الوكيل فيحتاج إلى قواعد تكميلية: ما الذي يُسمح له بقراءته، وما الذي يحتاج موافقة بشرية، وكيف يُسجل ما فعله.
يوضح مستودع dsh-superagent هذا المبدأ: يعمل الوكيل عند طلب شخص مسموح له، أو وفق قاعدة كتبها الفريق، ويتكلم فقط حين يحتاج إنسان إلى التصرف أو حين تكون النتيجة مفيدة للاستخدام. ومع ذلك يصف المستودع نفسه بأنه نموذج بحثي وليس برمجية جاهزة للإنتاج، لذلك يحتاج أي تطبيق داخل الشركة إلى مراجعة وتكييف.
متى يناسب كل منهما؟
تناسب الأتمتة الثابتة الإجراءات المتكررة التي تعرف مدخلاتها ومخرجاتها مسبقا. ويناسب الوكيل المهام التي تتغير تفاصيلها، وتحتاج إلى تجميع معلومات من أكثر من مصدر. يمكن أن تبدأ الفرق بالأتمتة الثابتة للإجراءات الواضحة، ثم تجرّب الوكيل على مهام التحليل داخل بيئة معزولة مع قواعد صلاحيات واضحة. هذا تقدير عملي يعتمد على طبيعة كل عملية ومخاطرها، وليس قاعدة عامة.
- الإجراء متكرر وخطواته معروفة: الأتمتة الثابتة.
- المطلوب تدقيق كامل لكل خطوة قبل التشغيل: الأتمتة الثابتة.
- الطلب يصاغ بلغة طبيعية وتتغير تفاصيله: الوكيل.
- المهمة تحتاج إلى قراءة سياق من أكثر من مصدر: الوكيل.
- لا يمكن كتابة كل الحالات مسبقا: الوكيل مع حدود واضحة.
- الخطأ قد يكون مكلفا: الأتمتة الثابتة أو موافقة بشرية قبل التنفيذ.
مقارنة مختصرة
أتمتة العمليات التقليدية بقواعد ثابتة
- تنفذ خطوات مكتوبة مسبقا بالترتيب نفسه
- سهلة المراجعة لأن كل قاعدة معروفة
- تتوقف عند أي حالة لم تُكتب لها قاعدة
الوكيل الذكي المستقل
- يفسر طلبا بلغة طبيعية ويختار الأدوات
- يناسب المهام التي تتطلب قراءة سياق
- يحتاج إلى صلاحيات محددة ونقاط توقف بشرية
ما المخاطر التي يجب أن يتحقق منها فريق تقنية المعلومات قبل تجربة وكيل مستقل في بيئة الشركة؟
قبل أن يعمل وكيل مستقل داخل بيئة الشركة، يحتاج فريق تقنية المعلومات إلى معرفة ما قد يحدث إذا أخطأ. الوكيل يقرأ ويكتب ويستدعي أدوات خارجية، لذلك تتجاوز مخاطره نصا خاطئا في محادثة. عند النظر في أنظمة الوكلاء الذكية المفتوحة المصدر، ابدأ بالمخاطر لا بالمزايا. وأهم المخاطر التي يجب مراجعتها:
مثال توضيحي: شركة تجارية تجرب وكيلا يعالج تذاكر الدعم. إذا أرفق الوكيل سجلات العملاء كاملة في كل طلب إلى خدمة خارجية، فقد تخرج بيانات شخصية دون قرار واعٍ من أحد.
- تسرب بيانات الموظفين والعملاء إلى خدمات خارجية، عبر طلبات النموذج أو أدوات الطرف الثالث.
- صلاحيات أوسع من اللازم، فالوكيل الذي يملك وصولا كاملا قد يتجاوز حدود مهمته.
- إجراءات لا يمكن التراجع عنها، كحذف سجل أو إرسال رسالة إلى عميل أو تنفيذ تحويل.
- تكرار أخطاء النموذج على عشرات المهام قبل أن يلاحظ أحد.
- غياب السجلات، فلا يمكن مراجعة ما حدث أو إثبات سببه.
هل يمكن استخدام أنظمة الوكلاء المفتوحة المصدر في الشركات السعودية؟
يسمح ترخيص MIT باستخدام البرنامج ونسخه وتعديله ونشره وتوزيعه، بشرط الإبقاء على إشعار حقوق النشر ونص الترخيص. ويُقدَّم البرنامج “كما هو” دون أي ضمان. أي أن الترخيص يحدد ما يحق لك فعله بالكود، ولا يضمن أنه آمن أو مناسب لبيئتك.
الترخيص وحماية البيانات مسألتان مختلفتان. نص الترخيص لا يتناول حماية البيانات الشخصية. لذلك نوصي بأن تراجع الجهة القانونية في شركتك الأنظمة المتعلقة بحماية البيانات الشخصية في المملكة، وأن تتحقق من إرشادات سدايا، الهيئة السعودية للبيانات والذكاء الاصطناعي، لمعرفة ما ينطبق على قطاعك حاليا. لم نتحقق في هذا المقال من نص نظام بعينه، والقواعد قد تختلف بين القطاعات وقد تتغير مع الوقت.
كما تنشر الهيئة الوطنية للأمن السيبراني ضوابط منها ضوابط الأمن السيبراني للبيانات وضوابط الأمن السيبراني الأساسية. فراجع إن كانت تنطبق على التجربة، دون افتراض ذلك مسبقا.
والمستودع نفسه يصف نفسه بأنه نموذج بحثي للمرجعية، وليس منتجا رسميا من DeepSeek، ويطلب من مشغّله مراجعته وتكييفه قبل الاستخدام في بيئته.
قائمة تحقق قبل التجربة
استخدم القائمة التالية عند تقييم وكيل ذكي قبل التجربة، وراجع كل بند مع فرق الأمن والموارد البشرية والجهة القانونية في الشركة. إذا لم تكتمل البنود، فأجّل التجربة.
وقد تفيدك وثيقتا 002 Authorization و003 Execution في المستودع في فهم كيف يحدد المشروع الصلاحيات والتنفيذ، فاقرأهما قبل أي قرار.
قبل تشغيل أي وكيل ذكي في بيئة الشركة
كيف تجرّب وكيلا ذكيا مفتوح المصدر في بيئة اختبار معزولة؟
تجربة وكيل ذكي مفتوح المصدر ليست تجربة إنتاج. الهدف منها أن تعرف ما يفعله المشروع فعلا وما لا يفعله. يصف المستودع نفسه بأنه نموذج أولي بحثي للمرجعية، وليس منتجا رسميا من DeepSeek، وقد يحتوي على أخطاء. لذلك يجب أن تتم التجربة بحذر ووفق خطوات محددة.
تبدأ بالقراءة قبل التثبيت. ينص ترخيص MIT على أن البرنامج يُقدَّم «كما هو» دون ضمان من أي نوع، فتعامل معه على هذا الأساس. ثم اقرأ الوثائق 000 و001 و002 بالترتيب، لأن كل وثيقة تبني على ما قبلها.
خطوات تقييم الوكيل الذكي
اقرأ الترخيص والوثائق بالترتيب
ابدأ بالترخيص، ثم اقرأ الفلسفة في وثيقة 000، ونموذج المجال في وثيقة 001، وقواعد الصلاحيات في وثيقة 002. لا تنتقل إلى التثبيت قبل أن تفهم ما يطلبه المشروع منك.
أنشئ بيئة اختبار معزولة للوكلاء
جهّز جهازا أو حسابا منفصلا لا يتصل ببيانات الإنتاج ولا بأنظمة الشركة الحساسة. استخدم مستودعا تجريبيا بدلا من مستودع العمل الفعلي.
امنح رمز وصول بأقل الصلاحيات
أنشئ رمز وصول يمنح الحد الأدنى الذي تحتاجه المهام الاختبارية فقط. وثّق ما منحته، وراجع نطاق الصلاحيات في وثيقة 002 قبل التشغيل.
شغّل مهام اختبارية محددة
اكتب ثلاث مهام صغيرة، مثل إصلاح خطأ معروف أو إضافة اختبار واحد، واكتب معيار نجاح لكل مهمة قبل تشغيلها. شغّل أيضا الأمر pnpm check، وهو ينفذ التحقق من الأنواع والاختبارات والبناء.
رسم تخطيطي يوضح مراحل العمل بالترتيب، من الهدف حتى التحقق من النتيجة. راجع السجلات والنتائج
تتبّع ما فعله الوكيل خطوة بخطوة: ما الذي قرأه، وما الذي كتبه، وأين توقف لينتظر إنسانا. قارن النتيجة بمعيار النجاح المكتوب، لا بانطباعك العام.
اتخذ قرارا واضحا
إما أن تتابع التجربة في نطاق أضيق، أو أن توقفها وتوثّق السبب. لا تنقل المشروع إلى بيئة الإنتاج من هذه المرحلة.
أسئلة شائعة
ما الفرق بين الوكيل الذكي المستقل وروبوت المحادثة؟
يجيب روبوت المحادثة عن رسالة المستخدم بنص، ثم تنتهي الجولة. أما الوكيل الذكي المستقل فيعمل نحو هدف محدد، ويستخدم أدوات، ويحتفظ بسياق المهمة، ويكرر الخطوات حتى ينجز العمل أو يتوقف. والفرق الجوهري أن الوكيل ينفذ أفعالا داخل بيئة العمل، لكن ضمن صلاحيات محددة يضعها الفريق.
هل مشروع DeepSeek superagent prototype جاهز للإنتاج؟
لا. يصف المستودع نفسه بأنه نموذج بحثي للمرجعية، وليس منتجا رسميا من DeepSeek. وينص على أنه قد يحتوي على أخطاء، ويجب التعامل معه كبرمجيات بحثية، ومراجعته وتكييفه قبل استخدامه في أي بيئة. كما أن بعض التصاميم المذكورة في المقال المرجعي اتجاهات مستقبلية غير منفذة في هذا النموذج.
هل يمكن تشغيل وكيل ذكي مفتوح المصدر داخل شركة سعودية؟
المستودع مرخص بموجب MIT، وهذا الترخيص يقدم البرنامج كما هو دون ضمان من أي نوع. أما التوافق مع الأنظمة السعودية، وسياسات حماية البيانات، وشروط الجهات التنظيمية في قطاعك، فيحتاج إلى مراجعة قانونية وأمنية داخلية. فالقواعد قد تختلف، وقد تتغير مع الوقت، ولا يكفي الترخيص وحده للحكم.
ما الصلاحيات التي يجب منحها للوكيل في البداية؟
ابدأ بأضيق صلاحيات تكفي لمهمة واحدة محددة. يمكن أن تكون البداية بقراءة الشيفرة أو السجلات دون كتابة، ثم توسيع الصلاحيات تدريجيا بعد مراجعة النتائج. وقبل منح أي صلاحية، اقرأ وثيقة التفويض في المستودع، واكتب شرط الاكتمال الذي ستقبل به نتيجة الوكيل.
متى يحتاج الوكيل الذكي إلى موافقة بشرية؟
يحتاج الوكيل إلى موافقة بشرية حين يكون الإجراء خارج ما سمحت به القاعدة التي كتبها الفريق، أو حين تتطلب النتيجة قرارا من شخص. يصف مشروع dsh-superagent هذا المبدأ: يتحرك الوكيل عند الطلب أو وفق قاعدة مسموحة، ولوحة الويب تعرض ما يحتاج إلى شخص. الفصل بين الحالتين يجب أن يحدده الفريق مسبقا.
خطوة عملية
الخطوة التالية: ابدأ بتجربة معزولة وبحدود واضحة
قبل أي تثبيت، اكتب هدفا واحدا وشرط اكتمال واضحا. اختر صلاحيات قراءة فقط إن أمكن، ثم اقرأ وثائق المستودع بالترتيب وجرّب المشروع في بيئة اختبار معزولة. تواصل معنا إذا أردت مساعدة في تبنّي هذه الأداة.
إذا كان هذا التحدي قريباً من واقع عملك، اكتب لنا ما تحتاجه.
تحدث مع الريتاج
