ابنِ أو اشترِ في Agentforce: الإجراءات الجاهزة، Flow، Apex، وواجهات برمجة التطبيقات (APIs)

الإجابة المختصرة

تُعد الإجراءات (Actions) هي النقطة التي يتوقف فيها الوكيل عن الكلام ويبدأ في العمل. ولذلك، تتركز فيها معظم المخاطر وتكلفة الصيانة. توجد أربع طرق للتنفيذ: الإجراءات القياسية (Standard Actions) وFlow وApex والخدمات الخارجية (External Services) عبر واجهة برمجة تطبيقات (API) خارجية. لا يُعد الاختيار بينها مسألة قدرة - فتقريباً كل إجراء ممكن في جميع هذه الطرق - بل هو مسألة تتعلق بمن سيقوم بالصيانة، ومدى سرعة التغيير الممكن، وكيفية الاختبار.

الترتيب الموصى به للاختيار هو من الأعلى إلى الأسفل: البدء بإجراء قياسي، الانتقال إلى Flow عند الحاجة إلى منطق عمل، إلى Apex عندما تكون التعقيدات حقيقية، وإلى الخدمات الخارجية (External Services) عندما يكون مصدر الحقيقة خارج Salesforce. كل نزول في هذا السلم يزيد من تكلفة الصيانة، ولذلك يتطلب مبرراً.

جدول القرار

القاعدة الأولى: الوصف قبل التنفيذ

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

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

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

متى يتم استخدام Flow ومتى Apex

يُعد Flow هو الخيار الافتراضي لقواعد العمل لأنه مرئي ويسمح لمالك العملية بفهم ما يحدث. في سياق الوكلاء (Agents)، هناك ميزة إضافية وهي سرعة الإصلاح: عند اكتشاف أن الإجراء لا يتحقق من شروط الأهلية، يمكن إصلاحه في نفس اليوم.

يُبرر استخدام Apex في أربع حالات: منطق ذو تفرعات متعددة يجعل Flow غير قابل للقراءة، معالجة كميات كبيرة في استدعاء واحد، الحاجة إلى تحكم دقيق في معالجة الأخطاء والمعاملات، والتكامل الذي يتطلب معالجة استجابة معقدة. بخلاف هذه الحالات، يزيد Apex بشكل أساسي من تكلفة التغيير التالي.

يرتبط الاختيار أيضاً بالديون التقنية الموجودة. يجب على المؤسسة التي تعاني بالفعل من آلاف الأسطر من كود Apex بدون اختبارات أن تفكر مرتين قبل إضافة طبقة أخرى – تظهر الاعتبارات الكاملة في Flow مقابل Apex.

الإجراءات مقابل الأنظمة الخارجية

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

اللامُساواة (Idempotence) هي المفهوم الحاسم. يمكن محاولة إجراء الاستدعاء بأمان مرة أخرى. أما الإجراء الذي يُنشئ سجلاً، أو يرسل رسالة، أو يخصم من بطاقة – فإن المحاولة المتكررة قد تُنشئ ازدواجية. الحل هو مفتاح فريد لكل طلب تتعرف عليه المنظومة المُستقبِلة، أو التخلي الواعي عن المحاولة الثانية.

الكمون (Latency) هو اعتبار يتعلق بتجربة المستخدم وليس فقط اعتباراً تقنياً. يُعد استدعاء يستغرق بضع ثوانٍ مقبولاً في قناة الدردشة (Chat) إذا قال الوكيل إنه يتحقق؛ أما الاستدعاء الذي يستغرق أكثر من ذلك فيتطلب مساراً غير متزامن – حيث يؤكد الوكيل الاستلام ويُحدِّث عندما تصل الإجابة.

تُفصل أنماط التعامل مع إخفاقات التكامل في معالجة أخطاء التكامل في Salesforce.

الصلاحيات على مستوى الإجراء

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

مبدأ العمل: حد أدنى من الصلاحيات لكل إجراء، التحقق من الصحة (Validation) داخل الإجراء وليس فقط في تعليمات الوكيل، والتحقق من أن الإجراء يحترم سياق المستخدم. لا يجوز الاعتماد على أن التعليمات (Instructions) ستمنع التشغيل – التعليمات هي إرشاد وليست تحكماً.

متى يجب تقسيم الإجراء

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

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

يتم تفصيل التخطيط لنقاط التوقف بين الأجزاء في Human-in-the-Loop في Agentforce.

سيناريو: مؤسسة انتقلت من Apex إلى Flow

قامت شركة خدمات ببناء ستة إجراءات (Actions) في Apex ضمن مرحلة تجريبية (Pilot)، على افتراض أنها ستحصل بذلك على تحكم كامل. وخلال شهرين، اتضح أن أربعة من هذه الإجراءات قد غيرت منطقها ثلاث مرات لكل منها – ليس بسبب الأخطاء (Bugs)، بل لأن قواعد العمل اتضحت أثناء الاستخدام. كل تغيير تطلب فريق تطوير واختبارات ودورة نشر استغرقت عدة أيام.

في الجولة الثانية، بقيت الإجراءات التي تتضمن استدعاءات متعددة لأنظمة خارجية ومعالجة استجابات معقدة في Apex. تم نقل الأربعة الأخرى إلى Flow، وأصبح مدير المنصة مسؤولاً عنها. انخفض متوسط وقت الإصلاح من أيام إلى ساعات.

لم تكن العبرة هنا أن Apex سيء، بل أن في المرحلة التي لا تزال فيها القواعد تتشكل، تكون تكلفة التغيير أهم من تكلفة البناء الأولية.

المخاطر والإجراءات الوقائية

مؤشرات الأداء للإجراءات (Actions)

عندما تتطلبون التوجيه في تخطيط طبقة الإجراءات (Actions) وتكييفها مع البنية الحالية، تُشكل خدمة Agentforce وAI المسار العملي للمتابعة.

قائمة مراجعة لكل إجراء (Action)

• ☐ تم كتابة وصف يتضمن "ماذا"، "متى نعم"، و"متى لا"
• ☐ المعلمات بحد أدنى ومن نوع محدد
• ☐ تم اختيار التنفيذ الأعلى مستوى الذي يفي بالغرض
• ☐ تم تحديد صلاحية منفصلة للإجراء
• ☐ التحقق من الصحة (Validation) موجود داخل الإجراء وليس فقط في التعليمات
• ☐ تم تحديد ما إذا كان الإجراء لَامُسَاوِياً (Idempotent) وما هي سياسة إعادة المحاولة (Retry)
• ☐ تم تحديد الحد الأقصى لوقت الانتظار ورسالة الفشل للمستخدم
• ☐ تم تقسيم الإجراءات متعددة القرار
• ☐ يوجد سيناريو اختبار للفشل وليس فقط للنجاح