سير العمل أم وكلاء الذكاء الاصطناعي: أيهما يحتاجه منتجك فعلًا؟

يدخل كثير من المؤسسين أول محادثة عن الذكاء الاصطناعي وهم يطلبون «وكيلًا» مباشرة. هذا مفهوم — فالوكلاء يبدون أكثر تقدمًا، وأكثر قدرة، وأقرب إلى صورة المستقبل. لكنه السؤال الأول الخاطئ، للسبب نفسه الذي يجعل «أي ذكاء اصطناعي يجب أن نبني؟» سؤالًا خاطئًا في Build vs. Cut: إنه يختار التقنية قبل تحديد المهمة.

السؤال الذي يهم فعلًا أبسط من ذلك: هل يمكن رسم هذه العملية مسبقًا؟

تبدأ معظم المنتجات أقرب إلى الحالة الأولى مما يتوقع المؤسسون.

هذا المقال جزء من مجموعة مقالات Build vs. Cut، وهدفه مساعدتك على تحديد موقع منتجك الصحيح على سلّم Sprint966 للبنية التقنية — تحديدًا، الحد الفاصل بين الدرجة الخامسة (أتمتة سير العمل) والدرجة السادسة (الوكلاء)، وهما الدرجتان اللتان يخلط بينهما المؤسسون أكثر من غيرهما.

ما الفرق بين سير العمل بالذكاء الاصطناعي ووكيل الذكاء الاصطناعي؟

يتلخص الفرق في شيء واحد: من يتحكم في تسلسل الخطوات.

وتضع Anthropic — التي تُعد إرشاداتها الهندسية من بين أوضح المعالجات لهذا الفرق — الخط الفاصل على النحو التالي: سير العمل ينسّق النماذج اللغوية والأدوات عبر مسار كود محدد مسبقًا. أما الوكيل فيتيح للنموذج أن يوجّه عمليته واستخدامه للأدوات بنفسه ديناميكيًا.¹

سير العمل قائمة تحقق. الخطوات محددة مسبقًا — من قِبلك، في الكود. مهمة الذكاء الاصطناعي عمل محدود داخل خطوات معرَّفة سلفًا: صنّف هذا، واستخرج ذاك، وصُغ هذه الرسالة. المسار لا يتغيّر بناءً على ما يقرره الذكاء الاصطناعي في منتصف المهمة.

الوكيل مُشغِّل موثوق يعمل داخل حدود معينة. تمنحه هدفًا، ومجموعة أدوات، وحدودًا — وهو يقرر، خطوة بخطوة، ما يفعله تاليًا، وأي أداة يستدعي، ومتى ينتهي.

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

هذا فرق ذو معنى بالنسبة للمؤسس، لأنه يغيّر مدى قابلية منتجك للتنبؤ والاختبار وتصحيح الأخطاء — قبل أن يغيّر مدى «ذكائه» الظاهر في عرض تجريبي.

متى تستخدم سير عمل بالذكاء الاصطناعي؟

ابدأ بسير عمل حين:

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

في تجربتنا، هذا يغطي معظم منتجات الذكاء الاصطناعي ذات الطابع التشغيلي التي يعرضها المؤسسون علينا. بعض الأمثلة الشائعة:

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

إن كان منتجك يشبه أيًا من هذه الأمثلة، فمن المرجّح جدًا أنه سير عمل — ومعظم المؤسسين الذين يطلبون منا «وكيلًا» لإحدى هذه العمليات يصفون في الواقع سير عمل محدد النطاق جيدًا، بداخله خطوة أو خطوتان بالذكاء الاصطناعي.

متى يكون وكيل الذكاء الاصطناعي منطقيًا فعلًا؟

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

يستحق الوكيل أن يُبنى حين تتحقق عدة أمور في الوقت نفسه:

• يستحيل فعلًا التنبؤ بالخطوات مسبقًا — الإجراء الصحيح التالي يعتمد على ما حدث في الخطوة السابقة، بطريقة لا يمكنك توقعها بالكامل.
• يحتاج المنتج إلى اختيار الأدوات ديناميكيًا، بحسب الموقف المحدد الذي يواجهه.
• يمكن التحقق من النجاح من حالة النظام الفعلية، لا من مجرد كون المخرج يبدو معقولًا.
• يستطيع العمل تحمّل المقايضات — فالأنظمة القائمة على الوكلاء غالبًا ما تكلّف أكثر، وتستغرق وقتًا أطول، وهي أصعب فعلًا في تصحيح الأخطاء من سير عمل يؤدي المهمة نفسها.¹
• يملك الوكيل مجموعة أدوات وصلاحيات ضيقة ومحددة النطاق بدقة — لا صلاحية واسعة «تحسبًا فقط».
• توجد مجموعة اختبار مرجعية أو مجموعة مهام فعلية للتحقق من أدائه، لا مجرد عرض تجريبي بدا جيدًا مرة واحدة.
• يسجّل النظام خطواته ويتتبعها، بحيث يمكن إعادة بناء أي نتيجة سيئة بدل الجدل حولها.

أين يظهر هذا في الواقع العملي:

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

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

لماذا يُعد سير العمل عادة الخيار الأكثر أمانًا للنسخة الأولى (V1)؟

هذه ليست حجة ضد الوكلاء. إنها حجة من منطق Build vs. Cut.

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

هذا هو السبب في أن كثيرًا من منتجات الذكاء الاصطناعي التي نبنيها تبدأ كأتمتة سير عمل قبل أن تصبح أي شيء أكثر استقلالية — تعرّف على ما نبنيه عادة.

يقايض الوكلاء تلك القابلية للتنبؤ بالمرونة. أحيانًا تستحق هذه المقايضة. لكن إرشادات Anthropic الهندسية نفسها صريحة بشأن التكلفة: الأنظمة القائمة على الوكلاء قد تقايض زمن الاستجابة والتكلفة بأداء ومرونة أفضل، والأطر التي تبنيها قد تجعل رؤية ما يحدث بالضبط أصعب — أي أصعب في تصحيح الأخطاء.¹

ما الذي يتغيّر حين تنتقل من سير العمل إلى الوكيل؟

إليك حسابًا صريحًا لما تتحمّله حين تصعد درجة. إن كانت معظم إجاباتك على «سؤال المؤسس» تشير إلى «لا أستطيع تحمّل هذا بعد»، فأنت أمام سير عمل. وإن كانت تشير باستمرار إلى «أنا فعلًا بحاجة إلى هذه المرونة»، فقد أثبت الوكيل جدارته.

كيف تختبر سير العمل والوكلاء؟

لا تُعد أي من البنيتين آمنة للإطلاق بناءً على قوة عرض تجريبي جيد. يحتاج كلاهما إلى الانضباط نفسه الذي نتناوله بالتفصيل في دليل Golden Dataset: كيف تختبر منتج الذكاء الاصطناعي قبل أن تبنيه؟ — هذا القسم هو النسخة المختصرة منه، مطبَّقة تحديدًا على سير العمل والوكلاء.

بالنسبة لسير العمل: اختبر كل خطوة على حدة مقابل مجموعة الاختبار المرجعية، واختبر النتيجة النهائية أيضًا. يمكن لسير العمل أن يُنتج النتيجة النهائية الصحيحة بينما تفشل خطوة داخلية بصمت وتُغطّى بما يأتي بعدها — وأنت تريد رصد ذلك قبل أن يتراكم.

بالنسبة للوكلاء: قِس أكثر من مجرد كون الإجابة النهائية صحيحة. تتبّع نجاح المهمة، وهل اختار الأدوات الصحيحة، وعدد الخطوات التي اتخذها، وتكلفته، والوقت الذي استغرقه، والأهم من ذلك، كيف يتعافى حين يقع خطأ في منتصف المهمة. الوكيل الذي يصل في النهاية إلى الإجابة الصحيحة بعد عشر استدعاءات غير ضرورية للأدوات لديه مشكلة تكلفة وموثوقية يجب أن يكشفها اختبارك، لا مجرد خانة اختيار «هل نجح؟».

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

وفي الحالتين، يعتمد معيار Sprint966 للنجاح قبل الإطلاق — شرط النجاح الذي تضعه قبل الإطلاق — على السؤالين نفسيهما كالعادة: ما تكلفة نتيجة خاطئة، ومدى قابليتها للتراجع؟ الوكيل الذي يتمتع باستقلالية أوسع ومساحة إجراءات أكبر يحتاج عمومًا إلى معيار أعلى، أو موافقة بشرية أكثر صرامة، من سير عمل يؤدي عملًا مماثلًا.

ماذا عن الأنظمة متعددة الوكلاء؟

إن كان الوكيل الواحد التزامًا أكبر من سير العمل، فالنظام متعدد الوكلاء — عدة وكلاء متخصصين ينسّقون على مهمة واحدة — التزام أكبر منه، ويستحق أن ننظر إليه بوضوح.

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

عمليًا، النظام متعدد الوكلاء يكاد لا يكون أبدًا الخيار الصحيح للنسخة الأولى. إن كنت تفكّر فعلًا في أحدها، فالاختبار الصحيح ليس «هل يبدو مبهرًا» — بل مقارنة مباشرة: شغّل مجموعة المهام نفسها مقابل سير عمل أبسط، ووكيل واحد، والنسخة متعددة الوكلاء، وانظر إن كانت النسخة متعددة الوكلاء تفوز فعلًا بعد احتساب تكلفتها الإضافية، وزمن استجابتها، وتعقيد تصحيح أخطائها. إن لم تفز بوضوح على مجموعة اختبارك الخاصة، فإنها لم تُثبت جدارتها بعد.

ما المخاطر الأمنية للوكلاء؟

حَقن الأوامر (prompt injection) — حيث يخدع نص يقرأه الذكاء الاصطناعي النظامَ ليتجاهل تعليماته الفعلية — مخاطرة بنيوية في أي تطبيق يعتمد على نماذج لغوية كبيرة، لأن التعليمات والمحتوى غير الموثوق غالبًا ما يُعالَجان عبر القناة نفسها.²

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

الاستجابة العملية، المتسقة مع إرشادات أمن التطبيقات واسعة الاستخدام، هي:

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

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

كيف تقرر Sprint966 بين سير العمل والوكيل أثناء فحص النطاق؟

هذا بالضبط نوع القرار الذي صُمم فحص نطاق منتج الذكاء الاصطناعي (AI Product Scope Check) لاتخاذه معك، قبل كتابة أي كود.

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

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

هذا هو المنهج نفسه الموضّح بالكامل في دليل Build vs. Cut: حدّد المهمة والمخاطرة قبل اختيار البنية التقنية، لا بعدها.

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

المصادر

1. Anthropic: Building Effective AI Agents
2. OWASP Prompt Injection Cheat Sheet
3. OWASP LLM01
4. Buçinca et al. — Automation Bias
5. Chen et al. — Human-AI Reliance
6. Vasconcelos et al. — AI Overreliance
7. سدايا — مبادئ أخلاقيات الذكاء الاصطناعي
8. دليل نظام حماية البيانات الشخصية لجهات التحكم والمعالجة
9. نظام حماية البيانات الشخصية (PDPL)
10. الدليل الاسترشادي لتحديد الحد الأدنى من البيانات الشخصية
11. لائحة نقل البيانات الشخصية إلى خارج المملكة