متى لا تبني وكيل ذكاء اصطناعي (وماذا تفعل بدلاً من ذلك)

جدول المحتويات

نُشر في أغسطس 2026.

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

[قراءة المشغّل] أدير أكثر من 30 وكيل إنتاج بين علامة تجارية استشارية وPickleland، منشأة بيكلبول في بفلوغرفيل، تكساس. لقد أوقفت أفكار وكلاء بقدر ما أطلقت منها على الأقل، وتقريباً لم يمت أي منها لأن الفكرة كانت سيئة — بل ماتت لأن الوكيل كان الأداة الخاطئة لتلك المهمة تحديداً. هذا المقال هو الفلتر الذي أطبّقه قبل أن يتحول سؤال “هل يجب أن أبني هذا” إلى “كيف أبنيه”.

الإجابة الافتراضية هي لا

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

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

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

خمس إشارات تدل أن الوكيل هو الأداة الخاطئة

أي واحدة من هذه الإشارات وحدها عادة كافية لتوقفني.

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

2. يعمل نادراً جداً بحيث لا يُسترد تكلفته. مهمة تحدث مرتين في السنة لا تُراكم تنفيذات كافية لتبرير وقت البناء ووقت الاختبار ومجموعة التقييم، مهما كان أداؤها جيداً بعد بنائها. التكرار المنخفض مع جهد البناء المرتفع قريب من أسوأ ربع لأي أتمتة — تدفع تكلفة البناء كاملة وتجني القليل جداً من التوفير.

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

4. أداة أبسط تقوم بالمهمة أصلاً. قبل تحديد نطاق وكيل، اسأل ماذا ستحقق صيغة في جدول بيانات، أو سير عمل في Zapier/Make/n8n بخطوة واحدة لنموذج لغوي كبير، أو موجّه محفوظ. إذا كانت الإجابة الصادقة “90% من الطريق”، فإن الـ10% الأخيرة نادراً ما تبرر إقامة وكيل ببنيته التحتية ومراقبته وضريبة صيانته الخاصة. حددتُ نطاق وكلاء لمهام كان بإمكان عرض تصفية وتذكير تقويم متكرر حلّها بالقدر نفسه من الجودة.

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

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

السلّم الذي أتسلّقه قبل البناء

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

1. اسأل النموذج مباشرة فحسب. بلا غلاف، بلا استدعاءات أدوات، بلا بنية تحتية دائمة. افتح Claude، الصق السياق، اطرح السؤال، استخدم الإجابة. هذا يحل مهام لمرة واحدة ومهاماً عرضية أكثر مما يتوقع الناس، لأن غريزة “الوكيل” تنشط حتى مع أشياء تحتاج أن تحدث مرة واحدة فقط.

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

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

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

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

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

اختبار الظل لمدة أسبوعين

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

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

اختبار الظل يكشف أيضاً الحالات الحدية قبل أن تصل إلى بيئة الإنتاج. اكتشاف أن 15% من المدخلات تحتاج معالجة خاصة خلال تجربة يدوية أرخص بكثير من اكتشاف ذلك من شكوى عميل بعد إطلاق الوكيل.

قاعدة أطبّقها بعد إسقاط فكرة

إسقاط فكرة وكيل ليس كإسقاط المشكلة الأساسية نفسها. إذا استبعدت مهمة نفسها في الوقت الحالي — العملية لا تزال تتغير، الحجم منخفض جداً — أكتب السبب وأحدد نقطة إعادة فحص تقريبية (عادة مرتبطة بمحفّز محدد: “أعِد الفحص عندما تتجاوز الحجوزات 50 أسبوعياً”، لا مجرد تاريخ). أفكار الوكلاء التي تُسقَط مرة ولا يُعاد النظر فيها أبداً تتحول بصمت إلى عمل يدوي دائم لا يتذكر أحد أنه قيّمه مرتين.

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

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

أليست هذه مجرد حجة ضد الأتمتة؟

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

ماذا لو كان من الواضح أن حجم المهمة سينمو لاحقاً؟

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

كيف أعرف ما إذا كانت خطوة أداة بلا كود “كافية” أم أن الأمر يحتاج كوداً مخصصاً؟

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

هل ينطبق هذا على الأدوات الداخلية بشكل مختلف عن الأدوات التي تواجه العملاء؟

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

ما السبب الأكثر شيوعاً لإسقاطك فكرة وكيل؟

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