Andrew Hanna

Andrew Hanna

Agentforce يغيّر شكل فريق الإصدارات في Salesforce

Agentforce يغيّر شكل فريق الإصدارات في Salesforce

الإجابة المختصرة: Agentforce بيحوّل الوكلاء إلى عناصر إصدار تُجمَّع وتُثبَّت كإصدارات غير قابلة للتعديل وتعتمد في تفكيرها على نموذج لغوي كبير. وده بيضيف مهمتين معظم فرق إصدارات Salesforce ما خصصتش لهم حد قبل كده: تقييم الوكلاء وملكية إصدارات الوكلاء، وبينقل مدير الإصدارات من تشغيل عمليات النشر إلى تحديد أي سلوك للوكيل مسموح له يوصل للإنتاج.

ما الذي يتغير فعلًا لفرق إصدارات Salesforce؟

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

ثلاث حقائق في المنصة بتقود التغيير:

  • الوكلاء الجدد بيتبنوا في المُنشئ الجديد. Salesforce جمّدت تطوير المُنشئ القديم، ومن يوليو 2026 بقى إنشاء الوكلاء الجدد متاح بس في Agentforce Builder الجديد، باستخدام Agent Script اللي بيجمع بين المنطق الحتمي وتفكير النموذج اللغوي.
  • الإصدارات المُثبَّتة غير قابلة للتعديل. الـ Agent Script بيتخزن كـ AiAuthoringBundle. تثبيت إصدار بيجمّعه وبيولّد Bot وBotVersion وGenAiPlannerBundle، والإصدار المُثبَّت ما ينفعش يتلغى تثبيته، زي ما بيوضح دليل Gearset لنشر Agent Script.
  • الاختبارات بتحكم على السلوك، مش الكود بس. Agentforce Testing Center بيقيّم سلوك الوكيل في بيئة sandbox قبل ما التغييرات توصل للإنتاج. نجاح اختبارات Apex ما بيقولش أي حاجة عن هل الوكيل بيختار الإجراء الصح.

ليه ما ينفعش تنشر وكيل زي ما بتنشر Flow؟

الـ Flow حتمي: تنشره، تشغّل الاختبارات، وخلصت. الوكيل حزمة من التعليمات والموضوعات والإجراءات وقوالب التوجيهات، ومعاها Apex وFlows اللي الإجراءات دي بتستدعيها، وجزء من سلوكه جاي من تفكير النموذج. ده بيكسر ثلاث عادات:

  1. "انشر آخر نسخة" ما بقتش آمنة. دليل Gearset بيوضح إن نشر Agent Script مُثبَّت غير مدعوم بشكل عام، فالسكربت بيتنقل كمسودة وبيتثبّت في المؤسسة الهدف. لازم حد يكون مسؤول عن خطوة التثبيت دي في كل بيئة.
  2. الاعتماديات بتستخبى جوه الوكيل. إجراء ممكن يعتمد بهدوء على Flow أو كلاس Apex مش موجود في الحزمة. تحليل الاعتماديات لازم يغطي مكونات الوكيل، مش البيانات الوصفية التقليدية بس.
  3. المسؤولين والمحللين بيكتبوا جزء أكبر منه. Salesforce بتقول إن محللي الأعمال يقدروا يبنوا وكلاء بلغة طبيعية على Canvas من غير صلاحيات مسؤول. مؤلفين أكتر يعني تغييرات أكتر بتتعمل مباشرة في المؤسسة، بره Git.

ما الأدوار التي يحتاجها فريق إصدارات Salesforce الآن؟

  • مدير الإصدارات: من منفّذ نشر إلى مالك إصدارات. زمان كان بيرتب الحزم. دلوقتي بيقرر أي إصدار مُثبَّت للوكيل يشتغل، وإيه الدليل المطلوب قبلها.
  • مقيّم الوكلاء: مقعد جديد. حد بيكتب ويحدّث عبارات الاختبار والنتائج المتوقعة، وبيقرا النتائج كأحكام تقديرية مش مجرد نجاح أو فشل. في الفرق الصغيرة ده غالبًا قائد الجودة.
  • باني الوكلاء: المسؤولين والمحللين. بيصمموا الموضوعات والتعليمات. شغلهم لازم يدخل في تغيير متتبَّع، وإلا الإنتاج هيبعد عن اللي في نظام التحكم بالإصدارات.
  • المطوّر: مالك الإجراءات. الـ Apex والـ Flows اللي الوكيل بيستدعيها لسه بيانات وصفية تقليدية، بتتراجع وتتختبر بالطريقة المعتادة.
  • المعتمِد: إنسان باسمه. وحدة Salesforce عن DevOps Center وAgentforce Vibes بتخلي مديري النشر يراجعوا حلول التعارض المقترحة ويأكدوا الموافقات ونتائج الاختبارات وفحوصات الأمان قبل الإنتاج.

ده مش لازم يعني عدد أكبر من الناس. ده بيحتاج ملكية أوضح، ودي جوهر التعامل مع DevOps كنموذج تشغيل مش كقائمة أدوات.

ماذا يقدّم موردو DevOps لـ Agentforce؟

  • Salesforce: Agentforce Vibes بيتصل بمؤسسة hub في DevOps Center وبيستخدم Skills لتنفيذ إعداد خط النشر والـ commits وطلبات الدمج والترقيات من أوامر بلغة طبيعية، والبشر بيفضل معاهم القرار النهائي.
  • Copado: أعلنت عن Agentia في 13 أبريل 2026، بوكلاء عبر التخطيط والبناء والاختبار والإصدار والتشغيل، مع بوابات موافقة وسجلات تدقيق.
  • Gearset: دعمها لـ Agentforce بيشغّل مجموعات اختبار Testing Center بعد النشر وبيوقف الترقية لو فشلت.
  • Flosum: في 12 يونيو 2026 عرضت نهج Agentic DevOps لنقل البيانات الوصفية للوكلاء وحواجز الحماية والإعدادات بين البيئات.

كيف تعيد تشكيل عملية الإصدار من أجل الوكلاء؟

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

الخطوات دي امتداد لـ الأماكن اللي لسه فرق Salesforce مقصّرة فيها في 2026: نفس الفجوات، بس تكلفة تجاهلها بقت أعلى.

أين يأتي دور Serpent؟

Serpent بيتتبع وينشر الـ Apex والـ Flow والبيانات الوصفية اللي الوكيل بيعتمد عليها عبر خط النشر القياسي، وبيسجّل تعديلات Agent Builder في مهمة علشان ما تبعدش عن اللي بيتنشر. خادم MCP الأصلي بيخلي Claude أو Cursor أو Copilot يطلبوا نشر محدد النطاق، ولسه في إنسان بيوافق عليه. قارن خطط Serpent وجرّبه على خط نشر حقيقي.

FAQ

هل يستبدل Agentforce مدير إصدارات Salesforce؟

لا. الدور بيتحول من نقل التغييرات إلى امتلاك إصدارات الوكلاء والموافقة على اللي يشتغل في الإنتاج.

هل يمكن نشر Agent Script مُثبَّت إلى مؤسسة أخرى؟

عمومًا لا. الإصدارات المُثبَّتة غير قابلة للتعديل، فالفرق بتنشر السكربت كمسودة وبتثبّته في المؤسسة الهدف.

من يجب أن يختبر وكلاء Agentforce؟

خصص له مالك واضح، غالبًا قائد الجودة. هو اللي بيحدّث عبارات الاختبار وبيحكم على النتائج قبل ترقية أي إصدار للوكيل.

ما هي Tekunda؟

Tekunda هي الشركة اللي بتطوّر Serpent، منصة Salesforce DevOps فيها CI/CD ومراجعة كود بالذكاء الاصطناعي وعمليات نشر بموافقة بشرية.

مقالات ذات صلة

هل تريد معرفة كيف يمكنكم الشحن أسرع قبل البدء؟ لنتحدث

بدون التزام.