Charmonye Logo
→ المجلة
التكنولوجيا ١٣ دقيقة قراءة

كيف نستخدم الذكاء الاصطناعي خارج الدردشة على الويب: نماذج، وكلاء، إعدادات محلية، وما الذي يصلح لكل مهمة

خريطة عملية لأدوات الذكاء الاصطناعي خارج تبويبة الدردشة: نماذج سحابية ومحلية، وواجهات API، ووكلاء CLI، ومهارات، وMCP، ونماذج رؤية، وتوليد صور - وأين يصلح كل منها في عمل المشاريع الحقيقي.

رسم توضيحي لسير عمل الذكاء الاصطناعي يربط البيانات المحلية والوكلاء وMCP وتوليد الصور وواجهات API وملفات المشروع

معظم الناس يلتقون بالذكاء الاصطناعي بطريقة واحدة: يفتحون ChatGPT أو Claude أو Gemini في المتصفح، يكتبون سؤالًا، يحصلون على إجابة. هذا يعمل. ونحن نستخدمه أيضًا، للأشياء السريعة - تعريف، صياغة، ترجمة سريعة.

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

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

أدوات مختلفة لمهام مختلفة. هذه هي الفكرة كلها.

النموذج والواجهة - شيئان مختلفان

الناس يخلطون بين هذين باستمرار، وهذا يجعل بقية الموضوع مشوّشًا.

النموذج (Model) هو النظام المدرّب الذي يقوم بالعمل - GPT، Claude، Gemini، Qwen، Gemma، Llama. عائلات مختلفة، نقاط قوة مختلفة. النموذج شيء واحد.

الواجهة (Interface) هي طريقة محادثتك مع النموذج. الدردشة على الويب واحدة. تطبيق سطح المكتب آخر. الطرفية (CLI) ثالث. إضافة لبيئة التطوير رابع. استدعاء API مباشر من شفرتك خامس.

نفس النموذج، واجهات مختلفة. Claude في تطبيق الويب هو نفس Claude في Claude Code في الطرفية. النموذج لا يتغيّر. ما يتغيّر هو ما يمكنك أن تطلب منه فعله وما يمكنه أن يلمسه.

فوق هذا - ومن المفيد إبقاؤه منفصلًا في ذهنك - يأتي مكان تشغيل النموذج فعلًا: على خوادم شخص آخر (سحابي) أو على جهازك (محلي). هذا سؤال مختلف عن "أي نموذج" و"أي واجهة"، وهو موضوع القسم التالي.

هذا يهم لأن معظم النقاشات حول "أي ذكاء اصطناعي أفضل" هي في الحقيقة نقاشات حول الواجهة أو التشغيل، وليس النموذج نفسه.

التفرّع الأول الحقيقي: محلي أم سحابي

هنا تبدأ الخيارات العملية.

السحابي (Cloud) - النموذج يعمل على خوادم شخص آخر. ترسل البيانات، يرسلون النتيجة. ChatGPT، Claude، Gemini، Qwen عبر Model Studio. لا حاجة لعتاد، أقوى النماذج متاحة، لكن بياناتك تغادر جهازك.

المحلي (Local) - تنزّل أوزان النموذج وتشغّله على بطاقتك الرسومية. البيانات تبقى معك. أنت تتحكم بكل شيء. لكنك تحتاج إلى العتاد، وعليك إعداده.

النماذج السحابية الأقوى لا تزال متقدمة على ما يمكن تشغيله محليًا، لكن الفجوة في المهام الروتينية ضاقت بما يكفي لجعل المحلي خيارًا حقيقيًا للعمل الجاد، لا مجرد هواية.

نستخدم الاثنين، حسب المهمة.

المحلي لـ: مواد المشاريع الخاصة التي لا نريد أن تمرّ عبر خدمات طرف ثالث - صور المنزل، مخططات الموقع، ملف العميل، الميزانيات؛ الفرز والفهرسة والتلخيص الروتيني؛ العمل المتكرر الذي قد يستنزف حصة سحابية؛ أي شيء نريد فيه تحكمًا كاملًا.

السحابي لـ: التفكير متعدد الوسائط الثقيل الذي لا يستطيع نموذج محلي القيام به؛ الأسئلة العابرة حيث الإعداد مبالغ فيه؛ المهام التي تكون فيها البيانات عامة أو مجهولة الهوية؛ ميزات مثل السياق الطويل جدًا أو أحدث إصدارات الرؤية التي لم تلحق بها النسخ المحلية بعد.

شغّلنا نماذج محلية على عتاد يتراوح من 5060 Ti إلى 4090 معدّلة إلى 48 GB VRAM (تأتي 4090 القياسية بـ 24 GB؛ ترقية الذاكرة إجراء معروف في أوساط الهواة والاستوديوهات). Qwen، Gemma، gpt-oss، بما في ذلك إصدارات الرؤية المقدّمة عبر vLLM. بعضها أبهرنا. وبعضها فاجأنا بكونه أسوأ بشكل ملحوظ على صور المواقع الحقيقية مما يوحي بطاقة النموذج. الفجوة بين "يدعم الرؤية" و"مفيد على صور المواقع الفعلية" قد تكون واسعة.

الاشتراك وAPI وCLI - محاور مختلفة، كثيرًا ما تختلط

هذا هو القسم الذي يضيع فيه معظم الناس، لأن ثلاثة أشياء مختلفة تُذكر وكأنها شيء واحد.

الاشتراك (Subscription) نموذج فوترة: تدفع رسمًا شهريًا ثابتًا (20-200 دولار) وتحصل على حصة استخدام للنموذج - عادة عبر الدردشة والويب وسطح المكتب والهاتف، و(في الاشتراكات الأحدث) وصول إلى CLI. تدفع مقابل الوقت، لا مقابل الاستخدام.

API نمط وصول برمجي: شفرتك ترسل طلبًا، النموذج يعيد ردًا، تدفع بحسب الرموز (tokens) المستخدمة. مفيد عندما تريد الأتمتة أو المعالجة الدفعية أو البناء فوقه.

CLI واجهة: برنامج طرفية تتحدّث معه بلغة بسيطة، يستطيع قراءة ملفاتك وتشغيل أوامر واستدعاء أدوات نيابة عنك. Claude Code، Codex CLI، Gemini CLI.

هذه الثلاثة على محاور مختلفة. يمكن لـ CLI أن يستخدم نموذجًا سحابيًا عبر اشتراك، أو نفس النموذج السحابي عبر رموز API، أو نموذجًا محليًا يعمل على جهازك. نفس الواجهة، تركيبات مختلفة تحتها.

بالنسبة لمعظم الناس، السؤال العملي ليس "اشتراك أم API" - بل "هل أحتاج إلى أتمتة". إذا كنت تكتب نفس السؤال في الدردشة للمرة العاشرة، فأنت على الأرجح تحتاج إما إلى مهارة (داخل وكيل CLI) أو سكربت API صغير. إذا أردت أن يتعامل الوكيل مع عمليات الملفات، فأنت تحتاج إلى CLI. الفوترة تتبع حالة الاستخدام.

ما الذي يفعله الوكيل فعلًا: استدعاء الأدوات، المهارات، الوكلاء الفرعيون، MCP

هذه هي الطبقة التي تحوّل الذكاء الاصطناعي من محرك بحث ثرثار إلى أداة عمل حقيقية.

استدعاء الأدوات (Tool calling) هو الآلية الأساسية. نموذج لغوي عادي يأخذ نصًا ويعطي نصًا. نموذج مع استدعاء أدوات يستطيع إضافةً إلى ذلك أن يطلب من النظام القيام بأشياء - قراءة ملف، استعراض مجلد، إجراء بحث، جلب صف من قاعدة بيانات، استدعاء API خارجي. بدون استدعاء الأدوات، حتى أقوى النماذج محبوس في المحادثة.

الوكيل (Agent) هو نموذج مع استدعاء أدوات بالإضافة إلى حلقة. تعطيه مهمة بلغة بسيطة. يختار الأدوات ويستخدمها ويتحقق من النتيجة ويعدّل ويكرر حتى ينتهي أو يعلق. Claude Code وCodex CLI وGemini CLI كلها تشغّل وكلاء على نظام ملفاتك وأمر الشل.

المهارات (Skills) تعليمات متخصصة قابلة لإعادة الاستخدام للوكيل. بدلًا من لصق نفس البرومبت الطويل في كل مرة تريد فيها مراجعة شفرة، أو فحص الصوت، أو بناء فهرس صور، تكتب SKILL.md واحدة ويستدعيها الوكيل عند الحاجة. اعتبارًا من 2026، Claude Code وCodex وGemini CLI وعدة بيئات تطوير تتشارك صيغة SKILL.md متوافقة - نفس ملف المهارة يعمل عبر الأدوات. نستخدم المهارات للتحرير والتدقيق ومراجعة الأسلوب وفهرسة الصور. المهارة هي وحدة "نحن نفعل هذا دائمًا بنفس الطريقة".

الوكلاء الفرعيون (Subagents) وكلاء مساعدون يستدعيهم الوكيل الرئيسي لأجزاء من مهمة. كل وكيل فرعي يحصل على نافذة سياق خاصة به، وأدواته المسموح بها، وأحيانًا نموذج مختلف. بينما يفكر الوكيل الرئيسي في البنية العامة، يجري وكيل فرعي بحثًا بالتوازي، وآخر يتحقق من حقائق مسوّدة، وآخر ينسّق المخرجات. يرسلون التقارير. الوكيل الرئيسي ينسّق.

MCP (بروتوكول سياق النموذج) هو الوصلة الموحّدة بين النماذج والأدوات الخارجية. بدلًا من أن تخترع كل أداة تكاملها الخاص، يحدّد MCP بروتوكولًا واحدًا يتحدّثه الجميع - Anthropic وOpenAI وGoogle وأغلب الأطر. توصل خادم MCP (لنظام ملفاتك، أو التقويم، أو قاعدة بيانات التصميم، أو مكتبة الصور، أيًا كان)، ويمكن لأي وكيل يدعم MCP استخدامه. اعتبارًا من 2026 أصبح فعليًا الطبقة الافتراضية للتكامل.

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

نماذج مختلفة لمهام مختلفة

لا يوجد نموذج واحد يفعل كل شيء بشكل جيد. محاولة جعل نموذج واحد يتعامل مع النص والصور وتوليد الصور وعمليات المجلدات هي الخطأ التقليدي للمبتدئين.

النماذج اللغوية تقرأ وتكتب النص. الموجزات، الملخصات، التناقضات في الملاحظات، الأسئلة، المسوّدات، المراسلات. معظم النماذج الحالية تتعامل مع هذا جيدًا.

نماذج الرؤية اللغوية (Vision-Language Models). نماذج تقرأ الصور كجزء من المحادثة، لا النص فقط. اللاحقة "VL" غالبًا ما تظهر على أسماء النماذج المحلية - مثل qwen3-vl - للإشارة إلى أن هذه النسخة تتعامل مع الصور لا النص فقط. مع نماذج السحابة المتقدمة عادة لا تحتاج للتفكير في ذلك: ChatGPT وClaude وGemini تتعامل مع الصور منذ فترة. لكنه ليس تلقائيًا - DeepSeek V4 مثلًا نصي فقط. فقدرة النموذج على "الرؤية" خاصية للإصدار المحدد، لا للسحابي مقابل المحلي.

بعد زيارة موقع لدينا صور: المنزل، السور، الأشجار، الممر، البقع الرطبة، الممرات الضيقة، نفايات البناء. نموذج قادر على الرؤية يستطيع وصف ما في الإطار - أين المنزل والمدخل، ما حالة السور، أين توجد تغيّرات في المنسوب - مفيد كقراءة أولى للمجلد. ليس بديلًا عن التواجد في الموقع.

مولّدات الصور تنشئ صورًا جديدة من برومبتات نصية. لا تقرأ الصور القائمة؛ بل تخترع فرضيات بصرية. مفيدة للمزاج، وكثافة الزراعة، ومواد الممرات، وشكل التراس. لكن الصورة المولّدة ليست مشروعًا - النموذج سيضع بسعادة ممرًا عبر منطقة وصول تقنية، أو يضع مسبحًا على المسار الرئيسي، أو يحذف شجرة قائمة لأنها أفسدت التكوين، أو يخترع مرجًا مستويًا حيث للموقع منحدر ومياه راكدة. تعامل مع المخرجات كأفكار بصرية للنقاش، لا كقرارات.

النماذج متعددة الوسائط (Multimodal) تجمع بعض ما سبق. أحدث نسخ ChatGPT وClaude وGemini تتعامل مع النص والرؤية وأحيانًا التوليد في نموذج واحد. الجودة عبر الأنماط ليست موحّدة - نموذج قد يكون ممتازًا في النص ومقبولًا في الصور، أو العكس.

VLM ومولّد الصور ليسا نفس الأداة. الـ VLM تقرأ؛ المولّدات تنشئ. لا يستبدل أحدهما الآخر.

ما يمكنك تشغيله محليًا فعلًا

لقطة زمنية حتى مايو 2026. هذا أكثر قسم متغيّر في المقال.

للعمل المحلي، الـ VRAM على بطاقة الرسومات تهم أكثر من اسم النموذج.

  • 8-16 GB VRAM - نماذج صغيرة فقط (7B-20B باراميتر). مهام نص بسيطة. مثال حالي: gpt-oss-20b، صمّمته OpenAI لسيناريوهات محلية وحافة الشبكة تحتاج إلى نحو 16 GB.
  • 24 GB VRAM - منطقة محلية عملية. Qwen3.6 27B، Gemma 4 26B، بعض إصدارات 31B-35B بشكل مكمّم. النص يعمل جيدًا؛ دعم الرؤية يختلف حسب الإصدار.
  • 32 GB VRAM - مريحة. سياق أطول، تشغيل وكيل أسلس، مجال لبعض السيناريوهات متعددة الوسائط.
  • 80 GB VRAM - أراضي محطات العمل والخوادم. gpt-oss-120b يتسع هنا. ليس لابتوب استهلاكيًا.

أدوات تشغيل النماذج المحلية:

  • Ollama - أبسط بداية؛
  • LM Studio - واجهة رسومية، ودودة؛
  • llama.cpp، vLLM - أكثر تقنية، تحكم أكبر.

عائلات النماذج التي عملنا معها:

Qwen3.6. النسخة السحابية qwen3.6-plus قوية: سياق طويل، دعم صور وفيديو، استدعاء دوال، مخرجات منظّمة. إصدارات الأوزان المفتوحة 27B تعمل على بطاقة 24 GB (Ollama يدرجها حول 17 GB)؛ نسخ 35B-A3B تنزل في نطاق 22-24 GB حسب الكمّمة.

Gemma 4. عائلة Google المفتوحة. خفيفة E2B/E4B للعتاد الأضعف والمهام البسيطة؛ 26B و31B للعمل المحلي الجاد. Ollama يدرج 26B/31B حول 18-20 GB مع دعم النص والصور.

gpt-oss. الإصدارات المفتوحة من OpenAI. gpt-oss-20b نموذج تفكير منطقي مع دعم استدعاء الأدوات في النطاق المحلي الميسور. gpt-oss-120b يعمل بكفاءة على بطاقة 80 GB واحدة وفقًا لـ OpenAI.

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

توليد الصور: أين تجده

اعتبارًا من منتصف 2026، يأتي توليد الصور في أربع صيغ تقريبًا.

مدمج في الخدمات السحابية. ChatGPT وGemini وClaude كلها تستطيع توليد صور داخل الدردشة. Google تقدّم NanoBanana 2 وImagen 4 عبر تطبيق Gemini وAI Studio وVertex AI. OpenAI لديها GPT Image 1.5 وGPT Image 2. الخدمات الصينية تشغّل Kling 3.0 وWan 2.7 وSeedream. الجودة تتفاوت؛ السهولة لا تُضاهى - أنت بالفعل في الدردشة.

مزودون مستقلون. Midjourney وHiggsfield وآخرون متخصصون تحديدًا في الصور والفيديو. تحكم أكبر، خيارات أكثر، سير عمل متخصص.

أدوات تصميم متخصصة. خدمات تغلّف نماذج التوليد السحابية ببرومبتات وأنماط مُعدّة مسبقًا لمجال ضيق - المناظر الطبيعية، التصميم الداخلي، العمارة. لا توليد خاص تحت الغطاء - بل توجيه إلى نماذج أساسية من OpenAI وGoogle وxAI وغيرها، مع طبقة خاصة بالمجال فوقها. مثال على ذلك app.charmonye.com - أداة بنيناها لعملنا في المناظر الطبيعية ونستخدمها يوميًا؛ تستدعي تحت الغطاء عدة نماذج أساسية (ChatGPT، Google، Grok) حسب المهمة. مريحة عندما تطابق إعدادات الأداة ما تحتاجه فعلًا.

التوليد المحلي. Flux.2 يتصدّر في الواقعية البصرية؛ Stable Diffusion 3.5 لديه أكبر مجتمع نماذج وأنماط مخصصة. كلاهما يعمل عبر ComfyUI أو Forge. دخول من 8 GB VRAM، مريح من 16 GB. HunyuanImage 3.0 من Tencent مفتوح المصدر. تحكم كامل، لا بيانات تغادر جهازك، الإعداد عليك.

كيف يتلاءم هذا على مشروع حقيقي

بعد زيارة الموقع، يحوي المجلد عادة صورًا، وملف العميل، والقياسات، والملاحظات، وأولى الفحوصات البصرية بالذكاء الاصطناعي.

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

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

نمط العمل عادة مختلط. افرز المجلد محليًا أولًا، حضّر ملخصًا مجهول الهوية، ثم أرسل فقط الجزء ذا الصلة إلى السحابة - بضع صور مختارة، سياق موجز، سؤال محدد. ليس "حلّل المشروع"، بل: "هذه صور لمنطقة السور ووصف قصير للقيود. لا تخترع مشروعًا. صف أي عناصر في الصور قد تؤثر على ممر مستقبلي وعلى الزراعة. أشِر بشكل منفصل إلى الأماكن التي لست متأكدًا منها."

الموقف العام: الذكاء الاصطناعي ليس مصدرًا لإجابات نهائية. هو أداة لمحادثة دقيقة مع المادة.

ما لا نتوقّع من الذكاء الاصطناعي أن يفعله

نموذج محلي ليس مصممًا.

نموذج رؤية ليس قياسًا. هو يخمّن الأبعاد، أحيانًا بثقة، أحيانًا بخطأ.

مولّد صور ليس وثيقة مشروع. ينتج فرضيات بصرية للنقاش، لا قرارات.

خدمة سحابية ليست تلقائيًا آمنة للمواد الخاصة. هي قرار واعٍ بشأن البيانات التي تغادر جهازك وتحت أي شروط.

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

الخلاصة

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

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

الدردشة على الويب جيدة. هي مجرد واحدة من أدوات كثيرة. باقي مجموعة الأدوات هو ما يصنع الفرق بين الذكاء الاصطناعي كمحرك بحث يردّ والذكاء الاصطناعي كجزء عامل من مشروع.

المصادر

مرجع النماذج والخدمات حتى مايو 2026: