🤖 وكلاء الذكاء الاصطناعي جاهزون للإنتاج: 5 دروس صعبة من إعادة هيكلة Monolith

فخ الـ Monolith

لقد قمت ببناء ميزات مدعومة بالذكاء الاصطناعي لعدة سنوات، ولو هناك نمط واحد رأيته يفشل أكثر من مرة مما أود أن أعترف به، فهو هذا: الجميع يبدأون مع سكريبت وكيل أحادي. ملف بايثون أو موديول نود واحد يدعو LLM، يقوم بتحليل الاستجابة، يفعل شيئًا معها، ويدعو أن لا يحدث شيء. يعمل بشكل رائع في العرض التوضيحي. ثم يصل إليه حركة الإنتاج، وفجأة يبدأ وكيلك المrafted بشكل جميل في الحلم بأدوات، يبتلع الأخطاء بصمت، ويحترق من ميزانيتك API كما لو لم يكن هناك غد. لقد كنت هناك - أكثر من مرة. نشر جوجل مؤخرًا منشورًا صادقًا حول إعادة هيكلة نموذج أبحاث المبيعات إلى وكيل من الدرجة الإنتاجية باستخدام أداة تطوير الوكيل (ADK)، والدروس التي شاركها تتماشى تقريبًا بشكل مثالي مع ما تعلمته بالطريقة الصعبة. هنا الحكمة المُستقاة. ## الدرس 1: تفكيك إلى وكلاء فرعيين في وقت مبكر الأكبر خطأ قمت به في البداية كان السماح لوكيل واحد بالتعامل مع كل شيء - جلب البيانات، التفكير فيها، تحديد ما يجب القيام به بعد ذلك، تنسيق الإخراج. ما هي المشكلة؟ تضخم البرومت. كل مسؤولية جديدة تعني المزيد من السياق، المزيد من الحالات الحدية، والمزيد من الطرق لتحويل LLM عن المسار. الحل بسيط للغاية: قم بتقسيم نظامك إلى وكلاء فرعيين متخصصين. وكيل أبحاث يجمع البيانات فقط. وكيل منطقي يتحليلها. وكيل كتابة ينسق الإخراج. لكل وكيل فرعي برومت نظام محدد، مجموعة أدوات ضيقة، ومعايير نجاح واضحة. typescript // قبل: وكيل أحادي يتعامل مع كل شيء const agent = new Agent({ tools: [searchTool, analyzeTool, writeTool, emailTool, dbTool], systemPrompt: "You are a research assistant that can do everything..." }); // بعد: وكلاء فرعيين متخصصين const researchAgent = new Agent({ tools: [searchTool], systemPrompt: "..." }); const analysisAgent = new Agent({ tools: [analyzeTool], systemPrompt: "..." }); const outputAgent = new Agent({ tools: [writeTool], systemPrompt: "..." }); كل وكيل فرعي يعود بالخرج المنظم الذي يستهلكه التالي. هذا يجعل التصحيح بسيطًا - يمكنك اختبار كل وكيل على حدة، وعندما ي发生 شيء ما، تعرف بالضبط أين. ## الدرس 2: الإخراج المنظم غير قابل للتفاوض تحليل نص LLM الخام هو قاتل صامت. لا أستطيع أن أحسب عدد المرات التي رأيت فيها JSON.parse() فشل لأن LLM قرر أن يغلف استجابته في سياج ترميز مع تسمية مختلفة قليلاً عن المتوقع. استخدم مخططات Pydantic (Python) أو Zod (TypeScript) لخرج كل وكيل. إذا كان

الدرس التالت: الـ RAG الديناميكي ضروري، مش مجرد حاجة حلوة

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

async function retrieveContext(query: string) {
  const embedding = await embeddingModel.embedQuery(query);
  const results = await vectorStore.similaritySearch(embedding, 5);
  return results.map(r => r.content).join('\n\n');
}

ده بيخلي نافذة السياق لوكيلك مركزة وملائمة. مينفعش تروح تلقى مجموعات الوثائق كاملة في كل استفسار.

الدرس الرابع: مراقبة من اليوم الأول

مينفعش ت调يب ما مش شايف. أضف تتبع OpenTelemetry، تسجيل منظم، وتتبع استخدام الرموز من أول سطر في كود الوكيل، مش بعد ما حاجة تتعطل في الإنتاج. كل مكالمة لوكيل يجب أن تنتج تتبع يظهر:

• الاستفسار الكامل (مقتطعة لو لازمة)
• الأدوات اللي تم استدعاؤها ومع أي حجة
• عدد الرموز لكل مكالمة
• تحليل التأخير
• الإخراج المنظم النهائي استخدم تتبع OpenTelemetry التلقائي مع المصدرين إلى Jaeger أو Google Cloud Trace. حفظ لي ساعات من وقت Debugging أكتر من ما أقدر أحسب.

الدرس الخامس: كود محدد للتنفيذ، احتمالي للتفكير

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

// ❌ سيئ: السماح LLM بتنفيذ
const llmResponse = await llm.call("Send an email to [email protected]");
// LLM قد ي格式ه بشكل خاطئ، أو يغيب عن الموضوع، أو يخترع!
// ✅ جيد: LLM يحدد النية، والكود ينفذه

الخلاصة

بناء وكلاء الذكاء الاصطناعي الإنتاجية مش هي عن هندسة البرومبت — هي عن هندسة البرمجيات مع LLMs كعنصر. نفس المبادئ المعمارية اللي بتخلي النظم الموزعة كويسة (الوحداتية، العقود المنظمة، الرصد، فصل الاهتمامات) بتطبق هنا مع تركيز إضافي. ابدء مع الوكلاء الفرعية، افرض مخرجات منظمة، RAG ديناميكي، اتبع كل حاجة، و احتفظ بمكالمات LLM الاحتمالية في طبقة التفكير فقط. وكيلك هيشكرك — و كمان دورة الاون كول الإنتاجية بتاعتك هيشكرك.