تنسيق الوكلاء المتعددين على Salesforce: ما الذي يجعل التسليم بين الوكلاء موثوقًا في الإنتاج

الإجابة المختصرة: تنسيق الوكلاء المتعددين على Salesforce يعني أن وكيلًا منسقًا واحدًا يمسك المحادثة ويسلّم كل مهمة إلى وكيل متخصص يغطي مجالًا ضيقًا. وما يجعل ذلك موثوقًا في بيئة الإنتاج ليس برومبت أكبر على المنسق، بل عقد تسليم محكم بين الوكلاء: ما الذي يُمرَّر، وما الذي يعود، ومن يحق له التنفيذ. أتاحت Salesforce تنسيق الوكلاء المتعددين في Agentforce بشكل عام في 15 يونيو 2026، ويمدّ بروتوكول Agent2Agent (A2A) النمط نفسه ليشمل وكلاء لا يعملون على Salesforce.

ما معنى تنسيق الوكلاء المتعددين على Salesforce؟

هو في جوهره معمارية توجيه. وكيل رئيسي واحد يكون نقطة التواصل الوحيدة مع المستخدم ويحتفظ بسياق الجلسة. وخلفه وكلاء متخصصون، لكل منهم مجال محدد بدقة ومجموعة إجراءات خاصة به: Apex وFlow وقوالب البرومبت وواجهات API خارجية.

التوجيه هنا ليس شجرة قرارات. فمحرك Atlas Reasoning Engine يقرأ وصف كل وكيل مسجَّل وتعليماته وإجراءاته المتاحة، ثم يختار الأنسب أثناء التشغيل. وهنا نقطة تقلل الفرق من شأنها: وصف الوكيل هو منطق توجيه، وليس توثيقًا. الأوصاف المبهمة تنتج توجيهًا مبهمًا.

لماذا يتوقف البرومبت الواحد الكبير عن العمل؟

كل فريق تقريبًا يجرّب أولًا نسخة الوكيل الواحد. تبدو ممتازة في العرض التوضيحي وتتدهور في الإنتاج، لأسباب بنيوية لا تُعالَج بالترقيع:

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

الوكيل المتخصص الذي يؤدي مهمة واحدة عبر خمسة إجراءات لا يعاني أيًا من ذلك. التعقيد لا يختفي، لكنه ينتقل إلى الوصلات بين الوكلاء، وهذا مكانه الصحيح، لأن الوصلة يمكن تحديدها بدقة.

كيف يبدو المنسق مع الوكلاء المتخصصين في الإنتاج؟

1. منسق يحدد النية ويحفظ السياق ويصعّد عند الحاجة، ولا يحمل أي إجراء تجاري خاص به.
2. وكيل متخصص لكل مجال محدد، مثل التحقق من الاستحقاق أو توزيع المهام الميدانية أو تعديلات الفوترة، لكل منه إجراءاته وحالات اختباره.
3. حمولة سياق منظمة تُمرَّر بينهم بدل النص الحر.
4. بوابة موافقة بشرية على كل ما لا يمكن التراجع عنه أو ما له أثر مالي.
5. تتبع لكل خطوة تسليم، حتى تُنسب النتيجة السيئة إلى وكيل بعينه لا إلى "الذكاء الاصطناعي" عمومًا.

الحجم هو سبب أهمية هذا كله. في برنامجنا مع ASSA ABLOY (شركتا FocusCura وPhoniro) تغطي المساحة التشغيلية 11,000 جهاز متصل تنتج حتى 2.5 مليون حدث أسبوعيًا في ثلاثة أسواق، وانخفضت الحالات الأسبوعية من 3,000 إلى 350 دون إضافة موظفي دعم. حِمل تشغيلي بهذا الشكل لا يتّسع له برومبت واحد.

ما الذي يجعل التسليم بين الوكلاء موثوقًا؟

هذا هو الجزء الذي تتجاوزه مواد الموردين، وهو بالضبط حيث تنكسر الأنظمة في الإنتاج. تعامل مع كل تسليم كواجهة برمجية، لا كمحادثة.

• مدخلات محددة النوع ومخرجات محددة النوع. إن لم تستطع كتابة التسليم كتوقيع دالة، فسيخترع المنسق توقيعًا، وسيخترع غيره غدًا.
• مرّر معرّفات لا نصوصًا إنشائية. CaseId وAssetId ينجوان من التسليم، أما الملخص المعاد صياغته فلا.
• امنح المتخصص وسيلة للرفض. "لا أستطيع المتابعة لأن الاستحقاق انتهى" إجابة قابلة للتوجيه، أما الارتجال الصامت فلا.
• اجعل الإجراءات متكافئة التكرار. المنسقون يعيدون المحاولة، ويجب ألا تؤدي إعادة المحاولة إلى استرداد ثانٍ.
• ضع الأوصاف تحت إدارة إصدارات. التوجيه يعتمد عليها، فتعديل وصف هو تغيير إنتاجي ومكانه المراجعة.

الوصلة هي المنتج. الوكلاء هم الجزء السهل، أما العقد بينهم فهو الهندسة الحقيقية.

أين يقع A2A وأين يقع MCP بالضبط؟

A2A يتولى التفويض عبر المنصات. ينشر الوكيل بطاقة تعريف (agent card) تصف ما يستطيع فعله، فيكتشفها وكيل عميل ويفوّض إليه مهمة ويستقبل الرسائل والمخرجات. بهذه الطريقة يصل منسق Agentforce إلى متخصص يعمل في مكان آخر تمامًا.

MCP هو المحور الآخر. يمنح وكيلًا واحدًا وصولًا إلى الأدوات والبيانات. نحن نبني خوادم MCP حتى يتمكن وكيل واحد من التنفيذ عبر الأنظمة التي تشغّلها الشركة أصلًا، بدل إجبار كل إجراء على المرور بشاشة CRM.

القاعدة العملية: A2A من وكيل إلى وكيل، وMCP من وكيل إلى نظام. واختيار الخطأ منهما هو أكثر أخطاء المعمارية شيوعًا في تجربتنا.

كيف تطرح هذا دون أن تكسر الوصلات؟

1. ابدأ بثلاثة وكلاء على سير عمل واحد بياناته نظيفة بالفعل. الوكلاء فوق بيانات فوضوية يضاعفون الفوضى.
2. فعّل القياس قبل التوسع. من لا يستطيع تتبع خطوة تسليم واحدة اليوم لن يصحح عشرة وكلاء الربع القادم.
3. عيّن لكل متخصص مالكًا بشريًا بالاسم.
4. اختبر التوجيه بأسلوب خصومي، بطلبات غامضة ومتعددة النوايا، لا بالمسار المثالي.
5. احتفظ بمفتاح إيقاف لكل متخصص، حتى لا يُسقط وكيل واحد سير العمل كله.

FAQ

هل تنسيق الوكلاء المتعددين متاح في الإنتاج على Salesforce اليوم؟

نعم. أتاحت Salesforce تنسيق الوكلاء المتعددين في Agentforce بشكل عام في 15 يونيو 2026، مع دعم A2A للوكلاء خارج المنصة.

بكم وكيل متخصص نبدأ؟

بثلاثة، على سير عمل واحد. أثبت التسليمات والتتبع أولًا، ثم أضف المجالات واحدًا تلو الآخر.

هل يغني النموذج الأكبر عن التنسيق؟

لا. النموذج الأقوى يحسّن الاستدلال داخل الوكيل الواحد، لكنه لا يمنحك صلاحيات محدودة النطاق ولا اختبارات لكل مجال ولا عطلًا قابلًا للنسب. هذه كلها تأتي من المعمارية.

ما الذي يتعطل أكثر من غيره في الإنتاج؟

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

هل نحتاج إلى إعادة بناء وكلاء يعملون على منصات أخرى؟

لا. يتيح A2A لمنسق Agentforce أن يفوّض إلى وكلاء من أطراف ثالثة، فينضم متخصص خارج Salesforce إلى سير العمل نفسه.

تبني Tekunda أنظمة متعددة الوكلاء على Salesforce وخارجها، بما في ذلك تنسيق وكيل إلى وكيل يعمل في الإنتاج. وإذا كنت تنتقل من وكيل واحد إلى فريق من الوكلاء، فتصميم الوصلات هو أول عمل يستحق الجهد.