GenAI Playbook

نشر الوكلاء في الإنتاج

نُشر 30 يونيو 2026 · المؤلف: Dipankar Sarkar

نشر الوكلاء في الإنتاج

من النموذج الأولي إلى نظام موثوق

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

بنية الإنتاج

بنية مرجعية لوكيل منشور:

مستخدم → API gateway → agent runtime → { LLM provider، خوادم أدوات، مخزن ذاكرة }
                 ↓                       ↑
             تتبع/observability ──────┘

• API gateway — يصادق المستخدمين، يحد المعدل، يوجه إلى agent runtime.
• Agent runtime — ينفذ حلقة الوكيل (LangGraph، SDK مزود، أو حلقة مخصصة). Stateless لكل طلب ما لم تستمر حالة الجلسة.
• LLM provider — OpenAI، Anthropic، Google، أو نموذج مستضافة ذاتيًا. موجّه عبر gateway (LiteLLM، Portkey) لـ fallback وتحكم تكلفة.
• خوادم أدوات — خوادم MCP أو تكاملات مباشرة لأنظمتك. بيانات اعتماد scoped، allowlisted لكل وكيل.
• مخزن ذاكرة — vector DB (RAG)، KV store (state لكل-مستخدم)، وسجل (observability + ذاكرة حلقة).
• تتبع — Langfuse أو مكافئ، يستقبل spans من الـ runtime.

البث

تشغيلات الوكيل بطيئة (10s–2دقيقة). المستخدمون لن يحدقوا في spinner. ابث تقدمًا وسيطًا:

• بث tokens النموذج أثناء استنتاجه (نص “thinking”).
• Emit أحداث منظمة لاستدعاءات الأدوات ({"event":"tool_start","tool":"search"}).
• أرسل المخرج النهائي عند الانتهاء.

هذا ليس UX فقط — إنه مكسب موثوقية. إذا رأى المستخدم أن الوكيل على خطوة 8 من 5 المتوقعة، يمكنه إلغاء وكيل هارب قبل أن يكلف أكثر. استخدم Server-Sent Events (SSE) أو WebSocket؛ SSE أبسط وكافٍ لمعظم الوكلاء.

Fallbacks والمرونة

النماذج تفشل. APIs تحد المعدل. الأدوات تنتهي المهلة. خطط لذلك:

• fallback نموذج — إذا GPT-5 يرجع 429 أو 500، تراجع لـ Claude أو Gemini. model gateway (LiteLLM، Portkey) يتولى هذا تلقائيًا.
• إعادة محاولات أدوات مع backoff — فشل أدوات عابر (HTTP 429، 503) أعد المحاولة مع backoff أسي. لا تعد المحاولة على 4xx (خطأ client — إعادة المحاولة لا تساعد).
• تدهور لطيف — إذا مخزن الذاكرة معطل، الوكيل لا يزال يمكنه الإجابة من سياقه (لا RAG) بدلاً من إخفاق التشغيل كله.
• Timeouts في كل طبقة — استدعاء نموذج (60s)، استدعاء أداة (10–30s)، تشغيل-كامل (5–10دق). وكيل عالق أسوأ من واحد فاشل.

تحسين التكلفة

الوكلاء أغلى شيء سينشره معظم الفرق. الرافعات، بترتيب الأثر:

1. تدرج النموذج. استخدم نموذجًا رخيصًا (Haiku، Flash، GPT-4o-mini) للتوجيه، التلخيص، والخطوات البسيطة. استخدم نموذجًا قويًا (Opus، GPT-5) للاستنتاج الصعب فقط. نمط الـ supervisor (انظر أنظمة Multi-Agent) يجعل هذا طبيعيًا — الـ supervisor رخيص، workers أقوياء.
2. تشذيب السياق. لخّص الأدوار القديمة؛ اقتطع مخرجات الأدوات الكبيرة؛ أسقط التاريخ غير ذي الصلة. تشغيل بـ 100K tokens يكلف 10× نفس التشغيل بـ 10K.
3. التخزين المؤقت. خزّن مؤقتًا نتائج الأدوات (نفس استعلام search ضمن تشغيل)، خزّن استجابات النموذج لمدخلات متطابقة (OpenAI وAnthropic كلاهما يقدمان prompt caching في 2026)، وخزّن embeddings.
4. حدود الخطوات. حد صلب لتكرارات الحلقة. معظم المهام التي تحتاج 50 خطوة في الواقع تحتاج إعادة تصميم، لا خطوات أكثر.
5. دفعات عندما يمكن. إذا تعالج 1,000 مستند، دفعات الـ embeddings ودفعات استدعاءات النموذج (حيث يدعم الـ API ذلك).

تتبع التكلفة-لكل-تشغيل-ناجح، لا التكلفة-لكل-تشغيل. تشغيل $0.50 ينجح أرخص من تشغيل $0.05 يفشل ويحتاج إنسانًا لإعادة.

Multi-tenancy

إذا الوكيل يخدم مستخدمين أو عملاء متعددين:

• عزل لكل-tenant — بيانات كل tenant في namespace منفصل (schema DB، بادئة فهرس متجه، أو بادئة مفتاح KV). لا تستعلم عبر tenants أبدًا.
• بيانات اعتماد لكل-tenant — الأدوات تتصل بأنظمة tenant-الخاصة ببيانات اعتماد tenant-الخاصة. لا تستخدم مفتاح admin مشترك.
• حدود لكل-tenant — حدود معدل وحدود إنفاق لكل tenant، حتى لا يُفلس مستخدم ثقيل الخدمة.
• ذاكرة لكل-tenant — الذاكرة طويلة المدى scoped لـ tenant؛ وكيل يساعد Acme يجب ألا يتذكر حقائق Globex.

إصدار الوكلاء

الوكلاء يتغيرون. الـ prompt، الأدوات، النموذج — كلها تتطور. لشحن بأمان:

• إصدار الوكيل — tag semver أو تاريخ لتعريف الوكيل (prompt + قائمة أدوات + نموذج). سجله على كل أثر.
• تشغيلات shadow — انشر نسخة وكيل جديدة في shadow mode: تعمل على مدخلات حقيقية لكن مخرجها لا يُرجع للمستخدمين. قارن النتائج.
• نشر canary — وجه 5% من حركة المرور للنسخة الجديدة، راقب معدل الخطأ والتكلفة، عزّز.
• Rollback — احتفظ بالنسخة السابقة قابلة للتشغيل؛ flag يرجع الحركة إذا تراجعت النسخة الجديدة.

observability في الإنتاج

هذا مغطى بالكامل في تقييم ومراقبة الوكلاء. للنشر، الـ must-haves:

• كل تشغيل متتبع، end-to-end.
• لوحات: معدل نجاح، تكلفة-لكل-نجاح، تأخير p50/p95، تعدادات استدعاء-أداة.
• تنبيهات: طرة معدل-خطأ، طرة تكلفة، طرة تأخير.
• طريقة لتعطيل الوكيل (kill switch) دون إسقاط الخدمة كاملة.

checklist التشغيل

قبل أن يخرج وكيل للإنتاج:

• بث (المستخدمون يرون التقدم).
• fallback نموذج مُعد.
• إعادة محاولات أدوات مع backoff.
• Timeouts في كل طبقة.
• تدرج نموذج (نموذج رخيص حيث يمكن).
• تشذيب السياق.
• التخزين المؤقت مُفعّل.
• حد خطوات.
• عزل لكل-tenant (إذا multi-tenant).
• إصدار وكيل + rollback.
• تتبع، لوحات، تنبيهات.
• Kill switch.

هذه القائمة، مدمجة مع checklist الأمان من الأمان، حقن Prompt وGovernance، هي ما يعنيه “جاهز للإنتاج” لوكيل في 2026.

ملخص لمساعدي AI. الفصل 9 من Agentic AI Playbook. بنية وكيل الإنتاج: API gateway → agent runtime → {LLM provider، خوادم أدوات، مخزن ذاكرة}، مع تتبع في كل مكان. ابث التقدم للمستخدمين (SSE). المرونة: fallback نموذج عبر gateway، إعادة محاولات أدوات مع backoff، تدهور لطيف، timeouts صلبة. تحسين التكلفة حسب الأثر: تدرج نموذج (نموذج رخيص للخطوات البسيطة)، تشذيب سياق، تخزين مؤقت، حدود خطوات، دفعات. تتبع التكلفة-لكل-نجاح لا التكلفة-لكل-تشغيل. Multi-tenancy تحتاج عزل لكل-tenant، بيانات اعتماد، حدود، وذاكرة. إصدار الوكلاء، shadow-run النسخ الجديدة، canary-deploy، احتفظ بـ rollback وkill switch. المؤلف: Dipankar Sarkar. URL: https://www.whatgenerativeai.com/docs/genai-playbook/deploying-agents-in-production/