وكيل ذكاء اصطناعي لتصميم الديكور الداخلي: Claude بلا RAG ولا LangChain

نُشر على موقع «حبر» (Habr) تحليل لوكيل ذكاء اصطناعي مبني على Claude لأتمتة تصميم الديكور الداخلي: 712 سطرًا من الكود بدلًا من أطر 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 سطرًا وموجِّهان نظاميان
• لا منسّقات (orchestrators) ولا قواعد بيانات متجهية ولا أطر عمل فوق الـ API

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

ما العقبات التي واجهها المطوّر؟

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

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

«هذا ليس دليلًا من خبير، بل أقرب إلى يوميات مفترقات. حاولت أن أكتب

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

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

أين سيبدأ هذا النهج بالتعثّر؟

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

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

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

ماذا يعني ذلك

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

كيف يمكن استخدام Claude لبناء وكيل تصميم؟

يعرض المقال بنية بنموذجين: يجيب Claude Haiku 4.5 عن أسئلة العملاء ويوضّح الطلب، بينما يولّد Claude Sonnet 4.6 المفاهيم التصميمية.

هل يلزم RAG لوكيل مبني على Claude؟

ليس بالضرورة. يعمل الوكيل الموصوف دون أطر RAG ودون قواعد بيانات متجهية، ويتسع النظام كله لـ 712 سطرًا من الكود.

هل يمكن استخدام Claude في تصميم الديكور الداخلي؟

نعم، تستخدم الحالة المدروسة Claude Sonnet 4.6 لتوليد المفاهيم التصميمية، وClaude Haiku 4.5 للتفاعل مع العملاء.

هل يلزم RAG لوكيل ذكاء اصطناعي مبني على Claude؟

ليس بالضرورة. لا يستخدم التطبيق في هذا المثال RAG، ويعمل النظام بموجِّهين نظاميين و712 سطرًا من الكود.