وكيل إنتاج على Claude بدون LangChain و RAG: معمارية بـ 712 سطر لاستوديو تصميم الديكور الداخلي

نشر مطور مستقل على موقع Habr تحليلاً تفصيلياً لهندسة وكيل إنتاجي على Claude، تم إنشاؤه لاستوديو تصميم داخلي صغير. يتسع النظام بأكمله في ملف main.py واحد يتضمن 712 سطراً من الكود واثنين من موجهات النظام — بدون LangChain، بدون إطارات عمل RAG، وبدون قواعس بيانات متجهة.

ما المكونات التي يتألف منها الوكيل؟

تُقسم أدوار نموذجي Claude بوضوح حسب نوع المهمة. تعمل واجهة الدردشة على Claude Haiku 4.5: يستجيب النموذج بسرعة لأسئلة العملاء، ويوضح الطلبات، ويحافظ على الحوار. يتولى Claude Sonnet 4.6 توليد مفاهيم التصميم: فهو يحول رغبات العميل إلى وصف هيكلي للديكور الداخلي. تُؤخذ الصور لتصور المفاهيم من مكتبة Pexels — وهذا أرخص بكثير وأسرع من توليد الصور عبر DALL-E.

المعاملات الرئيسية للحل:

• Claude Haiku 4.5 — الحوار مع العميل: سريع واقتصادي
• Claude Sonnet 4.6 — توليد مفاهيم تصميم منظمة
• Pexels API — اختيار الصور بدلاً من DALL-E
• ملف main.py واحد، 712 سطراً من الكود، موجها نظام اثنان
• بدون منسقات أو قواعد بيانات متجهة أو إطارات عمل فوق الواجهة البرمجية

هذا الخيار المعماري ليس صدفة. بالنسبة للاستوديو ذي الميزانية المحدودة وتدفق العملاء الصغير، فإن المجموعة الكاملة للـ RAG تعتبر هندسة معقدة. Haiku أرخص في الحوار؛ يتم تفعيل Sonnet فقط عندما تكون هناك حاجة لتوليد إبداعي منظم. لا معنى لحل مشكلة قابلية التوسع التي لم تظهر بعد.

ما الصعوبات التي تمت مواجهتها؟

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

الدقة الثانية هي سلوك Sonnet 4.6 مع الإخراج المنظم. يلتف النموذج أحياناً استجابة JSON في كتلة نصية إضافية بدلاً من إرجاع JSON نقي. يفشل `json.loads()` القياسي مع خطأ في هذه الحالات. جرب المؤلف عدة استراتيجيات تحليل واختار غلافاً بسيطاً بمنطق الرجوع — فهو أكثر موثوقية من استخراج JSON باستخدام التعبيرات العادية.

«هذا ليس دليلاً من خبير — بل دفتر يوميات للقرارات. حاولت أن أشرح

بصراحة لماذا اتخذت كل قرار»، يوضح المطور.

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

أين ستبدأ هذه الطريقة في الفشل؟

يحدد المطور بصراحة حدود حله. يعمل ملف واحد بـ 712 سطراً بشكل جيد لـ MVP واستوديو صغير، لكن قابلية التوسع ستخلق مشاكل:

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

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

ماذا يعني هذا

يُظهر المنشور: واجهة برمجة تطبيقات Claude كافية لوكيل إنتاجي بدون أطر عمل داعمة، إذا كانت المهمة محددة بما فيه الكفاية. بالنسبة للمطورين الذين يبدأون بناء وكلاء على Claude، هذا تحليل صريح للصعوبات الحقيقية — حد التخزين المؤقت لـ Haiku 4.5، وتحليل JSON لـ Sonnet 4.6، والتوزيع الدراس للمهام بين نماذج بمستويات مختلفة.