أنظمة الوكلاء الإنتاجية وإتقان المقابلات

لماذا الإنتاج هو الجزء الصعب

بناء وكيل يعمل في عرض تجريبي سهل. بناء وكيل يعمل بشكل موثوق على نطاق واسع — يتعامل مع آلاف المستخدمين ويدير التكاليف ويمنع انتهاكات الأمان ويتدهور بسلاسة عندما تسوء الأمور — هنا يكمن التحدي الهندسي الحقيقي.

هذا أيضاً ما يفصل مرشحي L4 عن مرشحي L6+ في المقابلات. أي شخص يمكنه وصف بنية وكيل للمسار السعيد. المهندسون الكبار يحددون استباقياً أنماط الفشل ومخاطر التكلفة ومخاوف الأمان قبل أن يسأل المحاور.

التحديات الإنتاجية الخمسة

1. السلوك غير المتوقع

على عكس البرمجيات التقليدية حيث نفس المدخل ينتج نفس المخرج، الوكلاء تتصرف بشكل غير حتمي:

التحدي	مثال	التخفيف
عدم حتمية LLM	نفس السؤال يحصل على استدعاءات أدوات مختلفة	قيّد شكل المخرَج (مخططات الأدوات، المخرجات المهيكلة) واجعل الأثر آمناً عند التكرار — لا أزرار الـsampling، انظر أدناه
التأثيرات الجانبية للأدوات	الوكيل يرسل بريداً لا يجب إرساله	قوائم السماح للإجراءات، بوابات تأكيد للعمليات التدميرية
الأخطاء المتتالية	نتيجة أداة سيئة تؤدي لسلسلة قرارات خاطئة	قواطع الدائرة، عدد أقصى للأخطاء لكل جلسة
حساسية الأوامر	تغييرات صياغة طفيفة تسبب سلوك وكيل مختلف	اختبار الانحدار مع مجموعات بيانات مرجعية

الإجابة التي لم تعد متاحة: temperature = 0

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

هي خاطئة آلياً: تُدرج Anthropic معاملات temperature وtop_p وtop_k ضمن إهلاك معاملات الـAPI، وعلى Claude Opus 4.7 وما بعده فإن ضبط أي منها على قيمة غير افتراضية يُرجع خطأ 400. كما حذفت حزمة Python SDK هذه المعاملات نهائياً في الإصدار 1.0، فتمريرها يرفع TypeError قبل إرسال الطلب أصلاً.¹

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

إذن الوكيل نظام يحتوي مكوّناً غير حتمي فعلاً، والسؤال الهندسي ليس كيف نزيل عدم الحتمية بل أي طبقة تمتصها:

2. انفجار التكلفة

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

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

أمران يستحقان الانتباه، وكلاهما يَرِد في المقابلات. رفع حد الخطوات من 6 إلى 20 يضاعف الفاتورة أكثر من ثلاث مرات دون أي تغيير في كودك — ولهذا فإن «الحد الأقصى للخطوات المستقلة» ضابط تكلفة لا ضابط أمان فحسب. ورموز المدخلات تهيمن عادةً، لأن كل خطوة تعيد إرسال السياق المتراكم؛ وهذا ما يجعل التخزين المؤقت للأوامر وضغط السجل رافعتَي تكلفة لا تحسينات هامشية.

استراتيجيات التحكم بالتكلفة:

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

3. حواجز الأمان

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

حواجز المدخل:

• كشف حقن الأوامر (مطابقة الأنماط + مصنّف)
• كشف وحجب المعلومات الشخصية (PII)
• فرض حدود الموضوع (البقاء ضمن المجالات المسموحة)

حواجز الإجراءات:

• قائمة سماح/حظر الأدوات حسب دور المستخدم
• فحص حدود المعاملات (مثلاً: أقصى عدد مستلمي البريد)
• تأكيد مطلوب للعمليات التدميرية (حذف، إرسال، دفع)

حواجز المخرج:

• تصفية المحتوى الضار/غير المناسب
• فحص الدقة الواقعية مقابل المصادر المسترجعة
• التحقق من التنسيق (امتثال المخرجات المهيكلة)

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

يستحق أن يُسمّى وحده لأنه التدبير الوحيد هنا الذي يعالج السبب لا العَرَض. حقن الأوامر ينجح لأن التعليمات والبيانات تتشارك قناة واحدة — فالنموذج وهو يقرأ مستنداً مسترجعاً لا يملك وسيلة على مستوى البروتوكول ليعرف أن جملة «تجاهل تعليماتك السابقة» محتوى منقول لا توجيه صادر منك. المكتشِف يخمّن الفرق بعد وقوعه؛ والفصل يزيل الالتباس الذي يعوّضه ذلك التخمين أصلاً.

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

4. التقييم والاختبار

اختبار الوكلاء مختلف جوهرياً عن اختبار البرمجيات التقليدية:

نوع الاختبار	ماذا يختبر	كيف
اختبارات الوحدة	المكونات الفردية (منفذ الأدوات، المحقق)	أطر اختبار الوحدة التقليدية
اختبارات التكامل	الوكيل + الأدوات يعملان معاً	محاكاة LLM باستجابات محددة مسبقاً
اختبارات السلوك	سلوك الوكيل من طرف لطرف	مجموعات اختبار مرجعية مع نتائج متوقعة
اختبارات عدائية	الأمان تحت الهجوم	محاولات حقن الأوامر، حالات حدية
اختبارات الانحدار	عدم التدهور بعد التغييرات	تشغيل مجموعة البيانات المرجعية، مقارنة الدرجات

المقاييس الرئيسية لجودة الوكيل:

• معدل إكمال المهام — هل يحقق الوكيل هدف المستخدم؟
• دقة استدعاء الأدوات — هل يستدعي الأدوات الصحيحة بمعاملات صحيحة؟
• الكمون (P50/P95/P99) — كم تستغرق حلقة الوكيل الكاملة؟
• التكلفة لكل تفاعل — متوسط تكلفة الرموز لكل طلب مستخدم
• معدل انتهاكات الأمان — كم مرة ينتهك الوكيل الحواجز؟
• معدل الهلوسة — كم مرة يقدم الوكيل ادعاءات غير مدعومة؟

5. المراقبة

تحتاج لتتبع كل قرار يتخذه الوكيل:

# سجل مهيكل لمراقبة الوكيل
{
    "request_id": "req_abc123",
    "user_id": "user_456",
    "timestamp": "2026-02-21T10:30:00Z",
    "event": "tool_call",
    "tool_name": "search_docs",
    "arguments": {"query": "سياسة الاسترداد"},
    "latency_ms": 245,
    "tokens_used": 1200,
    "cost_usd": 0.0024,
    "guardrail_flags": []
}

لوحات المعلومات الأساسية:

• حجم الطلبات ومعدل الخطأ عبر الزمن
• استخدام الرموز وتفصيل التكلفة حسب الوكيل/الأداة
• مئويات الكمون (P50، P95، P99)
• معدل انتهاكات الأمان وتكرار تفعيل الحواجز
• توزيع استدعاءات الأدوات (أي الأدوات الأكثر استخداماً؟)

إتقان المقابلات: المهارات الفوقية

بعيداً عن المعرفة التقنية، يعتمد أداؤك في المقابلة على كيف تتواصل:

إيقاع التواصل

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

التعامل مع "لا أعرف"

من الأفضل أن تقول "لست متأكداً من التنفيذ المحدد، لكن إليك كيف سأتوصل لمعرفته" بدلاً من اختلاق شيء. المحاورون يحترمون الصدق الفكري.

الأخطاء الشائعة

الخطأ	النهج الأفضل
القفز مباشرة للتنفيذ	ابدأ بالمتطلبات والبنية
تجاهل أنماط الفشل	اذكر استباقياً ما يمكن أن يسوء
نسيان التكلفة	ناقش دائماً ميزانيات الرموز وتتابع النماذج
الإفراط في هندسة الحل	ابدأ بسيطاً، أضف التعقيد فقط عند الحاجة
عدم طرح أسئلة توضيحية	اسأل 2-3 أسئلة قبل تصميم أي شيء
التحدث بمفردك لـ 10+ دقائق	تحقق مع المحاور بانتظام

ما التالي؟

خمسة أنظمة وكلاء مبنية، والأنماط التي تقف وراء الجولات التي تحسم هذه المقابلات. تبقّت فكرة أخيرة قبل أن تمضي وتستخدمها.

كل ما في هذه الدورة له عمر افتراضي إلا التسبيب. الأطر في الوحدة الأولى ستُستبدل — وقد استُبدل أحدها بالفعل أثناء عمر هذه الدورة، حين أحالت OpenAI إطار Swarm للتقاعد لصالح Agents SDK. ونوافذ السياق ستتسع مجدداً. والأسعار ستتحرك. ما يبقى هو العادة التي تقيسها جولة التصميم فعلاً: أن تسمّي المقايضة التي قبلتها، وأن تعرف ما الذي ينكسر حين يُخطئ النموذج.

لذا حين تستعد، استعد للأسئلة لا للإجابات. وحين يسألك محاور عن إطار لم تستخدمه، فالرد القوي ليس المجاملة — بل: «لم أستخدمه؛ وهذا هو النمط الذي أتوقع أن ينفّذه، وهذا أول ما سأفحصه فيه».

الدورات التالية الموصى بها

استمر في التحضير للمقابلات:

• مقابلات تصميم أنظمة الذكاء الاصطناعي — عمّق معرفتك بالبنية المعمارية للذكاء الاصطناعي مع تصميم أنظمة RAG وأنماط تطبيقات LLM والموثوقية الإنتاجية
• مقابلات مهندس LLM — أتقن أساسيات LLM التي تشغّل كل وكيل: المحولات والضبط الدقيق والتقييم وتحسين الإنتاج

ابنِ أنظمة حقيقية:

• ابنِ واجهة REST API إنتاجية — ابنِ واجهة API إنتاجية كاملة من الصفر — الأساس الخلفي الذي تعمل عليه أنظمة الوكلاء
• وكلاء الذكاء الاصطناعي المتقدمين — استكشف تكامل MCP متعدد الوكلاء والوكلاء طويلي المدى وأنماط النشر المؤسسي

حظاً سعيداً في مقابلاتك.

Footnotes

1. Anthropic، إهلاك النماذج — إهلاك معاملات الـAPI. يدرج الجدول temperature وtop_p وtop_k كمعاملات مُهلَكة على Claude Opus 4.7 وما بعده، تُرجع «خطأ 400 عند ضبطها على قيمة غير افتراضية»، ويشير إلى أن Python SDK من الإصدار 1.0 فصاعداً يحذفها فيرفع تمريرها TypeError. ونقطة الحتمية موجودة في دليل الترحيل. ::: ↩ ↩²