مساحة فعل الوكيل
مجموعة الأفعال والعمليات والأدوات والأنظمة والبيانات التي يستطيع وكيل الذكاء الاصطناعي الوصول إليها أو تنفيذها فعليًا داخل بيئة محددة، بغض النظر عن مقدار استقلاليته في تقرير متى وكيف يستخدمها.
شرح تفصيلي
## التعريف التشغيلي **مساحة فعل الوكيل Agent Action-Space** هي الحدود العملية لما يستطيع وكيل الذكاء الاصطناعي أن يفعله داخل بيئة معينة. لا تصف ذكاء النموذج، ولا جودة التخطيط، ولا درجة استقلالية القرار وحدها؛ بل تصف **القوة التنفيذية المتاحة** للنظام: ما الذي يمكنه قراءته، كتابته، تغييره، تشغيله، إرساله، استدعاؤه، تفويضه أو تنفيذه كمعاملة. هذا المفهوم مهم لأن تسمية النظام «مساعدًا» أو «وكيلًا» أو «Copilot» لا تكشف مستوى سلطته. قد يكون مساعد يسمى ظاهريًا أداة دعم لكنه يملك صلاحية تشغيل أوامر على terminal، أو تعديل ملفات، أو الاتصال بخدمة خارجية، أو إرسال رسالة من حساب موظف. وفي المقابل قد يكون نظام يسمى autonomous agent لكنه محصور تقنيًا في البحث داخل مستودع read-only. لذلك يجب الحكم على السلطة من **الأفعال المتاحة فعليًا** لا من الاسم التسويقي أو الوصف العام. ## الفرق بين مساحة الفعل والاستقلالية الاستقلالية Autonomy تجيب عن سؤال: إلى أي درجة يقرر الوكيل بنفسه كيفية تنفيذ المهمة وتسلسل خطواتها ومتى يستخدم أداة أو يطلب مساعدة؟ أما مساحة الفعل فتجيب عن سؤال مختلف: ما الأفعال التي تسمح له البيئة بتنفيذها أصلًا؟ قد تكون الاستقلالية عالية بينما مساحة الفعل ضيقة؛ مثل وكيل يخطط بحرية لكنه لا يملك سوى القراءة من قاعدة معرفة. وقد تكون الاستقلالية منخفضة بينما مساحة الفعل شديدة الحساسية؛ مثل نظام لا ينفذ إلا بعد موافقة بشرية لكنه قادر على تعديل صلاحيات privileged users. لذلك لا ينبغي استخدام autonomy كمقياس وحيد للمخاطر. في حوكمة Agentic AI، الخطر ينتج من تفاعل عدة عناصر: مساحة الفعل، الاستقلالية، شدة الأثر، قابلية العكس، حساسية البيانات، الأنظمة المتصلة، فعالية الإشراف البشري، وإمكانية انتقال الفعل إلى طرف ثالث أو وكيل آخر. ## مكونات مساحة الفعل يمكن تفكيك مساحة فعل أي وكيل إلى فئات عملية بدل وضعها في وصف واحد عام. ### القراءة Read ما البيانات والسجلات والملفات التي يستطيع الوكيل رؤيتها؟ هل يقرأ معلومات عامة أم بيانات شخصية أم أسرارًا تجارية أم بيانات مالية أو أمنية؟ هل يستطيع البحث عبر مستودعات متعددة؟ هل يمكنه الوصول إلى تاريخ محادثات أو ذاكرة مشتركة؟ صلاحية القراءة نفسها قد تكون عالية الخطورة عندما تشمل معلومات حساسة أو عندما يستطيع الوكيل تجميع بيانات من مصادر متعددة بما ينتج معرفة لم تكن متاحة للمستخدم في شاشة واحدة. ### الكتابة Write هل يستطيع إنشاء أو تعديل سجل؟ هل يعدل ملفًا؟ هل يغير ticket أو CRM record أو configuration؟ الكتابة توسع المخاطر لأنها تحول الوكيل من نظام يلاحظ إلى نظام يغير الواقع الرقمي. ### التنفيذ Execute هل يستطيع تشغيل shell command أو function أو workflow أو job أو script؟ التنفيذ قد يسمح للوكيل بتجاوز حدود واجهة المستخدم التقليدية والوصول إلى قدرات أوسع بكثير مما يوحي به use case الأصلي. ### المعاملات Transact هل يستطيع إنشاء طلب شراء أو حجز أو دفع أو تحويل أو إصدار أمر أو توقيع عملية؟ المعاملة تختلف عن الكتابة العادية لأنها قد تنشئ التزامًا ماليًا أو قانونيًا أو تشغيليًا تجاه طرف آخر. ### التواصل Communicate هل يستطيع إرسال بريد أو رسالة أو إشعار إلى عميل أو موظف أو جهة خارجية؟ وهل يظهر أنه يتحدث باسم المؤسسة أو باسم مستخدم محدد؟ القدرة على التواصل تخلق مخاطر سمعة وتصريح وتسريب معلومات حتى عندما لا يغير الوكيل نظامًا داخليًا. ### التفويض Delegate هل يستطيع استدعاء وكيل آخر أو إنشاء sub-agent أو تمرير مهمة إليه؟ هذه القدرة مهمة لأن مساحة الفعل المركبة قد تصبح أكبر من مساحة أي وكيل منفرد. Agent A قد لا يملك التنفيذ لكنه يستطيع تفويض Agent B الذي يملكه. ## الأدوات جزء من مساحة الفعل كل Tool أو API أو MCP server يضيف وظيفة جديدة إلى مساحة الفعل. لذلك لا ينبغي التعامل مع إضافة أداة كإعداد تقني محايد. عندما تربط الوكيل بـMCP server يعرض وظائف لقراءة ملفات أو تشغيل commands أو الوصول إلى SaaS، فأنت توسع السلطة المتاحة للنظام. المراجعة الصحيحة للأداة تشمل: ما الوظائف التي تعرضها؟ هل هناك فصل بين read وwrite؟ ما credentials المستخدمة؟ هل الوظائف ثابتة أم يستطيع الخادم إضافة أدوات لاحقًا؟ هل توجد allowlist؟ هل تسجل الاستدعاءات؟ هل تمر البيانات إلى طرف خارجي؟ وهل يمكن سحب الوصول بسرعة عند الحاجة؟ إطار IMDA لحوكمة Agentic AI يقدم مثالًا عمليًا في حالة GovTech Singapore، حيث بدأ النشر في نطاق محدود ومن دون أدوات MCP خارجية ثم استُخدمت المرحلة الأولى لبناء التسجيل والمراقبة وإطار أكثر أمانًا للاتصال بالأدوات المعتمدة. الدرس هنا ليس أن MCP ممنوع، بل أن **توسيع مساحة الفعل يجب أن يتبع جاهزية الضوابط، لا أن يسبقها**. ## مساحة الفعل الفعلية مقابل المساحة المعلنة المؤسسة قد توثق أن الوكيل «يقرأ فقط»، لكن الواقع التقني قد يكون مختلفًا. مثلًا API الممنوح قد يحتوي endpoints للكتابة، أو service account قد يملك صلاحيات أوسع من الوظيفة المستخدمة، أو tool wrapper قد يتيح تنفيذ أوامر غير مقصودة. لذلك يجب التمييز بين: - **Declared Action-Space:** ما تقول الوثائق إن الوكيل يستطيع فعله. - **Effective Action-Space:** ما يستطيع فعله فعليًا وفق credentials والأدوات والمسارات المتاحة. الحوكمة تعتمد على الثاني. يجب اختبار الصلاحيات وإثباتها، لا الاكتفاء بوصف معماري. ## علاقة مساحة الفعل بنطاق السلطة Authority Envelope في سيادة AI، يمكن اعتبار مساحة الفعل مكونًا داخل **Authority Envelope** أو نطاق السلطة. النطاق الأوسع قد يحدد الهدف، الهوية، البيانات، الأنظمة، الأدوات، أنواع الأفعال، الحدود الكمية، المدة الزمنية، نقاط الموافقة، شروط الإلغاء، وإمكانية التفويض. مساحة الفعل تجيب تحديدًا عن الجزء التنفيذي: ما الذي يمكن للوكيل فعله. أما نطاق السلطة فيضيف تحت أي شروط ولمصلحة أي هدف ومن فوّضه ومتى تنتهي الصلاحية. هذا التفريق يمنع خطأ شائعًا: اعتبار «صلاحية API» مساوية لسلطة مؤسسية كاملة. قد يملك الوكيل قدرة تقنية على الفعل لكن لا يكون مخولًا تنظيميًا باستخدامها في كل سياق. ## مساحة الفعل وقابلية العكس لا يكفي جرد الأفعال؛ يجب تصنيفها حسب قابلية العكس. تعديل draft يمكن التراجع عنه. إرسال بريد خارجي قد لا يمكن استرجاع أثره. كشف بيانات حساسة لا يمكن «إلغاء» معرفة الطرف الآخر بها. تنفيذ دفعة قد يحتاج عملية استرداد منفصلة وربما لا تكون ممكنة. يمكن تصنيف الأفعال إلى: - قابلة للعكس فورًا وبكلفة منخفضة. - قابلة للعكس بإجراء إضافي أو تدخل بشري. - قابلة للعكس جزئيًا فقط. - غير قابلة للعكس عمليًا بعد التنفيذ. كلما انخفضت القابلية للعكس، يجب أن تقل حرية التنفيذ التلقائي أو ترتفع متطلبات الموافقة والتحقق المسبق. ## استخدام مساحة الفعل في تقييم المخاطر بدل إعطاء الوكيل Risk Score عام، يمكن تقييم كل فئة فعل على حدة. مثال وكيل IT: - قراءة حالة جهاز: Read / أثر منخفض نسبيًا. - إعادة تعيين كلمة مرور بعد تحقق قوي: Execute / قابل للعكس نسبيًا. - تثبيت برنامج من allowlist: Execute / مشروط. - تغيير عضوية privileged group: Write/Authority Change / أثر أمني مرتفع. - تشغيل shell command مولد بحرية: Execute / مساحة واسعة وغير متوقعة. نفس الوكيل قد يكون مسموحًا له بالفعل الأول والثاني، يحتاج موافقة في الثالث، ويُمنع من الرابع والخامس. هذه دقة أفضل بكثير من وصفه «Autonomy Level 2» فقط. ## الأنظمة متعددة الوكلاء في multi-agent systems يجب حساب مساحة الفعل المركبة. وكيل التخطيط قد لا يملك أي write permission، لكن إذا استطاع أن يطلب من وكيل تنفيذ تعديل قاعدة البيانات، فإن النظام ككل يملك هذه القدرة. لذلك تحليل كل agent منفصلًا يمكن أن يخفي السلطة الحقيقية للشبكة. ينبغي رسم العلاقات التالية: من يستطيع استدعاء من؟ ما السياق الذي ينتقل؟ هل تنتقل credentials؟ هل توجد ذاكرة مشتركة؟ هل يستطيع وكيل إنشاء وكيل جديد؟ وهل يظل الأصل البشري للتفويض قابلًا للتتبع عبر السلسلة؟ ## الوكلاء من أطراف ثالثة عندما يأتي agent من مورد خارجي، قد تتغير مساحة الفعل بعد تحديث من المورد. إضافة tool أو connector أو capability جديدة قد توسع ما يستطيع النظام فعله من دون أن تتغير واجهة المؤسسة بوضوح. لذلك يجب أن تخضع تغيرات قدرات المورد لمراجعة change management وإعادة تقييم. وجود عقد مع المورد لا يساوي فهم Action-Space. يجب أن تعرف المؤسسة أيضًا حدود التنفيذ التقني، ومكان معالجة البيانات، والـsubprocessors، والـAPIs، وآلية التسجيل، وإمكانية تعطيل الوظائف الجديدة. ## كيف تُدار مساحة الفعل؟ الإدارة الجيدة تبدأ بـinventory لكل وكيل يربط الهدف بالهوية والأدوات والأنظمة والأفعال. بعدها تُطبق قواعد مثل least privilege، read/write separation، allowlisting، transaction limits، time-bound access، environment isolation، وapproval gates. ينبغي أيضًا وجود آلية لمقارنة المساحة الحالية بالمساحة المعتمدة. إذا ظهر Tool جديد أو permission جديد أو endpoint جديد، فهذه ليست مجرد configuration drift؛ قد تكون **Authority Drift**. ## Evidence المطلوبة لكي يثبت المدقق أو فريق الحوكمة أن مساحة الفعل مضبوطة، يحتاج أدلة مثل: - قائمة الأدوات والـAPIs المعتمدة. - permissions الفعلية للهوية المستخدمة. - access control policies. - سجلات استدعاء الأدوات. - اختبارات لمحاولات أفعال ممنوعة. - change history للصلاحيات. - approvals لتوسعة القدرات. - kill/revocation procedure. - mapping بين use case وكل فعل مسموح. ## مؤشرات المراقبة بعد التشغيل، يمكن مراقبة عدد الأفعال حسب النوع، محاولات الأفعال المرفوضة، الأدوات الأكثر استخدامًا، تغير مساحة الفعل بمرور الوقت، requests التي تجاوزت الحدود، الموافقات البشرية، rollback events، واستخدام وظائف جديدة بعد تحديث model أو tool. إذا كانت المؤسسة لا تستطيع معرفة ما الذي استخدمه الوكيل أمس، فهي لا تدير مساحة الفعل فعليًا حتى لو كانت لديها سياسة مكتوبة. ## الخطأ المفاهيمي الأهم مساحة الفعل ليست «قائمة features» للمنتج. هي **سطح السلطة التنفيذية** داخل سياق مؤسسي. Feature واحدة مثل «إدارة البريد» قد تتضمن قراءة، بحث، إرسال، حذف، إضافة attachment، مشاركة رابط، الوصول إلى جهات الاتصال، أو استدعاء calendar. كل فعل منها له أثر مختلف. لذلك يجب تحليل الأفعال عند مستوى يسمح بوضع control حقيقي، لا عند مستوى أسماء الوحدات التسويقية. ## العلاقة مع IMDA إطار IMDA لا يطلب من المؤسسات تبني مصطلحات سيادة الداخلية، لكنه يركز بوضوح على تحديد حدود قدرات الوكيل، مستوى الاستقلالية، الوصول إلى الأدوات والبيانات، نقاط التدخل البشري، الاختبار، النشر المرحلي، ومخاطر الأطراف الثالثة والأنظمة متعددة الوكلاء. مفهوم Action-Space هنا يستخدم في سيادة كعدسة تنظيمية لالتقاط الجزء المتعلق بما يستطيع الوكيل فعله فعليًا، وربطه بالسلطة والهوية والمساءلة. ## قاعدة عملية قبل السماح لأي Agent بالدخول إلى الإنتاج، يجب أن تستطيع المؤسسة كتابة جملة دقيقة من الشكل التالي: **هذا الوكيل، تحت هذه الهوية، ولتحقيق هذا الهدف، يستطيع قراءة X وكتابة Y وتنفيذ Z والتواصل مع A، ولا يستطيع تنفيذ B أو تفويض C، ويحتاج موافقة بشرية قبل D، وتنتهي هذه السلطة عند E.** إذا تعذر كتابة هذه الجملة أو إثباتها تقنيًا، فإن مساحة فعل الوكيل غير محكومة بما يكفي.
مثال عملي
وكيل خدمة داخلية يستطيع قراءة التذاكر، اقتراح حل، وإعادة تعيين كلمة مرور بعد تحقق محدد، لكنه لا يستطيع تغيير مجموعات الصلاحيات أو تشغيل أوامر عامة على الخوادم. هذا الوصف يحدد مساحة الفعل بصورة أدق من القول إنه «وكيل منخفض الاستقلالية».