تخيل مشروعًا برمجيًا يبدأ بفكرة مكتوبة في بضعة أسطر. بعد دقائق يقوم وكيل ذكاء اصطناعي بتحويل الفكرة إلى خطة، ويرسل جزءًا منها إلى وكيل يبحث عن الحلول التقنية المناسبة، بينما يبدأ وكيل آخر في كتابة الكود، ثم يأتي وكيل للاختبار وآخر للمراجعة، وفي النهاية يجمع وكيل مدير النتائج ويقرر ما إذا كان المشروع جاهزًا أم يحتاج إلى جولة أخرى. هذه هي الفكرة الأساسية وراء أنظمة الوكلاء المتعددة أو Multiagent Systems.
الاختلاف عن استخدام ChatGPT أو أي مساعد ذكي منفرد كبير. هنا لا توجد جلسة واحدة تنتظر منك التعليمات بعد كل خطوة، بل فريق رقمي مكوّن من عدة وكلاء، لكل واحد دور وأدوات وصلاحيات محددة، بينما تتولى طبقة تنسيق تحديد من يعمل ومتى، وما الذي يحدث إذا فشل أحد الوكلاء أو اختلفت نتائجه مع وكيل آخر.
الإجابة السريعة
أنظمة الوكلاء المتعددة تنسق المشاريع من خلال تقسيم الهدف الكبير إلى مهام أصغر، وتوزيع كل مهمة على وكيل متخصص، ثم تمرير النتائج بين الوكلاء عبر مدير أو Workflow مشترك. يستطيع وكيل التخطيط أن يوجه وكيل البحث، ثم يسلم العمل إلى وكيل التنفيذ والاختبار والمراجعة. لكن عبارة «بدون بشر» لا تعني عادة غياب الإنسان بالكامل؛ فالإنسان يحدد الهدف والصلاحيات وقواعد الأمان ونقاط التوقف، بينما يمكن للوكلاء تنفيذ الجزء الأكبر من سير العمل بصورة مستقلة.
أنظمة الوكلاء المتعددة ليست مجموعة روبوتات تتحدث عشوائيًا
الصورة التي تقدمها بعض العروض التوضيحية قد تجعل الأمر يبدو كأننا نضع خمسة نماذج لغوية في غرفة واحدة ونتركها تتناقش حتى يكتمل المشروع. الأنظمة العملية أكثر انضباطًا بكثير.
كل وكيل يمتلك عادة تعليمات محددة، مجموعة أدوات، سياقًا يحتاجه للمهمة، ونطاقًا واضحًا لما يسمح له بفعله. وفوق ذلك توجد طبقة Orchestration تقرر ترتيب التنفيذ وتدفق البيانات بين الأجزاء.
Microsoft تصف في Agent Framework الفرق بوضوح: الوكيل مناسب للمهمة المفتوحة التي تحتاج إلى تخطيط واستخدام أدوات، بينما Workflow يكون أفضل عندما تحتاج إلى تحكم واضح في ترتيب تنفيذ عدة وكلاء أو وظائف.
وكيل المدير هو مدير المشروع الرقمي
أحد أشهر تصميمات أنظمة الوكلاء المتعددة يعتمد على وجود Supervisor أو Manager Agent. هذا الوكيل لا يفعل كل شيء بنفسه، بل يفهم الهدف العام ثم يقرر أي وكيل متخصص يجب أن يعمل في كل مرحلة.
لو كانت المهمة مثلًا إنشاء تطبيق ويب، قد يبدأ المدير بطلب تحليل المتطلبات من وكيل التخطيط. بعد ظهور الخطة، يرسل تصميم قاعدة البيانات إلى وكيل Backend، والواجهة إلى وكيل Frontend، ثم يمرر النتائج إلى وكيل اختبار.
إذا اكتشف وكيل الاختبار خطأ، لا يحتاج الإنسان بالضرورة إلى التدخل. يستطيع المدير إعادة المهمة إلى الوكيل المسؤول مع تقرير الخطأ، ثم تشغيل الاختبار مرة أخرى.
هذا النمط قريب من مفهوم Magentic orchestration الذي تستخدمه Microsoft، حيث يحتفظ مدير مخصص بسياق مشترك ويتابع تقدم المهمة ويختار الوكيل التالي وفق حالة المشروع بدل الاعتماد على ترتيب ثابت مسبقًا.
تقسيم المشروع يبدأ من الهدف وليس من عدد الوكلاء
أحد الأخطاء الشائعة هو التفكير أن المشروع يصبح أكثر ذكاء كلما أضفنا وكلاء أكثر. الواقع أن كل وكيل جديد يزيد التكلفة والوقت وتعقيد التنسيق.
لهذا توصي Microsoft نفسها باستخدام أقل مستوى من التعقيد ينجز المهمة بصورة موثوقة. إذا كانت المهمة تحتاج Prompt واحدًا فقط، فلا يوجد سبب لبناء نظام Multiagent كامل.
وتصبح أنظمة الوكلاء المتعددة منطقية عندما توجد حدود طبيعية بين المهام: بحث منفصل، برمجة، اختبار، تحليل بيانات، مراجعة قانونية، أو أدوات وصلاحيات لا يجب أن يمتلكها وكيل واحد.
ماذا يحدث فعليًا عندما يستلم النظام مشروعًا؟
لنأخذ مثالًا عمليًا. شركة تريد إطلاق صفحة جديدة لمنتج رقمي. يدخل الهدف إلى النظام في صورة Brief واضح: المطلوب صفحة تسويقية، تحليل للمنافسين، نصوص، تصميم أولي، كود، واختبار.
الوكيل الأول يحلل الهدف ويحوله إلى قائمة مهام. وكيل البحث يجمع معلومات المنافسين. وكيل المحتوى يستخدم النتائج لكتابة النصوص. وكيل التصميم يجهز هيكل الواجهة. وكيل التطوير يحول المواصفات إلى كود، ثم يتولى وكيل الاختبار مراجعة الروابط والأداء والسلوك.
ولا تحتاج هذه العملية إلى أن يعمل الجميع بالتتابع. يستطيع النظام تشغيل البحث التقني وتحليل المنافسين في الوقت نفسه، طالما أن كل مهمة لا تعتمد على نتيجة الأخرى.
التنفيذ المتوازي هو أحد أسرار السرعة
في فريق بشري قد يستطيع ثلاثة أشخاص العمل بالتوازي، لكن التنسيق بينهم يتطلب اجتماعات ورسائل وانتظارًا. الوكلاء يستطيعون تنفيذ أجزاء كثيرة في الوقت نفسه ثم مزج النتائج بمجرد انتهائها.
مثلًا يمكن لنظام من أنظمة الوكلاء المتعددة تشغيل وكيل يبحث عن المنافسين، وآخر يراجع документаات التقنية، وثالث يجمع متطلبات الأمان، ثم يجمع الوكيل المدير النتائج الثلاث في خطة واحدة.
Microsoft Agent Framework يوفر Workflows متسلسلة ومتوازية ومتفرعة، بينما توفر أدوات مثل LangGraph إمكانية تعريف المشروع كشبكة من العقد والمسارات بدل الاعتماد على محادثة خطية واحدة.
Handoff: عندما يسلم وكيل المهمة لوكيل آخر
هناك نموذج آخر للتنسيق لا يحتاج دائمًا إلى مدير مركزي. يستطيع الوكيل نفسه اكتشاف أن المهمة انتقلت خارج تخصصه ثم إجراء Handoff إلى وكيل آخر.
تستخدم OpenAI هذا المفهوم داخل Agents SDK، حيث يمكن نقل التحكم من وكيل إلى آخر مع تمرير الحالة والسياق اللازم.
وكيل استقبال الطلبات مثلًا يستطيع فهم أن المستخدم يريد مشكلة مالية فيسلم المحادثة إلى وكيل الفواتير، أو يكتشف أنها مشكلة تقنية فيحولها لوكيل الدعم.
وفي مشروع أكبر يمكن أن تنتقل المهمة من التخطيط إلى التنفيذ ثم المراجعة بالطريقة نفسها.
الذاكرة المشتركة تمنع الفريق من البدء من الصفر كل مرة
لكي تعمل أنظمة الوكلاء المتعددة بكفاءة، يجب ألا تعيش المعرفة داخل ذاكرة كل وكيل بصورة منفصلة فقط. المشروع يحتاج إلى State أو حالة مشتركة تحتوي ما تم إنجازه والقرارات والملفات والمشكلات الحالية.
يمكن تخيلها كلوحة مشروع مركزية. وكيل البحث يضع النتيجة، ووكيل التنفيذ يقرأها، ثم يضيف ما أنجزه، وبعدها يأتي وكيل الاختبار ليرى النسخة الحالية بدل إعادة بناء السياق من البداية.
لهذا أصبحت إدارة الحالة والذاكرة والتخزين المستمر جزءًا أساسيًا من أطر الوكلاء الحديثة، خصوصًا عندما يستغرق المشروع ساعات أو أيامًا وليس استجابة واحدة مدتها دقيقة.
الأدوات هي التي تحول الوكيل من مستشار إلى منفذ
النموذج اللغوي يستطيع اقتراح ما يجب فعله، لكنه لن يبني مشروعًا فعليًا إذا لم يمتلك أدوات.
وكيل البرمجة قد يحتاج إلى قراءة الملفات وتعديلها وتشغيل الاختبارات. وكيل البحث يحتاج إلى متصفح أو Search API. وكيل إدارة المشروع قد يحتاج إلى GitHub أو نظام مهام. وكيل البيانات قد يحتاج إلى قاعدة بيانات أو بيئة Python.
وفي تحديث Agents SDK خلال 2026، وسعت OpenAI دعم الوكلاء للملفات والأوامر وتحرير الشيفرة والعمل داخل بيئات Sandbox مضبوطة، وهي قدرات تجعل تنفيذ مهام طويلة الأفق ممكنًا مع تقليل الخطر على النظام الحقيقي.
وهنا يصبح الفرق واضحًا بين chatbot يشرح لك كيف تنفذ المهمة ونظام Agentic ينفذ المهمة نفسها بالفعل.
كيف يعرف كل وكيل حدود صلاحياته؟
من أخطر التصورات الخاطئة أن إعطاء أنظمة الوكلاء المتعددة استقلالية يعني منحها وصولًا مفتوحًا إلى كل شيء.
النظام الجيد يعمل بالعكس تمامًا. وكيل البحث لا يحتاج إلى صلاحية حذف ملفات الإنتاج. وكيل كتابة المحتوى لا يحتاج إلى الوصول لبيانات الدفع. وكيل الاختبار قد يستطيع إنشاء نسخة تجريبية لكنه لا يستطيع نشرها على الموقع الأساسي.
تقسيم الصلاحيات بهذا الشكل يشبه المؤسسات البشرية: ليس كل موظف يمتلك مفتاح كل غرفة.
ماذا يحدث عندما يختلف وكيلان؟
هذا يحدث بالفعل. قد يقترح وكيل البرمجة حلًا بينما يرى وكيل الأمان أن الحل خطر، أو يرى وكيل المحتوى أن العنوان ممتاز بينما يرفضه وكيل SEO.
هناك عدة طرق لحل ذلك. يستطيع وكيل المدير مقارنة الحجج واتخاذ القرار، أو يمكن تشغيل وكيل ثالث يعمل كمحكم، أو تعريف قواعد صريحة تعطي أولوية لمجال معين.
في المثال الأمني، يمكن للقواعد أن تمنع الانتقال إلى النشر إذا أعطى وكيل الأمان حالة Failed، مهما كان رأي بقية الفريق.
بالتالي لا تحتاج أنظمة الوكلاء المتعددة إلى «اتفاق» نفسي بين الوكلاء؛ تحتاج إلى سياسة واضحة لحسم التعارض.
وكيل المراجع قد يكون أهم من وكيل المنفذ
أحد الأنماط القوية هو Generator-Evaluator. وكيل ينتج العمل ووكيل آخر لا يقوم بالإنتاج أصلًا، بل يبحث عن الأخطاء والثغرات.
في مشروع برمجي، المطور يكتب الكود والمراجع يفحصه. في مقال، الكاتب ينتج المسودة والمراجع يتحقق من المصادر والتكرار. وفي تحليل مالي، وكيل يحسب النتيجة وآخر يراجع الافتراضات.
إذا فشل التقييم، تعود المهمة إلى الوكيل الأول مع ملاحظات محددة وتبدأ دورة جديدة. وهكذا يستطيع النظام تنفيذ نوع من المراجعة الذاتية المنظمة دون انتظار الإنسان في كل جولة.
المشروع لا يسير دائمًا في خط مستقيم
العمل الحقيقي مليء بالفروع. لو نجح الاختبار انتقل إلى النشر، ولو فشل عاد للتطوير، ولو كان الفشل أمنيًا انتقل إلى وكيل متخصص، ولو كانت المشكلة في المتطلبات عاد إلى وكيل التخطيط.
ولهذا تستخدم الأطر الحديثة Graph Workflows. المشروع يصبح خريطة حالات وقرارات وليس سلسلة Prompt ثم Response ثم Prompt.
وهذا تحديدًا ما يجعل أنظمة الوكلاء المتعددة مناسبة للمشاريع المعقدة؛ النظام يستطيع تغيير المسار حسب النتيجة بدل اتباع خطوات عمياء.
هل يمكن لفريق وكلاء بناء برنامج كامل أثناء نومك؟
تقنيًا يمكن اليوم تشغيل نظام يستلم مهمة طويلة ويقرأ الملفات ويكتب كودًا ويشغل الاختبارات ويعيد المحاولة مرات متعددة دون وجود شخص أمام الشاشة طوال الوقت.
لكن عبارة «بناء برنامج كامل بدون بشر» تحتاج إلى قدر من الواقعية. الوكيل يستطيع تنفيذ أجزاء كبيرة من المشروع، لكن جودة الهدف الأول، حدود الصلاحيات، البيئة، الاختبارات ومعايير النجاح ما زالت تحتاج إلى تصميم بشري جيد.
إذا أعطيت النظام هدفًا غامضًا، فقد ينفذ الهدف الغامض بكفاءة شديدة ويصل في النهاية إلى منتج لا تريده.
الإنسان ينتقل من تنفيذ الخطوات إلى تصميم النظام
هنا يحدث التحول الحقيقي. بدل أن يكتب المدير عشرين مهمة يدويًا ويتابع كل موظف، قد يصبح دوره تحديد النتيجة المطلوبة وبناء قواعد التنفيذ.
الإنسان يقول: هذه هي الميزانية، وهذه الملفات المسموح تعديلها، وهذه الاختبارات التي يجب أن تمر، ولا يجوز النشر إذا فشل فحص الأمان.
بعد ذلك تنفذ أنظمة الوكلاء المتعددة عشرات الخطوات الداخلية دون الرجوع إليه إلا عندما تصل إلى قرار حساس أو حالة لم يعرف النظام كيف يتعامل معها.
Human-in-the-loop لا يتعارض مع الاستقلالية
وجود نقاط موافقة بشرية لا يعني فشل فكرة الوكلاء المستقلين. بالعكس، الأنظمة الإنتاجية الجيدة تضع الإنسان في الأماكن التي يكون تدخله فيها أعلى قيمة.
لا تحتاج إلى إنسان ليوافق على تشغيل Unit Test للمرة السادسة. لكن قد تحتاجه قبل تحويل 100 ألف دولار، حذف قاعدة بيانات، نشر بيان رسمي أو إرسال رسالة إلى آلاف العملاء.
LangGraph مثلًا يدعم Human-in-the-loop لإضافة نقاط توقف ومراجعة داخل مسارات الوكلاء، وليس فقط تشغيلهم باستقلالية كاملة.
مثال عملي: فريق برمجي من ستة وكلاء
لنفرض أن المطلوب إضافة نظام عضويات إلى موقع. يمكن أن يتكون الفريق الرقمي من وكيل مدير، وكيل متطلبات، وكيل Backend، وكيل Frontend، وكيل اختبار، ووكيل أمان.
المدير يبدأ بتحويل الطلب إلى مواصفات. وكيل المتطلبات يبحث عن النقاط الناقصة. بعد اكتمالها يعمل Backend وFrontend بالتوازي. عند انتهاء النسخة الأولى يبدأ الاختبار، بينما يراجع وكيل الأمان تسجيل الدخول والصلاحيات.
لو نجح الاختبار وفشل الأمان، يعيد المدير المشكلة إلى Backend فقط. وإذا نجح الاثنان، ينتقل النظام إلى خطوة بناء نسخة تجريبية.
هذه هي قيمة أنظمة الوكلاء المتعددة: المشكلة لا تُرسل إلى نموذج واحد ليحاول تذكر كل الأدوار داخل سياق ضخم، بل توزع على وحدات متخصصة يمكن مراقبة كل واحدة منها.
الفكرة نفسها تصلح لفريق محتوى كامل
الأمر ليس محصورًا في البرمجة. يمكن لوكيل بحث العثور على المصادر، ووكيل تحرير كتابة المقال، ووكيل SEO فحص الكلمة المفتاحية، ووكيل حقائق مقارنة الادعاءات بالمصادر، ثم وكيل نشر تجهيز الحزمة لووردبريس.
وهذا امتداد طبيعي لفكرة الوكيل الواحد التي شرحناها سابقًا في سوالف ضمن مقال كيف تنشئ AI Agents على ChatGPT. الفرق أن Multiagent لا يعطي مساعدًا واحدًا تعليمات أطول، بل يحول سير العمل نفسه إلى شبكة أدوار مستقلة.
البروتوكولات تجعل وكلاء من شركات مختلفة يتعاونون
مرحلة أكثر تقدمًا تظهر عندما لا تكون كل الوكلاء مبنية داخل النظام نفسه. قد يكون أحدها تابعًا لشركة، وآخر لخدمة خارجية، وثالث يعمل داخل بيئة سحابية مختلفة.
هنا تظهر بروتوكولات مثل MCP للوصول إلى الأدوات والبيانات، وA2A للتواصل بين الوكلاء والأنظمة المختلفة. Microsoft Agent Framework يدعم التكامل مع الاثنين ضمن تصميماته الحديثة.
وهذا يفتح الباب أمام أنظمة الوكلاء المتعددة التي لا تتكون فقط من وكلاء داخل تطبيق واحد، بل من خدمات مستقلة تتفاوض وتتبادل المهام عبر حدود الشركات والأنظمة.
لكن الاستقلالية لها تكلفة مالية حقيقية
إذا أعطيت سؤالًا لنموذج واحد فقد تحتاج إلى استدعاء واحد أو عدة استدعاءات. أما إذا كان لديك ستة وكلاء يتبادلون النتائج ويعيدون التقييم، فقد تتحول المهمة نفسها إلى عشرات أو مئات استدعاءات النموذج والأدوات.
كل Handoff يستهلك وقتًا، وكل مراجعة تستهلك Tokens، وكل وكيل قد يستخدم API مدفوعة.
لهذا لا يعني Multiagent دائمًا أرخص أو أسرع. بعض المهام البسيطة تصبح أسوأ عندما نحولها إلى نظام وكلاء، وهي نقطة تؤكد عليها إرشادات Microsoft التي تنصح بالبدء بوكيل واحد ثم الفصل فقط عندما توجد حاجة حقيقية للتخصص.
المراقبة مهمة لأن الخطأ يمكن أن ينتقل بين الوكلاء
إذا قدم وكيل البحث معلومة خاطئة، فقد يستخدمها وكيل التخطيط، ثم يكتب بناء عليها وكيل التنفيذ، وبعدها يراجع وكيل آخر المنتج دون أن يعرف أن المصدر الأول كان خطأ.
أي أن أنظمة الوكلاء المتعددة لا تلغي الهلوسة؛ بل يمكن أن تضخمها إذا لم توجد آليات تحقق.
لهذا أصبحت Tracing وObservability من المكونات المهمة. يجب أن يستطيع المطور معرفة من اتخذ القرار، وأي أداة استخدم، وما النتيجة التي مررها إلى الوكيل التالي.
OpenAI Agents SDK يتضمن تتبعًا لمسارات التنفيذ، بينما تركز أطر الإنتاج الأخرى على Telemetry وتسجيل الحالة لنفس السبب.
المشروع يحتاج شروط توقف وإلا قد يستمر الفريق بلا نهاية
تخيل وكيل مراجعة يطلب تحسين الكود، ثم يغيره وكيل البرمجة، فيكتشف المراجع مشكلة جديدة، ويستمران في الدورة عشرات المرات.
لهذا يحتاج النظام إلى Stop Conditions: حد أقصى للمحاولات، ميزانية Tokens، مهلة زمنية، أو معيار جودة إذا تحقق تنتهي العملية.
يمكن مثلًا أن تكون القاعدة: ثلاث محاولات إصلاح فقط، وإذا بقي الاختبار فاشلًا يتم تصعيد المهمة إلى إنسان.
هل يمكن أن تدير أنظمة الوكلاء المتعددة شركة كاملة؟
يمكنها بالفعل إدارة أجزاء كبيرة من العمليات: الدعم، التحليل، المحتوى، تطوير البرمجيات، مراقبة الأنظمة، التقارير، جدولة العمل وبعض العمليات الإدارية.
لكن إدارة شركة كاملة تتضمن مسؤولية قانونية وقرارات مالية وعلاقات بشرية ومواقف غير متوقعة لا يمكن اختزالها كلها في Workflow.
الأقرب للواقع في الوقت الحالي هو شركة يمتلك فيها كل موظف أو قسم فريق وكلاء، وليس شركة اختفى منها البشر تمامًا.
الفرق بين الأتمتة القديمة وMultiagent
الأتمتة التقليدية تقول: إذا حدث A نفذ B. وهي ممتازة عندما نعرف الخطوات مسبقًا.
أما أنظمة الوكلاء المتعددة فتضيف طبقة من القرار. الوكيل يستطيع النظر إلى النتيجة واختيار الخطوة التالية، أو تغيير خطته، أو طلب أداة أخرى، أو تسليم العمل لوكيل متخصص.
وهذا يجعلها أقوى في المشروعات التي لا نستطيع كتابة كل احتمال فيها كقاعدة ثابتة، لكنه يجعلها أيضًا أقل قابلية للتنبؤ من Workflow تقليدي.
متى لا تحتاج إلى Multiagent أصلًا؟
إذا كان المطلوب تلخيص ملف أو ترجمة نص أو تصنيف مجموعة بيانات صغيرة، فغالبًا يكفي استدعاء نموذج واحد. وإذا كانت العملية عبارة عن خمس خطوات ثابتة لا تحتاج إلى قرارات، فقد يكون Workflow برمجي تقليدي أفضل.
التعقيد يستحق الثمن عندما تحتاج تخصصات مختلفة، أو تشغيلًا متوازيًا، أو صلاحيات منفصلة، أو مراجعة مستقلة، أو قدرة على تغيير الخطة أثناء التنفيذ.
المستقبل قد يجعل مدير المشروع يدير وكلاء أكثر من البشر
التحول المثير هنا ليس أن الوكلاء سيختفون خلف التطبيقات، بل أن طريقة العمل نفسها قد تتغير. المدير قد لا يوزع المهام على عشرة أشخاص، وإنما يصمم نظامًا يضم عشرات الوكلاء ويحدد قواعد التعاون بينهم.
المبرمج قد يصبح مسؤولًا عن مجموعة من وكلاء البرمجة والاختبار. المحرر يدير وكلاء بحث وتدقيق ونشر. والمحلل يراجع نتائج وكلاء يعملون بالتوازي على قواعد بيانات مختلفة.
يمكن قراءة ذلك امتدادًا لما ناقشناه في سوالف حول Google Antigravity وفلسفة Agent-first التي تنقل الذكاء الاصطناعي من مربع دردشة إلى عنصر يعمل فعليًا داخل المشروع.
المهم ليس عدد الوكلاء بل جودة التنسيق بينهم
يمكن لفريق من عشرة وكلاء أن يكون أسوأ من وكيل واحد إذا كانت الأدوار متداخلة والسياق غير منظم والصلاحيات مفتوحة. ويمكن لثلاثة وكلاء فقط أن يديروا عملية معقدة إذا كان لكل واحد دور واضح وآلية تسليم ومقياس نجاح.
لهذا فإن جوهر أنظمة الوكلاء المتعددة ليس «ذكاءً أكبر» بقدر ما هو هندسة أفضل للعمل: تقسيم المهمة، توزيع المسؤولية، مشاركة الحالة، مراجعة النتائج، وحسم الأخطاء.
هل تستطيع المشاريع فعلًا الاستمرار بدون بشر؟
يمكن اليوم ترك مشروع محدد جيدًا يعمل لساعات مع قدر قليل جدًا من التدخل البشري. وكلما كانت الأدوات والاختبارات وشروط النجاح واضحة، زادت المسافة التي يستطيع النظام قطعها وحده.
لكن أفضل تصميم ليس الذي يلغي الإنسان بأي ثمن. الأفضل هو الذي يجعل تدخله نادرًا ومهمًا. بدل أن يوافق على 50 خطوة، يتدخل عند ثلاث نقاط فقط: تحديد الهدف، قرار حساس، واعتماد النتيجة النهائية.
وهنا تظهر الصورة الواقعية لـأنظمة الوكلاء المتعددة: ليست موظفين رقميين أحرارًا تمامًا، وليست مجرد Chatbots كثيرة. إنها بنية تشغيل تستطيع تحويل هدف واحد إلى شبكة من القرارات والأدوات والمراجعات، بحيث يصبح الإنسان مصمم النظام والمشرف على الحدود، بينما تتولى الآلات الجزء الأكبر من التنفيذ.
إذا استمرت أطر الوكلاء والبروتوكولات والبيئات الآمنة في التطور بالسرعة الحالية، فقد يصبح السؤال خلال السنوات القادمة ليس «هل يستطيع الذكاء الاصطناعي تنفيذ المشروع؟»، وإنما «أي أجزاء من المشروع ما زالت تستحق تدخل الإنسان أصلًا؟».
لا يسمح بنقل هذا المحتوى من سوالف دون الاشارة برابط مباشر
