تقييم الـ Agents في بيئة التشغيل: تتبع استخدام الأدوات والمسارات (Trajectories)

لم يفشل نظام الـ multi-agent الخاص بك لأن النموذج اللغوي الأساسي يفتقر إلى القدرة على التفكير والاستنتاج (reasoning). بل فشل لأن وكيل التوجيه (routing agent) قام بإنشاء معلمة تاريخ وهمية (hallucinated a date parameter) في الخطوة الثانية، ثم مرر هذه المعلمة غير الصالحة إلى أداة الـ CRM الداخلية في الخطوة الثالثة، ليتلقى مصفوفة فارغة كاستجابة، وفي الخطوة الرابعة أخبر المستخدم بكل ثقة أن حسابه غير موجود. إذا كنت تقيم المخرجات النهائية فقط لأنظمة الذكاء الاصطناعي الخاصة بك، فأنت أعمى تماماً عن الأخطاء المتراكمة التي تحدث داخل الصندوق الأسود—وهي أخطاء تترجم مباشرة إلى خسارة العملاء، وارتفاع تكاليف الدعم، وضياع ساعات عمل المهندسين.

يكتشف مهندسو البرمجيات عبر الصناعة أن أطر التقييم المصممة لأنظمة الـ Retrieval-Augmented Generation (RAG) الأساسية غير كافية بشكل خطير لمهام سير العمل الوكيلية (agentic workflows). نظام RAG أحادي الجولة (Single-turn) بسيط ومباشر: يطرح المستخدم سؤالاً، يسترجع النظام النص، ثم يولد النموذج إجابة. يمكنك بسهولة قياس دقة الاسترجاع (retrieval accuracy) وملاءمة الإجابة. لكن أنظمة الـ multi-agent تنفذ مسارات عمل معقدة ودائرية (cyclic). فهي تتخذ القرارات، وتستدعي واجهات برمجة التطبيقات (APIs) الخارجية، وتقيم مخرجات أدواتها الخاصة، وتوجه المهام إلى وكلاء آخرين متخصصين.

عندما تتجاوز هذه الأنظمة مرحلة العرض التجريبي (demo)، فإنها تراكم الديون التقنية للذكاء الاصطناعي (AI technical debt) بسرعة. ما يبدأ كنموذج أولي ذكي يتحول سريعاً إلى "سباغيتي الذكاء الاصطناعي" (AI spaghetti)—سلاسل موجّهات (prompt chains) متشابكة، ووكلاء غير مراقبين يدخلون في حلقات مفرغة لا نهائية (endless loops)، وتكاملات أدوات هشة تنكسر تحت ضغط التشغيل الفعلي. بالنسبة لمشتري المؤسسات ومؤسسي شركات الـ SaaS، يمثل هذا عدم الاستقرار التشغيلي خطراً تجارياً جسيماً: فواتير API غير متوقعة، وتراجع تجربة المستخدم، وتهديد سلامة البيانات. تقوم Verel Systems بنقل الذكاء الاصطناعي من حالة السباغيتي هذه إلى بيئة التشغيل الفعلية (production). والجزء الأساسي من هذا الانتقال هو تطبيق تقييم صارم للـ multi-agent، مما يعني نقل التركيز من الإجابة النهائية إلى المسار الكامل (trajectory) لتنفيذ الوكيل.

التكلفة المتراكمة لأخطاء الـ Multi-Agent

الحقيقة الرياضية الأساسية لأنظمة الـ multi-agent هي أن معدلات الخطأ تتراكم بشكل مضاعف (multiplicatively). هذا هو السبب الرئيسي وراء تعثر العديد من مشاريع الذكاء الاصطناعي للمؤسسات في مرحلة التجربة (pilot purgatory)، مما يؤدي إلى استنزاف الميزانيات دون تحقيق أي عائد على الاستثمار (ROI). فالنظام الذي يبدو عالي الكفاءة في الاختبارات المعزولة سينهار بالتأكيد عند نشره في عملية تجارية متعددة الخطوات.

لنأخذ مثالاً على سير عمل وكيلي (agentic workflow) بسيط مصمم لمعالجة طلب استرداد الأموال للعميل. يجب على النظام تصنيف نية المستخدم (intent)، واسترجاع سجل العميل عبر API، والتحقق من سياسة الاسترداد مقابل قاعدة المعرفة، وتنفيذ عملية الاسترداد عبر أداة بوابة الدفع، وصياغة بريد إلكتروني للتأكيد. هذه خمس خطوات متميزة.

إذا كان النموذج اللغوي الذي يدير الوكيل يحقق معدل نجاح بنسبة 95% في تنفيذ أي خطوة فردية بشكل صحيح—وهو معدل يبدو ممتازاً أثناء إثبات المفهوم (PoC) السريع—فإن الاحتمالية الإجمالية لإكمال النظام للمهمة بأكملها بنجاح هي $0.95^5$، وهو ما يعادل 77.3%. وإذا أضفت خطوتين إضافيتين فقط لحلقة موافقة المدير وتسجيل البيانات في قاعدة البيانات، فإن معدل النجاح ينخفض إلى أقل من 70%.

من منظور العمليات التجارية، فإن معدل الفشل البالغ 30% يعد كارثياً. إذا كانت منصتك تعالج 1,000 طلب استرداد يومياً، فإن 300 منها ستفشل بصمت أو تُنفذ بشكل خاطئ. وإذا كانت تكلفة حل تذكرة دعم عملاء واحدة متصاعدة تبلغ في المتوسط 15 دولاراً من وقت الهندسة والدعم اليدوي، فإن سير العمل غير المستقر هذا وحده يضيف 4,500 دولار يومياً (135,000 دولار شهرياً) من التكاليف التشغيلية غير الضرورية، مما يمحو تماماً وفورات التكلفة التي بُني الذكاء الاصطناعي لتحقيقها.

[Step 1: Classify] (95%) 
       │
[Step 2: Retrieve CRM] (95%) ──> Cumulative Success: 90.2%
       │
[Step 3: Verify Policy] (95%) ──> Cumulative Success: 85.7%
       │
[Step 4: Execute Refund] (95%) ──> Cumulative Success: 81.4%
       │
[Step 5: Email Confirm] (95%) ──> Total Workflow Success: 77.3% (22.7% Failure Rate)

هذا التدهور المتراكم غير مرئي إذا كنت تقيس المخرجات النهائية فقط. عندما يتلقى المستخدم بريداً إلكترونياً يفيد بـ "لا يمكنني معالجة عملية الاسترداد الخاصة بك في الوقت الحالي"، قد تصنف مقاييس التقييم التقليدية هذه الاستجابة على أنها "مهذبة" و"صحيحة لغوياً". المخرج النهائي سليم من الناحية الفنية. لكن الفشل حدث في عمق المسار (trajectory)—ربما قام الوكيل بتمرير سلسلة نصية (string) بدلاً من عدد صحيح (integer) إلى أداة بوابة الدفع، فتلقى خطأ 400 Bad Request، واكتفى برسالة فشل عامة افتراضية.

بدون تقييم المسار (trajectory evaluation)، يقضي مهندسو البرمجيات ساعات في قراءة سجلات الخادم (server logs) يدوياً لمحاولة إعادة بناء حالة الوكيل في اللحظة الدقيقة التي فشل فيها. عملية تصحيح الأخطاء اليدوية هذه لا يمكن توسيعها (does not scale) لتتجاوز عدداً قليلاً من المستخدمين المتزامنين. لتشغيل أنظمة الـ multi-agent في بيئة العمل الفعلية دون تضخيم ميزانية فريق الهندسة، يجب عليك تهيئة النظام لتتبع وتحديد وتقييم المسار المحدد الذي سلكه الوكيل للوصول إلى استنتاجه تلقائياً.

لماذا تفشل التقييمات التقليدية في مسارات الوكيل (Agent Trajectories)

بالنسبة لقادة الأعمال، فإن الاعتماد على مقاييس RAG التقليدية يعني شراء شعور زائف بالأمان. قد ترى دقة بنسبة 95% على الورق بينما يتراجع رضا العملاء الفعلي (CSAT) لأن الإخفاقات الصامتة تحدث في جوانب لا ترصدها مقاييسك. في عامي 2024 و2025، اعتمد معيار الصناعة لتقييم الذكاء الاصطناعي بشكل كبير على أطر عمل مثل RAGAS، والتي تحسب مقاييس مثل دقة السياق (context precision)، واستدعاء السياق (context recall)، وأمانة الإجابة (answer faithfulness). هذه المقاييس مصممة بدقة لخطوط معالجة الأسئلة والأجوبة الثابتة والخطية (linear).

الأنظمة الوكيلية (Agentic systems) ليست خطية؛ بل هي دائرية (cyclic)، وتحتفظ بالحالة (stateful)، وديناميكية للغاية. قد يحاول الوكيل استخدام أداة بحث، ثم يدرك أن نتائج البحث غير كافية، فيقوم بتعديل استعلام البحث الخاص به، ويحاول مرة أخرى، ثم يقرر استخدام أداة مختلفة تماماً. هذا التسلسل من القرارات، واستدعاءات الأدوات، وخطوات التفكير الداخلي يسمى مساراً (trajectory).

يفشل التقييم التقليدي في تتبع المسارات لثلاثة أسباب محددة:

أولاً، مطابقة النصوص (string-matching) والتحققات القائمة على التعبيرات النمطية (regex) هشّة للغاية لتقييم التفكير والاستنتاج. إذا كتبت اختباراً يتوقع من الوكيل إخراج عملية تفكير محددة قبل استدعاء الأداة، فإن أي اختلاف طفيف في صياغة النموذج سيؤدي إلى فشل الاختبار، حتى لو كان المنطق الأساسي سليماً تماماً. يؤدي هذا إلى حجم كبير من النتائج السلبية الخاطئة (false negatives)، حيث يقضي المطورون دورات تطوير (sprints) مكلفة ومجهدة في التحقيق في عمليات تشغيل "فاشلة" تم تنفيذها بشكل صحيح في الواقع.

ثانياً، لا يمكن للتقييمات التقليدية رصد أخطاء استخدام الأدوات الصامتة (silent tool-use errors). يحدث الخطأ الصامت عندما يتم تنفيذ الأداة بنجاح من منظور برمجياتي (تُرجع حالة HTTP 200 OK) ولكنها تفشل من منظور منطق العمل (business logic). على سبيل المثال، قد يستعلم الوكيل من قاعدة بيانات عن "العقود الموقعة في الربع الثالث" ولكنه ينسق نطاق التاريخ عن طريق الخطأ للربع الثاني. ترجع قاعدة البيانات عقود الربع الثاني بنجاح. وبسبب افتقار الوكيل إلى السياق لإدراك خطئه، فإنه يستمر في تلخيص المستندات الخاطئة. تبدو المخرجات النهائية موثوقة للغاية، لكن البيانات غير صحيحة تماماً. فقط من خلال تقييم المعلمات الدقيقة الممررة إلى الأداة خلال تلك الخطوة المحددة يمكنك رصد هذا الفشل قبل أن يصل إلى العميل.

ثالثاً، يعاني الوكلاء غير المقيدين (unconstrained agents) من معدلات خطأ مرتفعة في اختيار الأدوات. عندما يُعطى الوكلاء قائمة بعدة أدوات ويُطلب منهم اختيار الأداة الصحيحة باستخدام التفكير الحر، فإن دقة الاختيار تتراجع بشكل ملحوظ. لا يخبرك التقييم التقليدي في نهاية السلسلة (end-of-chain) لماذا اختار الوكيل الأداة الخاطئة؛ بل يخبرك فقط أن الإجابة النهائية كانت خاطئة. لإصلاح النظام، تحتاج إلى معرفة ما إذا كان الوكيل قد أساء فهم نية المستخدم، أو أساء فهم وصف الأداة، أو ببساطة تخيل أداة غير موجودة (hallucinated a tool).

التتبع (Tracing) ومنهجية LLM-as-a-Judge: كيف تبدو الممارسة المثالية

للانتقال من عشوائية "سباغيتي الذكاء الاصطناعي" إلى بنية تحتية جاهزة للتشغيل الفعلي (production-grade)، يجب عليك تطبيق تتبع شامل وتقييم وسيط. يتضمن ذلك ممارستين تقنيتين متميزتين: التقاط المسار (trajectory) عبر أدوات المراقبة (observability tools)، وتقييم هذا المسار باستخدام أطر عمل LLM-as-a-judge.

إن تطبيق هذه البنية الهندسية هو الفارق بين التخمين الأعمى لسبب استنزاف نظام الذكاء الاصطناعي لميزانية الـ API الخاصة بالمؤسسة، وبين وجود مسار واضح وقابل للتدقيق لكل دولار يُنفق على استدعاءات النماذج. إنه يحول فريق الذكاء الاصطناعي لديك من رجال إطفاء يتعاملون مع الأزمات بردود أفعال متأخرة إلى مطورين استباقيين يعملون على تحسين النظام باستمرار.

يتضمن التتبع (Tracing) تهيئة منسق الوكلاء (agent orchestrator) لديك (مثل LangGraph) لتسجيل كل انتقال للحالة (state transition)، واستدعاء للـ LLM، وتنفيذ للأدوات. باستخدام منصات مثل Langfuse أو Weave، يمكنك التقاط المدخلات والمخرجات الدقيقة عند كل عقدة (node) في الرسم البياني. إذا دار الوكيل في حلقة تكرارية ثلاث مرات، فإن التتبع يظهر ثلاثة استدعاءات أدوات مميزة، وزمن الاستجابة (latency) لكل استدعاء، واستهلاك الرموز (token consumption)، وحمولة الـ JSON الدقيقة التي أرجعتها واجهة برمجة التطبيقات (API) الخارجية.

بمجرد حصولك على التتبع، يمكنك تطبيق تقييم الـ multi-agent. ونظراً لأن المراجعة البشرية بطيئة للغاية ومطابقة النصوص هشّة جداً، فإن المعيار المعتمد في بيئة التشغيل هو LLM-as-a-judge. يتضمن ذلك استخدام نموذج لغوي سريع ومقيد للغاية لتقييم الخطوات الوسيطة للوكيل الأساسي.

بدلاً من سؤال النموذج الحَكَم (judge model) "هل هذه الإجابة النهائية صحيحة؟"، تقوم بإعداد موجّهات حَكَم (judge prompts) مستهدفة لحالات فشل محددة داخل المسار:

• ▸دقة اختيار الأداة (Tool Selection Accuracy): "بالنظر إلى استعلام المستخدم X والأدوات المتاحة Y، هل اختار الوكيل الأداة المثلى؟ أجب بنعم أو لا وقدم تبريراً في جملة واحدة."
• ▸الالتزام بالمعلمات (Parameter Adherence): "بالنظر إلى مخطط الأداة X، هل قدم الوكيل حمولة JSON صالحة تلتزم تماماً بالأنواع المطلوبة؟ تحقق من الحقول المطلوبة المفقودة."
• ▸إنهاء الحلقة التكرارية (Loop Termination): "هل أدرك الوكيل بنجاح أنه جمع معلومات كافية للإجابة على المستخدم، أم أنه نفذ استدعاء أداة زائداً عن الحاجة؟"

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

تكلفة تقييم الـ Multi-Agent في بيئة التشغيل

غالباً ما يتردد قادة الأعمال في تطبيق منهجية LLM-as-a-judge لأن تقييم الذكاء الاصطناعي باستخدام ذكاء اصطناعي آخر يبدو مكلفاً. ومع ذلك، عند تصميم البنية الهندسية بشكل صحيح، فإن تكلفة التقييم تمثل جزءاً ضئيلاً من السنت لكل عملية تشغيل، وتعمل بمثابة تأمين أساسي ضد أخطاء منطق العمل المكلفة وتكاليف الـ API المتراكمة.

لا تحتاج إلى استخدام أغلى النماذج الرائدة (frontier models) لتقييم الخطوات الوسيطة. فالنماذج السريعة المتخصصة في الاستنتاج أو حتى النماذج الأصغر التي خضعت للضبط الدقيق (fine-tuning) قادرة تماماً على تقييم حمولات JSON ودقة اختيار الأدوات. علاوة على ذلك، في بيئة التشغيل الفعلي، لا تقوم بتقييم كل عملية تشغيل. بل تقوم بتقييم عينة ذات دلالة إحصائية (على سبيل المثال، 5% إلى 10% من جميع المسارات) لمراقبة صحة النظام، واكتشاف التراجعات (regressions)، ورصد الحلقات اللانهائية قبل أن تستهلك آلاف الدولارات في استخدام النماذج.

لوضع الأرقام في منظورها الصحيح: إذا كان نظامك يعالج 10,000 مسار عمل متعدد الخطوات يومياً، وقمت بأخذ عينة بنسبة 10% منها (1,000 عملية تشغيل) للتقييم الوسيط، وكان متوسط كل عملية تشغيل 4 خطوات تتطلب 500 رمز (tokens) من السياق للنموذج الحَكَم، فإن حجم الرموز اليومي للتقييم هو 2,000,000 رمز. باستخدام نموذج سريع واقتصادي بسعر حوالي 0.15 دولار لكل مليون رمز مدخلات، ستكون تكلفة التقييم اليومية حوالي 0.30 دولار فقط.

البديل هو السماح لوكيل غير مراقب بالدخول في حلقة لانهائية، مما يلتهم دولارات من تكاليف الرموز في الدقيقة الواحدة مع الفشل في خدمة عميلك. هندسة بيئة التشغيل (Production engineering) تدور حول إنفاق قروش معدودة على التقييم لحماية دولارات في التنفيذ.

تطبيق حواجز الحماية (Guardrails): التوجيه الدلالي بدلاً من الاختيار الحر

بمجرد أن يحدد إطار تقييم الـ multi-agent نقاط الفشل في مساراتك، فإن الخطوة التالية هي إصلاحها. إن الرؤية الأكثر شيوعاً التي تكتسبها الفرق من التتبع هي أن منح الـ LLM استقلالية كاملة في اختيار الأدوات هو وصفة لعدم الاستقرار والتكاليف التشغيلية الخارجة عن السيطرة.

عندما يمتلك الوكيل إمكانية الوصول إلى عشرين أداة مختلفة ويُطلب منه "استخدام أفضل تقدير لديك"، فإن معدل الخطأ يرتفع بشكل كبير. سيخلط النموذج حتماً بين الأدوات ذات الأسماء المتشابهة، أو يتخيل معلمات وهمية (hallucinate parameters)، أو يربط تسلسلات غير فعالة من الإجراءات. هذا التوجيه غير المقيد هو المصدر الرئيسي لسلوك الوكيل غير المتوقع.

تحل Verel Systems هذه المشكلة بالابتعاد عن حلقات الوكلاء الحرة والاتجاه نحو رسوم بيانية (graphs) عالية الهيكلية وتحتفظ بالحالة باستخدام أطر عمل مثل LangGraph. بدلاً من الاعتماد على الـ LLM لتخمين الخطوة التالية، نستخدم التوجيه الدلالي (semantic routing) لتقييد مسار الوكيل.

من خلال تقييد مسارات الوكيل، فإنك لا تحسن الدقة فحسب؛ بل تحمي ميزانية الـ API الخاصة بك أيضاً. فالوكيل المقيد يحل المشكلات في خطوتين بدلاً من التخبط عبر 10 خطوات، مما يقلل مباشرة من تكاليف الـ LLM التشغيلية بنسبة تتراوح بين 60% إلى 80%.

يتضمن التوجيه الدلالي (Semantic routing) تحليل نية المستخدم مسبقاً ورسم خريطة لها لتوجيهها إلى سير عمل محدد وحتمي (deterministic). إذا سأل المستخدم عن استرداد الأموال، يوجهه النظام إلى الرسم البياني الفرعي للاسترداد (Refund Sub-Graph). وداخل هذا الرسم البياني الفرعي، يمتلك الوكيل فقط إمكانية الوصول إلى الأداتين الضروريتين تماماً لعمليات الاسترداد. ولا يمكنه بالخطأ استدعاء قاعدة بيانات التسويق أو دليل الموارد البشرية.

من خلال تقييد مساحة الحالة (state space)، فإنك تقلل بشكل كبير من احتمالية اتخاذ الوكيل لمنعطف خاطئ. يصبح المسار متوقعاً. وعندما تطبق منهجية LLM-as-a-judge على رسم بياني مقيد، ستتحسن درجات التقييم الخاصة بك على الفور لأن الوكيل لم يعد يهدر الرموز (tokens) في محاولة التنقل عبر مجموعة أدوات ضخمة وغير منظمة.

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

الأسئلة الشائعة

س: ما هو العائد على الاستثمار (ROI) التجاري لتطبيق إطار تقييم المسار بدلاً من الاعتماد فقط على اختبار الجودة اليدوي (Manual QA)؟ يتحقق العائد على الاستثمار في مجالين رئيسيين: كفاءة الهندسة والاحتفاظ بالعملاء. اختبار الجودة اليدوي لمسارات العمل الوكيلية مستحيل عملياً عند التوسع بسبب العدد الهائل من تباديل المسارات الممكنة. من خلال أتمتة تتبع المسار، يمكنك تقليل الوقت الذي تقضيه فرق الهندسة في تصحيح الأخطاء الصامتة من أيام إلى دقائق. والأهم من ذلك، أنه يمنع وصول الإخفاقات الصامتة إلى بيئة التشغيل، مما يحمي سمعة علامتك التجارية ويمنع خسارة العملاء الناتجة عن سلوك الوكيل الوهمي أو الخاطئ.

س: ما مقدار زمن الاستجابة (latency) الذي يضيفه تتبع وتقييم المسار إلى تجربة المستخدم؟ يضيف التتبع فعلياً صفراً من زمن الاستجابة إلى تجربة المستخدم لأن بيانات القياس عن بعد (telemetry data) تُرسل إلى منصة المراقبة (مثل Langfuse) بشكل غير متزامن في الخلفية. كما يتم تشغيل تقييمات LLM-as-a-judge بشكل غير متزامن بعد اكتمال التنفيذ. يتلقى المستخدم إجابته على الفور؛ بينما يحدث التقييم في الخلفية (offline) لمراقبة صحة النظام.

س: هل يمكننا استخدام نفس الـ LLM الذي يدير الوكيل ليعمل كحَكَم؟ يمكنك ذلك، ولكن من الأفضل عموماً استخدام عائلة نماذج مختلفة للتقييم لتجنب انحياز النموذج المتأصل. فغالباً ما يوافق النموذج بشكل أعمى على تفكيره السابق. يوفر استخدام نموذج منفصل ومقيد للغاية وموجه خصيصاً للتقييم تقييماً أكثر موضوعية للمسار.

س: ماذا نفعل عندما يشير حَكَم الـ LLM إلى فشل خطوة وسيطة، ولكن الإجابة النهائية كانت صحيحة؟ هذه إشارة بالغة الأهمية. تشير عادةً إلى أن الوكيل يقوم بالتصحيح الذاتي بشكل غير فعال. على سبيل المثال، قد يستدعي أداة بمعلمات خاطئة، ويتلقى خطأ، ثم يحاول مرة أخرى. في حين أن الإجابة النهائية صحيحة، فإن الوكيل يهدر الوقت، وزمن الاستجابة، وتكاليف الرموز. يمكنك استخدام بيانات التقييم هذه لتحسين أوصاف أدواتك أو تعديل موجّهات النظام (system prompts) حتى يتمكن الوكيل من القيام بذلك بشكل صحيح من المحاولة الأولى.

س: لماذا لا يمكننا فقط كتابة اختبارات وحدة (unit tests) قياسية لأدوات الوكيل الخاصة بنا؟ يجب عليك بالتأكيد كتابة اختبارات وحدة برمجية قياسية لواجهات برمجة التطبيقات (APIs) الأساسية ودوال Python التي تنفذها أدواتك. ومع ذلك، فإن اختبارات الوحدة البرمجية تتحقق فقط من أن الأداة تعمل عند إعطائها المدخلات الصحيحة. ولا تتحقق مما إذا كان الوكيل يفهم متى يستخدم الأداة، أو ما إذا كان قادراً على توليد تلك المدخلات الصحيحة ديناميكياً بناءً على سياق المحادثة. يختبر تقييم الـ multi-agent طبقة اتخاذ القرار في الذكاء الاصطناعي، وليس فقط طبقة تنفيذ البرمجيات.